Hard Light Productions Forums
Modding, Mission Design, and Coding => The FRED Workshop => Topic started by: Macfie on May 17, 2014, 07:45:18 pm
-
While doing some update work on STL I found a section I've never seen before:
#Sexp_variables
$Variables:
(
0 "ReconCount" "0" "number"
1 "SafeJump" "1" "number"
2 "ShipCount" "0" "number"
)
This is in several of the missions and in every case the mission causes FRED to crash if I modify it and try to save it. I can play the missions and modify them with notepad but can't modify and save them in FRED. This is only true for those missions that have a SEXP_variables section located prior to the Command briefing section. What does this do and can it be removed?
-
Aren't those just...variables? Broadly used in advanced mission design, a cornerstone of sophisticated FRED work? Why would you want to remove them?
Or am I missing some way in which they differ from normal variables? If I'm not, then, uh, meet variables! They are super cool and incredibly vital to complex mission design.
For reference, you're seeing the variable's index (0), its name (ReconCount), its default value (0), and the type of variable ("number" or "string").
-
In FRED, you interact with variables using the events editor. Right click and use 'add variable'/'modify variable' to add a variable or tweak a variable's name and default parameters. Use the modify-variable SEXP and its friends to modify variables. Use variables as values in data fields to call them/
-
Shouldn't they then be in the events section and why are they preventing FRED from saving the mission?
-
They're not events - just pieces of data that events interact with. Storing them up near the mission header helps with workflow, since it makes them easy to copy/paste between mission files when reusing event blocks that call the same variables.
If they're preventing FRED from saving the mission, then something's wrong. Is it possible that manual editing of those sections has damaged them? What version of FRED are you using?
-
The latest nightly. I was trying to figure out if I needed the variables.
-
Sorry, I have to ask a clarifying question. Did FRED start crashing on mission save before or after you manually edited the files in notepad?
Removing a variable will cause the mission to crash on save (or load) if that variable is referenced anywhere in the mission file. Odds are that any given variable is referenced, since it was probably added for a reason.
-
Before, I first tried to modify the missions in FRED and discovered the problem. The changes I made had nothing to do with the variables. After that was when I tried modifying the missions. It doesn't actually crash FRED it tells me it can't save the mission and I lose all the data in the mission. It essentially saves a default that looks like a new mission. It has a Ulysses with nothing else.
-
Wow. That's...quite something. Is there any chance you can use a debug build of FRED to repro the error, then post a fred2_open.log? (I assume those exist)
-
Here's the debug log.
[attachment deleted by an evil time traveler]
-
Wait what.
C:\Games\FreeSpace2\FSP_STL\data\missions\STL-12.fs2(line 1011): Error: Required token = [#Wings] or [$Name:], found [$Texture Replace:].
ERROR: C:\Games\FreeSpace2\FSP_STL\data\missions\STL-12.fs2(line 1011):
Error: Required token = [#Wings] or [$Name:], found [$Texture Replace:].
I have to ask, what exactly are you doing with those missions? Because that error message basically tells me that the order of entries in the .fs2 file is severely messed up.
-
This is from the original STL mission. It appears to be a preexisting problem. All I did was change a selection for debriefing music in the debriefing editor.
I've attached a copy of the mission.
[attachment deleted by an evil time traveler]
-
The error is related to the old feature around commenting out SCP features in the mission file by adding ";;FSO 3.6.8;;" or such. FRED scrambles up the mission when you try and save it with these still in there. You should do a global find and replace on ";;FSO 3.6.8;;" throughout the campaign, replacing it with nothing. This will fix the problem. I've been bitten by that issue in the past.
-
Thanks, Admiral. Now that you mention it I seem to remember something about that. I'll try that and see if it fixes the problem.
Removed ;;FSO 3.6.8;; and that solved the problem