Oolite Bulletins

I am in the middle of writing an OXP when I hit a snag.

My OXP is an injection system for Visas and I will have Visas appear temporarily as equipment. My OXP does not provide the Visa itself but allows other OXPs to register them with my OXP and let my code do most of the work.

To do this I am wanting to support the adding of a piece of equipment based on the value a few of mission variables such as VisaName_in_possession, VisaName_Eligibility, VisaName_Availability, etc . Adding the appropriate conditions to the equipment for this would be no issue but this then means that every visa ends up creating many mission variables each. I thought this was inelegant so I wanted to compact all the many mission variables into one single mission variable for each visa and then uncompact them into local mission variables (they start "local_" under legacy scripting) and use the local mission variables in the equipment conditions. This where I hit the snag. There is a JS method called "missionVariables" to modify mission variables from but nothing to modify legacy local mission variables. (Lets be honest, the normal reason for using local mission variables is as plain local variables so for this purpose they are replaced by Javascript's inbuilt local variables)

Is there a way to do this or do I have to go back to using multiple mission variables each?

As far as I know, there is no way to access local variables from outside the script they are contained in. That's why they are "local". Oh, and local variables are not stored in the save-file, so after a save and reload they are gone.

So if you want to do anything which shall (a) be accessible from outside and (b) survive a save and reload, the only thing you can use are mission variables.

(And by the way: JS "missionVariables" is not a method, it's the JS syntax for mission variables, like "mission_" is the legacy syntax for the same thing.)

As McLane writes: local_foo is not supported by the js engine. I also miss it sometimes because it had its usefulness. Specially in mission desciptions and other expandable text. With those variables you could change specific parts of the text. Using local_variables had the advantage that they were not saved. I now define temporary mission_variables for that purpose and delete them immediately after text display.

For your use in equipment.plist it would not work anyway. local_foo is not only not saved but it is also local. This means local to the script. Two scripts should be able to define this same variable without affecting each other. And because equipment.plist is not hooked up to a specific script, the engine does not know to what script that local variable belongs. I know it worked in some test releases, but is was actually a bug that it worked in equipment.plist or shipdata.plist.

I think your only option is to use many mission variables. Maybe you can delete them again on buying the stuff?

Commander McLane wrote:

Oh, and local variables are not stored in the save-file, so after a save and reload they are gone.

So if you want to do anything which shall (a) be accessible from outside and (b) survive a save and reload, the only thing you can use are mission variables.

I was relying on them not saving.

Eric Walch wrote:

And because equipment.plist is not hooked up to a specific script, the engine does not know to what script that local variable belongs.

I was going to use one that were local to the OXP I was writing but the problem with the scope meaning that the conditions not know which script it comes from was not something I realised. It looks like I will have to create the mission variables on the fly and delete after you change from the equipment screen.

You can always have a placeholder mission variable, and fill that with the contents of assorted local js variables (which can be defined as this.variablename or var variablename or let variablename)

That's what I did inside the commsDemo oxp, and it seems to work fairly well.