Child Cost Script Not Reflected on Load
 

I noticed an interesting problem when you load a saved roster under the following conditions:

-There is an upgrade that assigns a tag to a unit and allows a new upgrade type to be taken (and at a lower cost - identified by the tag being present).
-In implementation and execution it works for a user; the new upgrades are available and showed at a reduced cost.
-Save the roster for later use.
-When you then subsequently load said saved roster, all the items are there correctly, but the cost of the new upgrade is at the base cost and not the reduced cost.

I assume this is a process priority/ordering issue in regards to scripts and tags and whatnot, so I'm wondering what I can do to fix this. There is an obvious workaround (delete the upgrade and reselect it), but if possible, I'd like to figure out how to preserve the cost calculation on load.

If you want to reproduce/debug this, load the X-Wing datafiles, make an Imperial squadron, add any TIE Advanced to your squadron, select the TIE/x1 title upgrade, and add any of the newly available system upgrades. You'll see the cost of every upgrade of that type is 0 or 1 (as it should be). Save the roster then load it. The cost of the upgrade will now be show at its base cost.

Any thoughts? It's not any kind of pressing issue, but it is annoying for a user to have to reselect the upgrade on a list when they load with a roster with this scenario present to have points correctly reflected.

~A

Hey there! Sorry for the lack of reply. That's my bad. :( I've pointed the developer to this thread. He may ask for more details.

S'fine, Liz.

The issue is reproducible with the steps above.

I am willing to bet that it is a matter of the order of operations/priorities as opposed to an actual code bug, but we'll see what they can find.

~A

This looks to be an unexpected consequence of how the "ChildCost" script works. As described in the documentation:

Normally, the ChildCost script is only invoked once - right after the unit is added. That means when you're initially building the roster, you add the "advanced sensors" item, the ChildCost script runs once, finds the "be cheaper" tag is already on the unit, and reduces its cost appropriately.

However, when you load the saved roster, the ChildCost script is running during load, before the script on the "TIE/x1" item has run, and thus before it's added the "be cheaper" tag. So when the script runs, the tag isn't there, and the cost isn't reduced properly. :(

(There's actually another way to trigger the ChildCost script to run - hit the "Change Roster Settings" button, then hit "OK" without changing anything. This triggers a "global update" which re-runs the script, which can now see the tag and calculate things correctly. But obviously this isn't something you want to have to do every time you load the roster.)

I think I can fix this by forcing an additional "global update" after the roster loads, which seems like the most expedient way to fix this problem. I'll try to get a beta built sometime next week to fix this, so we can test this out before putting out the general release.

Thanks for the bug report!

Colen,

Thanks for the update and the work around.

Glad that I could be of service.

~A

Something that might be related (since it also has to do with loading) that might be worth touching at the same time:

If you have a datafile that autoloads a unit to your roster (like say the Armada datafiles) and you loaded a file directly (say double-clicked the saved roster), it launches AB, loads the correct data file, then asks if you want to save the current roster before continuing. This is confusing to users. It's clear that the direct launch makes a new roster first then loads the roster in question and since a new roster always has a unit shoved into it, you have a non-empty roster being displaced.

Not a priority at all, but clearly a user QoL issue that would be in a similar section of your code.

~A

Here's a release candidate for Army Builder that should fix the problem you encountered:

http://www.lonewolfdevel.com/downloa...in_install.exe

Please give this a try and see if you run into any problems with it? If it looks good, I'll put it out for wider testing before releasing it.

NB, if you get a "Windows prevented this program from running" message when you try to open it, don't worry, just have it install anyway - we have a new code signing certificate that Microsoft hasn't seen before, so Windows is just being overcautious with it.

Thanks for your other report, I'll file that as a bug.

The problem seems to be fixed in that build. I can't reproduce it with the steps I originally outlined.