Arcen Games

General Category => AI War II => Private Alpha Discussion => : BadgerBadger October 13, 2017, 09:49:53 PM

: Dyson Sphere tweaks
: BadgerBadger October 13, 2017, 09:49:53 PM
I'm playing an 8.6/8.6 game with an 8/10 Dyson Sphere game in my free time, and I'm reminded that one of the fun aspects of the Dyson Sphere was that until you aided it, the Dyson Sphere was being held off by its starting planet. But once you defeated the AI Guards of the planet it felt like it got stronger and started to help you more. There was basically no sense of the Dyson Sphere as a menace to you (except with the Antagonizer).

Now, right now the Dyson Sphere can just overwhelm half the galaxy. It continually spawns Mark V guardians, and it will readily destroy everything in its path (unless it's on a Mark IV world, in which case the defenses of the planet will just kill the sphere).

There's also a bug that causes the Dyson Sphere to periodically kill Planetary Controllers.

Keith (and everyone else), what sort of vision do people have for the Dyson Sphere? I really like the notion of a powerful human resource on the map that feels like it's restrained until you defeat a certain planet. Once you defeat that planet, it feels like it helps spread your influence, both by patrolling your planets and by sometimes attacking nearby foes. It feels like it plays very much as a human ally (except when the Dyson Antagonizer shows up, which adds a really fun achilles heal to the resource).

But I recognize that others may have other exciting ideas. I think it would be good to have a clear discussion of what is intended so we can start working on balance for the Dyson Sphere. I am currently tempted to try making the Sphere itself invulnerable to the AI and also make it spawn fleetships instead of guardians (we can make sure the fleetships go out in groups so they aren't always destroyed immediately), but I want to make sure I have some sense of the eventual gameplay intent so I don't waste time.

PS if the chosen ideas are too different from the Tradtional Dyson Sphere, I intend to reimplement the Traditional one and give it a new name. I really like it as a gameplay element.
: Re: Dyson Sphere tweaks
: keith.lamothe October 13, 2017, 09:54:23 PM
Yea, the current AIW2 implementation is functional, but not at all balanced.

I'll get to it eventually, but in the meantime if you or anyone else feels like adjusting it (in whatever way seems best; different spawn rates, different spawned entities, etc) to be closer to the 4/10 behavior on AIWC, I'm happy to incorporate that work. Then we can work on different intensities.

On the subject of faction intensities, I'm thinking in AIW2 it will be better to have custom fields like you implemented for map types. Most factions should be fine with a single scalar slider, but others may benefit from more than one axis of customization.
: Re: Dyson Sphere tweaks
: BadgerBadger October 13, 2017, 10:08:44 PM
I'll race you. If you can make Multiplayer functional and give us different sorts of AIs to choose between then before I finish a solid first pass at balancing the Dyson Sphere then I'll also take a first pass a Conduct that will give balance sliders for all the Factions. ;-)
: Re: Dyson Sphere tweaks
: Draco18s October 14, 2017, 01:03:25 AM
Get some baseline personalities in and I'll build some more. ;)
: Re: Dyson Sphere tweaks
: BadgerBadger October 16, 2017, 12:24:08 PM
Also, the Dyson Sphere really needs to have its collision radius tweaked, and ideally to be placed on the edge of the planet gravity well. I suspect this may require tweaking Mapgen_SeedSpecialEntities which is not in external code.

The ships the Dyson Sphere spawn appear inside the Dyson Sphere and can fly around in there. I zoomed in so that the camera wound up inside the Dyson Sphere (which is weird) and I can see the spawns. I don't know of a mechanism to change this in external code. I tried playing with a number of the XML fields to no avail.

Here is a picture (note that the Dyson Sphere is spawning fleetships instead of guardians, I was messing with the balance settings).
: Re: Dyson Sphere tweaks
: BadgerBadger October 16, 2017, 11:10:39 PM
I first wanted to get the Dyson Sphere to approximate the AIWC behaviour before I tried to really balance it.

Here's what I have for behaviour.

Dyson Sphere ships will stay on a planet set to "Attacker" until the Hostile Mobile strength on the planet is below Threshold. If a Dyson Sphere ship is on a planet where it's not in combat then it will Patrol for a certain amount of time (currently about a minute). Once it's done patrolling then the ship will pick a new planet to go to according to the following rules.

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).

If that doesn't happen (ie if there are no Friendly planets or there are friendly planets but we don't want to go to one of those), check if there are any adjacent planets whose enemy strength is below Threshold. If so, go to one of those Y% of the time (currently Y is 80).
If none of the above conditions are hit then pick a planet at random.

I feel like this will give a rough approximation of Dyson Sphere behaviour from AIWC. Still todo: implement Dyson Antagonizer behaviour. The above is implemented and does not crash, though I won't post it till I've also taken a stab at balance.


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 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;                                                                                 

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.
: Re: Dyson Sphere tweaks
: keith.lamothe October 17, 2017, 09:39:46 AM
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 :)
: Re: Dyson Sphere tweaks
: BadgerBadger October 17, 2017, 10:19:44 AM
The Dyson Sphere ships will defend adjacent planets that are planet.GetControllingFaction().GetIsFriendlyTowards(DysonSphereFaction)) from Hostile factions. So yeah, they will defend AI planets from humans if the Dyson Sphere is hostile to humans. I might consider making the "cry for help" radius larger on higher intensity levels, that might be fun.

I think trying to edit GameCommand objects and write my own is a bit tricky for me to figure out without greater insight into how they work (at the moment I only see how to use GameCommands to ship things between planets), so I'm going to ignore the problem for now. Incidentally, if we do get a "make ships wander around a planet" Behaviour then the Nanocaust would like to use that too. I don't really care how they move (in a big circle, a random walk, between all the wormholes), but it's boring when ships just sit still.

Is there a way to change the team_color of a faction in C#? I think it would be cool to change the Dyson Sphere ships color depending on whether it was hostile-to-all, hostile-to-human or hostile-to-AI. If I'm spawning them in the C# code then I could make a 'set this the right colour' call, I just would need to know the function to call. This is a low priority though.

This has given me a few ideas about how to implement Human Resistance Fighters or Human Marauders, but frankly at this stage I think new content should be avoided. It's gonna be hard enough to balance and polish what already exists.
: Re: Dyson Sphere tweaks
: keith.lamothe October 17, 2017, 10:59:46 AM
I think trying to edit GameCommand objects and write my own is a bit tricky for me to figure out without greater insight into how they work (at the moment I only see how to use GameCommands to ship things between planets)
Movement within a planet is simpler:

:
        public static void Helper_SendMoveCommand( GameEntity entity, ArcenPoint Destination, bool isQueuedCommand )
        {
            GameCommand command = GameCommand.Create( GameCommandType.Move );
            command.ToBeQueued = isQueuedCommand;
            command.RelatedPoint = Destination;
            command.RelatedEntityIDs.Add( entity.PrimaryKeyID );
            World_AIW2.Instance.QueueGameCommand( command, true );
        }

So if you have a list of points on the planet you want them to bounce around between, you can loop through the list and call that function (or just copy the body over and adapt it, as that function isn't intended as the one-place-you-can-send-move-commands-from-external), with entity=your-ship, isQueuedCommand=true-for-all-but-the-first-point, and destination=that-point.

It's not the best way to handle patrols, just mentioning it.

Is there a way to change the team_color of a faction in C#?
Not currently, but I've added Faction.ChangeColor(TeamColorDefinition) for next time. Bear in mind that the team color will need to already be defined in the xml.

This has given me a few ideas about how to implement Human Resistance Fighters or Human Marauders, but frankly at this stage I think new content should be avoided. It's gonna be hard enough to balance and polish what already exists.
Yea, extra factions isn't a current priority. But I know they're fun to work on, and modders who are having fun tend to be more helpful all around :)
: Re: Dyson Sphere tweaks
: BadgerBadger October 17, 2017, 11:16:25 AM
I tweaked the radius of the Dyson Sphere, but the ships still spawn right in the center of the structure, well inside the radius of the structure.

For moving the Dyson Sphere around with SetWorldLocation, is there a mechanism to make sure it doesn't wind up too close to any of the AI structures? Would I have to compute the location of all the AI structures then find a suitable spot?
: Re: Dyson Sphere tweaks
: keith.lamothe October 17, 2017, 11:34:01 AM
I tweaked the radius of the Dyson Sphere, but the ships still spawn right in the center of the structure, well inside the radius of the structure.
That's normal. Same thing happens when the Ark builds ships. The ships should fly out due to normal decollision logic, such that they are entirely outside the circle you see when mouseovering the unit, etc. Is that not happening?

For moving the Dyson Sphere around with SetWorldLocation, is there a mechanism to make sure it doesn't wind up too close to any of the AI structures? Would I have to compute the location of all the AI structures then find a suitable spot?
You can call this function on planet:

:
ArcenPoint GetSafePlacementPoint( ArcenSimContext Context, GameEntityTypeData EntityTypeToPlace, ArcenPoint BasePoint, int MinDistance, int MaxDistance )
So you could pass in CombatCenter as the BasePoint, and both MinDistance and MaxDistance to "ExternalConstants.Instance.Balance_AverageGravWellRadius * FInt.FromParts( 0, 850 )" or something like that. It probably needs to be far enough in that its sim-circle is entirely within the orbit ring, or strange things may happen.

Anyway, that function will try 100 times to get a point in the specified area that fits within the orbit ring and does not overlap with any unit or wormhole. If it fails after 100 tries it just returns the point 0,0 , which is way off in the middle of nowhere out of sight, so you can check for X==0 as a "just leave it where it is" condition, or try again with looser distance-from-center constraints, or whatever you like.
: Re: Dyson Sphere tweaks
: BadgerBadger October 17, 2017, 11:43:15 AM
The behaviour you describe is happening, but the Dyson Sphere visual is so large that it takes 5-10 seconds for ships to fly out and they are shooting the whole time. A ton of combat is happening with ships that are inside the Dyson Sphere visual, which is not desirable.  Sometimes tractor beams grab ships while they are still inside the Sphere Graphic.

Also ships will fly from outside the Dyson Sphere radius back into it. It seems like the collision check isn't working. Also also, if you set the radius to > 700 then the Dyson Sphere simply fails to spawn. 700 is still significantly smaller than the Dyson Sphere visual.
: Re: Dyson Sphere tweaks
: keith.lamothe October 17, 2017, 12:12:06 PM
Also ships will fly from outside the Dyson Sphere radius back into it. It seems like the collision check isn't working.
It only checks stationary things, which is why stuff can fly through other stuff in general. Collision checking that actually treats units as blocking other units from moving through them would basically break the game.

I think the problem is that the unit is just too big to look right as a unit. Either we need to make it small enough to look ok with the normal rules, or we need to adapt it into a planet graphic and have it not really be a unit at all (would no longer be something with a health bar or sim presence, etc, just its minions).
: Re: Dyson Sphere tweaks
: BadgerBadger October 17, 2017, 12:32:42 PM
I would love it as a planet graphic rather than as a unit.
: Re: Dyson Sphere tweaks
: Draco18s October 17, 2017, 01:41:19 PM
I would love it as a planet graphic rather than as a unit.
Oh, me too.
: Re: Dyson Sphere tweaks
: keith.lamothe October 17, 2017, 04:56:20 PM
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.
This statement naturally doomed any chance of it being released within 8 hours, so it's looking like tomorrow. But I do have AIType selection working now, as a custom field specific to the "AI" faction type, and an alternative AI type with an apt internal-name of "Annoying".

"So I hear you like bashing through ludicrous quantities of shields..."

This pattern would be followed by other faction-specific fields like intensity (for the dyson sphere) and starting alignment (for stuff like the neinzul roaming enclaves, if we wind up with an equivalent of those here: rather than having one faction produce 3 different alignments of units, you can add multiple factions of that type, each with different alignments, intensities, etc).
: Re: Dyson Sphere tweaks
: Draco18s October 17, 2017, 05:36:24 PM
Neat!
: Re: Dyson Sphere tweaks
: BadgerBadger October 17, 2017, 05:49:13 PM
So I think I figured out the GameCommand thing. So I can get a ship on a planet and queue up a few commands. But is there a mechanism to tell when there are no active move commands for a patrolling GameEntity so I can give it some additional commands? Otherwise I just have to queue up a very large number of commands and hope the ship doesn't run out before the code wants to send it to another planet.
: Re: Dyson Sphere tweaks
: BadgerBadger October 17, 2017, 11:23:12 PM
I found an adequate hack that involves setting the entity Behaviour to know whether I should send it on patrol, and resetting it on a regular basis to make sure a unit never runs out of things to do. It's not great or usable elsewhere in the code base, but it suffices.

This patch will very pleasantly update the Dyson Sphere behaviour. I also implemented how the Dyson Sphere can handle a DysonAntagonizer, though there is not an Antagonizer in the game yet. There are no current balance or XML changes, but I felt it was more important to get a foundation on which to build balance.

Patch submitted for review.
: Re: Dyson Sphere tweaks
: keith.lamothe October 18, 2017, 04:57:18 PM
To see if it still has points you can check its EntityOrderCollection for Orders.Count > 0, or check to see which orders those are, etc.

We'll eventually want to move logic of the kind you're talking about into behaviors, but I'm glad you've found a solution for the meantime :)

Still wrestling with the AI-types-in-the-lobby thing. Actually that part is working but now I'm trying to change how you add special factions (so their per-faction controls are handled similarly to the AI's) and I'm wrestling with some obscure UI bug that's making another dropdown not really respond to selection changes. UI debugging always takes forever, especially when I can't find any code that's actually getting called by the on-change event. Plenty of code that _should_ be executing, but none that is.

Screenshot attached of the current lobby state
: Re: Dyson Sphere tweaks
: BadgerBadger October 18, 2017, 05:28:07 PM
Human Remnant?! AI Sentinels?!?!

This release can't come soon enough!
: Re: Dyson Sphere tweaks
: keith.lamothe October 18, 2017, 09:02:56 PM
Human Remnant?! AI Sentinels?!?!

This release can't come soon enough!
Sorry for getting your hopes up, those are just the names I put in for the Human (i.e. player) faction and the AI faction :)
: Re: Dyson Sphere tweaks
: BadgerBadger October 18, 2017, 09:53:11 PM
You meant I should check EntityOrderCollection.QueuedOrders.Count, right? It doesn't seem to have an Orders field.
: Re: Dyson Sphere tweaks
: keith.lamothe October 18, 2017, 10:27:28 PM
You meant I should check EntityOrderCollection.QueuedOrders.Count, right? It doesn't seem to have an Orders field.
Yea, QueuedOrders.
: Re: Dyson Sphere tweaks
: BadgerBadger October 19, 2017, 12:01:36 AM
Okay great, the QueuedOrders check seems quite straightforward. Here's a version that uses that check instead. I also slightly modified the percentages for Dyson Ship movement and moved the tunings for that to be globals. Feel free to tweak those numbers. I don't intend any further changes for behaviour at this time. If you feel happy with things as they are then I'll start investigating balance. Otherwise, give me some feedback on how it can be improved! I hope I at least captured some of the spirit of the original Sphere.

Also, Dyson Ships will definitely sometimes destroy planetary controllers or warp gates. I'm not sure how to go about debugging that further, but I definitely observe it happening. It feels pretty random though. I've started the same game (same map, same seed) repeatedly and observed different behaviours. Some sort of race condition?

You guys probably want to bump the release up from the .500 series soon too. The game has come an incredible distance from .500 to where it is now and you should be proud of it!
: Re: Dyson Sphere tweaks
: keith.lamothe October 19, 2017, 10:16:27 AM
Okay great, the QueuedOrders check seems quite straightforward.
Glad it's working out.

By the way, if you're working with non-player-controlled units, and you're in the per-sim-step logic (not the long-range-planning logic), you can just do something like this:

:
entity.EntitySpecificOrders.ClearOrders();
entity.EntitySpecificOrders.QueueOrder( EntityOrder.Create_Move( somePointOnThisPlanet, false ));
// if multi-point path desired, make more calls to QueueOrder

I don't intend any further changes for behaviour at this time. If you feel happy with things as they are then I'll start investigating balance.
It sounds fine, I just need to finish my current wrestle-ui-into-submission match with the lobby stuff and get this release out before I spend time in that direction.

Also, Dyson Ships will definitely sometimes destroy planetary controllers or warp gates.
Odd. I'm assuming this happens with direct-target weapons, not just area-of-effect weapons? The don't-kill-it logic should apply to both, but it's somewhat different code paths.

You guys probably want to bump the release up from the .500 series soon too. The game has come an incredible distance from .500 to where it is now and you should be proud of it!
Not until the UI is made less visually awful :)
: Re: Dyson Sphere tweaks
: BadgerBadger October 24, 2017, 02:47:27 PM
Okay, here's a real first pass at things. All the tuning/balance should in theory be doable in the XML now (specifically ExternalConstants/Dyson_Constants.xml).
The primary difference with the previous pass are that the ship spawns are done in C# now. At the moment I think the Dyson Sphere is perhaps underpowered. It definitely should be incapable of freeing itself from the AI and wrecking havoc on the galaxy without human aid, but I think it could become a powerful ally. Unfortunately I don't have any saved games far enough in to check how powerful it will feel.

   
Here's how it works right now. The Dyson Sphere spawns ships with the BaseDysonSpawn tag.
The actual ship creation is done in C# so there's more fine-grained control over what's happening.
   
The Dyson sphere spawns ships at different rates depending on who owns the planet.
The Dyson Sphere spawns ships slowly when it's on an AI planet.
If the humans liberate the sphere then the Dyson Sphere will spawn faster to help against the AI.
If the humans capture the planets then the Sphere will spawn units very quickly to get rid of the humans.
The above spawn rates are tunable in the XML.
   
Sometimes the Dyson sphere will do a "Big Spawn", where it will spawn a bunch of ships instead of just 1.
The rate and size of these larger spawns is tunable in the XML.
   
Once a ship is created it will Patrol the planet it's on for a while; this time is tunable in the XML.
   
When the ship decides to move, it will examine its neighbors and choose where to go. The chance of moving to a given planet is tunable in the XML. If a "patrol friendly factions only" behaviour is desired, for example, then change the percentMoveFriendly to 100. Here is the algorithm for how it picks the planet to move to.

First, if the ship is next to a Friendly planet that is under attack, always go there.
Then check if it wants to go to a friendly planet.
If it doesn't want to go to a friendly planet, check if it wants to go to a Neutral planet.
If it doesn't want to go to a neutral planet, check if it wants to go to a weakly defended Hostile planet.
If it doesn't want to do that, pick a planet at random.

Note there are some changes in Nanocaust files because I track "Last time a ship was spawned" in ExternalData and use the same code for the Nanocaust. The nanocaust C# spawning code isn't sufficiently polished to hand over yet though.
: Re: Dyson Sphere tweaks
: BadgerBadger November 01, 2017, 12:00:31 PM
I observe that sometimes with my current code ships will get stuck trying to go through a wormhole to an AI planet. They just pile up on one side of the wormhole waiting to go through. Now, intriguingly, if I change the faction relationships to make the AI friends with the Dyson Sphere then the ships go through without a problem (it doesn't matter whether the Dyson Sphere likes the AI or not).

Does anyone have any clever ideas as to what's happening? The fact that everything works perfectly if I make the AI like the Dyson Sphere is really confusing.

Edit: Also, for Keith, if I have the Dyson Sphere only spawn single-target ships then they will not kill the controller. Area of effect damage (self destruction guardians, lightning guardians, etc) will take out the Planetary Controller even if it's not supposed to. I ran two experiments, one where I only spawned laser guardians and one with laser guardians and lightning guardians being spawned. When I spawned lightning guardians the planetary controller was killed even with GetShouldAttackNormallyExcludedTarget returning false always.
: Re: Dyson Sphere tweaks
: keith.lamothe November 01, 2017, 01:32:19 PM
I observe that sometimes with my current code ships will get stuck trying to go through a wormhole to an AI planet. They just pile up on one side of the wormhole waiting to go through. Now, intriguingly, if I change the faction relationships to make the AI friends with the Dyson Sphere then the ships go through without a problem (it doesn't matter whether the Dyson Sphere likes the AI or not).
That's probably the threat waiting behavior, same as when the AI has its ships pile up before going after you, rather than trickling them in like lambs to the slaughter.

I thought that logic was moved to the external library, but just checked and its still in core. Will move it out soon.


Thanks for the note about the AOE-killing-controller thing, I'll take a look.
: Re: Dyson Sphere tweaks
: BadgerBadger November 02, 2017, 11:32:50 PM
Okay, on .601 I think my previous code submission seems to work pretty well. Feel free to tweak the code or the XML, or to give me some feedback as to how you'd like it improved.
: Re: Dyson Sphere tweaks
: BadgerBadger November 03, 2017, 05:41:14 PM
Note I updated the tar file for the Dyson Sphere fixing a few bugs. It would crash sometimes when you started capturing planets near the Dyson Sphere,  it wasn't correctly detecting whether it was on a neutral planet, and there was a problem with routing the Dyson Sphere forces.

Also some additional debug logging code is included, all turned off by default.
: Re: Dyson Sphere tweaks
: keith.lamothe November 03, 2017, 09:22:46 PM
I've got the code incorporated, but the Dyson is afraid to compile unless I give it a stuffed teddy-bear named "BadgerFactionUtilityMethods". Any idea where I can find that?
: Re: Dyson Sphere tweaks
: BadgerBadger November 03, 2017, 10:37:19 PM
Whoops. I renamed NanocaustUtilityMethods in SpecialFactions/Nanocaust.cs to BadgerUtilityMethods.

Here's an updated version of the Nanocaust that includes that change.

Nota bene: For some reason the LongRangePlanning functions have stopped running. I put logging statements in them for multiple factions and they aren't being executed. That's very strange. The Devourer Golem is just sitting there looking hungry. This means that my code is not very well tested at the moment, but I expect it to be okay modulo some balance issues.

Here's a description of what the new Nanocaust code is doing. I moved the ship spawning code into C# where I have a lot more control over things, which is great for balance. Also the Nanocaust ships should be able to Patrol a planet (ie wander around the planet) which looks much better aesthetically than just sitting there.

Finally there's some visualization code to colour planet names appropriately. There are some problems with this. First, there seems to be a nasty race between the PerSimStep code in the nanocaust (where we figure out which planets are owned by the nanocaust) and the visualization code. Second, it is affected by https://bugtracker.arcengames.com/view.php?id=19257.  The visualization stuff is currently disabled (and will give an "unreachable code" error that can be ignored) due to these issues, but I give you the code anyway in case you see something obviously wrong with it.
: Re: Dyson Sphere tweaks
: Draco18s November 04, 2017, 09:17:35 AM
Whoops. I renamed NanocaustUtilityMethods in SpecialFactions/Nanocaust.cs to BadgerUtilityMethods. Just rename it, then so a search/replace through Nanocaust.cs to change NanocaustUtility to BadgerUtility.

Or use Visual Studio to do it for you. ;)
Badger: if you hold Ctrl and hit R twice that'll bring up VS's Refactor-Rename thingy. Just type a new identifier and hit enter, and VS changes every instance of that variable/class/whatever anywhere it's referenced.
(Although if you change a class name it doesn't change the file name, but if you rename the file it'll ask if you want to rename the class...)
: Re: Dyson Sphere tweaks
: BadgerBadger November 04, 2017, 09:44:00 AM
I don't use VS, I use emacs for code writing and reading the disassembled dll's so I know what functions exist ;-)
: Re: Dyson Sphere tweaks
: keith.lamothe November 04, 2017, 04:47:50 PM
Ok, got all your updates to the dyson code, and to your utility functions. Do you want me to include all the other changes in the updated nanocaust.tar ? You'd said previously that the new code wasn't ready yet so just wanted to make sure.

The LongRangePlanning thing was, I think, because I added default (mostly empty) implementations of that and other methods to SpecialFaction_Base and had the various factions inherit from that instead of just implementing ISpecialFactionImplementation directly. This didn't prevent you from declaring methods of the same name without the "override" keyword, but it made those not get called because as far as the interface was concerned, your parent class had already taken care of it.

Anyway, after I added override to that method it was getting called.

On the visualization race condition, bear in mind that the vis code and per-sim-step are not on the same thread, and so the vis code should avoid complex analyses of the gamestate. It could be changing at the same moment. For that reason I try to stick to objects that I know will be there (the planet list does not gain or lose members during the vis code, during the game) and to do atomic reads (checking an int field may return state that becomes stale before you use it, but it won't throw an exception, whereas looping over a potentially-changing list can lead to bounds exceptions).

I don't know exactly how you were checking your nanocaust state in there, but it needn't be fundamentally more complex than checking a bool or int on a Planet object, because you can store it in the external data. That said, having a concept of "Faction X has influence over planet Y, despite not owning the controller" is broadly useful, so I've added it. As an example when 0.602 is out, see how the Dyson claims influence over its home planet (there's no code for de-influencing it if the dyson somehow dies, that would need to be handled manually somehow). And notice how the display code sees that influence and uses the Dyson's color instead of the controller's color.
: Re: Dyson Sphere tweaks
: BadgerBadger November 04, 2017, 04:56:46 PM
Hmmm. Yeah, you're right about being able to just attach a bool to a Planet. I shall rethink my approach.

I feel confident with the principles of what I did for t he Nanocaust, I just didn't get a chance to test it. If you'd be willing to turn a game on with the Nanocaust and watch it conquer one planet (this will take about 3 minutes, which you can fast forward) and make sure nothing seems to look bad, go ahead and push it. If not then I'll test things myself, make any appropriate changes and submit a new patch tomorrow or monday.
: Re: Dyson Sphere tweaks
: BadgerBadger November 04, 2017, 07:56:56 PM
Erm. I think I mispoke. I meant to say "Push everything else but the Nanocaust changes if you don't want to test them for yourself." I can't test them right now due to the Tutorial AI bug, so I need the fix for that before I can test the Nanocaust fix for myself.
: Re: Dyson Sphere tweaks
: keith.lamothe November 06, 2017, 08:46:34 AM
FYI, when you write something like

:
for(int j = 0; j < 10; i++)
It runs for a very long time ;)

Thankfully in this case (in patrolPlanet() ) you had something that added to a list in that loop, so instead of just making the long-term-planning thread silently take forever (I should put in checks to detect abnormally long executions) it causes an out-of-memory exception.

This is one of the better arguments for having the compiler recognize the ruby-like pattern "10.times { doSomething(); }". "cross-threading" a loop like this is one of my more common errors, and I doubt we're alone.

: Re: Dyson Sphere tweaks
: BadgerBadger November 06, 2017, 08:53:34 AM
Whoopsies! I actually almost never make that mistake, but in this case I think I had to change the variable name from i to j and missed changing the last element of the list. Thanks for catching it.
: Re: Dyson Sphere tweaks
: keith.lamothe November 06, 2017, 09:11:24 AM
That was the only error that was evident; the nanocaust dutifully captured a planet and buzzed around like bored teenagers in sports cars. So all that's incorporated for 0.602. Not the galaxy-map-display stuff, as there's a different way to do what you want now.
: Re: Dyson Sphere tweaks
: Draco18s November 06, 2017, 09:34:46 AM
FYI, when you write something like

:
for(int j = 0; j < 10; i++)
It runs for a very long time ;)

I mean, you could always use var ? = 0 instead.
? != i
https://en.wikipedia.org/wiki/Homoglyph

Edit, boo, the forum did not like that character. BOO.
: Re: Dyson Sphere tweaks
: keith.lamothe November 06, 2017, 10:04:28 AM
I mean, you could always use var ? = 0 instead.

Edit, boo, the forum did not like that character. BOO.
For a moment I was thinking "wow, I know 'var' is there when you can't be arsed to declare a type, but I didn't know they had '?' for when you can't be arsed to declare a name".
: Re: Dyson Sphere tweaks
: Draco18s November 06, 2017, 06:11:44 PM
For a moment I was thinking "wow, I know 'var' is there when you can't be arsed to declare a type, but I didn't know they had '?' for when you can't be arsed to declare a name".

Tee hee.
It does read like that. But nah, the character I tried to use was one that looks just like 'i' but isn't.
: Re: Dyson Sphere tweaks
: Toranth November 07, 2017, 08:08:17 PM
I mean, you could always use var ? = 0 instead.

Edit, boo, the forum did not like that character. BOO.
For a moment I was thinking "wow, I know 'var' is there when you can't be arsed to declare a type, but I didn't know they had '?' for when you can't be arsed to declare a name".
Nah, that's for the PowerShell version of C#, where $_ basically means "whatever is currently important".
: Re: Dyson Sphere tweaks
: BadgerBadger December 16, 2017, 08:26:24 PM
Idea for further tuning Dyson Intensity.

Idea 1. At the moment the Dyson only spawns Laser, Needler and MLRS Mark II guardians. I propose to tweak the Dyson Sphere to change the ships it makes based on the intensity.

For Lower intensity, the Dyson Sphere spawns Mark 1 Guardians or Fleetships. For Medium intensity the Dyson keeps its old behaviour. For higher intensity the Dyson spawns a greater variety of ships. 

I would do this by using a DysonSphereIntensityX tag in GameEntity, then having the Dyson Spawning code make ship choices based on the current intensity.

Idea 2

I would really love to have a Dyson Antagonizer at higher intensities, but the obvious way to do so (aka "Whenever a Dyson Antagonizer is present, the Dyson Sphere will be hostile to humans and try to kill them") fails because all the current Dyson ships would all turn against humanity instantly. So if the Dyson were on all your planets you'd just die immediately."

One possibility would be to implement an "Antagonized Dyson Sphere" faction that would be quiescent until the Antagonizer was built. Once the Antagonizer existed then we would replace the DysonSphere with an AntagonizedDysonSphere (defined seperately in the XML), and it would start producing Antagonized Ships to go after humanity. Once the Antagonizer was killed we would replace the AntagonizedSphere with the regular Sphere, and the Antagonized faction would stop making ships (though it's current ships would remain active).

Opinion?
: Re: Dyson Sphere tweaks
: keith.lamothe December 16, 2017, 09:39:51 PM
Sounds fine on the intensity => guardian-type mapping.

Good general idea on the antagonizer, but you can simplify it a bit: when the antagonizer is on, switch the sphere itself to the antagonized-dyson faction (PlanetFaction.SwitchToFaction(entity,otherFaction) or something like that), but don't do anything to the things already spawned, so they remain in the normal dyson faction. That should be all you need to do, though it may be that the normal faction code will need a small adjustment to handle the "dude, where's my dyson-sphere?" case.

The antagonized dyson faction could just be a subclass of the normal one, implementation wise, so you need very little code.
: Re: Dyson Sphere tweaks
: Draco18s December 16, 2017, 11:36:02 PM
I might suggest switching the sphere and any Dyson units on the same planet just so they don't start fighting themselves immediately.
: Re: Dyson Sphere tweaks
: BadgerBadger December 17, 2017, 12:10:01 AM
In AIWC you got immediate combat between the newly spawned Antagonized units and the non-Antagonized ships; I feel like this is actually useful since it makes it really clear that the newly antagonized ships are your foes. I'm willing to be persuaded otherwise though.