Aquatics OXP

[Thargoid]

Now for the cheeky bit ...

Can I nick your some of your scripting for my ship ?

Of course. Especially as the main structure of the script I nicked myself from Kaks' Kestrel & Falcon OXP But the v1.00 has a couple of minor AI bugs (with the big ships, the Conger is OK), so please use v1.01 which I've just uploaded (link's in my sig or via the wiki).

[Thargoid]

As noted above, a couple of small AI improvements have been suggested (with thanks again to Eric Walsh for taking the time to look over the code), so I've updated the version with these. Nothing too major unless you're the pilot of a Man O' War or a Hawksbill, at which point you may end up smeared across a station

So v1.01 is available for download here or via the wiki.

[Gunney_Plym]

Just installed the OXP to have a look.

Love the rotation on the Man O' War

Can't say the same for the Conger , interesting idea but made it look to my eyes like a giant cam-shaft. In the Ooniverse wouldn't it make for some interesting cargo handling requirements ?

PS Sorry but I just killed one of your Sharks for escorting a very ... er ... 'naughty' Python ET. It did put up a fight though

[Thargoid]

I know what you mean about the Conger. Hence why they counter-rotate, originally they were all clockwise and it looked just like a crankshaft (or a corkscrew, depending on their offset).

The only other options were to spin them out of synch (which did my eyes in when I tried it), or leave them stationary (which made for a rather boring looking ship).

Plus having them rotating makes them more difficult to shoot individually, and also means that for those "shoot from behind" chases it's not necessarily the rear-most pod that dies first...

And as for the Ooniverse, who says they're spinning when they're loaded & unloaded? I don't think it's within the realms of OXP coding to start/stop/vary the spins, but it is within the game plot (and will be on the ships wiki entry when I get time to write it)

[Gunney_Plym]

Fair dues

I think I'd definitely be with you on having them in sync. Any Escort pilot would need a generous supply of sick-bags otherwise

[Dr. Nil]

Some nice and interesting models here.

A bit confusing perhaps that we now have both Rays, Mantas and Manta Rays Excellent.

[Thargoid]

Thank you. I had the Manta Ray designed and test-flying before I noticed that the Manta already existed, so had to find another name for it. And there aren't that many rays about that people would recognise as one (Manta and Sting were all I could come up with, and both were already used).

[Commander McLane]

Hi, Thargoid,

the -verify-oxp command line option reveals the following problems in the shipdata.plist of Aquatics.oxp:

Running OXP verifier for /Applications/Spiele/Oolite 1.71.2/AddOns/Aquatics 1.01.oxp
Scanning files
Checking requires.plist
Checking shipdata.plist
Ship "Box-Escort":
WARNING: unknown key "port_weapon_type".
WARNING: key "max_missiles" does not apply to this category of ship.
WARNING: unknown key "starboard_weapon_type".
ERROR: case mismatch: request for file "Models/Box.dat" referenced in entry "Box-Escort" of shipdata.plist resolved to "Models/box.dat".
Ship "Conger":
WARNING: key "max_missiles" does not apply to this category of ship.
WARNING: unknown key "rear_weapon_type".
ERROR: verification of ship "Conger" failed at "has_fuel_injection": Expected fuzzy boolean, found string.
Ship "GC-MantaRay":
WARNING: key "max_missiles" does not apply to this category of ship.
WARNING: unknown key "rear_weapon_type".
ERROR: verification of ship "GC-MantaRay" failed at "has_fuel_injection": Expected fuzzy boolean, found string.
Ship "Hawksbill":
WARNING: key "max_missiles" does not apply to this category of ship.
WARNING: unknown key "rear_weapon_type".
ERROR: verification of ship "Hawksbill" failed at "has_fuel_injection": Expected fuzzy boolean, found string.
Ship "ManOWar":
WARNING: key "max_missiles" does not apply to this category of ship.
WARNING: unknown key "rear_weapon_type".
ERROR: verification of ship "ManOWar" failed at "has_fuel_injection": Expected fuzzy boolean, found string.
Ship "MantaRay":
WARNING: key "max_missiles" does not apply to this category of ship.
WARNING: unknown key "rear_weapon_type".
Ship "Mil-MantaRay":
WARNING: key "max_missiles" does not apply to this category of ship.
WARNING: unknown key "rear_weapon_type".
ERROR: verification of ship "Mil-MantaRay" failed at "has_fuel_injection": Expected fuzzy boolean, found string.
Ship "Shark":
WARNING: key "view_position_aft" does not apply to this category of ship.
WARNING: key "view_position_starboard" does not apply to this category of ship.
WARNING: key "max_missiles" does not apply to this category of ship.
WARNING: key "view_position_forward" does not apply to this category of ship.
WARNING: key "view_position_port" does not apply to this category of ship.
WARNING: unknown key "rear_weapon_type".
Ship "Shark-Escort":
WARNING: key "view_position_aft" does not apply to this category of ship.
WARNING: key "view_position_starboard" does not apply to this category of ship.
WARNING: key "max_missiles" does not apply to this category of ship.
WARNING: key "view_position_forward" does not apply to this category of ship.
WARNING: key "view_position_port" does not apply to this category of ship.
WARNING: unknown key "rear_weapon_type".
Testing models
TODO: implement model verifier.
Checking demoships.plist
Checking for unused files
TODO: implement unused files check.
OXP verification complete.

What does it mean?

• The max_missiles-key is only used for player ships (at least for now). NPCs only need the missiles-key to determine how many missiles they actually carry.
• NPCs don't need view_positions. Who would look out of them?
• rear_weapon_type is spelled aft_weapon_type, which is a working key and will do what you expect it to do.
• port_weapon_type and starboard_weapon_type don't exist. NPCs cannot have sideways lasers. Period.
• As far as has_fuel_injection (and all the other has_foos) are concerned, the engine expects a boolean (which may be fuzzy). The syntax for that is not <string>no</string>, but <false/>. Alternatively it could be <real>0</real> (or, and that's the fuzzy thing about it, any real number between 0 and 1). I have no idea, though, why the verifying process only complains about has_fuel_injection, and not about the other keys that have the same "no" or "yes" in strings. Ahruman?
• Finally there is the case mismatch, where model-file of the Box Escort is called box.dat, but the shipdata's model-key requires Box.dat.

These are the problems spotted by the machine. This does not mean, however, that there may not be other problems as well. I haven't scrutinized the OXP myself yet.

One issue, however, meets the eye: Unique naming (or the lack of it). It is sensible to give unique names to your creatures. This includes unique entity-names and equally unique file-names. So better than "Shark" as the entity-name in shipdata would be "your-name-Shark" (you could get a problem, though, with simply using "Thargoid" as your-name; in the context of Oolite it doesn't really qualify as unique). And better than "Shark.dat" would be "your-name-Shark.dat" for the model. And "your-name-Shark.png" for the texture (what is not necessary, though, is the word "Texture" in every texture-name).

[JensAyton]

[*]As far as has_fuel_injection (and all the other has_foos) are concerned, the engine expects a boolean (which may be fuzzy). The syntax for that is not <string>no</string>, but <false/>. Alternatively it could be <real>0</real> (or, and that's the fuzzy thing about it, any real number between 0 and 1). I have no idea, though, why the verifying process only complains about has_fuel_injection, and not about the other keys that have the same "no" or "yes" in strings. Ahruman?

<string>no</string> is supposed to work (mostly because there’s no explicit boolean syntax in OpenStep format plists), but it doesn’t work for fuzzy booleans. I believe this is already fixed for 1.72.

One issue, however, meets the eye: Unique naming (or the lack of it). It is sensible to give unique names to your creatures.

*sniff* I’m so proud. :-)

[Rxke]

*sniff* I’m so proud.

Almost spilled my coffee over that!

[Commander McLane]

[*]As far as has_fuel_injection (and all the other has_foos) are concerned, the engine expects a boolean (which may be fuzzy). The syntax for that is not <string>no</string>, but <false/>. Alternatively it could be <real>0</real> (or, and that's the fuzzy thing about it, any real number between 0 and 1). I have no idea, though, why the verifying process only complains about has_fuel_injection, and not about the other keys that have the same "no" or "yes" in strings. Ahruman?

<string>no</string> is supposed to work (mostly because there’s no explicit boolean syntax in OpenStep format plists), but it doesn’t work for fuzzy booleans. I believe this is already fixed for 1.72.

Hm, that still doesn't explain it for me. Aren't all the has_foo-keys fuzzy booleans?

One issue, however, meets the eye: Unique naming (or the lack of it). It is sensible to give unique names to your creatures.

*sniff* I’m so proud.

Who says people can't learn?

@ Thargoid: BTW, alternatively to using your name for uniquifying (does that exist?) the names in your OXP, as for instance Griff does with all his works, you could also use the name of the OXP itself, as for instance I have done in Anarchies.oxp. So you would prefix all ship-names and related files with "Aquatics-" or "aquatics-". That's also unique, because OXP-names themselves have to be unique.

[JensAyton]

[*]As far as has_fuel_injection (and all the other has_foos) are concerned, the engine expects a boolean (which may be fuzzy). The syntax for that is not <string>no</string>, but <false/>. Alternatively it could be <real>0</real> (or, and that's the fuzzy thing about it, any real number between 0 and 1). I have no idea, though, why the verifying process only complains about has_fuel_injection, and not about the other keys that have the same "no" or "yes" in strings. Ahruman?

<string>no</string> is supposed to work (mostly because there’s no explicit boolean syntax in OpenStep format plists), but it doesn’t work for fuzzy booleans. I believe this is already fixed for 1.72.

Hm, that still doesn't explain it for me. Aren't all the has_foo-keys fuzzy booleans?

Well… no. has_escape_pod is a positive integer.

No, I guess that doesn’t help much.

uniquifying (does that exist?)

It does now. A more common verbification would be “uniquing”.

[Frame]

*sniff* I’m so proud.

Almost spilled my coffee over that!

my wife did that yesterday.. right down into the keyboard., my cup of coffe standing on a shelf above, her throwing some pillows ontop of a closet.. did´nt quite have the target skills i presume...

Had a happy time cleaning it for a couple of hours. but could´nt save the right shift key.... :-/

[Thargoid]

Updated version now available based on these findings (although most seem quite minor).

I've used the OXP name as the unique identifier rather than my nickname here (given it's not exactly unique and could be confusing). And the word "Texture" in the textures comes from the original filenaming in Wings. And it makes life easier for my housekeeping to name them like that, so that'll be staying.

Also a note for any players using the ships as their player ship, this update will temporarily break your save file. To fix it, open the relevant save game file in a suitable text editor and change "MantaRay-Player" to "aquatics_MantaRay-Player" (and similar if your ship is a Shark) wherever you find it, and then save it. That will fix your save game again.

[Commander McLane]

Hi!

New update needed for Oolite 1.72. Logfile says:

[shipData.load.error]: ***** ERROR: the shipdata.plist entry "box_ring" specifies no roles, ignoring.
[ship.sanityCheck.failed]: Ship <ShipEntity 0x1eb1a00>{"Box Escort" ID: 0 position: (0, 0, 0) scanClass: CLASS_NOT_SET status: STATUS_IN_FLIGHT} generated with missing subentity box_ring!

Which means that you haven't included the roles-key to the box_ring. Therefore Oolite 1.72 refuses to create the subentity altogether.

Solution: give box_ring a roles-key (you can put any nonsense in it, as it will never be used to call the ship anyway).

Similarly some other models are missing the model-key, which leads to another complaint:

[shipData.load.error]: ***** ERROR: the shipdata.plist entry "manowar_inner" specifies no roles, ignoring.
[shipData.load.error]: ***** ERROR: the shipdata.plist entry "manowar_outer" specifies no roles, ignoring.