I’m trying to refactor a delicate heap of code. Heap. Pile. Cesspool. Call it what you will. Its part of my TOE work.
So far its taken me two days and several restarts, to hack my way thru the weeds of poor nomenclature to discover that what I was dealing with was a very simple state engine that is driven by a modest little text file (.csv) interpreter.
The driver is actually very generic, but it clearly grew out of a specific use case, and the individual handlers have been copied and pasted, derived and adapted – some of the names are generic and some seem to be very specific. “count” turns out to be the field containg any general numeric value; when it was first used, the only numeric value was a counter.
It also suffers from opaque specialization – values passed as arguments to a function in some other file combined with hard-coded constants somewhere else combine to decide which columns will be in named fields while other columns somehow end up in an array called “values”. Some of these will be strings stored as values[n].tvalue, some will be integers stored as values[n].dvalue, and so on. You know which is which because you specify some of them and the engine works out the others for you.
The particular data being manipulated is the vehicle list. Did I say list? I mean’t lists. There are at least 110, each highly specialized. And of course, with so many specialized lists, you need lists and structures to help you map between them.
What makes something like this take forever, however, is unwinding all the code that is there purely to make the code work. For instance, when I removed 2 of the lists, 24 other lists generated “unreferenced” warnings – they had existed purely to associate the first two lists, which neither the client nor host ever used.
I can see why it got convoluted: originally there was just the list of vehicles. Then it dawned on someone that you would have to limit different vehicles to different spawners — aircraft to airfields, for instance. So in addition, vehicles are organized into categories and categories can be attached to spawners and a spawnlist thus implied – the alternative being you would have to have a complete custom spawnlist for every facility on the map.
Which, infact, we do.
When I’ve gotten all this working, my next step is to approach these per-facility spawn lists; they exist because facilities had their own supplies. Now that they don’t, these lists can be simplified down to a list of actual spawner objects, and the spawn system can use the generic rules to eliminate vehicles that can’t be spawned — e.g. a Z34 destroyer can’t spawn from a riverine docks facility.
Then its time to try grafting & adapting the TOE code I’d developed into that codebase. I’m fairly sure that some of these weapon lists are to blame for the crashes I was getting with the development codebase. There were some very, very dubious string operations and some mallocs where perhaps callocs were intended…