Some actions are not reported to the clients

[CrazySpence]

-Afterburner -Invulnerability -Teleport collision (from server)

Afterburner: Since currently the server does not sanity check movement this function still "works" but it is not acceptable because the server Afterburner energy is never properly depleted or verified and I suppose could somehow be exploited client side

Invulnerability: The Server handles this power up and counts it down as expected and it keeps damage from counting but since the other clients are not informed they do not get the graphical representation of an invulnerable player

Teleport Collision: The server handles and moves the colliding player as expected, I have verified this by firing lasers while hitting the TP and the lasers fire at the destination position (as seen by another client watching) HOWEVER the ship does not appear with it, it is SLEPT/LERPED by the viewing client into position eventually, handles as if it were a lag jump of some kind

Possible solution:

A new type of RE for actions or events that the server has verified that is passed to the other clients via a multicast RE similar to how weaponstate works. The types of events could be handled by a small bitmask translated into something readable with #define such as

AFTERBURNER_ACTIVE 0x00001 AFTERBURNER_INACTIVE 0x00002 INVUNERABLE 0x00003 TP_COLLIDE 0x00004

And so on, an optional location matrix variable may be required for things such as teleport collisions so the client can move the teleported ship properly?

Discuss please

[uberlinuxguy]

Per @CrazySpence, we may not even need the position matrix. Pretty much all the action bits can be derived from the location of the originating player.

So far I have this:

// struct for general remote events.  KEEP THIS AS SMALL AS POSSIBLE!!!
struct RE_Generic : RE_Header{ //2
    word        RE_ActionFlags; //2
    dword       HostObjId; //4  - the object spawning the event
//  Xmatrx      ObjPos; //48 - probably don't need this, we'll see.
    dword       TargetId; //4 - can be used for targetting events
    dword       Padding; //4 - can be used for anything you desire.
}; //Size: 16 bytes

I left the ObjPosition in there because I am going to test some things without it and see if it works. Nice that it drops the size of the RE Entry to only 16 bytes. Most of the other RE's can probably be moved to this type, if we assume that direction and object location come from already known values slung around by RE_PlayerAndShipStatus (or whatever comes after)

Thoughts?

[uberlinuxguy]

So I just realized that RE_ActionFlags can be obsolete if we start a new set of RE_Types that are for Action or Event RE's only and do away with the RE_GENERIC type I was creating. That consolidates this to 14 bytes.

[CrazySpence]

Invulnerability detection fixed so I suppose this works in some manner?

[uberlinuxguy]

Hmm this reads as possibly fixed? Wow I totally don't remember any of that stuff... but there I am... doin' stuff. Might have to verify this is or isn't fixed.