Oolite Bulletins

Posted: **Mon Oct 12, 2009 2:48 pm**

pmw57 wrote:
Commander McLane wrote:
pmw57 wrote:
Has anyone tested using playerWillEnterWitchspace to clean up the timer ecents?
Yes, as mentioned earlier.
Code: Select all
this.playerWillEnterWitchspace = function()
{
	this.findPlayer.stop()
	delete this.findPlayer
}
findPlayer is (obviously) the name of the timer.
Lestradre - are you up to producing a point release with this fix, so that the DEP hack is no longer required?

Nope

I'm just the librarian here, remember?

Posted: **Mon Oct 12, 2009 4:40 pm**

this build has become unstable, had two crashes within a short period of time, one when I had hyperradio playing and was approaching Ritila station, and the other when I managed to get their a second time, was when I just left the same station and another crash,

log files of both crashing events

http://www.matthewfarmery.net/oolite/Logs.rar

and yes DEP is disabled, at least for oolite

Ignore for now, I used my previous save game, starting afresh seems to have fixed the issue, so far so good, but will update once I know more

edit
damn still crashing, now its getting annoying, was in a dog fight and it crashed, something is unstable or buggy compared tio the previous build

http://matthewfarmery.net/oolite/Latest2.rar
log of the crash

Posted: **Mon Oct 12, 2009 6:25 pm**

matthewfarmery wrote:
log files of both crashing events

Hmmm. I could see nothing in the log. If the game crashes, please do also check if stderr exists and if there's anything in it that might hint at what happened.

I've just done only one flight for a random hits mission, that went without any problems.

First thing after that flight was that I did cut all the showplayer-stations scripts out, except that for the station I own.

FPS went up from 36 to maximum refresh rate - L, we really need a better solution for this problem! Interesting is, that my machine wasn't really busy, but somehow these scripts did slow down the refresh rate?!?

Screet

Posted: **Mon Oct 12, 2009 6:33 pm**

stderr is empty, I guess that is another crash dump file? is there anyway to get oolite to write to the file? as I suffered another crash, as I previously put, not sure what to do, to track down what is causing it to crash

Posted: **Mon Oct 12, 2009 6:42 pm**

matthewfarmery wrote:
stderr is empty, I guess that is another crash dump file? is there anyway to get oolite to write to the file? as I suffered another crash, as I previously put, not sure what to do, to track down what is causing it to crash

Yes, stderr sometimes has info that doesn't go to the log. If it's not there, nothing happened that would have been written to it.

Grrr...that crash behaviour sounds like that which I had to hunt down...but since solving that, I did not encounter any more crashes. However, with 0.7 I only made two flights so far.

Hmm. Just two ideas:
1) Please verify that you have none of the oxp's L did mention in his message in your addons folder (as they are included and having them twice might cause trouble)
2) If that did not help...you write that you were listening to your hyperradio? I never did own one...could you make a backup of your savefile and then remove the hyperradio from there or sell it and see if that changes anything?

L, have a look at this pirate cove:

Code: Select all

[dumpState]: State for <StationEntity 0x18b0ee60>{"Rock Hermit" "Rock Hermit" ID: 352 position: (13412.5, 18219.9, 114039) scanClass: CLASS_ROCK status: STATUS_IN_FLIGHT}:
  [dumpState.entity]: Universal ID: 352
  [dumpState.entity]: Scan class: CLASS_ROCK
  [dumpState.entity]: Status: STATUS_IN_FLIGHT
  [dumpState.entity]: Position: (13412.5, 18219.9, 114039)
  [dumpState.entity]: Orientation: (1 - 0i - 0j - 0k)
  [dumpState.entity]: Distance travelled: 0
  [dumpState.entity]: Energy: 1000 of 1000
  [dumpState.entity]: Mass: 6.15494e+007
  [dumpState.entity]: Owner: <StationEntity 0x18b0ee60>{"Rock Hermit" "Rock Hermit" ID: 352 position: (13412.5, 18219.9, 114039) scanClass: CLASS_ROCK status: STATUS_IN_FLIGHT}
  [dumpState.entity]: Flags: isShip, isStation, isSunlit
  [dumpState.shipEntity]: Name: Rock Hermit
  [dumpState.shipEntity]: Display Name: Rock Hermit (100 Cr)
  [dumpState.shipEntity]: Roles: <OORoleSet 0x1be68d48>{pirate-cove rockhermit(0.25) station}
  [dumpState.shipEntity]: Primary role: pirate-cove
  [dumpState.shipEntity]: Script: <OOJSScript 0x1be6b8b8>{"Pirate Cove Rock" version 1.2}
  [dumpState.shipEntity]: Subentity count: 8
  [dumpState.shipEntity]: Behaviour: BEHAVIOUR_IDLE
  [dumpState.shipEntity]: Target: <StationEntity 0x18bff320>{"Trade Outpost" "Trade Outpost" ID: 275 position: (117744, -5740.72, 698592) scanClass: CLASS_STATION status: STATUS_ACTIVE}
  [dumpState.shipEntity]: Destination: (0, 0, 0)
  [dumpState.shipEntity]: Other destination: (0, 0, 0)
  [dumpState.shipEntity]: Waypoint count: 0
  [dumpState.shipEntity]: Desired speed: 0
  [dumpState.shipEntity]: Thrust: 100
  [dumpState.shipEntity]: Fuel: 0
  [dumpState.shipEntity]: Fuel accumulator: 1
  [dumpState.shipEntity]: Missile count: 0
  [dumpState.shipEntity.ai]: AI:
    [dumpState.ai]: State machine name: pirateCoveAI.plist
    [dumpState.ai]: Current state: ATTACK
    [dumpState.ai]: Next think time: 289.277
    [dumpState.ai]: Next think interval: 0.125
  [dumpState.shipEntity]: Frustration: 0
  [dumpState.shipEntity]: Success factor: 0
  [dumpState.shipEntity]: Shots fired: 0
  [dumpState.shipEntity]: Time since shot: 100252
  [dumpState.shipEntity]: Spawn time: 36.791 (252.384 seconds ago)
  [dumpState.shipEntity]: Hull temperature: 60
  [dumpState.shipEntity]: Heat insulation: 1
  [dumpState.shipEntity]: Flags: canFragment
  [dumpState.stationEntity]: Alert level: yellow
  [dumpState.stationEntity]: Max police: 8
  [dumpState.stationEntity]: Max defense ships: 5
  [dumpState.stationEntity]: Defenders launched: 2
  [dumpState.stationEntity]: Max scavengers: 1
  [dumpState.stationEntity]: Scavengers launched: 0
  [dumpState.stationEntity]: Docked shuttles: 0
  [dumpState.stationEntity]: Docked traders: 0
  [dumpState.stationEntity]: Equivalent tech level: 1
  [dumpState.stationEntity]: Equipment price factor: 4.5
  [dumpState.stationEntity]: Flags: no_docking_while_launching

It did not want to launch ships at me, but after I did dock, they were waiting outside for me.

However...look at it's target! What kind of scanner range does that thing have? Targeting the systems main station from almost W buoy???

Screet

Posted: **Mon Oct 12, 2009 8:27 pm**

Lestradae wrote:
pmw57 wrote:
Lestradre - are you up to producing a point release with this fix, so that the DEP hack is no longer required?
Nope

I'm just the librarian here, remember?

Well then, if you're anything like the librarian that I hold great respect for, I won't put you wrong.

Here is the ose-0.7-script-cleanup.7z

Every script that invokes timers now has them cleaned up as well, with the following sort of code:

Code: Select all

this.playerWillEnterWitchspace = function() {
    if (this.buoyTimer) {
		this.buoyTimer.stop();
		remove this.buoyTimer;
	}
};

Posted: **Mon Oct 12, 2009 10:39 pm**

Thanks pmw57, as ever, very cool

Will implement the new scripts and take them for a test drive!

Cheers

L

PS: Wow

Just noticed you'd repaired about fifteen scripts or so ... if you ever get to Vienna, forget the stiff drink, I'm getting you drunk for a week

Posted: **Tue Oct 13, 2009 4:44 am**

downloading, looking forward to it finishing!!! even at 103kb/sec we're looking at almost an hour. *^^*

Posted: **Tue Oct 13, 2009 9:24 am**

Hey nijineko,

welcome back!

Feel free to update the downloaded version with pmw57's script update above your posting, and if you are on a windows system, you should really switch the frakkin' DEP off for Oolite.exe ...

Have fun & please report here if testing shows up anything unwanted,

L

Posted: **Tue Oct 13, 2009 9:36 am**

Lestradae wrote:
Have fun & please report here if testing shows up anything unwanted,

Interestingly, I yesterday had one crash when I did enter combat and nothing did show up in the logs.

However, there were two new things going on:
1) as I heard that an earlier version of the hyperradio would produce similar crashes, I bought one for a test (the OSE version seems to be the proper one, though)
2) I noticed that my old caduceus package did not contain auto-repair and thus did add the damage control node to my save file. At the very last frame before the crash I did get the report that one of my three damaged systems has been repaired.

Since then I've flown another two hours or so, makes about one crash in five hours. Still too much for my liking, but without enough crashes it'll be difficult to see a pattern.

Screet

Posted: **Tue Oct 13, 2009 10:29 am**

its also impossible to sell the hyperradio, at least from what I can see, I can buy more but can't sell them, is that intended? I tried again a little later on, this time no crashes, I will test again, but it seems that the log files aren't showing anything useful, is there anything that can change, so that a crash produces a more interesting and detailed log of what went wrong? otherwise its going to be impossible to track down what is causing these crashes

Posted: **Tue Oct 13, 2009 10:38 am**

matthewfarmery wrote:
but it seems that the log files aren't showing anything useful, is there anything that can change, so that a crash produces a more interesting and detailed log of what went wrong? otherwise its going to be impossible to track down what is causing these crashes

Yes, the solution is called gdb and it can give you a backtrace of what went wrong, including the exact line where it stopped in the code. You need a build environment to use it. Information about gdb can be found here. A complete development environment for Oolite for Windows can be downloaded from here, or alternatively, here.

Posted: **Tue Oct 13, 2009 10:46 am**

When adding the timer cleanup code I noticed a few things about the scripts that I was working with.

Code: Select all

let eqCounter = 0; // Syntax error, let is an invalid keyword
var eqCounter = 0; // Should be this

and, switch statements. Before:

Code: Select all

	switch(this.fixedItem) {
		case "EQ_FRAME_FUEL_COLLECTOR":
			{ // Should be a statement, not a block
			if(worldScripts["Fuel Collector"]) 
				{
				...
				break; // Should be mandatory, not conditional
				}
			} // shouldn't be here either
		case "EQ_FRAME_BOUNTY_SCANNER":

And after

Code: Select all

	switch(this.fixedItem) {
		case "EQ_FRAME_FUEL_COLLECTOR":
			if (worldScripts["Fuel Collector"]) {
				...
			}
			break;
		case "EQ_FRAME_BOUNTY_SCANNER":

Not to mention the number of lines missing semicolons, functions with separated parenthesis and other oddities.

None of these changes result in a change of behaviour. Instead, they bring the code to a consistent and coherent presentation that benefits the reader, as well as the interpreter.

Edit: www.jslint.com is being used to ensure that most obvious issues are corrected.
Edit 2: included a fix for the break statement as well

Posted: **Tue Oct 13, 2009 10:58 am**

another_commander wrote:
Yes, the solution is called gdb and it can give you a backtrace of what went wrong, including the exact line where it stopped in the code.

As I did very often state, that only gives the name of some third party library and nothing else, at least on my system. Maybe the timer/DEP issue could be cured if someone else does get more info out of gdb.

And, yes, I do make and run debug builds for gdb, and they are about 4 times larger than the normal build. However, I always get the name of the same lib in bt, both at the beginning and at the end, and no other info in between.

Screet

Posted: **Tue Oct 13, 2009 11:01 am**

pmw57 wrote:

Code: Select all

	switch(this.fixedItem) {
		case "EQ_FRAME_FUEL_COLLECTOR":
			if (worldScripts["Fuel Collector"]) {
				...
				break;
			}
		case "EQ_FRAME_BOUNTY_SCANNER":

At least for C++ this would be a problem:

If the break does not happen before the next case, the code from the next case is also being executed.

Screet

Oolite Bulletins

The Oolite Extended Project - Fork, no oxp

Re: ..

Re: ..

..

..

Re: ..