AI house that can't build anything from BaseUnit or other [AI] fields causes a crash

[DCoder DCoder]

AI house that can't build anything from BaseUnit or other [AI] fields causes a crash. This should exit gracefully.

[DCoder DCoder (dcoder1337)]

This was implemented in branch ft-ai-base-planning a while ago. Testing needed.

[Bug Importer (bug-importer)]

Code related to this issue has just been checked in!
Author: DCoder
Location: ft-ai-base-planning, r883
Commit contains DLL: Yes
Revision comment:
Related to issue #917 - merged latest trunk into this, added a hook not to crash when a house cannot build any BaseUnit= stuff.
SVN: http://svn.renegadeprojects.com/Ares/883

[Graion Dilach (graiondilach)]

When BaseUnit is missing, the AI will surrender. Test was done with commenting out PCV from the VehicleTypes list.

I've also did a test by commenting out YAPOWR from the BuildingTypes list - that resulted with a crash. Ares reported:

"Error: [YuriCountry] can't build any available Power Plants!" or something similar.

[DCoder DCoder (dcoder1337)]

Yeah, that second one is kinda intentional... Thanks for the confirmation.

[mevitar (mevitar)]

When the AI can't find a building to build under BuildWeapons= it causes a crash. It happens just after it finishes loading the map.

I tested by commenting out all BuildXXX fields under [AI] section. Other fields didn't cause any problems.

Here's the dump, log, and except from the crash: http://ddesire.cncguild.net/extra/debug.7z

[DCoder DCoder (dcoder1337)]

Apparently this is more complicated than I expected - no further additions/safeguards will be added for 0.2 .

[Bug Importer (bug-importer)]

Code related to this issue has just been checked in!
Author: DCoder
Location: trunk, r1022
Commit contains DLL: Yes
Revision comment:
Related to issue #917 - untested validators to warn if any AI houses are unable to build something it wants. See if it works.
Related to issue 917 .
SVN: http://svn.renegadeprojects.com/Ares/1022

[FS-21 (jagarni1983)]

Now If I start a skirmish game with r1022 It crash & it can't be dumped into a file like always when it crash. It crash just when the load screen end & the log text says:

[Developer error]House S cannot build any object in AlliedBaseDefenses. The AI ain't smart enough for that.[Developer error]House S cannot build any object in ThirdBaseDefenses. The AI ain't smart enough for that.[Developer error]House Y cannot build any object in AlliedBaseDefenses. The AI ain't smart enough for that.[Developer error]House Y cannot build any object in SovietBaseDefenses. The AI ain't smart enough for that.[Developer error]House G cannot build any object in AlliedBaseDefenses. The AI ain't smart enough for that.[Developer error]House G cannot build any object in SovietBaseDefenses. The AI ain't smart enough for that.[Developer error]House G cannot build any object in ThirdBaseDefenses. The AI ain't smart enough for that.[Developer error]House B cannot build any object in AlliedBaseDefenses. The AI ain't smart enough for that.[Developer error]House B cannot build any object in SovietBaseDefenses. The AI ain't smart enough for that.[Developer error]House B cannot build any object in ThirdBaseDefenses. The AI ain't smart enough for that.[Developer error]House A cannot build any object in SovietBaseDefenses. The AI ain't smart enough for that.[Developer error]House A cannot build any object in ThirdBaseDefenses. The AI ain't smart enough for that.
Fatal Error:
One or more errors were detected while parsing the INI files.

[Bug Importer (bug-importer)]

Code related to this issue has just been checked in!
Author: DCoder
Location: trunk, r1023
Commit contains DLL: Yes
Revision comment:
Related to issue #917 - I should stop coding at 23:00...
Changed logged information from house name (which is a unicode string always set to "Computer") to Country ID such as [YuriCountry].
Changed validator logic - the old version was always bound to fail since it checked all three sides' defenses (the ones in [AI], not respecting Ares additions) for each house. Now it checks the defenses and powerplants through Ares interface, meaning it respects all customizations on country/side done through Ares INI coding.
Note that these checks did not and still do not respect RequiredTheaters setting. More refactoring would be needed to support that.
Related to issue 917 .
SVN: http://svn.renegadeprojects.com/Ares/1023

[DCoder DCoder (dcoder1337)]

FS-21, note that the internal error popup in this case also contains an additional paragraph explaining the error:

One or more errors were detected while parsing the INI files.
Please review the contents of the debug log and correct them.

And there is no option to make a memory dump because the program knows where the problem is.

[DCoder DCoder (dcoder1337)]

This version worked okay for me, so marking as resolved and waiting for tester reports.

[Bug Importer (bug-importer)]

Code related to this issue has just been checked in!
Author: DCoder
Location: trunk, r1025
Commit contains DLL: Yes
Revision comment:
Related to issue #917 - removed the forced exit on error, added more detailed logging.
Related to issue 917 .
SVN: http://svn.renegadeprojects.com/Ares/1025

[FS-21 (jagarni1983)]

The r1022 bug was fixed. with this r1025 the result of removing the buildings in these tags (1 new game per tag test):
BuildConst= AI MCVs waited forever without deploy.
BuildPower= it crashed.
BuildRefinery= it crashed.
BuildBarracks= The game continued and nobody built barracks, no crash. But it was reported in the debug.log
BuildTech= The game continued and nobody built Tech centers, no crash. But it was reported in the debug.log
BuildWeapons= it crashed.
AlliedBaseDefenses= Allies didn't built defenses.
SovietBaseDefenses= soviets didn't built defenses.
ThirdBaseDefenses tag was ignored. AI built defenses.
BuildNavalYard= AI didn't built these buildings.
BuildRefinery= it crashed.
BuildRadar= The game continued and nobody built radars, no crash. But it was reported in the debug.log
ConcreteWalls= The game continued and nobody built walls, no crash. But it was reported in the debug.log
AI.Powerplants it crashed when AI needs more than the 2 initial power plants.
AI.BaseDefenses= The game continued and nobody built defenses, no crash (of the sides I removed the buildings in this list). But it was reported in the debug.log

Shipyard= isn't the same that BuildNavalYard? I haven't tested it.
BuildDummy= How is the right way to test it? only check if debug.log has this info? if is only that test then it is writen in that debug file.

If someone want test it remember removing the "AIBuildThis=yes" line on affected bui

[mevitar (mevitar)]

I also tested it for BuildWeapons entries commented out, the game also crashed, but I noticed this in my debug.log:

[Developer error]AI House of country [Americans] cannot build any object in BuildWeapons. The AI ain't smart enough for that.
 The list BuildWeapons contains the following items:

As one would expect, there's nothing there.
After that, no other problems (developer errors) reported in the debug.log.

[DCoder DCoder (dcoder1337)]

OK, thanks for the feedback. I'll reduce the list of tags to check based on these reports.

[Bug Importer (bug-importer)]

Code related to this issue has just been checked in!
Author: DCoder
Location: trunk, r1030
Commit contains DLL: Yes
Revision comment:
Related to issue #917 - only BuildPower, BuildRefinery, BuildWeapons, Shipyard and Powerplants lists are checked now, since they are evidently the only ones causing crashes ingame. The error dialog has been removed, because it has potential to break existing mods.
Related to issue 917 .
SVN: http://svn.renegadeprojects.com/Ares/1030

[YR M0ddEr (yr-m0dder)]

Using r1031
Some were fixed, some still create IE.

[Developer error]AI House of country [Americans] cannot build any object in BuildPower. The AI ain't smart enough for that.
[Developer error]AI House of country [Americans] cannot build any object in BuildRefinery. The AI ain't smart enough for that.
[Developer error]AI House of country [Americans] cannot build any object in BuildWeapons. The AI ain't smart enough for that.

------------------------

[AI]
BuildPower=NAPOWR,YAPOWR;,GAPOWR
BuildRefinery=NAREFN,YAREFN;,GAREFN
BuildBarracks=NAHAND,YABRCK;,GAPILE
BuildWeapons=NAWEAP,YAWEAP;,GAWEAP
BuildNavalYard=NAYARD,YAYARD;,GAYARD

Rest of the sections in [AI] is unchanged.

log, except and dump:
http://www.megaupload.com/?d=2WOT78YE

[DCoder DCoder (dcoder1337)]

Can you guys make up your mind on what you want the game to do if the AI can't build that stuff? I made it quit the game after explicitly telling you what's wrong, you complained. I made it simply log the problems and let the game crash as it used to, you complained. What do you expect me to do here?

[SovietWarrior (sovietwarrior)]

quite and write log problems as it was. Feature helped me to locate my AIBaseDefences and ConcreteWalls bugs.

[Graion Dilach (graiondilach)]

I think this feature is just another modding tool. Leave it as it is. If it crashes because of missing building, then it's the modder's fault for not adding that building in.

YR Modder, we can agree, without those three, the AI wouldn't even work. And that's the point. This wasn't meant to decrash YR if there's a missing building. This only meant to show the cause of crashing.

And that's achieved.

[YR M0ddEr (yr-m0dder)]

logging is what I think is the best. and it already do that.

[FS-21 (jagarni1983)]

If all the useful info of the problem is added in the debug file then make crash it. The developer should read the debug file because is a tool for help developers.

[mevitar (mevitar)]

I agree with others - logging is the most important thing here. If the game will crash, it's not much of a problem here, as it's the modder's duty to check if the AI can build everything. A finished mod won't crash because of a missing building anyway, so I don't see a need to implement some extra fixes to prevent it from happening.

[Bug Importer (bug-importer)]

Code related to this issue has just been checked in!
Author: DCoder
Location: trunk, r1058
Commit contains DLL: Yes
Revision comment:
Related to issue #917 - restored forced termination of game when errors are found in the lists. Let's see how many people fail to read the exit message and get confused.
SVN: http://svn.renegadeprojects.com/Ares/1058

[DCoder DCoder (dcoder1337)]

I'm now considering this issue fixed. Time for tester feedback.

[Rogan (pdrogan)]

I tried this in trunk r1060 and commented out one of the entries in baseunit.

Tried making the AI use the commented-out baseunit and it gives me a crash during loading.

It gives me this:

[quote]
Fatal Error:
One or more errors were detected while parsing the INI files.

Please review the contents of the debug log and correct them.
[/quote]

So this issue is fixed now.

[DCoder DCoder (dcoder1337)]

Thanks! I'll leave this open for a little longer so all the other testers can see it easily.

[YR M0ddEr (yr-m0dder)]

Work as Drogan described, and debog.log clearly explains the problem.

[Developer error]AI House of country [Alliance] cannot build any object in BuildPower. The AI ain't smart enough for that.

[DCoder DCoder (dcoder1337)]

Thanks for testing.

[DCoder DCoder (dcoder1337)]

Note to self: BuildBarracks should also be checked.

[OmegaBolt (omegabolt)]

Just found out that it is this fix which causes the crash on my singleplayer maps which include new houses. As they're not intended to be used by the AI they don't have buildings listed under the [AI] tags and so the game quits on load. These missions worked fine in YR 1.001 and earlier versions of Ares though...

IMO the forced termination isn't a good solution, as it seems to potentially break more than it fixes. I believe Speeder has also had this issue.

[Bug Importer (bug-importer)]

Code related to this issue has just been checked in!
Author: DCoder
Location: trunk, r1089
Commit contains DLL: Yes
Revision comment:
Related to issue #917 - moved house base plan check to the point where the house actually generates a base plan (after receiving an MCV or map triggers instructing it to start base planning) instead of at startup, this way we don't fuck up missions with baseless houses. Removed forced exit, if the game really wants to crash it can do so on its own.
Related to issue #1604 - this issue needs to be retested now.
Also included is a small fix that should reduce incorrect logging between consecutive matches.
SVN: http://svn.renegadeprojects.com/Ares/1089

[Bug Importer (bug-importer)]

Code related to this issue has just been checked in!
Author: DCoder
Location: trunk, r1090
Commit contains DLL: Yes
Revision comment:
Related to issue #917, Related to issue #1604 - last commit used incorrect version number, just recompiled the DLL with the right one.
SVN: http://svn.renegadeprojects.com/Ares/1090

[DCoder DCoder (dcoder1337)]

Time to test this again...

Recap: The check will be performed when a house receives an MCV, not at match startup. Ares will not force a game exit if these problems are detected, it will simply log them and let the game continue. The game will still crash in spectacular ways if certain lists can't be built, but that's not our fault.

[DCoder DCoder (dcoder1337)]

♫ ♬ Where have all the testers gone? ♪ ♫

[Rogan (pdrogan)]

Tried blanking out the BaseUnit and BuildBarracks entries.

There's no logging going on around them and the generic fatal error message (There one where you had the option to create a full error report) is displayed rather than the one before...

This is on the latest trunk rev.

Edit: here's the crash report http://www.mediafire.com/?29ievb1upoq6eic

[Bug Importer (bug-importer)]

Code related to this issue has just been checked in!
Author: DCoder
Location: trunk, r1141
Commit contains DLL: Yes
Revision comment:
Related to issue #917 - ugh, this again... Quite stupidly, the check for BaseUnit was placed in the base plan handler, which happens *after* the house acquires and deploys an MCV, which requires it to have something buildable from BaseUnit already. Awesome.
The first house failing to find BaseUnit will print a notice about it, the following ones won't - this is due to the game's internal organization, rearranging it is not a good idea right now. The game shouldn't crash, but if it does, the logging for the first house should be sufficient. If it does crash, the usual generic error message will be shown, not a special one with explanations about the possible causes - we decided that Ares shouldn't force a crash if this happens, so we cannot tell if a crash two seconds later is related to this problem or not.

Additional improvement: if parser errors have been detected, the generic IE window will mention this fact. Though WW's own code causes them by default, hoorah.
SVN: http://svn.renegadeprojects.com/Ares/1141

[DCoder DCoder (dcoder1337)]

Testers go-go-go!

[Graion Dilach (graiondilach)]

I still get the first result, without an useful baseUnit, AI surrenders.

The debug message works, BTW.

[Rogan (pdrogan)]

I tried this again, and I got an instant game over as soon as I start a game when blanking out the baseunit entries.

I got this message: "[Developer error]House of country [Alliance] cannot build anything from [General]BaseUnit=."

No dev error logged for blanking out BuildBarracks and the AI doesn't build them.

[DCoder DCoder (dcoder1337)]

What do you expect to happen without a base unit?

BuildBarracks does not get logged because the AI can't get to the point of planning its base without a BaseUnit. I'm not going to validate every house at match startup, because then all the missions will start logging errors.

[Graion Dilach (graiondilach)]

BuildBarracks also gets debugged, confirmed.

[Graion Dilach (graiondilach)]

Upon further tests the issue seems mystaical. FS-21 pointed out (and I could confirm it) that if a mod has more than three sides, no debug messages will appear.

I have a "WTF! vector has 1 items, requested item #2", though.

[Rogan (pdrogan)]

I blanked out the baseunit entries while having more than three sides in the file and it gave a debug message.

I then blanked out only BuildBarracks, restoring the baseunit entries. No AI builds a barrack and no debug message appears in the log.

The same thing happens if I use the default number of sides.

So I can somewhat agree to Graion and FS-21's claims.

[DCoder DCoder (dcoder1337)]

We have decided that this issue is not important enough to delay 0.2 for. Might get revisited some time in the future.