The dreaded event file...

[karsten]

If anything can go wrong with your map, it will be the dreaded

---------------- ------- EVENT FILE -------

Left to itself, an ambitious event file tends to go from bad to worse. Fixing it is not as easy as it looks, because every solution breeds new problems. The time you spend fixing it is inversely proportional to its importance, but directly proportional to the chorus of complaints about your crashing map. It will be all your fault, and everyone will eventually realize that.

The first rule for an aspiring mapmaker is: Don't mess with the event file. Use a simple, safe event file that cannot crash. The event file of my "Scrooge" map, for example, is perfectly safe, because it only refers to generic "boom" and "bust" events. Use it and never worry about events again.

Once you decide to ignore the first rule, chances are the events will retaliate and back-fire in your face. Your events will flummox SMR. Helpfully, it will log a "random event" ... and then it will die. In the log file the last entry before the crash clearly states: Random event! But the log does not tell you which event crashed the game, and so a big puzzle often remains.

I distinguish

• compatible event files and
• safe event files

A safe event file can be used in any map and cannot crash, no matter what you do in the map (ideal for starting a new map). A compatible event file is compatible (ie crash-free) exactly with its associated map. But any changes in the map need to be mirrored in the event file, and it is likely to crash eventually if used in other maps without compatibility adjustments. Some map-makers have been especially clever and have simply omitted the event file. That will work fine initially, with random events being generated by the game, but is almost guaranteed to crash the map towards the end.

An event file will be compatible if you make sure that the goods in the event file and the goods in the map match and if you don't touch the other XML in the event file. This statement is true only for stand-alone maps, and it is one of the main reasons they tend to be rock-stable (if any other component is not OK, they will tend to crash on load, so the map-maker knows immeditately that something needs to be fixed).

For global-dependent maps, it gets much more complicated, involving time-stamps and stuff. You don't want to know ...

The apparent black magic that has stymied many mapmakers is that after an event-induced crash, one can reload a saved map and play beyond the crash. However, the quirky event will soon crash the map again, with increasing frequency after reloads, until the last saved map is unplayable because it crashes soon after reload.

Once you start manipulating the event XML, all bets are off ...

Random events actually happen at regular intervals. What is random is which event is chosen.





Dont confuse random events with success events. Success events need art like the one below, beautifully done by Bushdoctor. Advanced map makers should invest more into including original success event art in their maps. Utah has some excellent examples.