AI War 2 v0.611 Released! "The Special Forces Have Arrived (Again)"

[keith.lamothe]

Release notes here!

This one had a lot of under-the-hood work to further the architecture goal of building the "Major" factions (human player, The AI) with mostly the same toolbox used for the "Minor" factions (Dyson, Devourer, Nanocaust, etc). This implicitly makes them all much more moddable and flexible.

But the result that stands out is that the Special Forces mechanic now stands out. Or rather, it used to be a mechanic, but now it's a faction in its own right. The main AI makes donations to the SF, but the SF decides what to build and where to go. As in AIWC it acts to defend the AI's planets against attack. Unlike AIWC, this behavior is more emergent (it should defend the AI against attacks from factions other than you, for instance) and is entirely moddable. If you want to make a SF sub-type that only builds long-range ships and only does sneaky drive-by attacks against the player, that can be done by modding. Or if you want a sub-type that only builds Etherjet Tractors and Widow Guardians and tries to tow the player's fleet to its destruction, that can be done too.

Enjoy!
Keith

[x4000]

I have to say, I really like this new modular approach to things like the special forces.  That was super clever.

[BadgerBadger]

I agree. Before you couldn't even tell whether the Special Forces was doing anything at all (and perhaps it wasn't). I think this release is a very useful step forward, both for Special Factions and for the lobby code.

Re: multiplayer. I'm happy to try to wrangle more machines to test on if you can tell me what additional debugging information you require. Or to try to reproduce the problem in other environments, etc etc, if given instructions.

On a somewhat more philosophical note, I'm not a fan of things allowing failures to happen silently like

Code: [Select]

            if ( target == null ) // this really shouldn't happen, but in case the implementing code is broken                             
                return;

Why not emit an actual error message to the log, so that if the code actually winds up broken then someone can open a bug against it? Or at least do something to register that there is an error for debugging purposes (spitting out errors every SimStep is probably not a great idea).  As written if the code is broken the Special Forces will just sit a round and not do anything, which is a much harder problem to diagnose.

Incidentally, I agree with the "I don't think this state can be hit" comment right now, but the concern is less for things breaking now and for someone (me? another modder?) who makes a dumb mistake modifying that function in the future.

[keith.lamothe]

Re: multiplayer. I'm happy to try to wrangle more machines to test on if you can tell me what additional debugging information you require. Or to try to reproduce the problem in other environments, etc etc, if given instructions.

MP is mainly a matter of me getting time to sit down, run some tests to find what's messing with it (is it trying to send too much over the network, is it bogging down the cpu processing the network messages, are we actually looking at desyncs, or is the timing logic just sitting around for a few extra frames instead of proceeding when it can, etc) and plug through it. There's not a lot you could do to diagnose that stuff since it's almost entirely in Core code.

And there's sorting out things like each player picking a starting planet, not stacking the Arks on top of each other if they pick the same planet (since we should probably allow that), and so on.

After that point, more specific testing would be good.

On a somewhat more philosophical note, I'm not a fan of things allowing failures to happen silently like

Code: [Select]

            if ( target == null ) // this really shouldn't happen, but in case the implementing code is broken                             
                return;


I entirely agree, that was a moment of my laziness that got copied over from Core to External with this release

That said, if you use the SpecialForces tracing (menu => system => debug => tracing => SpecialForces , and run tail -f ArcenDebugLog.txt or something like that) it would probably be evident where it was stopping. Having that branch add a trace message is probably sufficient.

[BadgerBadger]

For your consideration, a consolidation of map types.
MazeA-MazeD is now Maze with subtypes
Grid/Lattice/Crosshatch is now Grid with subtypes
Microcosm is now a subtype of Cluster and I tweaked the descriptions a bit.
The choices are Type of Clusters: Large/Medium/Small/Microcosm

[x4000]

Ooooh!  Wow, that makes things easier on players.

[keith.lamothe]

For your consideration, a consolidation of map types.
MazeA-MazeD is now Maze with subtypes
Grid/Lattice/Crosshatch is now Grid with subtypes
Microcosm is now a subtype of Cluster and I tweaked the descriptions a bit.
The choices are Type of Clusters: Large/Medium/Small/Microcosm

Thanks!

I may further combine Maze and G/L/C since they're all variations on Grid.

[BadgerBadger]

I feel like Maze and Grid maps play very differently so I kept them separate. You are welcome to do what you feel is right though, and it will be trivial to adapt my code to combine things in whatever way wish.

I feel like Special Forces and Dyson Sphere colours are too similar. You can tell the difference when they are next to eachother but it's not obvious the way you'd like it to be.

[keith.lamothe]

I feel like Maze and Grid maps play very differently so I kept them separate. You are welcome to do what you feel is right though, and it will be trivial to adapt my code to combine things in whatever way wish.

That's a good point; it's fine to leave it.

I feel like Special Forces and Dyson Sphere colours are too similar. You can tell the difference when they are next to eachother but it's not obvious the way you'd like it to be.

Yea, we need to put together a comprehensive (or at least long) list of sufficiently-distinct colors, as the current set has a lot of overlap.

[Draco18s]

Yea, we need to put together a comprehensive (or at least long) list of sufficiently-distinct colors, as the current set has a lot of overlap.

Hue variance of 15 degrees.

[keith.lamothe]

Yea, we need to put together a comprehensive (or at least long) list of sufficiently-distinct colors, as the current set has a lot of overlap.

Hue variance of 15 degrees.

I knew somebody here knew a lot more about color than I did.

I also suspected that person was a raptor.

[Draco18s]

I knew somebody here knew a lot more about color than I did.

I also suspected that person was a raptor.

I answered a question about this on stack overflow just the other day.
15 degrees is about as close as two colors can get and still be sufficiently distinct (when placed next to each other--in isolation it depends a little more: red and red-orange would be tricky, but red-orange and orange are fine). You can then do things with saturation and value for added variability.

[x4000]

What about saturation and value, though?  I'm also not really sure what a degree of hue is, since it's usually represented as 0-1 from my experience.  How would you translate the rule of 15 degrees into hex?

[Draco18s]

What about saturation and value, though?  I'm also not really sure what a degree of hue is, since it's usually represented as 0-1 from my experience.  How would you translate the rule of 15 degrees into hex?

15 dregrees of hue is about 0.05 on the 0-1 scale (specifically, 1/24).
Saturation and value you'd want to pick values from GIMP as a "these look good" and apply them to the list of hues. Generally I'd have 3 sets of numbers: (H,1,1), (H,y,1-y), and (H,1-y,y) where y is approximately 0.75. That would give you pure colors, a dark version, and a pale version.

Converting from hsv to rgb is easy enough, there is already code out there,  I've done it twice (once in Java, once in c#).

[x4000]

Cool.  And yep, we have an HSV to RGB converter directly in our ColorMath library that we set up, too.  I've done it twice as well, once in HLSL and once in C#.  Never in Javascript, tho.

I think the one in ColorMath is using tinyint style 0-255 definitions, Keith.  So simply having it loop through like this and do an export would work:

for ( int h = 0; h <= 255; h += 10 )
{
  normal = GetRGBFromHSV( h, 255, 255 );
  pale = GetRGBFromHSV( h, 180, 255 );
  dark = GetRGBFromHSV( h, 255, 180 );
}

And then I guess tacking on a few grays/whites:

white = GetRGBFromHSV( 0, 0, 255 );
gray = GetRGBFromHSV( 0, 0, 180 );
dark gray = GetRGBFromHSV( 0, 0, 90 );
black = GetRGBFromHSV( 0, 0, 0 );

And then we're done.  We'd need to export that to our xml file and then come up with friendly names for them (or not show names, either way), but that's about it.  Any modders want to take a crack at that pseudocode and save Keith the trouble?