Oolite Bulletins

since part goes to OXP section, part to bugs, and not sure where else...it's just a summary of anything that seemed wrong to me after playing Oolite for some time...

1. AI: I noticed some weird behavior...first, mining. I do mine asteroids sometimes, but as I noticed, so does AI but...they don't use mining lasers but normal pulse/beam ones. Second, they try to scoop anything, even when they don't have cargo space (or scoop maybe). They also loot asteroids I mine (happened to me that I was scooping splinters, and a fighter that was nearby just rammed me when trying to scoop the same splinter as me). Another thing, they often ram the nav. buoy at orbital bases, or maybe they destroy them? I'm not completely sure, I just notice a flash in the distance and buoy is gone on my ASC.

2. This is prolly related to RS and galactic navy OXPs. I had Gal navy installed, but found out that it incredibly slows my game (took like minutes to load system I jumped to) so I removed it. But...I noticed several times Navy Condor with status offender or fugitive. Seems weird...but maybe it's just the Navy condor being treated as any other ship, therefore being generated as pirate ship.

3. When I accidentally ram piece of wreckage from ship, like metal fragment or cargo container, it sometimes add as kill to my elite rating.

4. I have Black monks OXP installed (non-shader version), but I never found black monk monastery (and I've been searching for it at tl 11+ systems).

5. After installing RS, I noticed lots of error messages in my terminal when entering new system or going into buy ship menu. Something like "Unable to find texture const.png, used default material instead" (when entering system) and "unable to create ship Assasin-player, ship not found" (at buy menu. There's more ships and textures in these errors.)When I get home I'll post them here, with my OXP list.

Sarin wrote:

1. AI: I noticed some weird behavior...first, mining. I do mine asteroids sometimes, but as I noticed, so does AI but...they don't use mining lasers but normal pulse/beam ones. Second, they try to scoop anything, even when they don't have cargo space (or scoop maybe). They also loot asteroids I mine (happened to me that I was scooping splinters, and a fighter that was nearby just rammed me when trying to scoop the same splinter as me). Another thing, they often ram the nav. buoy at orbital bases, or maybe they destroy them? I'm not completely sure, I just notice a flash in the distance and buoy is gone on my ASC.

I agree that it would make sense to have mining ships outfitted with a mining laser. Would be a sensible change for the next version. EDIT: Blatant case of DidNotDoTheResearch : Actually all generic miners do have mining lasers. Probably it's just that the beam itself is not so different from a pulse laser?

For the other observations: Why do you think it is weird that other miners try to graze on your ground (so to speak)? You can do the same to them as well!

Starting ships ramming the buoy is a known bug in version 1.71, and has long been fixed for the upcoming version.

2. This is prolly related to RS and galactic navy OXPs. I had Gal navy installed, but found out that it incredibly slows my game (took like minutes to load system I jumped to) so I removed it. But...I noticed several times Navy Condor with status offender or fugitive. Seems weird...but maybe it's just the Navy condor being treated as any other ship, therefore being generated as pirate ship.

Yes, that's a bug in the condor.oxp, which made it into RS. Actually RS is full of bugs like these. Make sure you have the latest version, because they get squashed and bruised out, slowly.

3. When I accidentally ram piece of wreckage from ship, like metal fragment or cargo container, it sometimes add as kill to my elite rating.

Now that sounds strange. Can't remember to have seen that myself (although this may well be caused by me not paying a lot of attention to my killcount anymore).

4. I have Black monks OXP installed (non-shader version), but I never found black monk monastery (and I've been searching for it at tl 11+ systems).

It should be there, in all systems with the correct techlevel. Exacly on the corridor, roughly half between witchpoint and planet. Oh, and it is marked "B" on your advanced scanner.

5. After installing RS, I noticed lots of error messages in my terminal when entering new system or going into buy ship menu. Something like "Unable to find texture const.png, used default material instead" (when entering system) and "unable to create ship Assasin-player, ship not found" (at buy menu. There's more ships and textures in these errors.)When I get home I'll post them here, with my OXP list.

See answer to number 2. above. If you find errors and bugs related to specific OXPs it is best to post them in the thread that deals with that specific OXP in the Expansion Pack forum. E.g. you don't need to look very far to find the respective thread for RS. You could also have a look into that thread before, in order to find out if "your" bug has long been reported and fixed.

And don't forget: Right On, Commander! Have fun playing!

There are several (at least!) case errors in RS and other OXP's that give similar errors, but only on real computers, windows doesn't mind case errors. Several models use const.png texture file but it is in the texture folder as Const.png so linux cannot find it as Const.png and const.png are different files.
The same thing can happen when creating ships so a file that tries to create a Spiv-player ships fails if the ship is called spiv-player.

Perhaps I should create a list of all the problem files and put it on the wiki? When I have a spare minute of course.

Hi Tinker,

tinker wrote:

There are several (at least!) case errors in RS and other OXP's that give similar errors, but only on real computers, windows doesn't mind case errors. ... Perhaps I should create a list of all the problem files and put it on the wiki? When I have a spare minute of course.

I`m back from holiday ...

Yes, I`ll definitely come back to anyone`s lists (especially yours, as you obviously hunted for them a lot) of case error problems, as they are on the very top of my To-Do list for Realistic Shipyards` successor nowadays.

They are really pesky. They appear in ship keys, model names, texture names, shipdata.plist, shipyard.plist. So a really extensive list of what people already found/stumbled upon would definitely help.

Please do.



L

so, comprehensive list of Linux caps based bugs coming...

texture not found (including how the texture file is really named):
mainhull.PNG>mainhull.png
engines.PNG>engines.png
guntex.PNG>guntex.png
cannon.PNG>cannon.png
const.png,CONST.PNG>CONST.png
moose.png>MOOSE.png
ORB.PNG,orb.png>Orb.png

probably AI version only problem as player version appears in shipyard normally, mesh not found:
oresian_trader.dat

There are also bugs in shipyard. Unable to create ship of type xxx, ship not found:
Scoundrel-player
strut-player
Spiv-player
Assasin-player
Hoodlum-player

some of these eventually appear, but with wrong model (I think), spiv appears but without model.

and one dunno if related bug in RS:
2008-10-30 19:53:28.494 oolite[5721] [plist.parse.foundation.failed]: Failed to parse /home/sarin/.Oolite/AddOns/Zzzz_Realistic_Shipyards_V3.02b.oxp/AIs/PoliceCondorAI.plist as a property list using Foundation. Retrying using homebrew parser. WARNING: the homebrew parser is deprecated and will be removed in a future version of Oolite.
Parse failed at line 8 (char 440) - unexpected character (wanted ',' or ')')
2008-10-30 19:53:28.524 oolite[5721] [plist.homebrew.parseError]: Property list isn't in XML format, homebrew parser can't help you.

Thanks sarin,

all on my To-Do list now.

If you or someone else find more, please feel free to PM or post me and tell me what you found and where.

One side thought: Is it possible under Linux to switch off the case sensitivity for a given program (i.e., Oolite)? If possible, that would also be a solution.

Cheers

L

I'm not proficent with linux, but I think it can't be switched off.

Sarin wrote:

I'm not proficent with linux, but I think it can't be switched off.

No it can't.

Suggestions about these case-bug-lists: make them into a wiki page, ordered by OXP, file, and then alphabetised, including the latest version of the OXP in which the bug was found. Would make it much quicker for people to check whether their case-bugs have already been reported.

The OXP authors can then strike-thru the ones which have been fixed and the version number of their OXP in which it is fixed.

Possibly also have room to attach a 'patch-file' which people can apply until the OXP-author gets around to it instead of everybody editing their OXPs individually?

Micha wrote:

Possibly also have room to attach a 'patch-file' which people can apply until the OXP-author gets around to it instead of everybody editing their OXPs individually?

However it`s being done, I have started work on the successor to Realistic Shipyards and the case issue is first on my list, as this is tedious for all Linux users.

So: Whatever you tell me here, on a wiki-page or per PM I will correct, and I will do an extensive search and make an attempt at automated searching for this stuff.

I am also interested in individually tweaked RS versions of players.

Lestradae wrote:

So: Whatever you tell me here, on a wiki-page or per PM I will correct, and I will do an extensive search and make an attempt at automated searching for this stuff.
I am also interested in individually tweaked RS versions of players.

Really?

Remember the extensive list and some pms (and a nearly fixed and sorted shipdata.plist and shipyard.plist) I've sent to you in June for your 3.01 version.
Anything happened on this points in the meantime?

Maybe it's time to do something :-)

Hi Svengali,

good to hear from you!

Really?

Yes, now, really.

Remember the extensive list and some pms (and a nearly fixed and sorted shipdata.plist and shipyard.plist) I've sent to you in June for your 3.01 version.

Sure. Not only remember, I still have them. Your excellent help with the OpenStep lists had three problems:

1. They are by no means complete; completing them will take a sh**load of time.

2. While you compiled them, I was changing literally hundreds of things in the legacy scripted version to remove bugs - I warned you of that parallel work problem at the time, but ... so the 3.02 version went out in legacy script.

3. There are no automated error checkers for OpenStep that I am aware of, but there are ones for legacy script. That`s a serious OpenStep game stopper for me, because finding an error in 60000+ lines of code without automated search is, in short, impossible (at least for me).

If I or we could solve those problems, I would like OpenStep much more - it`s far more clear in its structuring than the legacy stuff, imho.

Anything happened on this points in the meantime?

Sadly, on this point, no

But as I have restarted work ... there might be.

Maybe it's time to do something

If you would (again) help me in an endevour to translate the whole bulk into OpenStep (couldn`t that be automated itself?) your help would be very, very much appreciated

The automated error search problem would have to be adressed, though, and made sure that we would not work in parallel again

I`d say the answer is yes!

Cheers

L

Lestradae wrote:

1. They are by no means complete; completing them will take a sh**load of time.

No, it was nearly complete and finishing it wouldn't take so much time - even with the changes that you have made.

Lestradae wrote:

2. While you compiled them, I was changing literally hundreds of things in the legacy scripted version to remove bugs - I warned you of that parallel work problem at the time, but ... so the 3.02 version went out in legacy script.

If I remember right, I pm'ed you to sent me the changes to implement them in the fixed version. It's not too late :-)

Lestradae wrote:

3. There are no automated error checkers for OpenStep that I am aware of, but there are ones for legacy script. That`s a serious OpenStep game stopper for me, because finding an error in 60000+ lines of code without automated search is, in short, impossible (at least for me).

The error handling and detection in Oolite is very good for OpenStep. It gives you more detailed messages to find bugs (at least on WIN), so it would be easy to use it. And the fixed version has only 13591 lines :-)

So send me the changes and I'll spend some time with it.

Just a thought here, but why don't you guys use some sort of source control system to coordinate work?
.

Lestradae wrote:

If you would (again) help me in an endevour to translate the whole bulk into OpenStep (couldn`t that be automated itself?)

Sure. Find a collaborator with a Mac, get them to install the developer tools (included on OS X installer DVDs) and use Property List Editor or plutil to convert the files. These tools will also point out syntax errors in the files.

Hi guys!

@Svengali:

It's not too late ... The error handling and detection in Oolite is very good for OpenStep. It gives you more detailed messages to find bugs (at least on WIN), so it would be easy to use it. And the fixed version has only 13591 lines

VERY good news ...

So send me the changes and I'll spend some time with it.

Very helpful of you - thanks! I will come back to your offer like a Faulcon DeLacy Homing Missile (ECM-proof) when I have reached a certain point in my To-Do list

Perhaps in December, I will be there. Great!

@Ahruman:

Find a collaborator with a Mac, get them to install the developer tools (included on OS X installer DVDs) and use Property List Editor or plutil to convert the files. These tools will also point out syntax errors in the files.

Cool! Didn`t know that. I am on the lookout for someone to play-test the betas on a Mac, anyways ... so if someone out there with a Mac would be so kind and has an idea of what you (Ahruman) are suggesting here, feel free to PM me!

Thanks for the tip

Cheers

L