FinalBuilder is the business. I haven’t completely won everyone over yet, but the coders have surprised me by all being onboard, especially Martini – then again he stands to gain the most from the addition of automated builds since we bleed out a huge amount of his time on building executables. But just building executables isn’t all its about: it’s just step 1 — you need executables to start doing anything else with.
The mmhost/cellhost work has been on hold for a little bit now – with all the map resets last year and the work to try and restore a saner pace, we lost some key development time there and the map/cell stuff ran into a fairly large obstacle that I won’t just hack my way around, which means I need more time to finish the whole thing.
So I’ve been handling small tickets that were outstanding, tidying up messy and loose ends – such as updating some of our tools to take command line arguments rather than operate with Freddy Kruger’s idea of AI, and integrating them with simple command line scripts; looking for SQL queries that weren’t asynchronous; etc.
I’ve been working around to clearing up the way we put kills/sorties/etc into the database – something which experienced significantly different constraints and environs when it was originally developed.
You won’t notice any advantage from this (well, maybe a couple of stats we weren’t recording before will show up in CSR, and I am tagging sorties with a “did you alt-f4” flag). It’s purely technical:
There are several components to a kill record. First, there is the “sortie” table, in which the details of a sortie is stored per crewman. So most sorties have one record – but – if the vehicle is multicrewed there is a sortie record for everyone on the vehicle. [BAD: Data replication en-masse!] I left this alone for now so as not to give Ramp (CSR) a seizure.
Because, in theory, the crew of vehicles can change in-flight, a kill is stored in two tables. One records the victim (although its called “wwii_vehicle”) and who was on-board (it also recorded a ton of stuff out of the sortie table because there was no single sortie record to join against to get it). The other records the killer (although its called “wwii_kill”) and who was on-board, and some other info for the same reason.
Actually, in both cases, they just recorded the list of people who spawned with the sortie … making them really rather redundant. There’s also no really good reason for them not to be a single table. I can’t believe whoever designed this split the killer & victim apart but didn’t split the sortie specifics from the sortie crew …
The process for getting data into these tables was hairy. First of all, the sortie only got saved after completion and – for reasons beyond me – that included after the kill/death records had been saved. And because each victim and killer record was assigned its own unique id, which was used to join them, they had to be added in order so that the ID of the one could be referenced from the other.
Since you can only die once, I cleaned this up radically by getting rid of the unique ID in the vehicle (victim) table and using the sortie id – it’s already unique. The killer is now also indexed by his sortie id plus a 5 digit unique-per-sortie “kill number” (MySQL lets you put auto-increment on a secondary field of a primary key to achieve this). I’d actually like to merge these two tables into one, but I’ll have to wait for Ramp’s OK on that.
With that done, I hit the code. Firstly, I made it so that every sortie gets written to the database as soon as the spawning process has been approved and the client departs the map host for the cell host. I added generous code to make sure that sorties don’t get left lying around when people CTD or CTHL while spawning.
The old system used to forward the sortie’s packet along with the kill/killer list to the map host, as the player despawned; the map host would fill in some fields and forward it to the strat host, the strat host would fill in more blanks and return it to the map host, which would fill in the final blanks and forward it to the “map dbse proxy” which would discover it had all kinds of data it didn’t need filled in but was missing some really crucial stuff, read it from the database (expensive) and write the final data to its 3 tables in a peculiar and dependency-heavy order.
Since sorties are now written early, and since the sortie ID now is or is-part-of the primary keys, I can simply pass the write to a stored procedure and let it worry about the rest. I do this through a pool of worker threads with database connections: they write the vehicle/kill entries and close the sortie record with the final data. The “elegant” touch is that it should now work correctly for the case where the pilot and crew of a multicrew vehicle despawn separately.
The underlying reason for doing this was fairly noddy. Ramp needs me to record the persona you were playing under during the sortie so that he can distinguish, say, airforce riflemen, for CSR.
Ramp is on vacation this week, I hope when he gets back he’ll be amenable to a final sweep cleaning up these records into a structure that actually makes sense – a single per-sortie record of what vehicle was used, where it spawned from, which brigade, etc, per-player record of time in-game, score, results, etc, and a single table recording kills (who killed, who got killed).
Would go a huge way to enabling a future scoring cleanup/rework.