death_actions and 1.71.2

[Ramirez]

Thanks - I removed the semicolon and it worked perfectly.

[Frame]

this is true for C++, and from what i can see it is also true for Java scripting

Code: Select all

this.checkTarget = function() 
{ 
  if(this.ship.target.shipDescription == "Timon Delaney") 
    
} //*********Wrong Bracket********
    missionVariables.mission_trident_down = "DELANEYMISJUMP"; 
    player.commsMessage("setting variables!", 5); 
} 
else 
{ 
player.commsMessage("do nothing", 5);
} 
}

notice where i have put in

Code: Select all

//*********Wrong Bracket********

Your Bracket is

Code: Select all

}

in theory that should end the function right there...

so everything after that, that is:

Code: Select all

 missionVariables.mission_trident_down = "DELANEYMISJUMP"; 
    player.commsMessage("setting variables!", 5); 
} 
else 
{ 
player.commsMessage("do nothing", 5);
} 
}

should be ignored, i cant imagine that the java script compiler can figure out on its own, where you put that wrong bracket

the bracket should be this bracket

Code: Select all

{

[Frame]

To expand on this....

on specially if sentences

here are two examples

Code: Select all

let p = example

if(something==other)
p = "ok";

You will notice that it does not use brackets, and this is oright, but did we do this...

Code: Select all

let p = 1;
let q = 1;

if(something==other)
p = 2;
q = 2;

Then q will allways be set to be = 2, and that might not be what we want, if we wanted q to be dependant on the if comparison... because when you do not use brackets after an if(), only the first line will be treated as if dependant of the if() statement

so thats when we use brackets.. like this

Code: Select all

let p = 1;
let q = 1;

if(something==other)
{
p = 2;
q = 2;
}

Thumbs rule is, when only one line is dependant on the outcome of the if() statement, you need no brackets...

on a side note... i noticed that Java scripting can do well without all Semi-colon" signs, all you need todo is to look in Bouyrepair oxp, for Erichs Exellent code...

edit: but ofcourse not when multiple declarations are done on the same line like..

Code: Select all

let a = 1; let b = 2; let c=3;

you still need the semi-colons to tell the compiler where what ends, and what starts.

this way is ofcourse also correct

Code: Select all

let a =1
let b =2
let c =3

i cant tell how many times i have forgotten a semi colon, and gotten some confusing warnings and errors in C++... because of a forgotten semi colon...

We do not have that luxuary that we get specified errors if we have forgotten does pesky semi colons... so its better todo away with them all together, i just didnt think that was possibel. but it seems it now is, at least in oolite java scripting...

While in Visual studio 2005 C++, its not...

[Ramirez]

OK, next up, I need to set some mission briefing text along with the mission variable using a ship script - I cannot use a simple death_action for the same reasons as above. Over in the Scripter's Cove thread (page 10) there was some talk about the mission.setInstructionskey function, which I understand is meant to do the same as setMissionDescription. I'm not sure whether the problems with that function were ever actually resolved though, and the wiki is very sketchy in this area.

Here's what I've got so far:

Code: Select all

this.detonateBomb = function() 

  {
    missionVariables.trident_down = "BODARENKODEAD";
    player.commsMessage("setting variables!", 5);
    player.bounty = 500;
    mission.setInstructionsKey = ("trident_down_bodarenkoreturn", "trident_down");
}

All except the setInstructionsKey bit are working OK. Thoughts, anyone?

[Eric Walch]

OK, next up, I need to set some mission briefing text along with the mission variable using a ship script - ...Here's what I've got so far:

Code: Select all

    mission.setInstructionsKey = ("trident_down_bodarenkoreturn", "trident_down");

All except the setInstructionsKey bit are working OK. Thoughts, anyone?

Remove the equal sign should do the trick.

Code: Select all

    mission.setInstructionsKey("trident_down_bodarenkoreturn", "trident_down");

[Ramirez]

Hmm, that doesn't seem to be doing anything. I'm not getting any error reports so the syntax must be OK. Is there a working example that you could point me to - it could be that I'm not expressing the mission keys properly, though I'm using the same names as in the missiontext.plist.

[Eric Walch]

Hmm, that doesn't seem to be doing anything. I'm not getting any error reports so the syntax must be OK. Is there a working example that you could point me to - it could be that I'm not expressing the mission keys properly, though I'm using the same names as in the missiontext.plist.

Maybe I missed something, it seemed okay to me. You could look in UPS version 1.4.1 (the latest). I use something similar in file "upsPython.js".

Or maybe there is an other misunderstanding

mission.setInstructionskey function, which I understand is meant to do the same as setMissionDescription

. This are two different descriptions. The mission.setInstructionskey only sets the short description string on the F5-F5 page. In 1.70- it wat only possible from within the main script, but with 1.71+ you can set this from within any script. This way a killed target can instantly update the short mission description.

EDIT: Looking at the wiki I couldn't find the mission page at once. All the other objects have a separate page. I moved the "mission" stuff to its own object page and updated it to the 1.71 situation:
http://wiki.alioth.net/index.php/Oolite ... e:_Mission

[Ramirez]

Thanks for the mission page. It is the short description that I want (the one that goes on the F5 screen).

I think I may be having trouble because my main script is a legacy plist, and the only JS elements I have are three ship scripts to get around the original death_action problem. When searching for the worldScript I think Oolite will be looking for another javascript somewhere rather than going into the contents of the config folder.

Maybe its something to do with the worldScripts.plist. I don't have one at the moment, and so the legacy and javascripts have been working together with no problem. I'm guessing that this plist tells Oolite whether to use the legacy script in the config folder or the collection of javascripts in the scripts folder. However, even with javascript enabled it should still be able to pick up data from the missiontext.plist, shouldn't it?

Looking at the UPS example, I don't quite understand how specifying the worldScript of 'UPS_container' in upsPython.js makes Oolite look at the UPS missiontext.plist. I thought that as long as you specify the key correctly, text can be found no matter where abouts it is. Are there some fundamental differences between legacy and javascript that I'm missing here?

thanks again.

[Eric Walch]

Maybe its something to do with the worldScripts.plist. I don't have one at the moment, and so the legacy and javascripts have been working together with no problem. I'm guessing that this plist tells Oolite whether to use the legacy script in the config folder or the collection of javascripts in the scripts folder. However, even with javascript enabled it should still be able to pick up data from the missiontext.plist, shouldn't it?

I have no ready answer to this. I think 1.71 looks first in the worldScripts.plist. If present, it uses those scripts. If not it looks for a "script.js" in the config folder. If that is not there it uses "script.plist" in the config folder. This way you can have a JS and a legagacy script in the same config folder. One for use by 1.71 and one for 1.65.

One thing you could try is to move the legacy script to the "scripts" folder. Than you also should give it a more meaningful filename. This filename you then must add in a worldScripts.plist so the system will find it. (you can add .plist files to this list) This is also what I did in one of my early JS translations of UPS before everything was translated. In UPS 1.3 I had a legacy script at both places, one to be used by 1.65 and one for the 1.70+ version.

However, I'm not sure if this helps. When you look in the startup part of the logfile you see that all legacy script are in the list with worldScripts. When testing if a script is present with if(worldScripts.transportSchedule) it only finds the JS version and not the old plist versions. (to detect the plist scripts one needs an other method). It could be that defining it in a worldScripts.plist makes it a real worldScript. Just try. When you have the debug console installed you can just type: "worldScripts.trident_down" in the console window. At the response you will know if it is known.

EDIT:
I wanted to know so a test showed that adding the script.plist with the worldScripts.plist does not give it a status world script. The console still says "null".

However, I tried:

Code: Select all

mission.setInstructionsKey("my_Message","chaff_set")

in the console. "my_Message" is just a key of one of the mission.text files and "chaff_set" is listed as one of the legacy scripts in my system. This command does set the short_message in my F5-F5 screen.

I don't quite understand how specifying the worldScript of 'UPS_container' in upsPython.js makes Oolite look at the UPS missiontext.plist. I thought that as long as you specify the key correctly, text can be found no matter where abouts it is.

The reason that the worldScript is explicit mentioned is not to tell were to look for the mission text. (they are loaded in one big file on startup). The short description is stored in the save-file with the script-name as key. But when "setInstructionsKey() is called from outside the worldScript it does not know under witch script-name as key it should be stored. Adding this script-name as second parameter solves that problem.

[Ramirez]

Sorry, I've been really slow - I just noticed that I used capitals in the script key - ' Trident_Down'; once I changed everything to lower case it worked properly. I'm glad I don't have to translate the whole thing to javascript just to get this little bit working!

I should be well on the way to getting a 1.71.2-compatible version of this OXP out soon. I've applied your mission offering fix as well and with the help of the new debug console I'm finding it much easier to do testing.