2019-01-21 15:10 EST

View Issue Details Jump to Notes ] Related Changesets ]
IDProjectCategoryView StatusLast Update
0002670FSSCPFREDpublic2012-08-22 01:23
Assigned ToGoober5000 
Product Version3.6.13 
Target Version3.6.14Fixed in Version 
Summary0002670: Long variable name + long variable content = FREDSPLOSION
DescriptionIf your variable name + variable content is longer than 32 characters, FRED will crash or fail to load the mission without warning. It does however let you commit the events/variables in question with the Event Editor without any issues. It just fails to load the mission and sometimes drops a lot of mission data upon save.
Steps To ReproduceOpen the attached mission in FRED.
Go to the Event Editor and right click on the event there.
Chooose to modify variable.
Change the BLASTpre variable name to targetsBLASTpre (or anything of a long length).
Hit OK.
Expand the event to see that the variable name + content is much longer than 32 characters.
Press OK on the Event Editor to commit the changes.
Save the mission.
You'll either get a crash or see the Ulysses dissapear.
Trying to reload the mission will always fail.
TagsNo tags attached.
Attached Files




Valathil (developer)

Fix committed to trunk@8903.


Zacam (administrator)

Fix committed to fs2_open_3_6_14@8961.


The_E (administrator)

As per TopAce's post here: http://www.hard-light.net/forums/index.php?topic=81558.msg1630525#msg1630525

This seems to still be an issue


The_E (administrator)

This definitely needs a more careful look. The problem here seems to be FRED's practice of saving a variable's default value at every point where the variable is referenced in the file, thus causing overflows, since the default values are not tokenized properly prior to being run by the parser.

In the mission file attached here, the parser will barf at this event:
$Formula: ( when
   ( true )
   ( modify-variable
      "@BLASTpre[Targets in Blast Range: ]"

As you can see, "@BLASTpre[Targets in Blast Range: ]" is parsed as a single token when it really isn't.


Valathil (developer)

Well the bug report stated A CRASH. I fixed the CRASH. This is an entirely different problem. Connected but different.


Goober5000 (administrator)

I've identified the core issue. Should be fixed soon...


Goober5000 (administrator)

Fixed in revision 9130.

Volition was actually aware of this issue and tried to account for it. Their code *almost* worked, which made the problem somewhat harder than if the code had not worked at all. :p

+Related Changesets

-Issue History
Date Modified Username Field Change
2012-06-23 14:43 MjnMixael New Issue
2012-06-23 14:43 MjnMixael File Added: Variable32Test.fs2
2012-06-23 14:47 Valathil Assigned To => Valathil
2012-06-23 14:47 Valathil Status new => assigned
2012-06-23 16:53 Valathil Changeset attached => fs2open trunk r8903
2012-06-23 16:53 Valathil Note Added: 0013711
2012-06-23 16:53 Valathil Status assigned => resolved
2012-06-23 16:53 Valathil Resolution open => fixed
2012-07-01 21:27 Zacam Changeset attached => fs2open fs2_open_3_6_14 r8961
2012-07-01 21:27 Zacam Note Added: 0013772
2012-08-20 02:24 The_E Note Added: 0013927
2012-08-20 02:24 The_E Status resolved => feedback
2012-08-20 02:24 The_E Resolution fixed => reopened
2012-08-20 13:17 Goober5000 Target Version => 3.6.14
2012-08-20 14:01 The_E Note Added: 0013928
2012-08-21 14:45 Valathil Note Added: 0013930
2012-08-21 23:35 Goober5000 Note Added: 0013933
2012-08-21 23:35 Goober5000 Assigned To Valathil => Goober5000
2012-08-21 23:35 Goober5000 Status feedback => assigned
2012-08-22 01:23 Goober5000 Note Added: 0013934
2012-08-22 01:23 Goober5000 Status assigned => resolved
2012-08-22 01:23 Goober5000 Resolution reopened => fixed
+Issue History