|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0002670||FSSCP||FRED||public||2012-06-23 14:43||2012-08-22 01:23|
|Target Version||3.6.14||Fixed in Version|
|Summary||0002670: Long variable name + long variable content = FREDSPLOSION|
|Description||If 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 Reproduce||Open 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).
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.
|Tags||No tags attached.|
|Fix committed to trunk@8903.|
|Fix committed to fs2_open_3_6_14@8961.|
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
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 )
"@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.
|Well the bug report stated A CRASH. I fixed the CRASH. This is an entirely different problem. Connected but different.|
|I've identified the core issue. Should be fixed soon...|
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
fs2open: trunk r8903
Timestamp: 2012-06-23 16:54:05
|Fix for Mantis 2670: Truncate tokens to their maximum length and pop up a MessageBox for the user.|
|mod - /trunk/fs2_open/code/parse/sexp.cpp|
fs2open: fs2_open_3_6_14 r8961
Timestamp: 2012-07-01 21:28:34
|Backport: Trunk r8903/8906/8911; Fix for Mantis 2670: Truncate tokens to their maximum length and pop up a MessageBox for the user.
Fix for Mantis 2670: Followup: Fix the bug without breaking mission parsing.
fine-tune Valathil's error message
|mod - /branches/fs2_open_3_6_14/code/parse/sexp.cpp|
|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|