Page MenuHomeFeedback Tracker

Script errors appear to persist in gamestate between editing/mission sessions.
Reviewed, WishlistPublic


This issue is difficult to pin down or describe. It seems that certain script errors can persist between editing previews, or indeed missions. To be more specific: -

If a script error occurs during a preview and is subsequently addressed and previewed again, there are occasions where random errors are thrown where there were none before. A game restart and preview of the mission appears to fix the issue.

This issue was originally to report that the script command "detach" was not working. There appeared to be absolutely no reason for "detach player" to throw a syntax error:

"detach |#|player"
"missing ;"

I originally reported this as a problem with the detach command, but have found that is is functioning correctly in a later editing session after a game restart. On reflection, there may have been a typographic error at some point before the problem appeared, so the assumption is that the error persisted between previews, and caused the syntax error.

This is an overt example where there is very little scope for incorrect syntax, and can be identified as a spurious error. There may however, be many more subtle errors that stem from the root cause as this one. {F19525}


Legacy ID
Steps To Reproduce

This is difficult to reproduce consistently.

  1. Start a mission editing session and make a typo in an init or activation field.
  2. Preview the mission to test
  3. After the error is displayed, go back to editor and correct the typo.
  4. Continue editing , previewing the mission.

At some point, there may or may not be spurious errors appearing.

Additional Information

The original report was for "detach" not working. The attached screenshot remains valid as there cannot possibly be a syntax error with such a simple command. Following the steps above led to this situation.

These types of errors have been appearing since Operation Flashpoint, and I am now conditioned to restarting before debugging obscure errors. This particular case leaves no doubt that an error does not exist, but sadly a reproduction recipe eludes me.

Event Timeline

Squelch edited Steps To Reproduce. (Show Details)May 20 2013, 5:54 PM
Squelch edited Additional Information. (Show Details)
Squelch set Category to Scripting.
Squelch set Reproducibility to Random.
Squelch set Severity to None.
Squelch set Resolution to Open.
Squelch set Legacy ID to 3398178555.May 7 2016, 2:11 PM

i've experienced this, i refer to as 'bleed-thru'...happened a few times, but more notably this past time, i have a basic script, the first thing it would do was SkipTime 12 on a empty playground testing mission i use to turn to night (faster than changing the editor options every time). When testing my scripts i am constantly hitting the "restart", and restarting. One screw up i had done (for got a semi-colon), and subsequently fixed, suddenly caused the SkipTime not to work, but the rest of the script would continue -exactly- as written, no errors, etc. I would have to exit the game to get it to run properly again. Its like it would be ignored (or the game hickuped, and believed it was -already- night, and i was skiptiming back to day?)

It is hard to describe, but when you feel the effects, its clear, something is not being cleaned up or reset to zero every time preview or restart is hit.


because it feels relevant, even though not specifically a scripting error, its representative of the bleed-over i was describing. I just added a intro.paa to my description.ext, upon mission restart from within the editor, the paa displays correctly, but a few seconds in it reverts to the previous default mission image. Subsequent restarts same thing. It appears for each image shown, the blue progress bar does one full load.

Ok, gets better:

exiting back to the editor, clicking preview again has the same exact effect. BUT, click save once, when click preview this final time, the proper intro.paa is shown through both full progress bar loads.

This to me means that part of the mission is always being loaded from memory, even though other parts freshly loaded. IMHO

OP, you cannot name the trigger detach it is reserved variable because there is command detach. Seeing you created your ticket in may, this ticket is no longer relevant as you get warned now if you do something stupid like this.