2022-08-10 02:53 EDT

View Issue Details Jump to Notes ]
IDProjectCategoryView StatusLast Update
0000397FSSCPFREDpublic2007-11-26 21:27
Assigned Tokarajorma 
Product Version 
Target VersionFixed in Version3.6.10 
Summary0000397: Cannot modify a string variable to equal the value of another string variable
Description The pull down menus do not allow you to make a SEXP like this

--String1(value 1)
--String2(value 2)

The only way to make such an event without resorting to notepad is to choose modify variable, select String1 normally and then enter @String2 as the second entry and then saving the mission.
TagsNo tags attached.
Attached Files




karajorma (administrator)

Once you have made the above SEXP you can't change the second value in any way. You can't even edit it as if it was a string any more. Nor can you use replace data > String. You can paste another string on top of it though.


phreak (developer)

Assigned to G5K.


Goober5000 (administrator)

Annoying, but fixed.


karajorma (administrator)

This one appears to be back (To be honest I can't really remember if it ever went away completely as I've barely touched strings in the last few months).

Some of the bug is gone but at the moment you still seem to need notepad to completely solve it. FRED does allow you to pick the second variable from the popup menu now but on saving it pops up a message saying that there is an error with the second variable. Going into notepad and putting quotes around the second variables name ends the problem.
 Unlike last time you can change the name of the variable to another variable (You can't change it to a string though but that shouldn't be a huge problem).


Goober5000 (administrator)

What's the exact error message?


karajorma (administrator)

Last edited: 2006-01-19 09:33

Error in mission event "Event name": Not a number

In sexpression: ( when
   ( true )
   ( modify-variable
(Error appears to be: ImAlsoAString)

I think the error is being caused by the game not putting the quote marks around the second string. It does this with strings too in fact.

edited on: 01-19-06 09:33


Goober5000 (administrator)

Okay, it looks like I may have forgotten to set a SEXP_FLAG_VARIABLE or SEXPT_VARIABLE flag somewhere. I can't check now, unfortunately, because FRED crashes on startup. :p


karajorma (administrator)

Okay. I checked this one again

It's pretty easy to get the code to assert. Simply make a pair of string variables and use modify-variable. As soon as you add the second one the code spits out this

Assert: Sexp_variables[var_idx].type & SEXP_VARIABLE_NUMBER
File: d:\c++\freespace\fs2_open 3.6.9\code\fred2\sexp_tree.cpp
Line: 2306

Seeing as how I'm using a string variable it shouldn't be even getting to that point.


Goober5000 (administrator)

Guess I'll ping this one back to karajorma. ;)


karajorma (administrator)

Rassum brassum msblsssl Rick Rastardly


Goober5000 (administrator)



karajorma (administrator)

Well the wrong output is being written by this code in build_sexp_text_string() but it's probably not the culprit.

        // not a variable
        if (Sexp_nodes[node].subtype == SEXP_ATOM_STRING) {
            sprintf(buffer, "\"%s\" ", CTEXT(node));
        } else {
            sprintf(buffer, "%s ", CTEXT(node));

It appears as though when a string variable is placed the child nodes are not updated to the right type and subtype.

I'll have to come back later and figure out why.


karajorma (administrator)

Should be fixed now

-Issue History
Date Modified Username Field Change
2005-05-01 15:59 karajorma New Issue
2005-05-01 15:59 karajorma File Added: string.fs2
2005-05-01 16:00 karajorma Note Added: 0002298
2005-05-02 18:21 phreak Note Added: 0002314
2005-05-02 18:21 phreak Assigned To => Goober5000
2005-05-02 18:21 phreak Status new => assigned
2005-05-15 22:18 phreak Category FRED_OGL => FRED
2005-05-25 02:20 Goober5000 Status assigned => resolved
2005-05-25 02:20 Goober5000 Resolution open => fixed
2005-05-25 02:20 Goober5000 Note Added: 0002504
2005-12-04 14:57 karajorma Status resolved => feedback
2005-12-04 14:57 karajorma Resolution fixed => reopened
2005-12-04 14:57 karajorma Note Added: 0003963
2006-01-18 22:32 Goober5000 Note Added: 0004397
2006-01-19 09:33 karajorma Note Added: 0004410
2006-01-19 09:33 karajorma Note Edited: 0004410
2006-01-26 00:14 Goober5000 Note Added: 0004480
2006-09-18 16:28 karajorma Note Added: 0006649
2007-04-11 03:30 Goober5000 Note Added: 0007960
2007-04-11 03:30 Goober5000 Assigned To Goober5000 => karajorma
2007-04-11 17:20 karajorma Note Added: 0007965
2007-04-12 02:11 Goober5000 Note Added: 0007973
2007-09-04 20:25 karajorma Note Added: 0008491
2007-11-26 21:27 karajorma Status feedback => resolved
2007-11-26 21:27 karajorma Fixed in Version => 3.6.10
2007-11-26 21:27 karajorma Resolution reopened => fixed
2007-11-26 21:27 karajorma Note Added: 0008702
+Issue History