[Havner]

Code: [Select]

Error: Invalid variable name.

In sexpression: ( when
   ( is-subsystem-destroyed-delay
      "EA Gibraltar"
      "engine01"
      0
   )
   ( modify-variable
      "EnginesScorched"
      ( +
[] 1 )
   )
)
(Error appears to be: EnginesScorched)
File: missionparse.cpp
Line: 6077


Call stack:
------------------------------------------------------------------
------------------------------------------------------------------
I know that only official builds are supported, but I'm not asking for any support. Merely pointing this out so maybe someone can fix that. Can't tell whos error is that (fs2_open or TBP) but it is there. I get this while loading rw09 mission using latest TBP and fs2_open build from today. Works fine on supported 3.6.9 build. I think it did work fine on build from 2-3 weeks ago. If someone could confirm it's definitely fault of fs2_open I'd mantis it.

[captain-custard]

as far as i understood the 3.6.10 builds work in multiplayer but not in single player .................

[Havner]

as far as i understood the 3.6.10 builds work in multiplayer but not in single player .................

???

You mean I can't play single player missions on latest svn code? Where did you read that?

[captain-custard]

i think it was discussed somewhere or maybe just in game , what mission/mod and build were you using g and ill try to replicate it...........

[FUBAR-BDHR]

Recent 3.6.10 build work in both single and multi but there are still bugs.  We are only supporting 3.6.10 in multi. 

As for your problem it seems you are missing an argument in that event.  It's not a 3.6.10 issue but a mission issue.  See where the modify-variable is.  The [] should be a sexp, number, or variable. 

[Havner]

It's not a 3.6.10 issue but a mission issue.  See where the modify-variable is.  The [] should be a sexp, number, or variable.

True, 3.6.10 reports this like it was mission error. But taking into consideration this mission is vanilla Raider Wars (rw09) mission that worked without any problems on previous builds it would point into some changes in 3.6.10. Either it's more sensitive to mission bugs (and this mission was always bugged, just it was never noticed) or this is a bug in 3.6.10.

[karajorma]

Yep. That's what I was thinking. Just let me run debug FRED and see what that reports for this mission.

EDIT : Yep. It's definitely a bug. I'll look into it then.

[Vidmaster]

What bug? 3.6.10 bug I hope, since RW worked previously.

[karajorma]

It did work before and I can see nothing actually wrong with the mission it's complaining about so I'm going to test more heavily later.

[FUBAR-BDHR]

I can see a problem with it.

Code: [Select]

$Formula: ( when
   ( is-subsystem-destroyed-delay
      "EA Gibraltar"
      "engine01"
      0
   )
   ( modify-variable
      "EnginesScorched"
      ( + @EnginesScorched[0] 1 )
   )
)
+Name: gibraltar engine 1 destroyed
+Repeat Count: 1
+Interval: 1
+Team: 0

$Formula: ( when
   ( is-subsystem-destroyed-delay
      "EA Gibraltar"
      "engine02"
      0
   )
   ( modify-variable
      "EnginesScorched"
      ( + @EnginesScorched[0] 1 )
   )
)
+Name: gibraltar engine 2 destroyed
+Repeat Count: 1
+Interval: 1
+Team: 0

$Formula: ( when
   ( is-subsystem-destroyed-delay
      "EA Gibraltar"
      "engine03"
      0
   )
   ( modify-variable
      "EnginesScorched"
      ( + @EnginesScorched[0] 1 )
   )
)
+Name: gibraltar engine 3 destroyed
+Repeat Count: 1
+Interval: 1
+Team: 0

$Formula: ( when
   ( is-subsystem-destroyed-delay
      "EA Gibraltar"
      "engine04"
      0
   )
   ( modify-variable
      "EnginesScorched"
      ( + @EnginesScorched[0] 1 )
   )
)
+Name: gibraltar engine 4 destroyed
+Repeat Count: 1
+Interval: 1
+Team: 0

As you can see the first EnginesScorched in each event doesn't have the @ or the [ 0 ].  Possibly saved with a bugged version of FRED or notepadded?

Checked every other variable reference in the mission and it's just those ones. 

[Havner]

So you're saying that after all it's mission bug? What would be the proper solution here since this mission worked before?

[IPAndrews]

As you can see the first EnginesScorched in each event doesn't have the @ or the [ 0 ].  Possibly saved with a bugged version of FRED or notepadded?

Buggy FRED. Fix one bug, it introduced another. Though I'm slightly confused as we beta tested this campaign and played it through before release.

[Vidmaster]

maybe everybody blew up the Gib instead of disabling (I did or at least I think so)

[FUBAR-BDHR]

Well there are a couple of possibilities.  The 3.6.9 in TBP final just ignores the bug when it shouldn't.  As you said nobody disables although I think I did when I first played but that was before 3.4b.  The 3.6.9 build were using for TBP is the one with the bug (unlikely since it hasn't popped up in any of my testing).  Notepad was used and there just wasn't an error check for that in 3.6.9. 

Isn't this the same mission that had the GOD satellite bug?  Maybe everyone looking for that missed this. 

Well I just loaded the mission in 3.6.9 FRED and while it doesn't give an error EnginesScorched shows up as data not a variable in those places.  Loading it in 3.6.10 gives an invalid variable name.  The variables are only used to send messages not to determine when the ship is disabled.  Going to play test it and see what happens.

Strange they actually function as variables in game even though FRED doesn't see them that way. 

Did a quick test and 3.6.9 FRED will let you type text in there but will error out unless the text matches a variable name.    So looks like a FRED warning that was buggy and fixed. 

[Vidmaster]

well, the easiest way to fix this would be to release a patch (-mission) with an upcoming campaign or multiplayer addon.

[FUBAR-BDHR]

Already checked with IP and he's OK with the patch idea since it doesn't change the core data.  See if Kara comes up with anything first. 

[Vidmaster]

and wait until we have a high-profile thing to release it with.
Maybe we discover some other error too, I am still wondering about the mission with the bomb in the shuttle. I never found and stoped the shuttle, but it doesn't hurt your progress. (Diff: medium). IP always said: "TURN UP THE DIFFICULTY" when I brought this up 

[IPAndrews]

I never found and stoped the shuttle, but it doesn't hurt your progress. (Diff: medium). IP always said: "TURN UP THE DIFFICULTY" when I brought this up 

The damage caused by the bomb is directly linked to the difficulty at which you play the mission. It's balanced so the shuttle will be badly damaged on medium but won't be destroyed. Anything higher, it'll be destroyed.

[karajorma]

I suspect you've hit upon the cause there. I've been doing a lot of work recently on the variable and argument code and so has Goober so it's likely that we fixed a parsing problem and this error appearing is the result. Since it obviously never would have worked before you might as well patch it.

[IPAndrews]

Since it obviously never would have worked before you might as well patch it.

It did work. The campaign was beta tested. That said I understand SCP won't change it's code to accomodate a mission bug. On the other hand that doesn't mean I can't be pissed off that your buggy FRED introduced a stupid (and apparently undetectable) mission bug.