User Tools

Site Tools


troubles

Troubles

The possible error messages are of two types, the most alarming and dangerous ones are the error messages printed out by the game itself and the other is the error messages given in form of Eden editor notification (the red stripe on the top of the edit area).

IMPORTANT NOTE: you should always run the game with the Show Script Errors ENABLED!
(-showScriptErrors start up param if not using the launcher)

Scripting errors

If you get a scripting error message shown on the screen, as in the white text on black background you should be alarmed. When you operate the tool it builds virtual databases and some of those get “perma saved” into the profileNamespace (which is a physical file on your storage drive; yourprofilename.vars.Arma3Profile). Some data is also saved into the mission.sqm.

THIS IS ESPECIALLY SEVERE IF THE ERROR MESSAGE MENTIONS ANY HNEG_FNC.
IF SUCH ERROR MESSAGE SHOWS UP YOU MUST STOP IMMEDIATELY AND MOST IMPORTANTLY DO NOT SAVE THE SCENARIO!

If you save after some error occurred in very high likelihood one or more of the databases are now corrupt and saving the scenario will save the corrupt database(s) which leads you to not be able to open the scenario into Eden with this tool running anymore.
There is a button in the Prefs leaf to be used if things go FUBAR: Revert.
Pressing that button will remove every trace of the emitters placed with the tool from the scenario and the profileNamespace.

IMPORTANT NOTE: This button should be used only if there was a scripting error shown and the scenario was saved after it, otherwise you should be fine just by loading the last saved version of the scenario.

If you happen to save the scenario after the error message and exit the editor and then attempt to load the scenario again you will not be able to do so (you most likely need to ALT + F4 the game).

Loading the scenario into Eden without this tool running and removing the emitters will not work. The edited scenario will have traces of them saved into the mission.sqm and profileNamespace, and the scenario itself is “paired” with the data saved into the profileNamespace so unless all that data is erased as well the scenario is fud for this tool. Should be fine otherwise though.

There is a way though; loading the scenario in “safe mode”: start Eden and this tool, load the terrain the scenario is made on, open the scenario load dialog (click on Open on the toolbar or CTRL + O), select the scenario that was fud, DO NOT DOUBLE CLICK ON IT, instead press and hold down SHIFT + CTRL + ALT and press the Open button (with left mouse).
This should load the scenario into Eden without loading any of the emitter data. Now you can just remove the emitters and save the scenario and it no longer has any trace of the emitters left.

To start editing with this tool again you have to restart Eden because the “safe mode” mucks some things up so the tool won’t run properly.

So even if this tool melts down it should be possible to save the scenario, but to be safe always make a backup of it before starting to edit with this tool.

If (we,, when…) you make the tool go belly up it would be useful if you report it to me, with the .rpt, tool version (can be found in the Prefs leaf) and all possible details on what you were doing when the error occurred.
Unfortunately the tool will some times fail, due to the fact that this is just a flimsy scripted house of cards it will never be 100% stable.

Error notifications

The way less severe errors are the Eden notification ones, shown on the top of the edit area:

These usually indicate you’re trying to do something that is not allowed, and don’t break anything.

For example things that are not allowed are changing the key attributes of the emitters; name and init or the text attribute of the trigger that is synced with an emitter.

There are also less severe scripting errors such as when you insert completely faulty data into some edit field, say you typo an array to something like [0,0,0],1 which will show a scripting error and break down the data verification for that edit field but it does not break the scenario as the faulty data never gets saved into the db.

Faulty data in parameter fields can also cause database corruption but if you correct the data before saving the scenario all is fine. It is impossible to make the data validation perfect as there is no way to detect scripting errors.

Reporting Bugs

TODO

troubles.txt · Last modified: 2022/03/12 08:59 by hneg