• Home
• T3A:Online
• Tournaments & Games
• Replays
• Tutorials
• Mods
• Maps
• Downloads
• Forum
• Showcase
• Users
• Links
• Help

Quick Lists

Top Rated Popular New Updated Last Comments Users

Page 1 2 3 4

Let's now learn how to handle Worldbuilder errors.




For those yet unfamiliar with Worldbuilder (how did you even come to read Expert tutorials ?), it's the tool that mappers can use to design maps, as well as script most of the things that run on maps (Hear that music in the background while you are playing ? That's a script. Playin' BfME1 ? the AI is entirely scripted).

You will find the Worldbuilder launcher in the main BfME directory, the exe being named, strangely enough, worldbuilder.exe.




Right, so Worldbuilder is an invaluable tool if you intend for your mod to be somewhat elaborate (new music, AI adapted, new bases for the new factions ...). Yet, EA didn't think it would be fit to equip Worldbuilder with a debugger, which is justified by the fact that the game has one already.

However, that's not the only limitation that WB has. It somehow finds it fit to load the entire contents of your BfME main directory, reading any and all .big file it reads, as well as loading the requested files.
Your entire INI structure will be interpreted by the engine, while each object contains a maximum of 10 lines that are useful to WB. No wonder the tool is so laggy on low-end computers ...

What's more, and that's probably the most crippling problem for WB, is that it doesn't support any of the arguments that the game supports. That means that one cannot launch WB with a -mod argument, thus forcing you to arrange your modded files differently.




The best advice I can give you if you have a fully working mod and would like to launch WB simply is to place your file in the main BfME directory, and to rename it to have an underscore ( _ ) at the beginning of its name.
For example, MyCoolMod.big becomes _MyCoolMod.big. This ensures that your files get read before the games' default, thus preventing the INI from being read twice.
Note that if you have altered the INI's organisation, you are advised to disable INI.big (simplest solution being renaming it to INI.bfme).

Now launch WB. If your coding is irreproachable, you should gain access to Worldbuilder. If you have some errors in your INI file, WB will just close itself, not reporting any errors.


First off, try to start the game, and correct any errors reported by the game. If after that, Worldbuilder still crashes, we'll be moving into the hardcore part.




That's a fancy title, eh ?
My advice would now be to make some arrangements to prepare for the actual debugging. Place your INI files (the modded ones, the vanilla ones can remain disabled) unpacked in the data/ini/ folder, and remove your .big file (loading your INI is enough to effectively debug.

Launch Process Monitor, which you should have installed in page 2, and start logging the events.
Now launch Worldbuilder, and wait calmly for it to crash. When it crashes, stop logging the events in Process Monitor, and apply the filters described on page 2 if you haven't done so yet.
Now, that looks like a mess huh ? Skip directly to the INI files, and try to see which one is loaded last. That's the problematic file.
To help you out with finding out where things go wrong, I've added in the references what happens to be the loading sequence for Worldbuilder with a vanilla game. It's in PML format, which can be opened in Process Monitor

If you're lucky, it won't be an object file, linked to a thousand others and thus taking hours to check.
If one of your object crashes, try to go ingame with him, and see if he happens to crash somewhere. If you get a game.dat with him, refer to the "Known game.dat errors" article.

If it's not an object file, then simply review the file and try to see where the error is. Here are a few tips that you should know:

• Upgrade.ini is the first file loaded that makes use of macros. Check your macros if it's crashing. {Submitted by ched}
  
• The most common error is the old 75% loaded... then splash/load dialog disapears and then nothing.
  
well I find that running the game, then quitting straight back out fixes it.
its something to do with the resource files getting temporarily screwed up. {Submitted by Hebblewhite}

I have also enclosed the loading order to a vanilla WB to load, so that you can see where it goes wrong for you.
Also, abuse of WinMerge to compare the differences you have between the last known version to work with WB you have and that buggy version of yours. The differences are the only points likely to crash the game.


Best of luck with the debugging ! Know that while this is a lengthy process, there is no known solution that is more efficient ...