Scanner problems

[tinker]

Created 1.71.2 on 30.7.2008 from source d/l the same day, built as user in /home. There was another install of 1.65 that was installed from a ubuntu repository, by default that was installed somewhere in /usr so should not conflict?

I have got into the habit of always starting with the shift key down but have noticed that sometime the stderr file does not show it.

Do you recommend a complete removal of all instances and rebuild from scratch? While I would prefer not to go through all the rebuild process if it helps I will. Though it is perhaps better to find the root cause and fix it without rebuilding everything and not knowing what went wrong.

@LittleBear
Are you saying that RS is broken, at least in part and that Linux users need to check every OXP for case sensitive files?

[LittleBear]

It'll work, just some of its ships will either not appear or come up without textures. Most OXPs have squashed the case sensitive bug, but if you are getting this error reported then you'd need to change the case.

[Lestradae]

Hi again,

@tinker: No, RS is not broken, it will run but as LittleBear has said some ships won`t show up. The reason is that there are a few case-sensitive bugs still left in RS and I, running Oolite on Vista, have been having a hard time of finding them - because on Linux, a case-sensitive bug leads to an object not working, on Windows it will work fine

As it`s very difficult to find those buggers for me, I`m glad if someone points me to them because I`m going to correct those typos for the next RS release (which will be termed Oolite Ships Extension V1.0, by the way).

If you want to do something about that yourself, then rename all such typos to the same upper/lower case form, and the ships affected will appear!

But, none of this will create any problem with RS`s function as such, and has even less to do with the problems you observed ...

Don`t give up just yet, Oolite`s a great game and with things that size, bugs are inevitable



L

[Frame]

Hi again,

@tinker: No, RS is not broken, it will run but as LittleBear has said some ships won`t show up. The reason is that there are a few case-sensitive bugs still left in RS and I, running Oolite on Vista, have been having a hard time of finding them - because on Linux, a case-sensitive bug leads to an object not working, on Windows it will work fine

As it`s very difficult to find those buggers for me, I`m glad if someone points me to them because I`m going to correct those typos for the next RS release (which will be termed Oolite Ships Extension V1.0, by the way).

If you want to do something about that yourself, then rename all such typos to the same upper/lower case form, and the ships affected will appear!

But, none of this will create any problem with RS`s function as such, and has even less to do with the problems you observed ...

Don`t give up just yet, Oolite`s a great game and with things that size, bugs are inevitable



L

I can recommend ultra edit,it got a powerfull search in files function, so you can find all those case sensitive problems...

here is a picture

http://i304.photobucket.com/albums/nn18 ... raedit.jpg

cl

[tinker]

@Lestradae
I wasn't thinking of giving up, just getting it to work better. Played it first about 25 years ago and been thinking about it ever since.

Do you want me to let you know about any case errors I find?

I did not get any idea if this was a problem

Code: Select all

.:85: element array: validity error : Element array content does not follow the DTD, expecting (array | data | date | dict | false | integer | real | string | true)*, got (key integer key integer key string string string )
            </array>
                    ^ 

or where the problem may be.
In any case I know a bit more about what I am looking for and will persist in trying to solve the problems I have seen - but tomorrow.

@frame
I remember using ultra edit many years ago,won't help now though as I only use Linux, thanks anyway.

[Lestradae]

@Frame:

I can recommend ultra edit,it got a powerfull search in files function, so you can find all those case sensitive problems...

Thanks very much for the tip, will try that one out ...

@tinker:

Do you want me to let you know about any case errors I find?

Yes, please! (Although frame`s program might make that obsolete, but until then, yes!)

Good night

L

[tinker]

I did a quick look through RS 3.03 and the 7 dependencies for obvious errors, they have to be obvious for me to spot them

There may be other things wrong as well but this is what I spotted.

Commies.oxp
Model comsturgeon.dat uses comsturgeon.png which does not exist

Zz-Oo-Haul.oxp
Textures folder contains juggernaut.dat model that refers to textures used: ['default', 'hull_auvtt.png', 'middlething', 'oohdet'] though the mappings are not added to the dat file and the textures do not exist.

Realistic Shipyards 3.02.oxp
Orb.dat and 0-spin refer to ORB.PNG file is orb.png (o-sturret.dat uses orb.png)
asp2v.dat refers to asptesa.png which does not exist
bridge.dat, doors.dat, e-turret.bat, hull.dat, nacelles.dat, neck.dat, phaser.dat, pt.dat, pylons.dat, rearphot.dat, saucer.dat, s-doors and s-turret refer to const.png file is CONST.png
cannon.dat refers to cannon.PNG file is cannon.png
condor.dat uses MOOSE.png Textures folder has MOOSE.png - condorhab1.dat and condorhab2.dat call moose.png
engines.dat, l_wing.dat and r_wing.dat use engines.PNG file is engines.png
gun.dat uses guntex.PNG file is guntex.png
hud.dat missing texture hudtex.png
mainship.dat uses mainhull.PNG file is mainhull.png
navyinterceptor.dat and s-dock.dat use CONST.PNG file is CONST.png, see above

advisory -
aegidian-pccv26.dat archasp.dat aspexplorer.dat cobra3rapier-tailend.dat CobracourierSE.dat CobracourierSEt.dat rapier_tail-cargo.dat
all these have comments that refer to different textures than used, not a problem but also not good programing practice.

Herald.mesh is this format correct?
pt.3ds should this be in the oxp?

Hope this helps, I have updated all my files so none of this can confuse matters in trying to solve the original problem, Just to be sure I will be checking the other oxp's before I add them back in.

[Lestradae]

Hey tinker,

thanks for looking that up, hope it will work out for you now, your list is on my to-do list!

For your original bug, I guess it could be what LittleBear said - in that case, it`s to be found by the scripter gods who do the Oolite game itself.

Cheers

L

[tinker]

Hey tinker,

thanks for looking that up, hope it will work out for you now, your list is on my to-do list!

No problem happy to help.

Starting up with just these installed -

AAACrooks.oxp
Assassins.oxp
Commies.oxp
Hotrods.oxp
ionics-1.2.1.oxpVector.oxp
Zz-Oo-Haul.oxp
Zzzz_Realistic_Shipyards_V3.02.oxp

I get a clean stderr, so we are starting from a level pitch. I loaded up a commander and went searching for trouble. It seems that all scanner blips now display correctly. Nav beacons, stations and SIRF stations all appear green, I only found asteroids or canisters as white. Other ships were all yellow unless they attacked and then they turned red, if I killed them any debris showed as white. I didn't come across any of the problem ships I had before so I cannot be sure that everything works OK but so far so good.
This would imply that the basic install is good and the errors I had were caused by one of the OXP's that I have not added back in yet.

I did check the stderr after a longer flight and did find this.

Code: Select all

2008-08-18 09:47:28.439 oolite[6387] [universe.getShip.unknown]: Attempt to create ship of type "behe-dockv2", but no such type could be found.
2008-08-18 09:47:28.976 oolite[6387] [dataCache.willWrite]: About to write data cache.
2008-08-18 09:47:29.059 oolite[6387] [dataCache.write.success]: Wrote data cache.
2008-08-18 10:14:36.128 oolite[6387] [dataCache.willWrite]: About to write data cache.
2008-08-18 10:14:36.218 oolite[6387] [dataCache.write.success]: Wrote data cache.
2008-08-18 10:14:38.785 oolite[6387] [unclassified.MyOpenGLView]: Found mode {Height = 1024; RefreshRate = 0; Width = 2560; }
GCJ PLUGIN: thread 0x6229a0: NP_GetMIMEDescription
GCJ PLUGIN: thread 0x6229a0: NP_GetMIMEDescription return
GCJ PLUGIN: thread 0x6229a0: NP_GetValue
GCJ PLUGIN: thread 0x6229a0: NP_GetValue: returning plugin name.
GCJ PLUGIN: thread 0x6229a0: NP_GetValue return
GCJ PLUGIN: thread 0x6229a0: NP_GetValue
GCJ PLUGIN: thread 0x6229a0: NP_GetValue: returning plugin description.
GCJ PLUGIN: thread 0x6229a0: NP_GetValue return

behe-dockv2 is in RS /config/shipdata.plist line 90

I am not sure what the GCJ PLUGIN: lines are or even if they are a problem or just a notification.

[tinker]

I did a couple more tests, just popping out to see what was spawned and how it reacted, the only thing I noticed was twice I was attacked on leaving a station by a mamba tiger that did not show up as red though I did get a klaxon and the hud was showing condition red. A police ship that was sitting by the station ignored the attacks on me and my returning fire.

To progress testing further I added asteroid storm oxp back in and got the Javascript errors from it.

Code: Select all

2008-08-18 13:43:34.014 oolite[6691] [script.javaScript.warning.206]: ----- JavaScript warning: Mission.missionScreenTextKey is deprecated and read-only.
2008-08-18 13:43:34.016 oolite[6691] [script.javaScript.warning.206]: ----- JavaScript warning: Mission.imageFileName is deprecated and read-only.
2008-08-18 13:43:34.016 oolite[6691] [script.javaScript.warning.206]: ----- JavaScript warning: Mission.musicFileName is deprecated and read-only.
2008-08-18 13:43:34.016 oolite[6691] [script.javaScript.warning.206]: ----- JavaScript warning: Mission.choicesKey is deprecated and read-only.
2008-08-18 13:43:34.016 oolite[6691] [script.javaScript.warning.206]: ----- JavaScript warning: Mission.instructionsKey is deprecated and read-only.

to be sure removed asteroid storm and the errors disappeared, so something is not right with that oxp.

[Eric Walch]

To progress testing further I added asteroid storm oxp back in and got the Javascript errors from it.

These errors are generated from the part of the code that checks if Oolite has version 1.68/1.69. When this check is removed, the errors disappear. (Same is happening with hotrods.oxp) However, I never was able to find what exactly triggered the error as I never found a location were the "Mission.missionScreenTextKey" was actually used.

In both oxp's you can safely remove the complete script: "JSversion" and its link in the world-scripts.plist. This script only puts up a warning when 1.68 or 1.69 is active. But when such a test itself generates warnings with the current oolite version, you better remove it.

However, the warnings are at the moment harmless and the scripts has to be changed further to be working for 1.72 anyhow.

[tinker]

In fact I did not get the errors with hotrods.oxp only with Asteroidstorm.

I checked hotrods and JSversion script is not present in it, in asteroids I removed the script and the link in world-scripts/plist but it made no difference the errors are still present. In fact from the names of the variables it would seem they were more likely to be part of script.plist.

[tinker]

Yet another problem found with RS

Code: Select all

2008-08-18 16:50:22.866 oolite[7755] [plist.parse.foundation.failed]: Failed to parse /home/rhian/.Oolite/AddOns/Zzzz_Realistic_Shipyards_V3.02.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-08-18 16:50:22.868 oolite[7755]   [plist.homebrew.parseError]: Property list isn't in XML format, homebrew parser can't help you.

[Lestradae]

Thanks again, the policecondorAI.plist one was already a known bug (to me, that is)

Only a dead bug is a good bug!

L

[Eric Walch]

In fact I did not get the errors with hotrods.oxp only with Asteroidstorm..... I removed the script and the link in world-scripts/plist but it made no difference the errors are still present.

It was already long ago that I changed those lines. I compared the original version with my changed version. It were the next lines in asteroid storm that triggered those errors:

Code: Select all

for (var i in this.badOolite){
        if (oolite.compareVersion(this.badOolite[i]) == 0){
                LogWithClass("script."+this.name, "--- Script disabled to avoid bugs in Oolite v"+oolite.versionString+". Please use another version. ");
                return false;
        }
}

I rechecked it. When I put them in, I get those warnings, when I remove them, the warnings are gone. I just don't understand how those warnings are generated. It is a test for a incompatible oolite version.