Oolite Bulletins

For information and discussion about Oolite.
It is currently Mon Jul 24, 2017 4:32 pm

All times are UTC




Post new topic  Reply to topic  [ 181 posts ]  Go to page Previous 18 9 10 11 12 13 Next
Author Message
PostPosted: Mon Jan 04, 2016 8:58 pm 
Offline
Commodore
Commodore
User avatar

Joined: Tue Jan 21, 2014 10:37 pm
Posts: 1579
Location: [p]laying [h]ard and [k]icking [b]utt somewhere in G7...
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.

_________________
My OXP's


Top
   
PostPosted: Mon Jan 04, 2016 10:00 pm 
Offline
---- E L I T E ----
---- E L I T E ----
User avatar

Joined: Mon May 20, 2013 9:53 pm
Posts: 2307
Location: Budapest, Hungary (Mainly Agricultural Democracy, TL10)
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.

_________________
OXPs by Norby


Top
   
PostPosted: Mon Jan 04, 2016 10:20 pm 
Offline
Commodore
Commodore
User avatar

Joined: Tue Jan 21, 2014 10:37 pm
Posts: 1579
Location: [p]laying [h]ard and [k]icking [b]utt somewhere in G7...
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.

_________________
My OXP's


Top
   
PostPosted: Mon Jan 04, 2016 10:51 pm 
Offline
---- E L I T E ----
---- E L I T E ----
User avatar

Joined: Mon May 20, 2013 9:53 pm
Posts: 2307
Location: Budapest, Hungary (Mainly Agricultural Democracy, TL10)
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:
this._systemDockingData = [];
var stationkey = station.position.x+"_"+station.position.y+"_"+station.position.z;
this._systemDockingData[stationkey] = [];

_________________
OXPs by Norby


Top
   
PostPosted: Tue Jan 05, 2016 2:19 am 
Offline
Commodore
Commodore
User avatar

Joined: Tue Jan 21, 2014 10:37 pm
Posts: 1579
Location: [p]laying [h]ard and [k]icking [b]utt somewhere in G7...
Quote:
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:
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!

_________________
My OXP's


Top
   
PostPosted: Tue Jan 05, 2016 3:41 pm 
Offline
---- E L I T E ----
---- E L I T E ----

Joined: Mon Apr 27, 2015 9:03 pm
Posts: 276
Quote:
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).

_________________
warning sound if a missile is inbound: Missile warning


Top
   
PostPosted: Fri Jan 08, 2016 8:21 pm 
Offline
---- E L I T E ----
---- E L I T E ----

Joined: Mon Apr 27, 2015 9:03 pm
Posts: 276
It seems your last version did the job. I don't seem to get that infinite loop (?) or those hangs anymore.

_________________
warning sound if a missile is inbound: Missile warning


Top
   
PostPosted: Fri Jan 08, 2016 9:11 pm 
Offline
Commodore
Commodore
User avatar

Joined: Tue Jan 21, 2014 10:37 pm
Posts: 1579
Location: [p]laying [h]ard and [k]icking [b]utt somewhere in G7...
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.

_________________
My OXP's


Top
   
PostPosted: Fri Apr 22, 2016 1:39 pm 
Offline
Commodore
Commodore
User avatar

Joined: Tue Jan 21, 2014 10:37 pm
Posts: 1579
Location: [p]laying [h]ard and [k]icking [b]utt somewhere in G7...
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.

_________________
My OXP's


Top
   
PostPosted: Fri Apr 22, 2016 9:44 pm 
Offline
---- E L I T E ----
---- E L I T E ----

Joined: Sun Jul 21, 2013 12:26 pm
Posts: 424
Bad news:
Code:
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.


Top
   
PostPosted: Fri Apr 22, 2016 10:33 pm 
Offline
Commodore
Commodore
User avatar

Joined: Tue Jan 21, 2014 10:37 pm
Posts: 1579
Location: [p]laying [h]ard and [k]icking [b]utt somewhere in G7...
<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.

_________________
My OXP's


Top
   
PostPosted: Sat Apr 23, 2016 11:19 am 
Offline
---- E L I T E ----
---- E L I T E ----

Joined: Sun Jul 21, 2013 12:26 pm
Posts: 424
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.


Top
   
PostPosted: Tue Apr 26, 2016 12:13 am 
Offline
Commodore
Commodore
User avatar

Joined: Tue Jan 21, 2014 10:37 pm
Posts: 1579
Location: [p]laying [h]ard and [k]icking [b]utt somewhere in G7...
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.

_________________
My OXP's


Top
   
PostPosted: Fri May 20, 2016 11:21 pm 
Offline
Commodore
Commodore
User avatar

Joined: Tue Jan 21, 2014 10:37 pm
Posts: 1579
Location: [p]laying [h]ard and [k]icking [b]utt somewhere in G7...
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.

_________________
My OXP's


Top
   
PostPosted: Fri Jun 10, 2016 11:19 am 
Offline
Commodore
Commodore
User avatar

Joined: Tue Jan 21, 2014 10:37 pm
Posts: 1579
Location: [p]laying [h]ard and [k]icking [b]utt somewhere in G7...
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.

_________________
My OXP's


Top
   
Display posts from previous:  Sort by  
Post new topic  Reply to topic  [ 181 posts ]  Go to page Previous 18 9 10 11 12 13 Next

All times are UTC


Who is online

Users browsing this forum: Google [Bot] and 10 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum

Search for:
cron
Powered by phpBB® Forum Software © phpBB Limited