Hard Light Productions Forums
Hosted Projects - Standalone => The Babylon Project => Topic started by: Havner on January 09, 2009, 02:02:20 pm
-
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.
-
as far as i understood the 3.6.10 builds work in multiplayer but not in single player .................
-
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?
-
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...........
-
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.
-
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.
-
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.
-
What bug? 3.6.10 bug I hope, since RW worked previously.
-
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.
-
I can see a problem with it.
$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.
-
So you're saying that after all it's mission bug? What would be the proper solution here since this mission worked before?
-
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.
-
maybe everybody blew up the Gib instead of disabling (I did or at least I think so)
-
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.
-
well, the easiest way to fix this would be to release a patch (-mission) with an upcoming campaign or multiplayer addon.
-
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.
-
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 :lol:
-
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 :lol:
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.
-
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.
-
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. :p
-
It may have loaded, the question is did it actually do anything? There's a very good chance that the game simply went "No such variable" and the function returned without actually modifying the variable.
And unless you're certain that this mission was never notepadded you can't be certain FRED is to blame. :p
-
You can't progress past this mission if the code doesn't work. I've never notepadded this particular mission. The vanishing @ used to happen all the time. It was one of the regular bugs along with reseting exits from fighterbay to hyperspace and screwing up special explosions (which also used variables incidentally). This all led to the great FRED save lottery. Although the odds of winning and getting a working mission were generally a lot worse than winning the lottery.
-
It may have loaded, the question is did it actually do anything? There's a very good chance that the game simply went "No such variable" and the function returned without actually modifying the variable.
And unless you're certain that this mission was never notepadded you can't be certain FRED is to blame. :p
I thought the same thing but it does work and the correct messages based on that variable do play. I also tested to see if you can do that without using notepad in 3.6.9 and it will let you and there is no warning as long as what you type is a variable that is defined. All you do is add the modify variable and type the name in instead of selecting it from the list. It still shows up as data but FS2 treats it as a variable. 3.6.10 will also let you type the name it but then you get that error when you exit the event editor or try to save.
-
Hello guys,
sorry for posting on this old topic, but:
I'm currently playing the Raider Wars Campaign and as mentioned in the first post, the game crashes. I have to use build 3.6.10 as the old 3.6.9 is somehow not working on my system (Windows 7 Ultimate x64, GeForce 8800GTS 640MB, 4GB RAM, Athlon X2 5200+) - but thats another thing to deal with.
Please, I'm just asking for guidance or any hint on what file I have to modify to get this to work - I really like the mod and want to finish the missions.
Thanks in advance,
ThE_-_BliZZarD
-
Do you have the Zathras mod installed? If yes, does the campaign still crash?
If it does, please use the debug build (fs2_open_3_6_10d or similar) that came with Zathras, run the mission that is giving you trouble, and then post the fs2_open.log from the data folder in your TBP directory.
-
I'm guessing it's M9 and that is fixed in Zathras.
-
No, I did not have Zathras - but now I have. My Problem is gone now. Thank you for this useful tip :)
But: Why isnt this information included on the TBP DVD (I installed it via this DVD) or anywhere else? Shouldnt Zathras Mod be a standard for this installation helpers?
-
Problem is that the DVD release was finished long before the Zathras project even started.
There will be a new DVD, but until then, manual installs are necessary.