If there are any Friendly planets (ie a planet owned by a Friendly faction) under attack adjacent to this planet then always go to one of the planets being attacked. If there are no Friendly planets under attack, go to a random friendly planet X% of the time (currently X is 80).
Does this work regardless of the Dyson's alignment? I.e. it will move to defend an AI planet that you are attacking, if it is friendly to the AI at the time? If so, awesome
I'm not sure that it would be a real case under the rules as they stand (Dyson is only AI-ally if you own the Dyson's planet, so most of its stuff would be focused on freeing itself) but it's a good sort of emergent behavior.
Still todo: implement Dyson Antagonizer behaviour.
I wouldn't worry about that for now.
A few additional questions. For being able to tune faction intensity, should I look to add an Intensity factor in External Code attached to a Faction? Or would it make more sense to have that be part of the Faction class itself? This is a code architecture question so I leave it to you, either way is fine by me.
I'm currently working on the architecture for faction-specific per-faction settings like AIType, and intensity would go there too. I hope to have it released within 8 hours.
I have trouble with getting the patrol behaviour I want. I don't see a good mechanism for telling a ship to "wander around a planet". I tried the following with both Guardians and Fleetships but it doesn't seem to work.
entity.EntitySpecificOrders.Behavior = EntityBehaviorType.Guard_Guardian_Patrolling;
Right now there may be no EntityBehaviorType setting that does what you want. There are two general solutions to that:
1) Add more EntityBehaviorType possibilities. Maybe even move EntityBehaviorType from a hardcoded enum in Core to an xml-table in External. I think the latter is ultimately the way of the future.
2) For anything not human-controlled, you don't strictly need behaviors, you can just issue orders (GameCommand objects) from the long-term-planning thread or directly modify the state (including orders) of the units in PerSimStep. That said, behaviors are preferable as they tend more towards emergent behavior, which leads to more !!fun!!
Finally, would you prefer factions to use the buildingDronesInternally functionality or to spawn units directly in the C# code? Either one will work (though using buildingDronesInternally may require multiple XML entries for Dyson Spheres at different Intensity levels). Or some combination could be done.
If the desired behavior is constant (like a Carrier Starship) and fits within the XML definition, put it there. If it doesn't fit, or it changes during the game in ways that can't be readily expressed in the XML, feel free to do it directly in code (obeying all the usual sync rules, etc).
I'm guessing that the Dyson's construction rate will vary by more than just the picked-in-the-lobby settings (the antagonizer, for instance, or balance calling for a human-ally dyson to spawn at a different rate than a neutral one, etc), so I'd just put that in code.
But perhaps some of the Dyson minions, if custom ones of those are ever defined, could use the carrier-starship pattern for their own stuff. That way you don't have to have blocks of code just for them too.
In general the xml is less work, and produces more consistent behavior, so if we find ourselves doing this sort of dynamic-scale spawning all over the place we may want to extend the xml schema to feed off a new per-entity variable that can be changed at will in code. But it's not clear that this would satisfy all the requirements.
On the dyson size, change its "radius" value in the xml. On its placement I'll try to make that function give you more control over the per-planet placement in the release after this one. For the time being, after that function call, you could just find the dyson by tag (or just the only unit in the faction) and call SetWorldLocation to some point further away.
Overall great progress, thanks