Also I made a bunch of video tutorials a while ago, these are explaining only a few very basic xml issues, for beginners:
How to solve a EAW or FOC Bug:
You can find out if a .xml file is suspicious by commenting it out in GAMEOBJECTFILES.XML with <!-- <File>Suspiciousfile.xml</File> --> this deactivates it.
If you deactivated it and the game stopped crashing you know this .xml caused the crash. But this wont work allways, because some .xmls depend on other xmls and to remove them will just generate a second error, so the game has 2 reasons to chrash.
Usually the last few xmls you changed are suspicious, mostly the last one you edited before a error appeared.
So if you are working with .xml files there is 1 major way to find out what causes your bug: simple logic, like this:
- Copy the xml you worked on, right before your error appeared anywhere on your computer to have a backup, so you dont loose any progress.
- Then delete about 50% of all content of the suspicious .xml and save.
(Be carefull to not leave a opening tag behind and delete only the closing tag or vice versa. So keep the last tag at the end of the file which is also at the top.)
- Then start the game. If the bug was within the 50% of the file you just deleted your game should work just fine. If it crashes again you need to reduce Content of the .XML by 50%, until your bug is gone.
Then you will know what you've just deleted and where it should be. Then you test THIS PART of your xml (again by removing 50%) until you finally locate the bug.
Another thing that can help you locating bugs is:
WHEN DID IT HAPPEN? 1. At starting a GC Conquest?
2. On entering a Planet on the Galactic Conquest Map?
3. Before or after loading a Map?
4. When using a Units special ability?
5. After loading a Savegame?
If your game crashes when you start a new GC the issue will probably be in its GC.xml file, that means you have to find the right .xml file ( indexed in CampaignFiles.xml ) and search there for a bug.
As far I know this happens if the xml of a planet (planets.xml or similar) points to a prop that doesent exist in the .\Art\Models directory. Or if it points to a image that isnt in .\Art\Textures\Mt_Commandbar.tga and Mt_Commandbar.mtd
-/ If it loads the map in 1 Second and then you click on "Start" but nothing happens that means in the planets.xml the Tag <Space_Tactical_Map> or <Land_Tactical_Map> of THIS PLANET points to a non existing Map file in .\Data\Art\Maps\???.ted
-/ If it crashes after successfully loading (a few seconds) and then you clicked "Start" that can have several reasons:
When your game crashes at this point the reason will probbably be one of the assets it was loading, like unit XMLs, missing Models, missing Textures ...
- A spaceship/ground unit with broken .xml code:
You can figure out which unit causes the crash by simply loading the same savegame or doing the same things as last the time and removing (every unit of) the same type. Then if the error occurs again you know it wasnt that unit type, so you can go on to test any other unit you've sended last time, until the game stopps crashing which means the broken unit wasnt sent to the planet.
After you found the unit that caused a crash you have to search for its .xml file and there to search there for the Error (what were the last changes you made there?)
Spaceships are causing many crashes because of missing art assets, tags pointing to missing assets because of wrong written names or missing files, check especially for these tags:
<Space_Model_Name> Crashes the game if there is no .alo file with this name in .\Data\Art\Models or because of misspelling.
<Icon_Name> = May crash the game if Icon is not existing in .\Data\Art\Textures\Mt_Commandbar.mtd and Mt_Commandbar.tga, or because of misspelling.
- A Building on this planet (have a look at the <Starting_Forces> tag of this Planet in its GC.xml) It that crash happens on several planets it could be caused by a building they have in common.
- See one post below in my next Post (missing text entrys)
Well, this is quite avious when a unit uses its ability which causes a crash you have to take a look at the units .xml file..
The game seems to save parts of the GC.xml (indexed in CampaignFiles.xml), the Story_Sandbox_???_???.xml, and some battle statistics into the savegames. Beside of how many units you have and where. So if you make changes on one of these two files it will aviously make all your Savegames on this map USELESS.
Unless you saved the original GC.xml and Story_Sandbox_???_???.xml somewhere and are able to put them back to their original positon.
This explains also, why the game is allways crashing when you try to load savegames of the original game or of Mod A in Mod B.
I know, what causes the game to crash when you happen to save the game or when you click on the "End Game" button:
This kind of crash happens when a LUA Syntax error occurs.
In this case, it is caused by .\Star Wars Empire at War Forces of Corruption\Mods\Stargate\Data\Scripts\StoryDialog_???.txt, and allways happens when this .txt file has a syntax error. (Because these Story.txt files are simple LUA Tables)
It occured in my case because I just pasted the name of a textstring (which is located in the MasterTextFile.dat) and forgot to add the command "TEXT" in front of it. This error may happen also because of any other kind of syntax error in that .txt file.
You can fix this bug by taking a closer look at your .\Star Wars Empire at War Forces of Corruption\Mods\Stargate\Data\Scripts\StoryDialog_???.txt using the logically deleting 50% method to locate the mistake.
This is the way the Xmls are innitiated:
[ Zum Anzeigen klicken ]
[ Zum Verstecken klicken ]
CampaignFiles.xml -> CAMPAIGNS_SINGLEPLAYER.XML -> in the right Campaign in the tag: <???_Story_Name>Story_Plots_Sandbox_???_???.xml</???_Story_Name>
In the Story_Plots_Sandbox_???_???.xml you will find the: Story_Sandbox_???_???.xml, and in this file in the tag: <Story_Dialog>Dialog_???</Story_Dialog> which points to a .txt file in .\Star Wars Empire at War Forces of Corruption\Mods\Modname\Data\Scripts\ The .txt file there itself points to string entrys in MasterTextFile_???.dat.
(With "Infobox" I mean the blue box that allways pops up when a new Galactic Conquest was started.)
- A other side effect of this bug is that ALL text of the Infobox will not be shown any longer, and everything is just black.
- And it also causes the game to crash when a map is loading, this issue is very hard to localize because usually you might think the game crashes because of the map itself, or the GC.xml file, or because of a faulty Spaceship.xml which is true for 98% of the cases. But not for this case.
It took me 3 hours to figure out what causes this bug and 3 additonal hours to learn that it also causes the game to crash when loading a map.
A similar bug caused a crash each time I tryed to load or to end the game, because I removed .\Stargate\Data\Xml\AI\GoalFunctions to prevent the AI from freezing Spaceships, which solved the freezing problem (Look at FAQ point 5.8) but unfortunately leaded me into this second LUA-Syntax error.
I just had a minor Bug:
In Galactic Conquest view, you can still move with the mouse to the right side and below but you can't move up or to the left.
Accidently I pressed the Windows key to get out of the game and do something else. After returning to the game the mouse got its function back I was able to move on the screen as usual.
So the Windows Key or getting out of the game using Strg + Alt + Entf is probably the solution for this minor, but annoying thing.
Right after that I ran into the next goddamn Bug; I am working on a Story Script for a GC and all of a sudden the Icons in the GC mode are freezing.
So I cant move my groundunits down to the planet, nor can I move them to one of the other fields of the planets.
The only thing I was able to do is moving the spaceships to the next planet.
After hours of testing I foud out that one of my Events in Story_Sandbox_??.xml triggered at the same time as a similar one (STORY_CONSTRUCT) and both of them pointed towards a minor spacehero unit (a icon) to destroy him.
That didnt caused the bug by itself, but that in combination with a STORY_ELAPSED event.
The bad thing about this bug is, one is saving it into a savegame and later he is going to load it all over again.
I located that double pointing event and got rid of it.
I've just worked on some models in 3DS Max for the game, and got white unit textures. After some research I found a solution. And I'd like to share some more Develloper soltutions:
- The unit models are green. This means the game cant find your textures. Maybe because the path to the texture isnt set correctly, or you didnt used a shader like BumpMeshColorize or MeshGloss.
- The Game shows a unit very bright or entirely in white.
Solution: Probably the parameters for your textures are the default ones (they are too bright). This often happens using the BumpMeshCollorize Shader.
Open in Max the Material editor the settings of this shader and set the first 3 Values of Emissive (red, blue, green) to 0,3 then click on "close".
Then set the first 3 values of Diffuse to 0,3.
And finally the most important one, Specular is adding lot of gloss effects we dont want, set the first 3 values to 0,02. Be aware the last 3 values have one additional 0
If then its too dark you have to play with the first 2 values (between 0,1 and 1.0) until you have the right brightness.
- When you hover over a space unit with the mouse, it doesent show the hardpoints, altrough they are set to to be shown in the unit xml, or your Unit is not getting attacked by opponent units at all.
Solution: Open the Model in 3DS Max 6,8 or 9 and create a simple shape, call it "Colision" then open the Alamo Utility and check the "Enable Colision" and the "Hidden" checkboxes.
Alternatively you can check the Enable Collison box of the model itself, but that will be more expensive for the cpu.
Finally here is a debugging checklist to solve the green texture issue.
Please use this checklist to search for the mistake:
1. Is the texture in one of the 2 correct formats: .tga or .dds
2. Is the texture in the .Data\Art\Textures directory of the right mod.
3. What kind of shader do you use to load that texture (bumpmeshcolorize or meshgloss.fx) ?
4. If you use 3Ds Max 9, did you renamed that shader from .fxo to .fx ?
5. Make sure the path of the shader points to the correct texture path (no mistyping).
6. Each time you open the alamo viewer, it has to load the model from inside the .Data\Models directory of whether any mod or the original game (otherwise it wont find any textures and display all in green).
7. are the brightness values for ambient, diffuse and specular all in a good range (About 40%, rather dark then light) otherwise the model will be displayed ingame very white.
That depends on which type of star destroyer you got spawned.
Some spaceships are single units (nothing is written in theyr xml <Starting_Spawned_Units_Tech_0> or <Reserve_Spawned_Units_Tech_0> tags) , they dont spawn fighters and because they didnt spawned them nothing follows these ships.
By the way they require to have SPAWN_SQUADRON, in theyr <SpaceBehavior> tag in order to be able to spawn anything.
Fighters are spawning from a ships hangar hardpoint and then they usually are following them.
Otherwise (Im not sure) maybe one of these tags is controlling the following behavoir (the ship and the fighter squadrons both got them):
</Guard_Chase_Range> and <Idle_Chase_Range>
And, one more thing.. 5 more hours lost for a other bug:
I tryed to start a tactical mission using the "LINK_TACTICAL" reward. But it allways instantly loaded the map in a sec without displaying the start button, or when I click on that button position at the lower right corner it dropps me back to the Galactic Map view.
This was caused by an empty <Terrain></Terrain> tag in the Planets.xml.
So after changing it to <Terrain>Temperate</Terrain> the map loaded normally.
ok i've narrowed it down to the "GUARD" command not working. If tie fighters are tasked to guard a star destroyer, they will fly to where the star destroyer is and just sit there. if I move the star destroyer, the tie fighters WILL NOT follow it, they will still sit and float around where the star destroyer was when i ordered them to guard it.
After trying to load a map using "LINK_TACTICAL" I dropped back to the galactic view and some parts of the UI were at a wrong place.
The UI went crazy I wasnt able to select units and play as usual.
Solution; Obviously the map file was missing, I renamed it in the Link_Tactical event, but forgot to do the same in my maps directory.
I encountered this bug allready once, last time not because of a missing map but because, I think .. the double pointing construction bug a few posts ago.