Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: karajorma on April 24, 2005, 08:59:50 am
-
Well I said I was going to do some testing this weekend. Here's what I've got so far.
Variable Related FRED2_Open bugs
[List=1]
- The pull down menus do not allow you to make a SEXP like this
-modify-variable
--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.
- 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.
- The above SEXP doesn't work in the game. When used the value of String1 is set to an integer (Sometimes I got 0 sometimes 1. No idea what causes the difference.) This effect can be seen in the provided mission by pressing V
- If you set up an event like this
when-argument
-Agrument 1
-Argument 2
-Some condition
-Modify-variable
--String1(value 1)
--< argument >
The word is writen into the variable instead of the value of < argument > This can be verified by pressing B in the provided mission.
- When you try to use string-equals it won't let you enter the variables. You can call up the replace variable submenu but when you select a variable the SEXP remains unchanged.
- Again you can get the variables into the SEXP by typing in @VariableName. If you attempt to pick a variable from the list after entering a variable both entries reset to < any string >.
- When using the $VariableName option in a message the variable is resolved into a string the first time the event is called. If the message is called a second time the variable is not resolved and whatever was the value the first time is used. (Press N to check this. The first message is sent, the second variable is altered and then a sceond message is sent to prove this. Finally the first message is sent again. If the check is carried out properly messages 2 & 3 should be the same. If the variable is not being resolved a second time messages 1 & 3 will be the same).
- Interesting. You can use
-send-message
--whoever
--whatever
--< argument >
Combine that with invalidate-argument and you've got random messages that can only appear once. Hmmmmmm. I could find uses for this :) Not a bug but I've just noticed it and it's in the test mission (press M) so I thought I'd mention it :D
- This one is a little odd. Sometime you can simply add in a
not
- =
SEXP and sometimes you can't. I have no idea why. This bug shows up several times during the same session but isn't always there.
- If you select a SEXP, click on it to edit it, blank it (or make it into an invalid SEXP name) and then deselect FRED crashes. Admittedly it's been doing that since retail but if it's an easy fix to get FRED to simply revert to what you had before you did anything it might save some accidental crashes.
How do you want this mantised? As one big bug report or seperately?
Here's the mission BTW so that whoever fixes these bugs doesn't need their own test mission to check them. (For some reason the mission crashed Goobers latest _r build but works fine with the debug build).
-
Originally posted by karajorma
The above SEXP doesn't work in the game. When used the value of String1 is set to an integer (Sometimes I got 0 sometimes 1. No idea what causes the difference.)
Figured out what is causing the difference :D
Here's the string variable declarations from the mission file
$Variables:
(
0 "ArgToVar" "null" "string"
1 "CheckingSomething" "Null"
"string"
2 "CopyThisVar" "SomeValue"
"string"
3 "EquivTest1" "Equal" "string"
4 "EquivTest2" "Equal" "string"
5 "OverwriteThisVar" "Null"
"string"
)
The number at the start which appears to be the index value used for the variable is what is being written in rather than the actual value of the variable.
-
Originally posted by karajorma
- If you select a SEXP, click on it to edit it, blank it (or make it into an invalid SEXP name) and then deselect FRED crashes. Admittedly it's been doing that since retail but if it's an easy fix to get FRED to simply revert to what you had before you did anything it might save some accidental crashes.
[/B]
This is happening to me too, although in the retail version it only happened when I did that outside of the Events Editor. Now, using FRED2 Open, when I enter a SEXP manually, even if I get it correct, FRED2 takes a dump. I can still select stuff from the drop down menus without a problem, but simply left clicking the mouse over a SEXP operator to edit it and then pressing enter or left clicking somewhere else on the screen causes a crash.
-
I've had similar crashes to that but when I was making the report I couldn't remember exactly what had caused them.
-
I guess this is a little off topic, but it is a bug in FRED.
Anyways, I have FRED_OPEN 3.6.5, and in this all the z-axis markers (the little green or white lines) are shown as if viewing from Alpha 1, even though the actually camera viewing at a different angle and from a diff location. When you move the camera around, the z-axis markers stay the same.
Also, I have noticed that the background editor is not working very well. I am not sure that it actually positions the background images where you specify them to be, as every image i have added it always at 0,0,0.
Not, a SEXP bug, but a bug nonetheless.
Thanks
-
You're using FRED 3.6.5. There are newer builds that have fixed the Y-axis bugs, and the background bug can be solved by adding -jpgtga to the command line.
-
:bump:
About Mantis. One big bug report for all the variable stuff or do you want it seperately?
-
Separate. That way we can tick them off one by one. :)
-
:bump:
Bugs added. Oddly enough that's twice as many bugs in one day than I had previously entered into Mantis (although I did enter a few into Bugzilla when you used that). Guess I should report more bugs :)
I've not entered number 9 cause I'm going to try to track down what's causing it next time I'm FREDding.
-
too much red. i should start assigning them to goober.