The Oolite Extended Project - Fork, no oxp

[Eric Walch]

Even more usefully, there is this.reportScreenEnded() event handler which fires when the resports screens are all done, so mission screens can then be activated after that.

http://wiki.alioth.net/index.php/Oolite ... creenEnded

There is not always a report. The main difference between old and new scripting is that with the old you could just skip doing your job until it was safe to do your stuff as the script triggered every 10 seconds.

JS is completely event driven so when skipping something we must be sure there will be a new event to react on.

So basically we display on the docking event but when one of the three above mentioned situations occurs we skip showing. All three occasions will generate an event when ready. The script must than just check if no other script reacted sooner on that event. But in that case there will be a new event.

[Diziet Sma]

What's the hasing ritual for obtaining such an account?

I think it involves contacting (summoning, evoking, conjuring up, channeling) winston.

I could have sworn that I had already. What happens when a PM sits in the outbox and doesn't do anything?

It means the recipient hasn't read it yet.. it will disappear from your outbox when he opens it.

[pmw57]

So basically we display on the docking event but when one of the three above mentioned situations occurs we skip showing. All three occasions will generate an event when ready. The script must than just check if no other script reacted sooner on that event. But in that case there will be a new event.

Does that mean that this information from http://wiki.alioth.net/index.php/OXP_mi ... ne_with_JS is still the best advised way to offer a mission screen when docked?

Code: Select all

this.shipWillDockWithStation = function(station)
{
   if(missionVariables.offering) missionVariables.offering = null;
   /* When using the missionVariables.offering variable in script you need this function to clear the
   variable in case the player launched from within the missionscreen without making choices. By clearing
   this, most scripts that are created acording this layout will automatic do the offer again.
   */
   
   /*
   This is also the place to add your messages to the arrival report with:
   if(condition) player.addMessageToArrivalReport(expandDescription("Your message"));
   */
}

this.shipDockedWithStation = function(station)
{
       // an other eventhandler cauld have launched the ship already when it fires for this script.
       if(player.ship.docked) this.missionOffers();
}

this.missionScreenEnded = this.missionChoiceWasReset = this.reportScreenEnded = function()
{
   if(!player.ship.docked) return;
   if(mission.choice) this.choiceEvaluation();
   this.missionOffers();
}

this.missionOffers = function()
{
   if (guiScreen == "GUI_SCREEN_MISSION" || guiScreen == "GUI_SCREEN_REPORT") return; 
	// there will be a "missionScreenEnded" or "guiScreenChanged" in future to react uppon.
   if (missionVariables.offering || (mission.choice && mission.choice != "")) return;
	// when "missionVariables.offering" or "mission.choice" are present it means that an other script claimed the mission_screen.
   if (player.ship.dockedStation.isMainStation)
   {
       //  Your stuff for the main station
   }
   else if (player.ship.dockedStation.shipDescription == "My Station")
   {
       // Your stuff for a special named station
     
   }
}

[Eric Walch]

Does that mean that this information from http://wiki.alioth.net/index.php/OXP_mi ... ne_with_JS is still the best advised way to offer a mission screen when docked?

Yes, that script I maintained within UPS-courier as example and to my knowledge it anticipates on all possibilities and would give the most compatible script. But as the "this.reportScreenEnded" handler was only added with oolite 1.73, it needs at least this version.

The use of missionVariables.offering is only added to create a way to claim the next missionpage in a multipage offer. With JS you could also do that by giving the mission.choice a value even when you don't use choices. Both are mend to notify other scripts they should wait with their offer. But I prefer the missionVariables.offering as this shows more clearly that a script is still busy with an offer.

In your Hoopy translation you never cleared the mission.choice. That is good as all other scripts that also has a page for display should be delaying their display as long as hoopy s active. Only when the player decides to leave the hoopy playfield, the choice is reset and this allows other scripts to show a page.

Of course this only works with other scripts that also do things according this rules and respect other scripts. The way above script is set up, it should be able to recover from other scripts overwriting its missionpage by redoing an offer when the player launches and docks again.

[Svengali]

FINAL EDIT. I now removed both ups and vector and added the following line in my test oxp:

Code: Select all

this.shipWillDockWithStation = function()
{
    if(player.ship.docked) log(this.name, "Player is docked")
}

The result is false so nothing is logged. But only the fact I check for player.ship.docked during this handler triggers the bug and I am not visually docked.

Do you have something in your Log, Eric? On my machine

Code: Select all

[general.error.inconsistentState]: ***** ERROR: status is STATUS_DOCKING, but dockedStation is nil; treating as not docked. This is an internal error, please report it.
[general.error.inconsistentState]: ***** ERROR: status is STATUS_IN_FLIGHT, not STATUS_DOCKED, but dockedStation is not nil; treating as docked. This is an internal error, please report it.

After docking I've got a black screen (HUD is inactive like docked, but no other info) and the other screens are accessible and I can launch.

[pmw57]

The use of missionVariables.offering is only added to create a way to claim the next missionpage in a multipage offer. With JS you could also do that by giving the mission.choice a value even when you don't use choices. Both are mend to notify other scripts they should wait with their offer. But I prefer the missionVariables.offering as this shows more clearly that a script is still busy with an offer.

Okay, I have a few questions, but really they should be handled on the discussion page of the wiki.

this.mustPopulate is a clever idea. I was not aware that ships remain in the system while docked, though it now makes sense.

The script conversion for Lestradae will need to be modified so that these "basic fundamentals" are applied. I should double check though Eric, without the mustPopulate technique, when you enter from witchspace some ships are populated with for example:

Code: Select all

system.legacy_addShipsAt('INRA', 1, 'pwu', [0, 0, 0.7]);

Question 1: The original plist code often has the same ships populating both when you enter from witchspace, and when you leave the station. If the javascript does this on shipWillExitWitchspace as well as shipWillLaunchFromStation, (enter from witchspace, dock, undock) does that mean that a duplicate set of ships is now populated in the system?

Question 1a If the above scenario is the case, is that then what inspired the use of this.populate ?

Question 2: It appears that there are a lot of edge-cases that the standard mission code must make allowance for. Should the intended paths (pave the cow paths) be mentioned up front before the script, so that others are more aware of why they should use those techniques? This would also help inspire others to come up with potentially better solutions.

Something like:

Along with handling missions, this mission script also protects things in the following manner:

• adds ships to the system if you've loaded from a save game
• uses an offering variable to ensure that we don't process responses from other scripts
• clears the offering variable before docking. in case the player departed from a mission page
• Ensures that ships aren't mistakenly added in interstellar space

Question 3: I am puzzled by the comment in startup section

Code: Select all

    this.reset(); // this.reset() fires not for a cmdr Jameson. When needed for a Jameson, call it here.

Would you kindly elaborate? Is that a statement about why things are done that way, or a warning that certain situations will require additional code to work properly?

Or in short, what gives?

[Thargoid]

Although the same principles are valid for JS:
1) Never create a mission page when an important page is shown. (That are mainly the mission-screen and the arrival_report-screen as those content is lost by overwriting)
2) Never use the mission.choice variable when it contains a value that your script has not generated as that can contain a value that must be read by an other script.

If I may add one:

3) Clean up the mission.choice variable when you have finished with it. If your choice is present and acted upon then reset it to null. But if the choice in it isn't yours, then leave it be for some other OXP to deal with and clean-up.

[Thargoid]

Question 1: The original plist code often has the same ships populating both when you wnter from witchspace, and when you leave the station. If the javascript does this on shipWillExitWitchspace as well as shipWillLaunchFromStation, (enter from witchspace, dock, undock) does that mean that a duplicate set of ships is now populated in the system?

Yes, unless your code is clever enough you will end up with duplication (and if you keep docking and undocking, eventually a very full system). You can of course get over this by only using shipWillExitWitchspace but that they doesn't deal with first undocking after a reload. To overcome that you can use a flag variable to say you've already done things.

Question 2: It appears that there are a lot of edge-cases that the standard mission code must make allowance for. Should the intended paths (pave the cow paths) be mentioned up front before the script, so that others are more aware of why they should use those techniques? This would also help inspire others to come up with potentially better solutions.

Something like:

Along with handling missions, this mission script also protects things in the following manner:

• adds ships to the system if you've loaded from a save game
• uses an offering variable to ensure that we don't process responses from other scripts
• clears the offering variable before docking. in case the player departed from a mission page
• Ensures that ships aren't mistakenly added in interstellar space

That sounds like you're asking for a whole heap of trouble, or at least breaking almost every existing mission/ship OXP in existence. All of this can be dealt with by a properly written OXP populator script, see above.

Question 3: I am puzzled by the comment in startup section

Code: Select all

    this.reset(); // this.reset() fires not for a cmdr Jameson. When needed for a Jameson, call it here.

Would you kindly elaborate?

Currently if you use a "new Jameson" (ie if you don't load a save game), this.reset() doesn't fire. this.startUp is triggered when the game is initially loaded, but this.reset only kicks when a save game is loaded and/or you die (and go back to the default base Jameson).

There is planning to depreciate (remove) this.reset in the future and have the scripts reloaded when a save game loading/death occurs, which will mean that this.startUp will trigger instead in those cases.

[pmw57]

That sounds like you're asking for a whole heap of trouble, or at least breaking almost every existing mission/ship OXP in existence. All of this can be dealt with by a properly written OXP populator script, see above.

I think that we're at cross-purposes here.

My intention is for there to be a summary for the js mission code, in wiki text just above the script, that summarises the main points and issues that the code correctly handles.

[Kaks]

There is planning to depreciate (remove) this.reset in the future and have the scripts reloaded when a save game loading/death occurs, which will mean that this.startUp will trigger instead in those cases.

I can confirm that's the case.

The distinction between this.startUp & this.reset has now been eliminated in trunk, and given that most js scripts already have

Code: Select all

this.startUp = this.reset = function ()

There probably won't be too many problems updating that bit of js when 1.74 gets released.

Talking about js changes, there's going to be a few more improvements to the js API in 1.74. I'm just testing some of those improvements, and should be able to give you a proper update in a couple of days...

[Eric Walch]

without the mustPopulate technique, when you enter from witchspace some ships are populated with for example:

Code: Select all

system.legacy_addShipsAt('INRA', 1, 'pwu', [0, 0, 0.7]);

Question 1: The original plist code often has the same ships populating both when you wnter from witchspace, and when you leave the station. If the javascript does this on shipWillExitWitchspace as well as shipWillLaunchFromStation, (enter from witchspace, dock, undock) does that mean that a duplicate set of ships is now populated in the system?

I think this question is already answered by others. In the original script there were a few anomalies that made that some ships were added on every launch. Your JS translation in this was correct in the way it did exactly the same as the original. Without seeing the original oxp I can not see if this is intentional or a bug, therefor I did not comment on that. I still think that bugs must be fixed in the original oxp to begin with so you have a context for the oxp and not first in a copied bundle.

System is only populated on first entry. And that is always from the witchspace side with exception of the first launch after reloading (or starting) a new game. So instead of a (relative) time consuming scan for all entities on every launch, it is more efficient to flag this first launch.

And all scans for custom ships on witchspace entry have always been useless as the outcome would be by definition 0. But bear in mind that most scripts were made by people that did know the details and just copied existing scripts, and sometimes copied stuff that they didn't need. And those bugs were copied again by others. So never assume that an existing script is correct.

[pmw57]

System is only populated on first entry. And that is always from the witchspace side with exception of the first launch after reloading (or starting) a new game. So instead of a (relative) time consuming scan for all entities on every launch, it is more efficient to flag this first launch.

And all scans for custom ships on witchspace entry have always been useless as the outcome would be by definition 0. But bear in mind that most scripts were made by people that did know the details and just copied existing scripts, and sometimes copied stuff that they didn't need. And those bugs were copied again by others. So never assume that an existing script is correct.

Thanks Eric.

Okay, after around 18 hours of sleep + work, I'll work on recoding the ose.js script so that it does things the proper way.

The issues as I see them with the existing OSE script (both plist and js) are:

• Some ships don't get added to the system when you load a save game. They only appear after your next witchjump
• Some ships get added every time you leave a station. Dock and leave a station 6 times, and you can have 6 more of these ships flooding the system
• Some ships are supposed to appear in interstellar space, but most aren't
• Free Trade Zone does different things depending on exiting the station, or exiting witchspace. Are these differences supposed to be there?

Lestradae - can you please provide me with a list of which ships are supposed to do what, based on the above differences.

These are all of the related ships in the current existing code:

Added in witchspace jump, but not from save game
this.addFrogRickshawShip();
this.addMissionaryShips();
this.addClipperShip();
this.addDredgerShip();
this.addExecutiveFlightShips();
this.addSalezaShips();
this.addSuperCobraShips();
this.addIxianShips();
this.addHardPirateShips();
this.addBehemothShips();
this.addFreeTradeZoneExitWhitespace();
this.addPirateCove();
this.pimpMySystem();

Multiple possible duplicates on every dock/departure
this.addOoBayShips();
this.addInraPatrolShips();
this.addNavyPatrolShips();

Which of the above ships are you aware of that are allowed to appear in interstellar space.

Free Trade Zone from witchspace
1 x pirate @ 25% chance
3 x ftzpirate @ 100%, 70% and 30% chance
2 x ftzhauler @ 50% and 25% chance

Free Trade Zone extras on every exit from station
1 x pirate @ 50% chance
1 x ftzpirate @ 25% chance
2 x ftzhauler @ 50% and 25% chance
1 x police @ 10% chance

I suspect that this needs to change to be a consistant set of rules for the ships, regardless of entry from witchspace, station, or save game. Is that right?

[Eric Walch]

And there are the lines:

Code: Select all

 conditions=(
	"status_string equal STATUS_EXITING_WITCHSPACE",
	"planet_number greaterthan 0"
	);

that correctly translated to:

Code: Select all

	if (!system.isInterStellarSpace && system.ID >= 1)

I don't know the oxp but is it deliberate that system 0 is excluded? or was it mend to be:

Code: Select all

 conditions=(
	"status_string equal STATUS_EXITING_WITCHSPACE",
	"planet_number greaterthan -1"
	);

like the other code. In witchspace is: planet_number equal -1. In that case it would just translate to:

Code: Select all

	if (!system.isInterStellarSpace)

[Lestradae]

I obviously overlooked some stuff that comes to light now. Well, that's what this thread is for, and again: Thanks guys.

Eric, please simply say it whenever you find something in the OSE code that you find strange. Always. Irrelevant if it affects an original oxp or not. I will often try to inform the original oxps creators about troubles that appeared in their scripts also. And every little bit helps, even if it should turn up as false positive from time to time.

pmw57, you wrote:

* Some ships don't get added to the system when you load a save game. They only appear after your next witchjump
* Some ships get added every time you leave a station. Dock and leave a station 6 times, and you can have 6 more of these ships flooding the system
* Some ships are supposed to appear in interstellar space, but most aren't
* Free Trade Zone does different things depending on exiting the station, or exiting witchspace. Are these differences supposed to be there?

Most of these differences are not at all supposed to be there.

All the stuff you listed should simply always be there, once, unduplicated, irrelevant if you launch from a station the first or umpteenth time or if you come in from a jump. Everything:

this.addFrogRickshawShip();
this.addMissionaryShips();
this.addClipperShip();
this.addDredgerShip();
this.addExecutiveFlightShips();
this.addSalezaShips();
this.addSuperCobraShips();
this.addIxianShips();
this.addHardPirateShips();
this.addBehemothShips();
this.addFreeTradeZoneExitWhitespace();
this.addPirateCove();
this.pimpMySystem();
this.addOoBayShips();
this.addInraPatrolShips();
this.addNavyPatrolShips();

The same holds true for the Free Trade Zone and all its inhabitants etc.

There is the question which ships should appear in interstellar space! It is btw not deliberate that planets = 0 are included - I thought that would denominate interstellar space - so "-1" it has to be instead.

These here should appear in interstellar space:

this.addMissionaryShips();
this.addDredgerShip();
this.addHardPirateShips();
this.addBehemothShips();
this.pimpMySystem();
this.addNavyPatrolShips();

... and all others shouldn't!

Ah - and I took out the Behemoth ships spawning anyways and used Eric's new-ishly modified (from Giles/aegidian) script for them to appear instead.

Hope I am understandable

Cheers

L

[pmw57]

Ah - and I took out the Behemoth ships spawning anyways and used Eric's new-ishly modified (from Giles/aegidian) script for them to appear instead.

I take it that this means that the ose.js code relating to the behemoths should not be there.

About the FTZ, there are currently two different sets of rules regarding it. How do you wish to combine them? Something like this?

1 x pirate @ 25% chance
3 x ftzpirate @ 100%, 70% and 30% chance
2 x ftzhauler @ 50% and 25% chance
1 x police @ 10% chance