(Release) Station Dock Control OXP

[phkb]

OK, Anonymissimus, here's another version for you to try. Version 0.12.3 can be downloaded here https://app.box.com/s/95trc6tq4oltb6lxrjybgq1746e6ls62

I think the problem has been with stations getting created during the "shipLaunchedFromStation" event (and others), rather than through the system populator routines. What I've tried to do is to minimise the workload when these stations are found, spreading it out through a number of iterations of the systemWillRepopulate event. Fingers crossed this works for you.

The other possibility is that the number of station OXP's you are running is putting too much drain on the system during the population phase. If that's the case I'll need to do some more radical surgery!

Let me know how you get on.

[Norby]

After a review of stationdockcontrol.js I think the root of these problems is a nested loop which can not finish before timelimit, especially if Stations for Extra Planets is installed.

The $checkForClearBay and $checkDepartureSlot functions are called often from randomized retry cycles and contain a cycle over a big array so sometimes need exponentially more time to finish, which hit the timelimit sooner on slower CPU and with more stations.

My suggestions:
1. Change the _systemDockingData array to two-dimensional where the first key is the number of the station in the system.station array. In this way you will check the slots of the current station only so can handle any number of stations without slowdown.
2. Before return false; you can do a linear search for the next free slot after the checked position. This cut the random retry cycle for a clear bay easily. For departure slot this is not simple, you need to build and maintain an index which contain the ships in departing order (also two-dimensional to separate stations), so maybe worth only if my first idea is not enough.

[phkb]

Thanks for the feedback Norby! And well done for going through that code and understanding it.

I'll think about how to do a two-dimensional array. Is the order of items in system.stations consistent between saves? I'm not sure. But I'll check this out and see what can be done. Thanks again.

[Norby]

The station key really should be the same even if new stations added by a newly installed OXP. A sure key is station.position, for example:

Code: Select all

this._systemDockingData = [];
var stationkey = station.position.x+"_"+station.position.y+"_"+station.position.z;
this._systemDockingData[stationkey] = [];

[phkb]

A sure key is station.position

I just ran some tests, and in most cases this is true. But just occasionally it isn't. For instance, I jumped into Ormadi in G6, a Multi-Gov system where I know a FTZ exists. In the "shipExitedWitchspace" function I ran through the system.stations array and out put the positions of each station found. I did this twice. Here's the results:

Code: Select all

Jump 1:
12:14:27.091 [StationDockControl]: Coriolis Station -- 73740.6015625_73117.4375_621809.8199462891
12:14:27.091 [StationDockControl]: Free Trade Zone -- 7446.484375_-15159.375_-199674.5625
12:14:27.092 [StationDockControl]: Kiota Habitat Station -- -171656.28125_-120421.2109375_869578.75
12:14:27.091 [StationDockControl]: Kiota Research Station -- -904317.25_-501376.59375_1668072
12:14:27.091 [StationDockControl]: Kiota Solar Station -- -1358905_-787624.9375_2555679.25
12:14:27.091 [StationDockControl]: Rock Hermit -- -9418.75_-15184.375_69392.078125
12:14:27.092 [StationDockControl]: Rock Hermit -- -574895.4375_-335465.3125_1521409.75
12:14:27.092 [StationDockControl]: Rock Hermit -- -1078491.5_-610021.0625_2228478.25

Jump 2:
12:23:13.403 [StationDockControl]: Coriolis Station -- 73740.6015625_73117.4375_621809.8199462891
12:23:13.403 [StationDockControl]: Free Trade Zone -- -21948.046875_107.8125_-179150.34375
12:23:13.403 [StationDockControl]: Kiota Habitat Station -- -171656.28125_-120421.2109375_869578.75
12:23:13.403 [StationDockControl]: Kiota Research Station -- -904317.25_-501376.59375_1668072
12:23:13.403 [StationDockControl]: Kiota Solar Station -- -1358905_-787624.9375_2555679.25
12:23:13.403 [StationDockControl]: Rock Hermit -- -9418.75_-15184.375_69392.078125
12:23:13.403 [StationDockControl]: Rock Hermit -- -574895.4375_-335465.3125_1521409.75
12:23:13.403 [StationDockControl]: Rock Hermit -- -1078491.5_-610021.0625_2228478.25

As you can see, for all but the FTZ the positions are identical. This means that FTZ's are being created in a more random way (which is probably a fault with the OXP), but it means I can't be absolutely certain about the position.

That doesn't mean this is a bust, though. All it means is that I need a different method of creating a key, using different elements of the station.

I have to say, though, that I rarely see the timeout issue, and I have SFEP installed, as well as Wildships, Constores, Rescue Stations, Random Hits, Commies, FTZ's, Anarchies, and Dictators, each of which add stations to the mix. The only time I've seen a problem is when stations are added outside the standard systemWillPopulate routine (as with FTZ). Changing the key lookup mechanic for the main data array is a substantial job which I might hold off on if the most recent update fixes the issue. If not, then the next update will be slightly longer in development!

[Anonymissimus]

I think the problem has been with stations getting created during the "shipLaunchedFromStation" event (and others), rather than through the system populator routines. What I've tried to do is to minimise the workload when these stations are found, spreading it out through a number of iterations of the systemWillRepopulate event. Fingers crossed this works for you.

The other possibility is that the number of station OXP's you are running is putting too much drain on the system during the population phase. If that's the case I'll need to do some more radical surgery!

I don't have many OXPs that add stations in systems generally. Only seedy space bars, rrs waystations and mining outposts. These three are static. Then deep space pirates can sometimes add a hermit (looks like it can happen while it flight), and pirate cove sometimes changes the type of a station while docked somewhere within the system (or docking/undocking...). I suspect one of these 2 OXPs clashes with SDC (but I don't want to test-remove them).

[Anonymissimus]

It seems your last version did the job. I don't seem to get that infinite loop (?) or those hangs anymore.

[phkb]

Well that's good news! I'll post an official update later this morning. Thanks for testing!

[edit] And done. Version 0.12.4 is now available via the download manager. This version fixes a couple of Javascipt bugs I found.

[phkb]

Version 0.13.0 of this OXP is now available in the usual places. There is one change in this version: an internal restructure of the data that will (fingers-crossed!) mean that there will be no more issues with timeouts. If this version proves to be reasonably stable then I think I'll call off the "beta" label.

[Astrobe]

Bad news:

Code: Select all

22:24:21.305 [script.javaScript.exception.unexpectedType]: ***** JavaScript exception (StationDockControl 0.13.0): TypeError: this._systemDockingData[system.ID] is not an object
22:25:01.337 [script.javaScript.exception.unexpectedType]: ***** JavaScript exception (StationDockControl 0.13.0): TypeError: this._systemDockingData[system.ID] is not an object
22:25:17.720 [script.javaScript.timeLimit]: ***** ERROR: Script "spicy_hermits_ship_script" ran for 1.96499 seconds and has been terminated.
22:25:43.102 [script.javaScript.exception.unexpectedType]: ***** JavaScript exception (StationDockControl 0.13.0): TypeError: this._systemDockingData[system.ID] is not an object
22:26:03.118 [script.javaScript.exception.unexpectedType]: ***** JavaScript exception (StationDockControl 0.13.0): TypeError: this._systemDockingData[system.ID] is not an object
22:26:23.134 [script.javaScript.exception.unexpectedType]: ***** JavaScript exception (StationDockControl 0.13.0): TypeError: this._systemDockingData[system.ID] is not an object
22:26:38.725 [script.javaScript.timeLimit]: ***** ERROR: Script "oolite-default-ship-script" ran for 1.50594 seconds and has been terminated.
22:26:44.466 [script.javaScript.exception.unexpectedType]: ***** JavaScript exception (StationDockControl 0.13.0): TypeError: this._systemDockingData[system.ID] is not an object
22:27:44.498 [script.javaScript.exception.unexpectedType]: ***** JavaScript exception (StationDockControl 0.13.0): TypeError: this._systemDockingData[system.ID] is not an object

At some point I began to see "Establishing communication with Station Control. Please stand by." in the Station Control MFD.

[phkb]

<swears under breath>
<sighs>

OK, let's try that again, shall we?

Version 0.13.1 of this OXP is now available in the usual places. There is one change in this version: an internal restructure of the data that will (fingers-crossed!) mean that there will be no more issues with timeouts (or Javascript errors). If this version proves to be reasonably stable then I think I'll call off the "beta" label.

[Astrobe]

It looks better now. I still have loads of log messages about timers being garbage-collected while running, but it's not clear to which OXP they belong since I have another alpha-stage OXZ installed that is a bit dirty.

One thing I didn't mention yesterday is that I did something perhaps a bit unusual: I was engaging jumps from within the exit tunnel. I have the GalNav OXZ installed, which auto-sets the next jump target in my route, so the enter/exit time is perhaps unusually short. I tried that again a couple of times today.

[phkb]

Apologies for the frequency of updates, but I think I've gotten on top of the timeout issues now in version 0.13.2, available from the usual places.

[phkb]

It appears I introduced some bugs in recent updates. I've been experimenting with seeing what happens when you stay in a system for a long time (2-3 hours) and all sorts of interesting things turned up, the most important of which were some significant bugs. In Version 0.13.4

• Fixed issue where docking shuttles were not being given a valid intra-system destination for when they next launch.
• Fixed faulty looping logic where a failsafe was included. Hitting the failsafe number of interations of the loop was not causing the loop to end.
• Fixed issue where launching ships were not being bumped in high-congestion states.
• Added way to allow some non-core roles to dock and be shown in the dock list.
• Function optimisation for (hopefully) better performance.
• Changed "==" comparisons to "===" for performance improvements.
• Better handling of null conditions in some routines.
• Bug fixes and code cleanup.

[phkb]

Version 0.13.5 has just been released. In this version:

• Added routines to let third party OXP's provide details of script properties they want SDC to make a note of so they can be relaunched with the same settings.
• Added routines to let third party OXP's provide details of their custom Javascript AI files so ships can be relaunched with the same AI.
• Fixed issue with recognising and storing the correct AI type for bounty hunter leaders.
• Added dock version of hornet_alt_npc.
• Updated "developer notes.txt" to include information about docking exceptions (introduced in version 0.13.4) and the two new abilities noted above.

Available from the download manager or via links in the first post.