player.dockedStation.isMainStation not always valid

[Eric Walch]

Today I added a option in UPS to switch between the longRangeGalaxticChart and the missionscreen. It works very well: My boa mission now has an extra choice to look at the chart first before accepting the mission. When leaving the chart, the mission is shown again. It works OK but I noticed when a player launched from within the chart, the next error was logged:

Code: Select all

Exception: TypeError: player.dockedStation has no properties
Active script: "ups_container" 1.3.5  ups_container.js,
line 80:  if (player.dockedStation.isMainStation)

It was caused because the script now used "player.dockedStation.isMainStation" while in space. It was easy corrected by first testing if still docked before calling this routine, but I think it should not generate an error at all when called in flight.

[Hoopy]

that's a great option! Could random hits get it too?

please!

[Kaks]

@Eric: From a javascript point of view, if you're not docked, player.dockedStation should return false, and if it's false, it can't have any extra properties(like isMainStation). If you check you're on the main station by doing

Code: Select all

if (player.dockedStation && player.dockedStation.isMainStation)

javascript will notice that player.dockedStation is false, and will do the right thing without complaining, or generating any errors.

@Hoopy: Let's all ask LittleBear!

[Eric Walch]

that's a great option! Could random hits get it too?

please!

yes, but with unworkable restrictions. It is because legacy scripting only has the 10 second "tickle" timer.

Legacy and JS can jump to the chart with respectively:
setGuiToLongRangeChartScreen and player.call("setGuiToLongRangeChartScreen")

But in JS I set a timer to check every 0.5 second if the player has left the galaxtic chart. If yes I show the mission screen again. This goes fast. (I even switch the red cross on/off at this time, so it blinks)
In legacy it could take up to 10 seconds until the script gets a change to show the mission screen again. That pauses would be annoying.

@Eric: From a javascript point of view, if you're not docked, player.dockedStation should return false, and if it's false, it can't have any extra properties(like isMainStation). If you check you're on the main station by doing

OK, it is normal it generates errors. I now checked it sooner so I even do not call that routine. I just thought it should return false instead of an error. But maybe also put the check there as one never knows how this routine is called. now it also happened unexpected by a player launching in the middle of an mission screen.

[LittleBear]

The problem with Random Hits isn't so much allowing you to view the F6 screen before taking a hit (you can do this by selection Exit, look at the F6 screen launch and redock and your back on the BB). Its that every word in each briefing is generated by hundreds of independant dice roles (many of which have 150 to 500 sides!).

For example each character has a three to four word description (“a murderous furry bearoid” – for example). The chances just of hitting the JUST that same three word phrase again (never mind the whole mission) are less than the chances of making 4 Aces in holdem poker and then making 4 Aces again the next hand. As each mission is 200 – 300 words long the chances of hitting the same mission again are literally trillions to one. The pay does factor in that you may have to do some travelling. You can be lucky and the system is on your doorstep (or even the one you are currently in) or unlucky and its a 20 jump trek. Basically there is nothing hand-coded in the OXP. I didn’t actually type in any of the comms messages e-mails or mission briefings you see. The OXP just puts together random words using “rules” I’ve given it to make the words form a message that makes sense. I’m really relaying on the laws of chance for the missions to be fair, but you can get lucky or unlucky. On average a hit should take 6 – 7 jumps to reach with a pay of 300 – 9000 C. The odds are weighted however for higher paid hits to have victims with better ships, better equipment etc.

However as Oolite uses a seed rather than true dice roles, the sequence of “cards” dealt will repeat eventually provided you don’t make a H-jump. Thus, if you do not make a jump the same mission on a given page will come up again after flicking through the board a few times (ie you get 3-4 different easy, medium and hard missions on each docking without making a H jump). A jump resets the seed and then the chances of finding the same mission again are virually nill.

[Hoopy]

could you store the results of the dice rolls whilst the player is docked? Then clear them when they leave to prevent the save file being full of dice rolls. Is there some sort of volatile storage you could use so it wouldn't get into the save file at all?

[JensAyton]

@Eric: From a javascript point of view, if you're not docked, player.dockedStation should return false, and if it's false, it can't have any extra properties(like isMainStation).

Strictly speaking, player.dockedStation is null (the non-object) when you’re not docked. This is the Right Thing; it doesn’t make sense for player.dockedStation to be non-null when the player is not docked to any station. By the language definition, null has no properties, and there’s only one null.

Kaks’s solution using && is correct.

[LittleBear]

Off topic admittadley, but @Hoopy.

Yes I could, but this would mean that each docking would only give a choice of 3 different hits (rather than 9 - 12) and I was going for maxium variety. As you'll usually get a choice of 9 - 12 systems to make hits in (and all systems are always chosen from the Galaxy you are currently in), its a virtually certainy that on any docking you'll find a hit being offered reasonabley close. If I reduced it to 3 hits that remained the same until the player jumped, then the odds would be faily high that all three would involve a substantial trek. The hits will always come up again as long as you don't make a jump, but you may have to flick through the whole board a few times to find the hit you wanted.

[Hoopy]

hmm... perhaps a 'go to bed and come back the next day option' could reroll all the dice and increment the date?

actually, i minor moan - on the first hit the 3rd item is 'accept the contract', but on the 2nd and 3rd hits it's the 1st option. could you change this to make it consistant please

[Svengali]

could you change this to make it consistant please

No, he can't, Hoopy. Oolite switches the sorting order by itself. You can't control it from within an Oxp.

[Hoopy]

odd... I presume there's a good reason for that? Ahruman?

[JensAyton]

Sorry, haven’t a clue.

Edit: I go, I come back…
setMissionChoices: loads choices as a dictionary from missiontext.plist. It then iterates over the keys in the dictionary. Since a dictionary is an unordered collection, the order of results is undefined, but I’m a bit surprised that GNUstep changes it for a dictionary that has not itself changed.

Anywho, in Oolite 1.71 mission choices will be sorted by key. If you want them in some specific order, use keys like:

Code: Select all

"myOXP_mission1_choices" =
{
    "myOXP_mission1_response01" = "Yes";
    "myOXP_mission1_response02" = "A fish";
    "myOXP_mission1_response03" = "Never on a Thursday";
};

[Hoopy]

I guess an unordered dictionalry is the simplest implementation - that's a good enough reason for it being like that.

Good plan for the new version.

I guess I'd have implemented it as an ordered collection of name value pairs. OTOH I haven't done any coding in Oolite (yet...?) so my version wouldn't work at all!

[Eric Walch]

Anywho, in Oolite 1.71 mission choices will be sorted by key. If you want them in some specific order, use keys like:

Code: Select all

"myOXP_mission1_choices" =
{
    "myOXP_mission1_response01" = "Yes";
    "myOXP_mission1_response02" = "A fish";
    "myOXP_mission1_response03" = "Never on a Thursday";
};

Very useful. I already noticed that the sort order was sometimes different with the same call, so I already assumed it being random. But I look in my own mission code so it will be predictable sorted in version 1.71 upwards.

[JensAyton]

I guess I'd have implemented it as an ordered collection of name value pairs.

Thing is, property lists (and the Foundation framework) don’t have an ordered-pairs collection, so you’d either have an array of two-element arrays, a separate array specifying sort order, or (as I did) sort by key.