Oolite Bulletins

[ai.takeAction.badSelector]: ***** ERROR in AI comminer2AI.plist in state DOCK_WITH_STATION: Astromine Convict 682 does not respond to setStateTo:COLLECT_STUFF

(You need a space after the colon.)

Also, these files are not sufficiently uniquely named. See this? This is my frowny face.

While I’m complaining, having less ships in demoships.plist would be nice. Including each variation of the nav buoy billboard is rather pointless for those of us not testing the OXP.

Ahruman wrote:

While I’m complaining, having less ships in demoships.plist would be nice. Including each variation of the nav buoy billboard is rather pointless for those of us not testing the OXP.

I didn't really want to say, but this annoys me a little too
(Yes, I'm sad and sometimes just watch the pretty spaceships spinning around for a while)

Still love the .OXP though. Certainly helps in adding flavour to the galaxy.
Thanks Dr Nil.

Ace Garp wrote:

(Yes, I'm sad and sometimes just watch the pretty spaceships spinning around for a while)

At least I’ve got an excuse, I was testing the updated octree generation code and tweaking the magic numbers controlling it. :-)

Thanks for your input.

Typo corrected

demoships.plist renamed to _demoships.plist

Names retained for now - I will look into that issue, if/when I give this expansion a major overhaul.

2.07 March 2008

Corrected a typo in an AI spotted by Ahruman

Commies 2.07

Thanks. But currently you probably used a wrong link. It just downloads a 1.8 kb file on my computer with only the readme file in it.

Eric Walch wrote:

Thanks. But currently you probably used a wrong link. It just downloads a 1.8 kb file on my computer with only the readme file in it.

Yes i can confirm that

Sorry about that.

It should work now.

Commies 2.07

There is something in this and previous zip files that makes it impossible to download it for me. The previous two versions had the same problem. It starts downloading as usual until it reaches a certain point. Then the speed drops to almost zero. After some time it then ends the download as if is was ready, but the resulting file is much to short and of course corrupted. I have tried it a dozen times the past half year with the same result.

I never had this before with a download. Also the other long files on that same site download without troubles. Can anyone shed light on this? I use an isdn connection. It looks like it is hitting a certain row of characters that have a special meaning for my transmission protocol. Other browser does not help. Could zipping with an other brand zipper help?

Weird, just tried it and it downloaded ok for me...

Have you tried using a different browser (firefox if you used safari before, safari if you were using firefox)? Sometimes a corrupted browser cache can cause weird problems with downloading... Just my 2 pennies' worth.

Eric Walch wrote:

There is something in this and previous zip files that makes it impossible to download it for me. The previous two versions had the same problem. It starts downloading as usual until it reaches a certain point. Then the speed drops to almost zero. After some time it then ends the download as if is was ready, but the resulting file is much to short and of course corrupted. I have tried it a dozen times the past half year with the same result.

I recall that problem when downloading Put_your_AD_Here ver 3.
I had to try 5 times in order to get it.

Kaks wrote:

Have you tried using a different browser (firefox if you used safari before, safari if you were using firefox)? Sometimes a corrupted browser cache can cause weird problems with downloading... Just my 2 pennies' worth.

No cache problem as I had this problem over half a year with several browsers and different versions of this OXP. But never with any other download.

As a last resort I switched to the internal 56k modem. That downloaded perfect (but slow). Have it now.

It must be a special character sequence that is interpreted as a break by my isdn modem. I know that a "+++" sequence is also illegal with a plain modem and sets it in a special command mode. But normal modem transmission protocol makes sure a "+++" is never sequential transferred.

While I was trying to solve another problem with several OXP's I was checking out the texture file associated with models. Linux systems being case sensitive.

I noticed that comsturgeon.dat refers to comsturgeon.png but that file is not packaged with the OXP. Was this an oversight or is it really not needed?

tinker wrote:

I noticed that comsturgeon.dat refers to comsturgeon.png but that file is not packaged with the OXP. Was this an oversight or is it really not needed?

If it's referred to in the dat-file then it's needed. (At least if the ship that refers to the dat-file actually exists.)

tinker wrote:

While I was trying to solve another problem with several OXP's I was checking out the texture file associated with models. Linux systems being case sensitive.

I noticed that comsturgeon.dat refers to comsturgeon.png but that file is not packaged with the OXP. Was this an oversight or is it really not needed?

It's just some old files, that I forgot to remove. I don't think it should be a problem since the model isn't used in the shipdata.plist where the Sturgeon is referred to as 'comlim'.