Well, STOs themselves aren’t complicated. Standard stuff really. I’ve got a little class hierachy: base, transport and implementation. The abstraction means that Rick/Martini get to stay a step or two away from the evil that is teulKit, but I don’t have to write a new set of callback routines for each and every STO. It probably costs a little efficiency, but I’ve bought plenty of that :) And I’ve added plentiful hooks for monitoring these things.
First up will likely be smoke and mobile spawns. What’s that face for? Smoke is a good test of some fundamentals, lets us make smoke work somewhat better, and I hope eventually lets us add smoke to tanks. We want to increase the number of mobile spawns significantly, so we want to let you despawn your deployed MSP truck and have it replaced with an MSP object.
And once both those are working, they have natural follow-ons. As I’ve been writing the transport classes it’s been cool seeing how close the code is to what we need for a whole bunch of stuff.
The tricky part is integration to an existing, complex system. I was going to do this on the cell hosts. Seemingly the “right” place for it tho is probably on the map/mission host, but players transfer to/from that when they despawn/spawn, and I’ve not had sufficient opportunity to sit down and break that disconnection.
And ultimately I want to replace our current world “grid” system, edit: an overhaul for which the area chat system was actually a basis for. The current system is frighteningly over-complicated by the fact its design screams “write me in object-oriented C++”, but instead it was written in “no, we shall not use classes, even if you threaten to scare us! C”. It has complex, unexplained, lines of code like this:
FAST_POSITION fast; fast.x=((raw.X - FAST_OFFSET_X*100 + 87732) / 100) >>WIDTH_ADJUSTMENT_LEVEL; fast.y=(THEATRE_MAX_X*1600); if (fast.x > fast.y) .. some error about out of bounds .. fast.y=((raw.Y - FAST_OFFSET_Y*100 + THEATRE_MAX_Y)/100) >>WIDTH_ADJUSTMENT_LEVEL; fast.x=(THEATRE_MIN_Y*1600); if (fast.y > fast.x) .. some error about out of bounds ..
“WIDTH_ADJUSTMENT_LEVEL” is 4, so “>> 4” is a very fast integral “divide by 16”, some of the rest begins to make sense. That * 1600 is probably supposed to be divide by 1600.
After a while going through defines, looking at numbers, typing stuff into calc, I came to the conclusion this code doesn’t work. And lo. It’s called the same thing as the real function, its defined in three different files, but through the magic of compilation, it actually turns out that it uses a different function entirely:
// Convert from cm to 16m units x = raw.X / RAW_TO_GRID_RATIO ; y = raw.Y / RAW_TO_FAST_RATIO ; x -= GRID_X_OFFSET ; // Zero-based from left edge of map y -= GRID_Y_OFFSET ; // Zero-based from top edge of map // x and y are unsigned so if they go negative they become very large if ( fast.x > GRID_WIDTH || fast.y > GRID_HEIGHT ) .. error ..
The sharp eyed will notice something about the syntax of the second bit of code ;)
Where’d the shifting stuff go? Well, “>> 4” is a fast divide by 16. But since we’re dividing by 100 to get from cm to m anyway, we might as well go ahead and divide by 1600 which is what “(X / 100) >> 4” amounts to.
Well, for now I’m going to overcome the obstacle of surgery-on-the-old grid system by bypassing it entirely.
No, there isn’t going to be an separate, dedicated ordnance server, but there will be a server that handles ordnance.