Oolite Bulletins

IMO I like this station very much. It's Unique. and Oolite is not Elite. Keep up the work guys!

Eric Walch wrote:

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.

Turning off smoothing didn't do anything - as I guessed, my CPU is fine, it's the graphics card that's choking.

I downloaded and installed the latest Radeon drivers for Ubuntu direct from AMD and now I get between 50-100fps. Tried it amongst a bunch of about a dozen large asteroids and worst was ~35fps. Wow, wasn't expecting such a large improvement on such an old card! In fact, I wasn't even expecting to find any new drivers for it, especially since I updated only about half a year ago. It's a lot happier launching out of stations when the planets are custom-textured as well now.

Anyhoo, looks like my machine will be quite happy with Oolite for a while longer now

Hi!

Oolite 1.72 complains:

[shipData.merge.failed]: ***** ERROR: one or more shipdata.plist entries have like_ship references that cannot be resolved: <NSCFSet: 0xecbc810> (repaired-buoy-docker1, grs-womasiloRev, repaired-buoy-womaRev, grs-womasilo)

Commander McLane wrote:

Hi!

Oolite 1.72 complains:

[shipData.merge.failed]: ***** ERROR: one or more shipdata.plist entries have like_ship references that cannot be resolved: <NSCFSet: 0xecbc810> (repaired-buoy-docker1, grs-womasiloRev, repaired-buoy-womaRev, grs-womasilo)

I have not downloaded 1.72 yet. Without seeing it, I think it is a tiny bug(#) in oolite 1.72. I use like_ship to the woma ship from transports.oxp. However, the JS code first checks if this oxp is installed before adding this ships to the universe. When you don't have the oxp installed, it will not try to add this non-existing ship.

Probably UPS will generate a similar "error". But also here the code first check for the for the presence of the external oxp before using any of the like_ships.

New buoy-repair version is almost ready. We now will first check if everything works well with the new 1.72 before doing a the release.

# Not really a bug as Oolite can't make a real conclusion without analysing the JS code itself.

Commander McLane wrote:

Oolite 1.72 complains:

[shipData.merge.failed]: ***** ERROR: one or more shipdata.plist entries have like_ship references that cannot be resolved: <NSCFSet: 0xecbc810> (repaired-buoy-docker1, grs-womasiloRev, repaired-buoy-womaRev, grs-womasilo)

It also seems that you are using a still unreleased WIP version :-)

Thanks for notifying us, McL.

Eric Walch wrote:

I have not downloaded 1.72 yet. Without seeing it, I think it is a tiny bug(#) in oolite 1.72. I use like_ship to the woma ship from transports.oxp. However, the JS code first checks if this oxp is installed before adding this ships to the universe. When you don't have the oxp installed, it will not try to add this non-existing ship.

Hmm. A possible fix would be to add a is_external_dependency flag to indicate that failure is “permissible”.

Svengali wrote:

Commander McLane wrote:

Oolite 1.72 complains:

[shipData.merge.failed]: ***** ERROR: one or more shipdata.plist entries have like_ship references that cannot be resolved: <NSCFSet: 0xecbc810> (repaired-buoy-docker1, grs-womasiloRev, repaired-buoy-womaRev, grs-womasilo)

It also seems that you are using a still unreleased WIP version

Now, where may I have got that from.

I confess. Eric wanted to show me something. And then I forget to remove the WIP-version again.

Anyway, glad to be of help.

Commander McLane wrote:

Now, where may I have got that from.

Anyway, glad to be of help.

Ahruman wrote:

Hmm. A possible fix would be to add a is_external_dependency flag to indicate that failure is “permissible”.

Yes, I would appreciate this key. But, should it be a boolean, or should it contain the name of the external oxp? I would favour the later as it makes it easier to figure out on what oxp it is dependent.

Currently there are several legacy oxp's around with such a dependancy. Here you can only read in the manual that you need to install other oxp's also. I currently have made 3 such oxp's that use external ships. But with JS I check for the other oxp and if not present, I add a generic oolite ship as replacement. e.g. in Behemoth spacewar it will add just plain police vessels and plain thargoids when the Behemoth.oxp and Thargorn_Threat.oxp are not installed.

Best things always come last: I just uploaded a new version of buoyRepair.oxp: Buoy Repair 1.02

Minimum requirements Oolite 1.72.

- The oxp contains two new ships and some modified existing ships.
- As advertised earlier we now allow big traders that don't fit though a regular dock, to dock at our external ports.
- The station now has shaders.
- adaptation to the 1.72 alterations.

Eric Walch wrote:

Minimum requirements Oolite 1.72.

Well !!! according to the requires.plist it is 1.71.2

@Ark: We apologize for this mistake, it's a v1.72 version only. As a compensation the pic above is for you.
And for sure you should know that there is always a safe and warm place for you at every GRS station - err at least in our welding section :-)

PS: We'll change it for the next shot.

Excellent work

Svengali wrote:

@Ark: We apologize for this mistake, it's a v1.72 version only. As a compensation the pic above is for you.

Well that is very kind of you!!!!!!!!!!

pagroove wrote:

Excellent work

Thanks pagroove :-) Do you mean the pic or the new version?

Ark wrote:

Well that is very kind of you!!!!!!!!!!

:-) We are always thinking about our shareholders to guarantee a higher yield. And getting feedback is also a integral part of our strategy to improve the level even more. So if you can see some more 'nasty, glitchy, zero-working' things feel free to contact your nearest GRS crew member .-)

BTW: Have you (or anybody else) noticed any changes? The new version has a lot of -currently- unique stuff and some eastereggs. Some of the new features are - we call it - silent and subtle changes, most players won't notice it on the first look (maybe even never), but they are improving the play-feel without being a eye-candy only.
We still have some problems with the collision detection, but this station is a extreme case, so don't expect that everything is working without any problems. As Ahruman has said, changing the detection would be a big job and it needs a lot of time to do this complex coding without losing so much performance. I think it is already working very well and we have worked at the thin line between possible and impossible things (and sometimes had to give up). But hey - that's the fun, isn't it?