(Topic got changed during writing; the dinner I ate isn’t settling well)
Worked from home today, since it seemed like most of the rest of the team weren’t going to be in today. I have a pretty decent setup at home, and I wanted to get cracking on some more OIC code rather.
Last week Gophur, Ramp and I sat down and talked out some of our qualms about the OIC system. We want it to be more of a merrit system rather than a human-managed system, but we don’t have time for 1.25 to develop let alone design the system we want, and it would be best done after I merge map/chat.
Based on our talk, the voting system I had wired into the OIC system was kinda moot. Instead we’re going with what you might call a vetoable-proposal system. When an officer – HC Staff or OIC – wants to take an action, it’s treated as a proposal, announcd to the other officers, and they have a window in which to veto it. As soon as someone vetos, its aborted.
For now the way a non-HC player will get OIC of a brigade is this:
. An HC staffer nominates them – they must be in the brigade to be nominated;
. If no-one vetos the nomination, its announced to the player and converted to an “offer”;
. They have a window (60-120s) to accept, otherwise it lapses;
. If they accept, they are bumped to OIC of the brigade and given access to the hc channel and most of the HC commands;
There’s probably another 1-2 days of work for me on the OIC stuff, and probably another day or two of work that we’ll be able to squeeze in to make it a little cooler; other than that once Ramp starts banging out the UI side of it, I should be clear to put together the TOE snippets I’ve accumulated over the last few weeks that’s getting close to being code-ready.
It’ll probably take me a day wandering around the strat system code to clear my head of all the chat stuff and re-find my little zen surgical strike plan for minimum impact introduction of TOEs into the supply system; I’ve sketched out most of the TOE code already as self contained classes, which means I can throw away lots of code and replace it to tie-ins to the classes.
I’ve gotten probably 50-70% of the docket system coded up in a mix of real and pseudo code, mostly real code. I’m throwing away a small amount of the strat system’s flexibility, but all its ever done for us is bend in the breeze, and make coding in strat harder. It may, however, give me a nice ability – to distinguish between equipment in the resupply queue that’s been destroyed vs equipment that’s there because its been spawned.
This would go a long way towards making it feasible to implement a rollback system for server outages. When people ask for rollbacks right now they don’t think it through: 20 minutes ago you hadn’t lost all your armor to the enemy, but you *had* spawned it. You really don’t want the enemy to get back the last 15 minutes worth of get you killed without getting back what you spawned 40 minutes ago to killed it…