That’s better

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.

6 Comments

Cool stuff. I think anything that helps the CS&R accuracy & reliability will please a lot of people!
Well at stat ho’s at least. :-)

Oh and Happy New Year Oli. Hope it’s a great one for you.

I’ve always hated not seeing my CDT sorties, since they usually had my best kills on them.

Now if you could only speed up the process of merging the just ended campaign stats to the other existing stats, we stat ho’s would be really really happy. Going 3-4 days with out stats can be painful. ;)

I can only guess the hoops that must be jumped through for that.

runs off to check the web3 site for a link to grab player stats.

Sounds much better. Should also more easily enable the “Join in flight” scoring for all who come and go from a vehicle.

We’re transitioning to Continuous Integration stuff (Cruise Control since we’re a .NET shop) and it’s been a real blessing. A constant topic of conversation these days is “breaking the build”. It annoyed the heck out of me at first, but it really really changes your thinking when it comes to what you are going to check-in and when.

That plus unit testing have really altered the way I work these days in coding – the greatest things about tools like NUnit is that they are a fantastic time-saver for debugging – for me at least. It’s a lot quicker to deal with a couple of objects fired off from a quick Nunit test and trace through that then getting the whole project up and running.

Unfortunately too many coders think of debugging as some kind of admission of weakness.

A real genius programmer is the one who writes for when he gets called in on New Years Morning, hung over and ridden with flu. It’s nothing to do with debugging, he’s not gonna need that, its just pre-meditated laziness.

Leave a Reply

Name and email address are required. Your email address will not be published.

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

You may use these HTML tags and attributes:

<a href="" title="" rel=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <pre> <q cite=""> <s> <strike> <strong> 

%d bloggers like this: