AI War 2 v0.515 Released! "The Settings Menu Of Doom"

[keith.lamothe]

Release notes here!

I never expected something like "A Settings Menu" to take a whole week, but here we are. And in retrospect it makes a degree of sense: this is just a huge chunk of engine that we hadn't written yet. The settings themselves were all there and working, but we had to:

1) Pull them out into moddable xml, so modders can define their own settings that persist across save/load.
2) Extend our UI framework with a way of defining UI controls that's reasonable for this kind of variably-sized table where the rows have different types of controls (toggle settings need different input elements than a slider setting or a dropdown-choice setting, etc).
3) While we were at it, add sliders to our UI framework. Both for scrolling the menu itself, and for the slider-based settings.
4) Get those maddening floating tooltips to draw _over_ everything else, rather than under some things. They have to be drawn on an entirely different _canvas_ for this to work. Nothing else we tried would do.
5) Actually code the window, test, and debug some "interesting" issues. Notably what happens when all the settings somehow get initialized to zero instead of their defined defaults or even their defined "minimum" values, and when this doesn't happen at all until a user is testing with their steam copy (sorry, Badger!).

And more. The menu is still in fairly rough shape; it needs a background and border, and it needs some kind of tabs or other sub-categorization so you're not scrolling endlessly, and so on. But it functions, and here it is

Enjoy!
Keith

[chemical_art]

Hi Keith, I am really happy to see all this UI work going into AIW2. As you said, it can be rough, but if it works then that is what matters. I hope the works continues. Once the UI work is done then there can be an audience that can help with polish (myself included).

[keith.lamothe]

Hi Keith, I am really happy to see all this UI work going into AIW2. As you said, it can be rough, but if it works then that is what matters. I hope the works continues. Once the UI work is done then there can be an audience that can help with polish (myself included).

Thanks I agree.

Overall we've been hit pretty hard by how much engine work we'd wind up doing in this new approach. There's a lot we took for granted in AIWC's engine, with all the years of work that went into it.

At the same time, AIWC's engine made it very hard to deal with some longstanding issues (hence them becoming longstanding), and UI flexibility is certainly one of them. With the sequel we're already to the point where someone with modest programming experience can go from a fresh steam install to a working mod for (for example) "what numbers does it show me for metal" in like 5-10 minutes.

Another key piece of that flexibility missing in classic was the ability to scale the UI, which I hope to add soon. I was about to add it and realized that it would be yet-another-setting-you-have-to-hand-edit-in-the-xml, so it was time to bite the settings-menu bullet.

[BadgerBadger]

You know what would be handy? A "reset to default settings" button. Edit: I got bored. See attached copy of Window_SettingsMenu.cs. Click the "Set Defaults" button to change the "current" values to the defaults. You then have to click "Save" to apply the changes.

[BadgerBadger]

Also, when you change the screen settings it doesn't actually change the size of the window, it changes the resolution the game is shown at inside the game window. I don't think there's currently a mechanism to change the size of the AI War 2 window at all, except to full screen (and full screen has issues).

[keith.lamothe]

Also, when you change the screen settings it doesn't actually change the size of the window, it changes the resolution the game is shown at inside the game window.

Weird, I can't reproduce that locally either in my dev copy or my steam copy. I change it from 1024 wide to 1400 wide and hit save and the window gets wider.

It could be an issue specific to Linux, which would be just lovely.


On another note, I'm integrating your updates before making 0.516 live. I see:

Nanocaust - https://forums.arcengames.com/ai-war-ii-modding/the-nanocaust/msg216000/#msg216000
Find Planet - https://forums.arcengames.com/private-alpha-discussion/proposed-'find-planet'-screen/msg215906/#msg215906
Galaxy Display Modes - https://forums.arcengames.com/private-alpha-discussion/proposed-'find-planet'-screen/msg215982/#msg215982
and of course the Settings Default button - https://forums.arcengames.com/ai-war-ii/ai-war-2-v0-515-released!-'the-settings-menu-of-doom'/msg216070/#msg216070

Anything else?

For the ones with multiple files, could I impose upon you to submit those as archives (one per feature is fine, or all together is fine) where I can just unzip them into the game directory and they'll be placed in the right position? For instance with the nanocaust that's a lot of different config directories to put stuff in. Even for the single-file ones that structure would be helpful. I realize I'm being terribly lazy But it also helps avoid mistakes on my part, as a misplaced config file might or might not cause any immediately obvious problems.

Thanks very much for that work, and for the testing

[BadgerBadger]

Sure, I'm happy to submit packages in whatever format is desired going forward. This new nanocaust.tar should be what you are looking for.

A quick glance through my sandbox has the following extra code you might want.
Adding this code to MapGeneration.cs will cause a Starship Constructor to be added to your starting planet when you say "Start With First Planet." I find this handy, since if I don't want it I can just cancel it later and building a starship constructor takes a couple minutes.

Code: [Select]

                                             GameEntity.CreateNew( side, controllerData, controllerPoint, Context );
                                             haveCreatedController = true;
 
+                                            GameEntityTypeData starshipConstructorData = GameEntityTypeDataTable.Instance.GetRowByName( "StarshipConstructor", true, null );
+                                            ArcenPoint starshipConstructorPoint = center.GetPointAtAngleAndDistance( angleToAI, Context.QualityRandom.Next( innerSystemMinimumRadius, innerSystemMaximumRadius ) );
+                                            GameEntity.CreateNew( side, starshipConstructorData, starshipConstructorPoint, Context );
                                             if ( controllerData.PlanetsWorthOfAIPOnDeath != 0 )
                                                 World_AIW2.Instance.ChangeAIP( controllerData.PlanetsWorthOfAIPOnDeath * ExternalConstants.Instance.Balance_BaseAIPScale, AIPChangeReason.EntityDeath, controllerData, Context );

I am attaching code for adding support for "Strength" to be shown along with "number of ships" and "number of squads" in the sidebar. To support the added Strength field, please update KDL_UIWindows as follows (I'm not going to attach KDL_UIWindows since that has some other changes)

Code: [Select]

-    <element prefab_lookup_name="BasicText" width="20" height="3.5" type_name="tEnemySummary" />
-    <element prefab_lookup_name="BasicText" width="20" height="3.5" type_name="tPlayerSummary" />
-    <element prefab_lookup_name="BasicText" width="20" height="3.5" type_name="tAllySummary" />
+    <element prefab_lookup_name="BasicText" width="30" height="3.5" type_name="tEnemySummary" />
+    <element prefab_lookup_name="BasicText" width="30" height="3.5" type_name="tPlayerSummary" />
+    <element prefab_lookup_name="BasicText" width="30" height="3.5" type_name="tAllySummary" />

I also have code for making the metal data more readable, but that is a bit more hacky and requires some other tweaks (like moving the Hide GUI button) that I'm not sure are ideal for actual inclusion in the game.

Finally there are also the extra map types, but please hold off on those until I get around to using the new UI code to let players tune their maps in the Game Selection Screen

[BadgerBadger]

Also, it would appear that I failed to understand that modifying the "Fullscreen Resolution" field would not change my current window size. http://buttersafe.com/2008/10/23/the-detour/

Please ignore that complaint.

[keith.lamothe]

Also, it would appear that I failed to understand that modifying the "Fullscreen Resolution" field would not change my current window size. http://buttersafe.com/2008/10/23/the-detour/

Please ignore that complaint.

Yea, it's a weird thing but AIWC worked that way too. There's no reason I can't unify the fields, but it may cause undesirable behavior when changing to fullscreen erases the memory of your last windowed size, and vice versa.

Alternatively the controls could be unified so that there's no "use fullscreen" toggle, and instead the fullscreen dropdown has a "windowed" option. So if the dropdown is set to non-windowed it just uses the dropdown option, and if it's set to windowed it uses the two textboxes for that.

More important than that is finding out why switching to fullscreen mid-run does strange and wonderful things (more strange than wonderful) to the display.

[keith.lamothe]

The strength thing is a good idea. I made some refinements that are worth noting so you know why some of those circular saws do what they do:

Code: [Select]

            int squadResult = 0;
            FInt strength = FInt.Zero;
            localSide.DoForRelatedSides( relationship, delegate ( CombatSide side )
            {
                if ( relationship == SideRelationship.SidesIAmFriendlyTowards && side == localSide )
                    return DelReturn.Continue; // when counting "ally" units, don't count my own units
                side.Entities.DoForEntities( GameEntityCategory.Ship, delegate ( GameEntity ship )
                {
                    int shipCount = 1 + ship.GetCurrentExtraShipsInSquad();
                    strength += ship.TypeData.BalanceStats.StrengthPerShip * shipCount;
                    strength += ship.GetStrengthOfContentsIfAny();
                    squadResult++;
                    return DelReturn.Continue;
                } );
                return DelReturn.Continue;
            } );

            if ( squadResult > 0 )
            {
                int strengthAsInt = strength.IntValue;
                string strengthSuffix = ArcenFormatting.GetRoundedNumberWithSuffix( ref strengthAsInt );
                Buffer
                    .Add( squadResult )
                    .Add( " squads (" )
                    .Add( strengthAsInt )
                    .Add( strengthSuffix )
                    .Add( " strength)" )
                ;
            }Specifically:

I'm just showing squads and strength, rather than squads, ships, and strength, since ships is a middle-ground granularity that strength is more useful than, and it's less text to squeeze onto the screen. I'm also getting the strength of the ships rather than the strength of the squads, so that it reflects squads which have lost ships (and therefore have less offensive power)

I stored the running total of strength as an FInt instead of an int. Just doing (int) on an FInt truncates the part to the right of the decimal, which wasn't a big deal for squad strength (you lose a little precision) but is more relevant for ship strength.

I called GetCurrentExtraShipsInSquad() rather than using the saved value on the long range planning object. Generally it's unnecessary (and possibly dangerous, though probably not) to read from long range planning data when not on the long range planning thread.

Finally, I used GetRoundedNumberWithSuffix (which I pulled out of another class in external code to make it accessible generally) so that if the strength numbers get very large it will start using k and m suffixes to keep the screen space requirement from getting too large.

[BadgerBadger]

As a heads up (I just realized this) the new nanocaust implementation powerful, but it doesn't handle save/reload well. It relies on having internal Fleet data structures to keep track of what's happening. This lets us do awesome things like "Coordinated strike from multiple planets on a single objective" but save/reload doesn't keep any of that state.

I believe I have a really cool fix to this though, but it will take a bit of help. My proposed solution: for each Fleet in motion, have a Nanocaust Fleet Control Ship generated. This ship will have the information currently only in the Fleet data structure, and ships persist across save/reload. This has the additional huge upside of "You blow up the Fleet Control Ship and the nanocaust attack just stops" (imagine trying to defend your Ark from a huge fleet while frantically searching for the Control Ship, then blowing up the control ship just before the Ark dies, thus disabling the attacking fleet).

This would require the ability to encode some data (a few ints? a string?) into some field associated with a given GameEntity that would persist across save/load. Could I entice you to include a few modding-reserved fields? Or are there additional complications that I don't foresee?

[Draco18s]

This would require the ability to encode some data (a few ints? a string?) into some field associated with a given GameEntity that would persist across save/load. Could I entice you to include a few modding-reserved fields? Or are there additional complications that I don't foresee?

Really what you want is an "attach arbitrary data to the entity" method.

In Minecraft this was handled as letting each Entity store an NBTtag* that would get serialized when the entity was saved (and deserialized when it was loaded). Any mod could simply go "get me the Entity NBT and stick some data in there." We've since 'upgraded' to a capabilities system, but that just keeps the runtime data separate from the serialization data (serialization wise, the data gets encoded the same way) and I only sorta understand how it works.

But yeah, being able to attach arbitrary data to a game entity that it automatically (or near-automatically**) serialized would be awesome.

*NBT also being the format of the serialized data
**Nothing wrong with making the modder have to handle serialization themselves, as long as how to do it is understood

[keith.lamothe]

Yea, being able to serialize your own stuff both for GameEntity objects and for WorldSide objects (which includes special factions) is definitely a goal. You'll be doing it manually but we've got solid tools for it.

New version out; I didn't get the nanocaust or galaxy display modes in as I need to run, but I thought you'd like one of the new features sooner than later

[BadgerBadger]

So I'm looking at using the new code from the Settings menu to be able to show some settings for map types. I'm a bit stuck though. I can see how to create arbitrary settings in XML and how to extract them. But in order to let the user interact with them I need to call ArcenUI_SetOfCreateElementDirectives.GetNextFree passing in the following: a string naming a prefab type ("int input box", "boolean toggle button" ,etc), the class to handle that interaction (public class iInputType, public class bToggle, etc), the X/Y and height/width and a CodeDirectiveTag. The resulting GUI element Has A CodeDirectiveTag that's used to index into the settings table so that the ensuing bToggle object knows which setting it corresponds to in the ArcenSettings table.

This all makes good sense, but I don't see a way to call ArcenSettingTable.LookupByName("my setting") and also get the index of that setting in the table. Which means that the CodeDirectiveTag won't help me.  In the SettingsMenu you interact with the ArcenSettingsTable by examining the VisibleRows List, so you always have access to the index. But hidden settings don't let you do that since they aren't in the VisibleRows list.

There is a workaround, which is to define a unique class per setting to handle the interaction (so instead of using a generic iInputType/bButton class and having each class object look up which setting it corresponds to, I would define a unique iInputForSettingX class for each setting X). This would be awful coding practice and I refuse to sully my hands with it.

On a related note, can the external code see the UI scaling number? If so, how? I want to make sure that any UI elements I do scale in location appropriately (like right now, the save/load buttons look kinda weird with higher scaling).

[BadgerBadger]

Also, here's a very minorly tweaked version of the nanocaust (the only change is to make the Nanobot Centers/Hives not autotargeted by human ships. Doing otherwise makes hacking the nanocaust very hard).