local_variables don't work in 1.69.1.1-mac

[Commander McLane]

I noticed that in 1.69.1.1-mac (and presumably in previous versions) local_variables can't store numerical values. This goes for both integers and real numbers.

I noticed this in connection to the "awardCredits: "-can't-handle-negative-numbers bug, which already is fixed. I was wondering however, why in Anarchies.oxp still things didn't cost anything. I found out that I had not used "awardCredits: -5000", but "awardCredits: -[local_foo]", which had been set to 5000 before. But it isn't. It's still undefined. local_variables that store strings, however, work correctly. Also mission_variables work correctly with numbers. What I have done so far is to change all my local_variables that contain numbers to mission_variables.

Here is a short testscript:

Code: Select all

{
	"testscript" = (
		{
			conditions = (
				"status_string equal STATUS_DOCKED",
				"mission_testscript_run undefined"
			);
			do = (
				"set: local_test_variable 50"
			);
		},
		{
			conditions = (
				"status_string equal STATUS_DOCKED",
				"mission_testscript_run undefined"
			);
			do = (
				"commsMessage: variable is [local_test_variable]",
				"awardCredits: [local_test_variable]",
				"set: mission_testscript_run YES"
			);
		},
	);
}

Just start Oolite with a new Jameson and press F5 twice to see the result. The commsMessage shows that the variable isn't defined and therefore credits are not awarded.

If you replace all 'local_' with 'mission_' everything works correctly.

[JensAyton]

I believe you are mistaken. What’s happening is simple: local variables are never being set, regardless of type. In fact, all local (and mission) variables are strings. This bug was probably introduced in 1.69 or 1.68. (Fixing)

[JensAyton]

There was a second problem: [] substitution for local variables simply wasn’t happening. Now fixed.

[Commander McLane]

Hm, that's strange. I had no problem with local_variables containing things like "YES" or "STAGE_1". They were queried correctly. Even a local_variable with a value of "5000 " (note the final space) was correctly displayed with a method like "commsMessage: [local_variable]". A local_variable containing "5000" (without space) wasn't, however.

[Eric Walch]

It want just to confirm that the local-variable bug(s) in 1.69 as mentioned above is solved.

I was writing a test-script by setting a local variable in one OXP and use it in an other OXP. It didn't work. (it works with mission_variables).

Looking in the code I noticed local_variables are really what the name says: LOCAL. (Stupid me to think that a variable with a name local would work globaly.) Every mission reads in their own local variables. So you don't have to worry that other oxp's could use the same variable name with local variables. (e.g. local_test can be safely used as variable within an oxp) This was not mentioned explicitly in the WIKI. (I always thought the only difference with mission-variables was that they were not stored.)

I have to watch for this. UPS-courier.oxp defines internally 5 separate missions within one OXP and the variables are only valid within each separate mission, not within the total OXP when I interpret things right.

In my previous UPS version I used local variables in a barrel scooping mission. Every time a NPC ship scooped one the variable was increased and the value was presented to the player with a console message. Thinking of this, it was a bug that is worked, as barrels (or ships) have no link with a certain mission. They are not really local when they are shared among script_actions of different barrels. In UPS version 1.2 I changed them into mission_variables that work well in Oolite 1.70.

But in 1.70 script_actions can also not deal with local variables within a script as submitted as bug elsewhere.

[TGHC]

Once again excellent analysis, well done Eric, BTW should we start calling you Sherlock now?

[Eric Walch]

BTW should we start calling you Sherlock now?

I'm just a very good reader of potential problems and I am always curious why things don't work as I like. And when I am troubled about a problem, I assume I can't be the only one.

[Captain Hesperus]

Once again excellent analysis, well done Eric, BTW should we start calling you Sherlock now?

Elementary, my dear Commander. <shoots up with a syringe of good quality coke>

Captain Hesperus

[Commander McLane]

It want just to confirm that the local-variable bug(s) in 1.69 as mentioned above is solved.

I was writing a test-script by setting a local variable in one OXP and use it in an other OXP. It didn't work. (it works with mission_variables).

Looking in the code I noticed local_variables are really what the name says: LOCAL. (Stupid me to think that a variable with a name local would work globaly.) Every mission reads in their own local variables. So you don't have to worry that other oxp's could use the same variable name with local variables. (e.g. local_test can be safely used as variable within an oxp) This was not mentioned explicitly in the WIKI. (I always thought the only difference with mission-variables was that they were not stored.)

I have to watch for this. UPS-courier.oxp defines internally 5 separate missions within one OXP and the variables are only valid within each separate mission, not within the total OXP when I interpret things right.

In my previous UPS version I used local variables in a barrel scooping mission. Every time a NPC ship scooped one the variable was increased and the value was presented to the player with a console message. Thinking of this, it was a bug that is worked, as barrels (or ships) have no link with a certain mission. They are not really local when they are shared among script_actions of different barrels. In UPS version 1.2 I changed them into mission_variables that work well in Oolite 1.70.

But in 1.70 script_actions can also not deal with local variables within a script as submitted as bug elsewhere.

I think it was mentioned somewhere (though perhaps only during a discussion here on the board) that local_variables are local and therefore only valid within one script. So I was never confused about that.

In Anarchies.oxp I am using local_variables a lot, basically because I am just manipulating things like legalStatus_number, and in the end of each action the final value is returned to that by the setLegalStatus method. So no need to store anything anywhere, no need to exchange values with other scripts, and no need for any traces in the player's save-file (I find it ugly to put up a lot of mission-variables and leave them in the save-file forever, but that's only a question of personal taste, I guess; therefore I think that each script, when everything is said and done, should reset all its mission_variables except the main variable, named after the mission (like mission_deposed or mission_trumbles)).

What I was wondering about during these last days was whether local_variables are stored anywhere? Let's say a variable like local_jumpcount counts the number of jumps the player has made in the context of a certain mission. Now, I'd like to know what happens to this local_jumpcount, if the player decides to save his game, loads another game, plays for a while, and then reloads the first game. Will local_jumpcount still have the same value? Or will it be undefined again? And what happens if the player doesn't just reload the old game, but quits and restarts the program (although I guess that in this case all local_variables are gone)?

Would be nice to get answers to these questions, if you have already dug deep enough to know them, Eric.

[Eric Walch]

What I was wondering about during these last days was whether local_variables are stored anywhere? Let's say a variable like local_jumpcount counts the number of jumps the player has made in the context of a certain mission. Now, I'd like to know what happens to this local_jumpcount, if the player decides to save his game, loads another game, plays for a while, and then reloads the first game. Will local_jumpcount still have the same value? Or will it be undefined again? And what happens if the player doesn't just reload the old game, but quits and restarts the program (although I guess that in this case all local_variables are gone)?

The easiest to find out is to just write a little test script.

Code: Select all

        {
            conditions = ("status_string equal STATUS_LAUNCHING"); 
            do = (
                {
                    conditions = ("local_test undefined"); 
                    do = ("set: local_test 0"); 
                    else = ("increment: local_test"); 
                }, 
                "consoleMessage6s: Counter: [local_test]"
            ); 
        }

Every time you launch the counter raises. Then I did just a "load game". From this point on it started counting from zero again. So the local_variables are reset on loading a new game. They should be reset on a new game, and you don't have to worry about old values hanging around.

[Commander McLane]

Thanks, Eric!

(You're right; could've done that myself .)

[Eric Walch]

McLane, you mention mission_jumpcount as variable. I don't like this method. It works perfectly but it defy the time physics of Oolite that long jumps take more time than short jumps.

I would always prefer the use of oolites real time for timing purposes. Instead of resetting a jumpcount variable and incrementing it in each jump, one can also store the actual start time and than check if a certain time has passed. e.g. Store the starttime in "mission_my_timerstart" and than check it with:

Code: Select all

                      "set: local_difference [clock_days_number]", 
                        "subtract: local_difference [mission_my_timerstart]", 
                        {
                            conditions = ("local_difference morethan 8"); 
                            do = ( ); 
                        }

It takes two line extra than the jumpcount method, but you don't need the increment on every jump. (So overall it takes just one program-line extra) You can count in days as in this example, but you can also use the [clock_hours_number] counter. Both methods work well, but this method of keeping track of time follows the physics of oolite.

[Commander McLane]

I know, and in fact that's my words and my point of view.

I proposed a real timer for the Blackmonks.oxp a long time ago. (Just to say that I'm not that stupid after all. )