Oolite Bulletins

Very cool!

Wow, just wow!

Operation completed
Amazed and proud on Oolite as it is today

I think I just found a bug with the GRS Armadillo's logic when replacing buoys.

I arrived at a system with no Nav Buoy (not my fault!!) and just as I neared the station 2 Armadillos launched with a replacement buoy each. The first one flew out and replaced the missing buoy while the second one is still hovering just outside the station entrance with its load... presumably waiting for the nav buoy to get destroyed again so it can replace it. In the meantime it appears to be idling and stopping traffic to/from the station.

Micha wrote:

I think I just found a bug with the GRS Armadillo's logic when replacing buoys.

I arrived at a system with no Nav Buoy (not my fault!!) and just as I neared the station 2 Armadillos launched with a replacement buoy each.

Wrong, it's an Oolite bug. The OXP really gives a single launch command!

I had a lot of troubles in bypassing this bug. The bug is introduced in system 1.71. Whenever an AI orders a launch with a main station, two ships launch.
I wrote this OXP with 1.70 where were all the launches worked perfectly. When 1.71 was released, several things around the main station launches were buggy. Not only my launches but also system ship launches. I had not yet released the stuff and looked for ways to reduce the damage. There is now special code in that detects the second launch and sends that ship directly home to prevent double buoy release.

After I wrote al that stuff I noticed that, when I give the same launch command with a JS "call" instruction, I just get a single launch. I knew the "call" option would be removed with 1.72 so in the release version there is a check for 1.71 were I use the "call" to launch the tugger. When in 1.72 or higher, I switch back to the same launch command, issued by AI that gave the bug.

Seeing you get the bug again tells me.
1) You are using the 1.72 trunck version.
2) The double launches at a main station still happen.

Eric Walch wrote:

Seeing you get the bug again tells me.
1) You are using the 1.72 trunck version.

Correct. Well, a slightly hacked trunk anyway.

Eric Walch wrote:

2) The double launches at a main station still happen.

Ok, well that gives me a starting point to track this down then. Unless someone is already on the case?

Still doesn't explain why the second ship just hung around immediately in front of the docking port though...? Exactly how do you send the ship 'directly home'?

Eric, I can’t seem to find this issue on the bug tracker…

Ahruman wrote:

Eric, I can’t seem to find this issue on the bug tracker…

I thought I send it in together with the "getWitchSpaceEntryCoordinates" bug. But it seems I only mentioned it on the forum together with this bug. But I found a way to bypass this bug. (see below). This means the bug has the same source and when one is solved, the other will be solved also.

I'll look into the code if I can find something and will file a bug report. At least will my solution show a way to look for the bugs source.

----
To the double launch bug as reported by Micha:

I fixed it for the next release. (Thanks to cmd James who found a way to bypass an other bug with the main station that leaded to traders flying into the N-buoy, by transferring an AI command from the first ENTER message to a later moment).

When using an Oolite version 1.72, I gave the launch command in the first ENTER message of a ships creation. For some reason ships don't see the main station at this very moment since 1.71. I moved the command to the UPDATE moment (0.125 seconds later). With this change there is now only one launch on using the "launchShipWithRole:" command on the main station.

It's not fixing the bug itself, but just preventing that my oxp suffers from the bug. Thanks for the report Micha.

EDIT:
I just wrote a little testscript that writes into the log during the ENTER message of the GLOBAL AI state. It was logged twice. This probably means that since 1.71 all other GLOBAL ENTER messages are executed twice. This could lead to troubles with more AI's

How is the next version coming along?
The stations are turned now.. curious what will happen next.

Just a thought here.. but, to be honest, the Buoy Repair Station doesn't look very Oolitey to me. What I mean is that all the standard stations are very plain geometric shapes. This station looks more at home in X-Beyond the Frontier. It's gorgeous, just not very fitting, imho.

Would it be possible to provide a simpler design as an alternative which can get switched to as an option in the OXP? I haven't done any scripting so I have no idea whether this would have a larger impact in terms of code as well.

Sorry for late answering, I was a few days off.

pagroove wrote:

How is the next version coming along?
The stations are turned now.. curious what will happen next.

Eric has opened his treasure chest again and wrote some very cool scripts to awake the station to life. Traders docking at the outer platforms!!! That is already working - with some exceptions, but currently we have a problem with the collision detection and it seems we can't avoid some collisions. But that is not the only new feature (and not the only problem). I'm working on a reduction of the used maps, but the tests give me the feel that I have a wrong approach. The hole_material causes some system hangs (<1 sec) when flying around the new station pieces, so I think this won't be part of the next release.

Micha wrote:

Just a thought here.. but, to be honest, the Buoy Repair Station doesn't look very Oolitey to me. What I mean is that all the standard stations are very plain geometric shapes. This station looks more at home in X-Beyond the Frontier. It's gorgeous, just not very fitting, imho.

:-) It is not a 'standard' station, so why should it look like one of them? And you will see (in the next version) that there is a idea behind our design. Creating just a 'simple' station wouldn't be such a fun/pain at all. The basic design was meant to be unique and totally different from any other station we currently have - and it is built up with simple geometrics. :-)

Micha wrote:

Would it be possible to provide a simpler design as an alternative which can get switched to as an option in the OXP? I haven't done any scripting so I have no idea whether this would have a larger impact in terms of code as well.

It would be possible (with changes of the js-code, using two station-declarations in shipdata.plist and diffent models, textures), but we have no plans to do it, because the next version needs this structure to work with the new features.

Fair enough - looking forward to seeing the new features then

Although I'll probably need a new graphics card - the existing station already makes it choke In general it seems that if there's a half-dozen or so largish textures around, it dies. Objects are no object - using the console I added 200 ships in my vicinity and the machine kept chugging along nicely at ~35fps. But several large asteroids and I'm down to 4fps.

Micha wrote:

using the console I added 200 ships in my vicinity and the machine kept chugging along nicely at ~35fps. But several large asteroids and I'm down to 4fps.

Could that be caused by the smooth definition of the asteroids. I can imagine it will require a lot more calculations to rotate such a structure were even the shape of the faces has to be recalculated on every frame.

Possibly..? I'll turn it off tonight and see.

And I've noticed that using a negative rotation is not the same as a positive rotation (and our station is using a negative rotation).