Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Standarize player ship indexes #11

Open
IvanSanchez opened this issue Apr 27, 2015 · 3 comments
Open

Standarize player ship indexes #11

IvanSanchez opened this issue Apr 27, 2015 · 3 comments

Comments

@IvanSanchez
Copy link
Member

The player ship indexes have been bugging me for some time. In some packets (e.g. console status, setPlayerShipIndex) the field is 0-indexed; while in some other packets (player ship updates) is 1-indexed. So sometimes the player ship index goes 0-7 and sometimes 1-8.

Maybe it would be a good idea to standarize these into the same, by creating an offset integer datatype. _Maybe_.

@mrfishie
Copy link
Member

We could actually define an 'in-place' type so that we aren't cluttering the types file with ones that are only going to be used once.

For example:

... new struct({
        playerShipIndex: {
            pack: function(buffer, value) {
                type.int32.pack(buffer, value - 1);
            },
            unpack: function(buffer) {
                return type.int32.unpack(buffer) + 1;
            }
        }
    })

This could be used for other properties where we want to compute something dynamically.
Additionally, some way to process the fields object before the event is fired/before the buffer is sent (for example, added process and unprocess properties in some packet objects) could be useful for some packets where we want to do some extra processing on the packet before the application gets it.

@IvanSanchez
Copy link
Member Author

Additionally, some way to process the fields object before the event is fired/before the buffer is sent [...]

Yeah, that sounds exactly like middleware (like the stuff in express.js routers) and is not a completely bad idea. And this could be used to:

  • Fix up the player ship index
  • Cast/uncast some fields to Bool
  • Cast/uncast some fields to enum

There should be a way to create the asbs.Socket specifying which of these middlewares are wanted. Another idea I had in my mind is to create different sets of datatypes, so you could specify "I want to use the basic datatypes", "I want to use the basic and enum datatypes" or "I want to use the basic and Bool datatypes".

Right now I'm not sure which is the best way to implement this.

@mrfishie
Copy link
Member

Yeah, that would be useful for more complex packets, however I think we should ensure that most packets are able to be written without middleware (e.g. enums/bools as a type).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants