BOTA is FIXED!!! Thanx guys!

[Quanto042]

Alrights ppl. Heres the deal.

I've been trying to create BOTA 1.5 for a while now. I've been retooling the units and adjusting this that and the other thing and ultimately just trying to being the quality of the mod up a few notches.

Unfortunately since the release of Spring 0.74b(x), BOTA has been suffering a major error. A game ending error, a mod ending error.

Apparently, the Core Advanced Kbotlab and the ARM Advanced Vehicle plant both create a game ending error upon the moment the game tries to spawn them onto the screen. This bug happens with ALL versions of BOTA, not just 1.4 and 1.5 but also all of Thors original works as well. This is deeply troubling to myself and a few others as i have called upon the help of a few of the more experienced Modders out there, (Smoth, Peetah, and Noize) to name a few and none of us have been able to find a simple solution to the problem.

Before all you other guys come rushing in with "Simple Solution (A)" and "Simple Solution (B)" I would like to inform that "Been there, Done that."

This is a list of things that I did in the process of troubleshooting, All of which failed:

1) Check the FBI files for possible typos or syntax errors. - Found none

2) Replace FBI file with another from another TA mod. - No dice

3) Use 3DO file from other TA mod. - Nope

4) Use script file from other TA mod. - Nada

5) Bang head upon keyboard. - Headache


This is incredibly frustating. Anyone please help me!!

Oh and if you want to check the problem for yourself, its recurrent in all BOTA versions, so no matter what you have in your mods folder, just run the game and after entering cheat mode, type .give armavp or coralab and see what happens. Maybe one of you guys will have an idea that we haven't thought of yet.

[KDR_11k]

Hm, replacing all of its files with AA ones results in "armavp is not a valid unitname" and giving a con veh crashes Spring then... Any of the devs willing to follow this stacktrace:

Exception: Access violation (0xc0000005)
Exception Address: 0x006eccd3
DLL information:
0x00400000 spring
0x7c910000 ntdll
0x7c800000 kernel32
0x77da0000 ADVAPI32
0x77e50000 RPCRT4
0x73e70000 dsound
0x77be0000 msvcrt
0x77d10000 USER32
0x77ef0000 GDI32
0x774b0000 ole32
0x76af0000 WINMM
0x77bd0000 VERSION
0x68fc0000 GLU32
0x5f0d0000 OPENGL32
0x736d0000 DDRAW
0x73b30000 DCIMAN32
0x76c50000 IMAGEHLP
0x71a30000 WSOCK32
0x71a10000 WS2_32
0x71a00000 WS2HELP
0x10000000 SDL
0x7c340000 MSVCR71
0x00b00000 DevIL
0x66fc0000 freetype6
0x61b80000 zlib1
0x003d0000 glew32
0x76330000 IMM32
0x62e10000 LPK
0x75790000 USP10
0x746a0000 MSCTF
0x10100000 lgscroll
0x75250000 msctfime
0x69500000 nvoglnt
0x719b0000 mswsock
0x66710000 hnetcfg
0x719f0000 wshtcpip
0x76ee0000 DNSAPI
0x76f70000 winrnr
0x76f20000 WLDAP32
0x76f80000 rasadhlp
0x72c90000 wdmaud
0x76bf0000 WINTRUST
0x77a50000 CRYPT32
0x77af0000 MSASN1
0x72c80000 msacm32
0x77bb0000 MSACM32
0x77ba0000 midimap
0x73e40000 KsUser
0x59dd0000 DBGHELP
Stacktrace:
(0) E:\games\mini\TASpring\spring.exe [0x006ECCD3]
(1) E:\games\mini\TASpring\spring.exe [0x0069C8A2]
(2) E:\games\mini\TASpring\spring.exe [0x004E786F]
(3) E:\games\mini\TASpring\spring.exe [0x004EBBF5]
(4) E:\games\mini\TASpring\spring.exe [0x004ECDF4]
(5) E:\games\mini\TASpring\spring.exe [0x007142C6]
(6) E:\games\mini\TASpring\spring.exe [0x00719B96]
(7) E:\games\mini\TASpring\spring.exe [0x00719F52]
(8) E:\games\mini\TASpring\spring.exe [0x0071A0F2]
(9) E:\games\mini\TASpring\spring.exe [0x007963E5]
(10) E:\games\mini\TASpring\spring.exe [0x00401092]
(11) E:\games\mini\TASpring\spring.exe [0x0040110F]
(12) C:\WINDOWS\system32\kernel32.dll(RegisterWaitForInputIdle+0x49) [0x7C816FD7]

[Tobi]

Code: Select all

CFactoryCAI::CFactoryCAI(CUnit*)
C:/taspring_trunk/rts/Sim/Units/CommandAI/FactoryCAI.cpp:75

CUnitLoader::LoadUnit(std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, float3, int, bool, int)
C:/taspring_trunk/rts/Sim/Units/UnitLoader.cpp:168

CGame::HandleChatMsg(std::basic_string<char, std::char_traits<char>, std::allocator<char> >, int)
C:/taspring_trunk/rts/Game/Game.cpp:3075

CGame::ClientReadNet()
C:/taspring_trunk/rts/Game/Game.cpp:2270

CGame::Update()
C:/taspring_trunk/rts/Game/Game.cpp:1470

SpringApp::Update()
C:/taspring_trunk/rts/System/Main.cpp:812

SpringApp::Run(int, char**)
C:/taspring_trunk/rts/System/Main.cpp:990

Run(int, char**)
C:/taspring_trunk/rts/System/Main.cpp:1047
WinMain@16
C:/taspring_trunk/rts/System/Main.cpp:1096
main
J:/MinGW/home/Sherpya/stage/mingw-runtime-3.10/main.c:78
_mingw_CRTStartup
J:/MinGW/home/Sherpya/stage/mingw-runtime-3.10/crt1.c:226
WinMainCRTStartup
J:/MinGW/home/Sherpya/stage/mingw-runtime-3.10/crt1.c:260

[trepan]

Do the 'UnitName' tags in the FBI files match the filenames?

[Maelstrom]

Perhaps it isnt the lab that is killing Spring, but one of the units that it tries to build.... Worth looking into maybe?

[KDR_11k]

Nope, I removed its build entries in the sidedata.tdf to no avail.

[Quanto042]

To KDR: Replacing EVERY file with that of an AA one will create a whole new error altogether rather than offer a fix. The files I had replaced were the armavp.3do and coralab.3do in one instance and i also replaced their script .cob files in another. Also keep in mind that in AA the filenames are often different so you also need to make sure that they properly renamed.

To the Devs: Simple question first from Trepan, yes that was one of the first things i check when i checked FBI files for errors. Tobi, I'm not very familiar with that deep level of coding, could please explain to me what that big block of code means??? >_>

To Mael: That was also and early idea, though i haven't been able to figure out a way to be able to tell if its actually the unit's buildtree thats causing the problem or another unit. Also the fact that the buildtree for every unit is stored in a seperate file from the FBI doesn't make it any simpler.

[KDR_11k]

The crash is caused by the code that sets up the build options, specifically the line where it retrieves the unit names for the build options. Have you checked if the filename and unitname match for every unit it builds?

Code: Select all

		string name=bi->second;
		UnitDef* ud= unitDefHandler->GetUnitByName(name);
		CommandDescription c;
here> c.id=-ud->id; //build options are always negative
		c.action="buildunit_" + StringToLower(ud->name);
		c.type=CMDTYPE_ICON;
		c.name=name;

[Quanto042]

Nope, I removed its build entries in the sidedata.tdf to no avail. The crash is caused by the code that sets up the build options, specifically the line where it retrieves the unit names for the build options.

Code: Select all

		string name=bi->second;
		UnitDef* ud= unitDefHandler->GetUnitByName(name);
		CommandDescription c;
here> c.id=-ud->id; //build options are always negative
		c.action="buildunit_" + StringToLower(ud->name);
		c.type=CMDTYPE_ICON;
		c.name=name;

Code: Select all

c.id=-ud->id; //build options are always negative

wait, alright. So u are totally sure this is the bad piece??? >_>

Just got a few questions, like where is the file this code is located in?
Also, could you please explain to me why this particular line of code is so evil???

Annnndd, if this really is the source of the problem, KDR, u are truly my lord and savior.

[KDR_11k]

His stack trace says FactoryCAI.cpp (75) on the top, means the 75th line of that file. Since it's an access violation -ud doesn't point to a valid unit. This is probably because the call to the unitdefhandler two lines up returned an invalid number. Did you check if the unitname and filename for all build options matches?

[Quanto042]

Hmmm, i'll look now.

[AF]

Argh came to me a while abck sayign AIs crashed with his mod no matter what he did, and indeed UnitDef** has a null value in it somewhere. This was caused by an extra double bracket in the units tdf file.

[MadRat]

Its not in your sidedata, guy, the whole problem can be traced in the buildtable log.

I've had this problem before and the fix was to clear the AA caches for all maps and for the specific mod. You probably just need to clear the log folder, too, as it builds one for buildtable and this one will be where its mostly the cause of your crash. Clearing the caches helps it start building AI behavior from square one. Automate the process with a batch file so you can quickly clean out these files before each and every test.

If it keeps crashing then I found one easy way to troubleshoot bad units. You read down the buildtable log and you look for "unknown". But you can't just read down it, you need to open a explorer view of your units folder. Look up each unit in the explorer window, beginning from the A's, and read through the buildtable for each one. (Why? Because your buildtable uses unitnames in alphabetical order which are not in the same order as the filenames.) The first one that says "unknown" could be your culprit. Keep working through all the units until the only "unknown" types are radar units.

[tombom]

ai stuff

It has nothing to do with an AI because we weren't using it.

[MadRat]

Well, if you aren't using it then try it. It'll shortcut your troubleshooting if you follow the path I described. It makes it quick and easy to find typoes.

[Tobi]

Quanto, just ignore that stacktrace (that code block) if you don't know what to do with it - others will know.

[smartie]

This problem was in Nota when the .74 version of spring came out. I emailed you about it but you must not have gotten the email. It's a problem with two units, the arm mobile antinuke, and the core crawling bomb. Both units reference the track type SpidTrack which isn't in the mod. Spring has just ignored it up until now.

[MadRat]

Do any of the helper AI's rely on the AAI buildtable? The problem you describe really reminds me of two different possibilities, a simple cob file not matching the unitname or a corrupt buildtable log. Sure wish my windows machine was running or I'd cross-reference them files for you. But I'm a week out at the moment.

[Quanto042]

This problem was in Nota when the .74 version of spring came out. I emailed you about it but you must not have gotten the email. It's a problem with two units, the arm mobile antinuke, and the core crawling bomb. Both units reference the track type SpidTrack which isn't in the mod. Spring has just ignored it up until now.

So, um do i pick a new track file or should i remove the tag???

[smartie]

So, um do i pick a new track file or should i remove the tag???

It's fine either way. The normal kbot track looks good enough for spider tracks. I dunno if the SpidTrack was something that used to be in bota and got removed or if it ever existed in the first place.