No strings starting with numbers in missionVariables.

Post by **Eric Walch** » Thu Feb 28, 2008 8:37 pm

Is it a bug or a feature? I thought I was back at basic again. There you could build variables with any characters as long as you didn't start with an number.

I just was literally translating the nova mission by using the original names: missionVariables.nova = "2HRS_TO_ZERO". But it didn't work. After a little debugging I found the course. The content of the variable became 2. Apparently you can not give a mission variable a stringcontent starting with a number. Is this a bug or has this technical reasons?

I now just use: missionVariables.nova = "TWO_HRS_TO_ZERO" This will work just as well for the mission. It now works in JS. I only added that when launching in an escape pod while the ship is full of refugees, you will not get the end message. The mission just stops. It didn't make sense to me to arrive in a pod full of refugees in this case. (And we now have a nice eventhandler for using an escape pod)

JensAyton · Post by **JensAyton** » Thu Feb 28, 2008 8:43 pm

Hmm. I didn’t think [NSString doubleValue] would behave that way, but since it does, let’s call it a technical restriction. I think the ability to store numbers in mission variables is more useful than the ability to store strings starting with digits. (Storing numbers directly would be possible, but I think it would break saved-game compatibility. Unless they were stored separately. Hmm.)

Post by **Eric Walch** » Thu Feb 28, 2008 9:16 pm

Ahruman wrote:
Hmm. I didn’t think [NSString doubleValue] would behave that way, but since it does, let’s call it a technical restriction.

Don't change this when it is good working in an easy way now. Just document that strings can't start with an number or they will be read as a number. Textstrings starting with numbers will be rare and I never would have thought doing it myself. I can't remember an other OXP using an string starting with an numeric character in a mission variable.

Commander McLane · Post by **Commander McLane** » Mon Mar 03, 2008 12:17 pm

Anarchies does (but it's a legacy script, therefore it works).

When you bribe the official in order to get your legal status cleared, the bribesum is stored as a number in mission_anarchies_bribesum and a text string in local_anarchies_bribestring. The number is e.g. "10000" and the concurring text string "10000 ". The text string is displayed in the missiontext, the number is what you pay. (BTW: The former being a mission_variable and the latter a local_variable is a heritage from 1.69.1.1, where local_variables could not store numbers, so I had to refrain to a mission_variable, although I still prefer a local_variable for the purpose.)

I had to do it this way, because the number appears to be stored as a real. So when I displayed it on the missionscreen, it appeared as "10000.0000". Ugly.

Post by **Eric Walch** » Mon Mar 03, 2008 1:29 pm

Commander McLane wrote:
Anarchies does (but it's a legacy script, therefore it works)...... The number is e.g. "10000" and the concurring text string "10000 ". The text string is displayed in the missiontext, the number is what you pay. ....
I had to do it this way, because the number appears to be stored as a real. So when I displayed it on the missionscreen, it appeared as "10000.0000". Ugly.

You talk here of a pure number. That will be no problem as it is stored as a number. The problem is that when there is text after the number it will be ignored and it gets stored as a number.

About the "10000.0000", yes, ugly. Those numbers are generated on additions. Therefor in legacy I always did an increment/decrement cycle with such a variable to remove the tailing zeros when I had to display the number on screen.

Commander McLane · Post by **Commander McLane** » Tue Mar 04, 2008 5:08 am

Eric Walch wrote:
Commander McLane wrote:
Anarchies does (but it's a legacy script, therefore it works)...... The number is e.g. "10000" and the concurring text string "10000 ". The text string is displayed in the missiontext, the number is what you pay. ....
I had to do it this way, because the number appears to be stored as a real. So when I displayed it on the missionscreen, it appeared as "10000.0000". Ugly.
You talk here of a pure number. That will be no problem as it is stored as a number. The problem is that when there is text after the number it will be ignored and it gets stored as a number.

You have noticed the ending SPACE in the text string, which makes it a string (at least in legacy scripting)?

About the "10000.0000", yes, ugly. Those numbers are generated on additions. Therefor in legacy I always did an increment/decrement cycle with such a variable to remove the tailing zeros when I had to display the number on screen.

Ah, that's a nice workaround. Didn't know!