What to make of the following?

Flying_Circus · Post by **Flying_Circus** » Sun Mar 25, 2007 10:24 pm

Here's a request for help:

***** Encountered localException during initialisation in [Universe update:] : NSInvalidArgumentException : *** -[NSCFString count]: selector not recognized [self = 0x7227e20] *****


2007-03-25 23:09:22.756 Oolite[230] *** NSTimer discarding exception '*** -[NSCFString count]: selector not recognized [self = 0x7227e20]' that raised during firing of timer with target 115e570 and selector 'doStuff:'
2007-03-25 23:09:22.867 Oolite[230] *** -[NSCFString count]: selector not recognized [self = 0x7227e20]
Oolite [unclassified]:

I know it is something wrong with an OXP... Yes, it's my fault... I absolutely know it's when I summon a ship, from an OXP (one that I'm building), on leaving witchspace (the OXP parses, fine, during the actual load, mind!)

But what is a fellow supposed to make of this error output (other than sod off, with yer stupid OXP

)? I realise this isn't generated by Oolite, but by the graphics layer, by the way

But.... what have I done wrong?

I work in software... I always say: software should never output hexadecimal numbers in its error reports, if it does, there's something wrong with the software, not the error. (Witness: all Microsoft software outputs hexadecimal nubers in its errors... all the time... usually the exact hexadecimal reference to the location in memory, where the error ocurred: veeeery useful, thanks! I rest my case.)

This is not so much a "What's gone wrong this time, then" request, since I know it's of my own doing, but more of a "can we have a proper crash-dump" type request, please?

I'm sure this will form part of the major overhaul that Ahruman is doing, but part of the reason I gave up OXPing, earlier was that OXPs, traditionally, failed without giving any useful feed back as to why.

JensAyton · Post by **JensAyton** » Sun Mar 25, 2007 11:02 pm

This is from the Objective-C runtime, or rather, from the more runtime-like bits of the Foundation framework. It indicates a bug in Oolite, although quite possibly triggered by the OXP. What it means is that it’s expecting an array, but getting a string. If you send me the OXP, I can find exactly what is triggering the error, and make Oolite catch it more gracefully.

Post by **dajt** » Sun Mar 25, 2007 11:12 pm

Well, the message "selector not recognised" is repeated a few times there. My first guess is that a script is calling a method that does not exist.

JensAyton · Post by **JensAyton** » Sun Mar 25, 2007 11:31 pm

I’m sticking to my hypothesis – it’s a plist with a string where it ought to have an array.

Flying_Circus · Post by **Flying_Circus** » Mon Mar 26, 2007 12:20 pm

Well, now I know what to look for, I may well be able to solve it. if you want to see the error, this is the OXP that is causing thegrief http://www.kettonlane.me.uk/files/beyonders.zip - throws a complete lock-up when you try to summon the ship in question using the script.plist.

Also illustrates a point I was going to make about the shader: take a look inside one of the big ships, like the Muirdis, and you'll see that the shader doesn't seem to take into account inverted faces.

Many thanks.

JensAyton · Post by **JensAyton** » Mon Mar 26, 2007 1:35 pm

I don’t know which shader you’re referring to. If you mean the lighting model for entities without a shader, Oolite uses single-sided lighting with some ad hoc rules to guess which way is out. There isn’t a way to modify this behaviour at the moment.

Shipdata.plist has errors: line 149 (<string>hud.plist</string>) should be immediately after line 140 (<key>hud</key>); likewise, lines 347 and 348 (<key>smooth</key><true/>) are between <key>setup_actions</key> and its value; same problem at 487-490 (<key>thrust</key><key>weapon_position_forward</key>...).

<tests> The <key>setup_actions</key> one is the root of the problem you’re seeing. As I suspected, it’s an effect of insufficient property list structure validation in the scripting system. This’ll hopefully be fixed in the release after next.

Incidentally, the two rosualt textures are 640x640, and are being scaled up to 1024x1024 by the game. This slows loading noticably and reduces quality.

Flying_Circus · Post by **Flying_Circus** » Mon Mar 26, 2007 2:00 pm

Interesting, thanks. As I'm sure is apparent, I've been shifting things up and down the stack, quite a bit, as I test them out. I obviously got it badly messed up, while doing so.

I originally scaled the textures down from 1024. I was aiming for 512x512, but somewhere on the way from brain to fingertips, that got changed to 640x640 (goodness knows where I got that figure from: VGA resolution, maybe?)