Oolite Bulletins

pmw57 wrote:

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

pmw57 wrote:

Lestradae wrote:

pmw57 wrote:

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?

Eric Walch wrote:

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.

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
     
   }
}

pmw57 wrote:

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?

Eric Walch wrote:

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.

[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.

Eric Walch wrote:

pmw57 wrote:

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

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

Eric Walch wrote:

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.

pmw57 wrote:

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?

pmw57 wrote:

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

pmw57 wrote:

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?

Thargoid wrote:

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.

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.

this.startUp = this.reset = function ()

pmw57 wrote:

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?

Eric Walch wrote:

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.

• 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?

* 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?

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();

Lestradae wrote:

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.