1. Hey! Guest! The 35th GMC Jam will take place between November 28th, 12:00 UTC - December 2nd, 12:00 UTC. Why not join in! Click here to find out more!
    Dismiss Notice

GM:S 1.4 about "buffer" types

Discussion in 'Programming' started by Turkish Coffee, Sep 1, 2017.

  1. Turkish Coffee

    Turkish Coffee Member

    Joined:
    Nov 25, 2016
    Posts:
    559
    Hey,

    I'm reading through the Networking stuff and I just wanted to know whats the difference between the buffer types (buffer_u8, buffer_s8, buffer_u16...)

    For example, I'm making an online RTS and I want to create a unit. For that, I need to send a package with coordinates and the object type thats going to be spawned right? So which type of buffer should I use for these?
     
  2. Simon Gust

    Simon Gust Member

    Joined:
    Nov 15, 2016
    Posts:
    3,199
    Depends on how big the number is.
    u8: 0 - 255
    s8: -128 - 127
    u16: 0 - 65535
    s16: -32768 - 32767
    ...
     
    Turkish Coffee likes this.
  3. Turkish Coffee

    Turkish Coffee Member

    Joined:
    Nov 25, 2016
    Posts:
    559
    Okay, for the object names?
     
  4. Simon Gust

    Simon Gust Member

    Joined:
    Nov 15, 2016
    Posts:
    3,199
    Object names are resource names starting at 0. So the first resource object in your resource tree has an object_index of 0.
    u8 is probably fine.

    Instances have id numbers starting at 100000 or something.
     
  5. flyingsaucerinvasion

    flyingsaucerinvasion Member

    Joined:
    Jun 20, 2016
    Posts:
    2,187
    i wouldn't be transmitting things like instance ids from one machine to another... the ids may not correspond at all. Instead, make your own id number, you can be 100% positive that they will correspond. For example, the server can choose a new id number when creating an instance, then transmit a command to the clients indicating to create a new instance and to give it that id. I would be weary of using transmitting object indexes to identify an object type, because it seems to me that there is a remote possibility that objects might be ordered differently on different machines. So, I would use macros or enums.

    When you talk about object names, what do you mean? Is each instance have a unique name? In that case you will need a string. If they have predetermined names, you don't need to transmit the name at all since it can be determined at the other end of the network.
     
    andev likes this.
  6. Turkish Coffee

    Turkish Coffee Member

    Joined:
    Nov 25, 2016
    Posts:
    559
    With "object names", I meant that for example a player selects an unit and has enough resources to build it, and he starts to build it, when the building is complete and the object will get created, I need that object's name -for example oTank- to spawn it on the server then sync in all clients. I'm asking that how can I say to the server to get the object's name thats going to be created. I'm sorry for the confusing sentences btw.
     
    Last edited: Sep 1, 2017
  7. Simon Gust

    Simon Gust Member

    Joined:
    Nov 15, 2016
    Posts:
    3,199
    if you send the name of the object resource it is the object index.
    ->
    object_index of oTank is oTank
    object_index of oWhatever is oWhatever.
    And it's going to be the same for all clients, no matter if they have or do not have that object.
    You should not send a string of the actual name, that would require an asset_get_index which is slow and redundant.
     
    Turkish Coffee likes this.
  8. CMAllen

    CMAllen Member

    Joined:
    Mar 2, 2017
    Posts:
    856
    Yup. It's better to set up an array or a ds_list that contains all the necessary referencing values. Then it's only a byte or two worth of transmitted data to achieve the same effect. Also, you assume complete control of your references, meaning you can be assured of 100% uniformity between platforms and systems.
     
    Turkish Coffee likes this.

Share This Page

  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.
    Dismiss Notice