[karajorma]

In order to fix a rather nasty bug that is currently in the code I had a chat with Goober and we came up with suggestion of changing the way the argument code works slightly.

At the moment if you have 3 variables both of these are legal

when-argument
-any-of
--Var1
--Var2
--Var3

when-argument
-any-of
--@Var1
--@Var2
--@Var3

I proposed making it so that only the 2nd one was legal but I wanted to check I wasn't stepping on anyones toes before I did so.

In case you're wondering the bug is subtle but rather nasty. If I have a variable called Warspite (which holds some numeric value to do with the ship) and a ship called Warspite then any event like this

when-argument
-any-of
--Warspite
--etc....

stands a good chance of failing because the game will look for a ship with the same name as the value held in the variable rather than simply look for the Warspite. The solution would solve the problem unless you're silly enough to name a ship @Warspite.

[Stormkeeper]

We can just name the ship Warspite#Ship can't we?

[IPAndrews]

hmm... @variable name is the way variables are represented in the actual text of the mission file, but the editor has never required anyone to know that. Until now... I doubt this is the kind of thing a novice mission designer would need to know but even so perhaps this is a step in the wrong direction?

[FUBAR-BDHR]

Since it wouldn't break anything existing (or would it?) I don't see anything wrong with it.  The argument sexps are pretty advanced and take some research on how to use anyway.  A little change like that shouldn't  cause too much of a problem.  Aren't there future plans for adding other uses for variables that would require the same type of representation anyway?

[karajorma]

It wouldn't break anything of mine. In fact, off the top of my head I can't think of an example of why you'd even want to have a variable as an entry on the argument list for one of the new conitionals. The situation where you'd actually need it is esoteric enough that it's the sort of thing you tend to stumble across halfway through a mission. There are probably only 10 FREDders in the community for whom it might actually be an issue.

We can just name the ship Warspite#Ship can't we?

Yeah but the problem affects any SEXP using the CTEXT() to read a string. Any string, not just a string denoting a ship. And a quick grep turns up 400+ calls to CTEXT in Sexp.cpp alone. That basically means that a very large number of possible argument types are vulnerable to this bug. Not just ship names, weapon names, message names, subsystem names etc.

hmm... @variable name is the way variables are represented in the actual text of the mission file, but the editor has never required anyone to know that. Until now... I doubt this is the kind of thing a novice mission designer would need to know but even so perhaps this is a step in the wrong direction?

I figured I'd just add an NB at the bottom of the help text for the argument SEXPs saying that variables should use the @ symbol.

The only other solution is to expect the same novice mission designer to know that they should never name a variable after anything which could conceivably be a valid SEXP argument while having it on the argument list. Until this weekend even I didn't know that and I've never heard anyone say anything to suggest they did either (Even Ransom Arceihn's Mantis bug didn't identify the root cause).

The problem is made worse by how subtle this bug actually is. The original Mantis report was that after using special-hits the argument SEXPs stopped working. The problem is that special hits are saved to the mission file in a variable named after the ship. I've plugged that hole already but there is no easy way to solve the problem of someone naming a variable Engines or Radar and then using when-argument together with a SEXP that deals with subsystems.