Oolite Bulletins

Screet wrote:

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

Thanks, saw that after resolving other issues. Will include that with the original post.

Have a look at CaduceusAutorepair.js for that is where the examples came from. It's a horror show, and is long-past due for some tidying.

another_commander wrote:

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.

thanks for that, I will try that out, otherwise I won't be able to help test this thing if its crashing and its not showing in the logs, hopefully that qdb is the answer, and will pinpoint what is causing these crashing and hopefuly will yeld a fix, so downloaidng, and thanks

Screet wrote:

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

Screet, I assure you that this happens exclusively on your system and the reasons are probably related to having previously DEP enabled. Using gdb is the standard way of debugging not only Oolite, but any program running under GCC. The name of the lib you are getting is simply an indication that the crash happened while processing code outside of Oolite, which in most cases is, unfortunately, the result of Oolite passing invalid data, but can also be due to trashed stack or invalid calling conventions in functions etc.

OK, I only had that one crash within several hours of playing since I updated to 0.7 - and the best thing is: I am very sure that this was because I did update my savefile to reflect the changes made since I bought my Caduceus Omega.

I had that crash instantly after equipment was repaired - and when I just did look through the script, I noticed that the timer handling was everything but safe. Turning dep off will prevent Vista/XP from stopping Oolite when it tries to run on a deleted thing, but it won't prevent crashes if there's something going on in these parts which are still executed.

That's a good reason why it should not be enough to turn DEP off as a final solution to this timer thingy. Even if that stops most crashes from happening, it's everything but safe. It's just luck when it's not crashing under that condition.

Screet

Some interesting things are being found.

For example, in deep_space_pirates.js, this part adds a random pirate ship and makes them an offender. 1/3 of the time they are supposed to be clean instead.
THe issue is with the last line. Because == was used, that last line only uselessly checks if the bounty equals 0 (doing nothing regardless), so all ships end up being offenders, instead of 2/3 as intended.

That really should be fixed so that "bounty = 0;" is used instead.

Any odds on whether Eric will be willing to update the original OXP?

ok I have downloaded the package, but haven't a clue what to do, any pointers on how to get OoliteDevelopmentEnvironment_20090330 working? I have loads of directories, but now Im lost to starting the debugger, any help please? never done this before, so a step by step would be helpful, then I can start trying to work out what is causing the game to crash, thanks in advance

matthewfarmery wrote:

ok I have downloaded the package, but haven't a clue what to do, any pointers on how to get OoliteDevelopmentEnvironment_20090330 working?

All the information necessary for building Oolite from source using the prepackaged development environment can be found in this thread:
https://bb.oolite.space/viewtopic.php?t=5943
With the above, you should be able to build an oolite.exe from source. However, if you do not know what gdb is or what it does, then unfortunately you are not ready to use it yet. The point I was trying to make earlier is that there are ways to get better, more detailed logs of what happened when Oolite fails, but I don't think we can make them any higher-level than what they currently are. Which in turn means that some programming knowledge will be required if you want to go deeper into Oolite testing.

As I have said in the past, the Latest and stderr logs can catch and report errors for which the programmers have already made predictions. When crashes happen, it usually is exactly because we had not considered the consequences when a particular piece of code was written. It will be more normal receiving a crash suddenly without error reports than getting something in the log. Which is why some programming knowledge is necessary in my opinion for in-depth analysis and debugging.

pmw57 wrote:

Some interesting things are being found.

For example, in deep_space_pirates.js, this part adds a random pirate ship and makes them an offender. 1/3 of the time they are supposed to be clean instead.

Code: Select all

				if (pirates[i].bounty == 0 && Math.random() < 0.9) {
					// script added pirates are often clean. Make part of them offender. Clean ships will have cargo added.
					pirates[i].bounty = Math.round(Math.random() * 40) + 10;
				}
				if (pirates[i].AI == "pirateAI.plist") {
					pirates[i].switchAI("DSPpirateAI.plist");
					pirates[i].script.checkDSPlayer = this.checkPlayer;
				}
				if (pirates[i].cargoCapacity > 15 && Math.random() < 0.33) pirates[i].bounty == 0;

THe issue is with the last line. Because == was used, that last line only uselessly checks if the bounty equals 0 (doing nothing regardless), so all ships end up being offenders, instead of 2/3 as intended.

That really should be fixed so that "bounty = 0;" is used instead.

Any odds on whether Eric will be willing to update the original OXP?

I think that's clearly a typo. Best thing to do is to PM Eric about it.

Hi pmw57,

the new scripts give me quite some of these here, multiple of them:

[script.javaScript.warning.undefinedProp]: ----- JavaScript warning ("PlanetFall" 1.2): reference to undefined property this.rangeCheckTimer
[script.javaScript.warning.undefinedProp]: ../AddOns/A - OSE Main Data WiP V0.70.14.oxp/Scripts/PlanetFall.js, line 496.
[script.javaScript.exception.noProperties]: ***** JavaScript exception ("PlanetFall" 1.2): TypeError: this.rangeCheckTimer has no properties
[script.javaScript.exception.noProperties]: ../AddOns/A - OSE Main Data WiP V0.70.14.oxp/Scripts/PlanetFall.js, line 496.

Other than that, the V0.7 with that (pmw57's) script patch has reduced the crashes massively. Had one, while docked at the main station and saving

/report

L

crashing for me, hasn't really ended, still having a few, I also installed gdb debugger, (not complied from source yet, not had time, as Im helping another company beta testing a website generator program

anyway, had a couple of crashes, but managed to have gdb running for the second, its output is inluded in this zip along with oolite log

http://matthewfarmery.net/oolite/crashlogs.rar

I will compile from source at some point, see if I can give that a go, maybe it can give me more details, but OSE 0.7 hasn't been happy

Lestradae wrote:

Other than that, the V0.7 with that (pmw57's) script patch has reduced the crashes massively. Had one, while docked at the main station and saving

What are you doing that you are still experiencing crashes? I don't get any since modifying that caduceus ship script...

L, I just sent you the updated caduceus and landing script. There were some safety checks missing.

Need to test them, though.

The script updates from pwm interestingly give me some problems when they try to use remove instead of delete - thus I had to exchange remove for delete. Different js versions or some c&p typo that went unnoticed?

Screet

Commander McLane wrote:

pmw57 wrote:

THe issue is with the last line. Because == was used, that last line only uselessly checks if the bounty equals 0 (doing nothing regardless), so all ships end up being offenders, instead of 2/3 as intended.

That really should be fixed so that "bounty = 0;" is used instead.

Any odds on whether Eric will be willing to update the original OXP?

I think that's clearly a typo. Best thing to do is to PM Eric about it.

No idea why I missed this as this was already wrong with version 1.1. I now uploaded a corrected version 1.2.2.

Originally it was not mend to make part of them clean, but until oolite 1.73 all script added pirates were clean and I wrote that code part to give them a bounty.
But according the readme, pirates are regrouping outside the space lane and send clean members to the station with their loot. So it would make thing consequent to leave a part of the pirates clean.
For 1.73 this cleanness for script added pirates changed but this part I wanted to maintain.

Screet wrote:

The script updates from pwm interestingly give me some problems when they try to use remove instead of delete - thus I had to exchange remove for delete. Different js versions or some c&p typo that went unnoticed?

About 2 minutes after uploading I realised that remove is an invalid keyword, and that delete should be used instead. Such is the challenge of knowing multiple languages.

Now that I'm tidying up some of the scripts, I see several of them use
let variable = value;
when instead they should be
var variable = value;

It's a simple confusion because let is used in other languages, but it needs to be resolved amongst other things.

All will become clear in the next script update.

pmw57, can I suggest you and Screet have a talk together concerning the script updates? Because I am now getting them from both of you, and I guess four eyes see more than two eyes, and I am useless at checking the scripts except finding the most blatant errors or when gametesting.

Screet, you too? Please?

You have already bug-fixed the scripts of twenty oxps or so amongst you two - would be a real pity if some work was double-done or lost!

Cheers & keep up the good work

L

PS: I have to tell you that Realistic Shipyards in its V3.02b incarnation - the ancestor of OSE - has, two days before it was downloadable for a year, passed the 5000 downloads barrier!

I am really curious now what the OSE download numbers are going to be ...

if its stable, and fully working, I would say it would easy go past 3 times that amount,