Dyson Sphere tweaks

[BadgerBadger]

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.

[keith.lamothe]

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?

[BadgerBadger]

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.

[Draco18s]

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

[BadgerBadger]

I don't use VS, I use emacs for code writing and reading the disassembled dll's so I know what functions exist ;-)

[keith.lamothe]

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.

[BadgerBadger]

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.

[BadgerBadger]

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.

[keith.lamothe]

FYI, when you write something like

Code: [Select]

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.

[BadgerBadger]

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.

[keith.lamothe]

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.

[Draco18s]

FYI, when you write something like

Code: [Select]

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

I mean, you could always use var ? = 0 instead.

Spoiler for Hiden:

? != i
https://en.wikipedia.org/wiki/Homoglyph

Edit, boo, the forum did not like that character. BOO.

[keith.lamothe]

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

[Draco18s]

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.

[Toranth]

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