Player leaves no free MaskBits - LOGGED

#1 Its not really a bug... but it is very frustrating and inconvenient.

In the upcoming beta release we've removed a few old unused mask bits in ShapeBase and Player which will help, but longer term we just won't be building gameplay objects with deep class hierarchies like Player, Vehicle, etc.

I would suggest removing or reusing existing maskbits by deciding what parts of ShapeBase and Player you need for your game.

#2 How about using 64 bits if the pack/unpack update route is really the way to go?

For now, I'm using NetEvents for all c/s msg passing, which probably is inefficient

#3 You're even out of bits in Camera. This mask bits thing needs some rethinking.

#4 Do all engines still use this sort of approach for networking? I remember Quake 3 did, which was around the same time as Tribes 2.

Is there a new way to do this? Or is this still the norm?

#5 Less data is better, but I suppose you could inherit from any of your networked classes that you need to use and add a data carrier mechanism of your own. Torque's network infrastructure is pretty darn fast and to me that leaves room to burn a little more bandwidth if you like - on the downside you'll be reducing the maximum number of players who can be logged in simultaneously to an given server....

#6 The devs have been talking about removing the hierarchy as we know it for a while now, and it sounds like a good idea in theory, though I don't know how much I like the idea of losing the ShapeBase-style "every game object has a common base" design I've relied on for so much of my code. Still, this system has proven to be as much of a problem as it is an advantage. Maybe I just don't like having to change my code. ;)

Games these days may be less picky about when they send network updates, but then very few of them would support more than 32 players in a game (Torque has been known to support 128+ if I'm not mistaken). I'd say you could get more wins than losses from turning the mask into a 64-bit value assuming you intend to efficiently use all of those new mask bits. You'll add 32 bits to every network exchange, but if the result is that you more efficiently control when to send larger chunks of data in control client streams and update packets, it should improve networking overall. For the best results, you could add the extra 32 bits to only the ShapeBase or Player class itself, though that implies adding a whole new layer of mask control you'll need to write yourself.

That said, if the data you want to regulate totals less than 32 bits per packet, you'd actually do better just streaming that data in every packet with no mask at all, or at least all under 1 umbrella mask. This is unlikely, but I thought it was worth mentioning.

As a short fix, as Tom pointed out there are a number of basically unused masks sitting around. In ShapeBase.h, search for enum ShapeBaseMasks and you'll see a few obvious choices for removal: CloakMask, ShieldMask, InvincibleMask. These masks were specifically part of Tribes 2 I believe. While they may have some functionality (I believe InvincibleMask may actually be part of a working timed invincibility sytem), there's a good chance you're not using the things they're connected to.

#7 Logged Key: TQA-180

#8 Invincibility seems pretty useless / way too genre or debug specific. Perhaps that could be torn out to make room.