Aquatics OXP

[Thargoid]

Thanks.

You're a little ahead of me, I'm planning to download 1.72 tonight, and go through all my OXPs (why did I write so many! ) over the next few days and update the lot of them for 1.72 compatability and to make use of the new features where possible.

[JensAyton]

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.

Bother. Subentities are a case I didn’t consider.

[Thargoid]

A v1.72 compatible version can be downloaded from here.

I'm currently working on some more ships for this OXP (including some of the fabled large haulers) but it's still very much a WIP.

[Arexack_Heretic]

you interested in some aquatic Krait adaptations?

I had a similar idea years ago.
oh yeah, they were lost when the star HDD001 went nova...

hint: put a krait on its side move the viewport and it looks somewhat like this:

[Thargoid]

Hmm, I hadn't considered vertically aligned ships (or sea creatures)...

One to add to the list, once I get the v1.72 updates done and go back to the Aquatics upgrade.

[Arexack_Heretic]

The fact you got those two main concepts immediately bodes well for you and further projects by you.

ed: just had a good look around and am quite sure most WIP was lost during a string of harddrive calamities. There's some stuff left on my webspace, but not much.
It's depressing to think about all that work that was desintegrated.

The Aqua krait had backwards trailing edges instead of the traditional krait laserprongs, the drive was like an F18's directed thrust with two plates suggesting a fish tail.
and the lasers were housed inside a 'mouth' in the 'bow' of the vessel.
(I was planning suggesting hatches for underwater-mode in the texture)
texture was bright red-white with silver details and clear anime-style black lines seperating hullplates and component hatches etc.
ugh. not even an image on box. except this:
http://www.box.net/shared/kphctkmc7l

[Commander McLane]

Hi, Thargoid. I went through Aquatics' shipdata again in the new version and noticed only one problem:

The Military Manta Ray will not actually appear in-game, because it doesn't have any generic role ('military'--contrary to popular belief and/or intuition--isn't one). So it would have to be spawned by script, but there is none in the OXP.

Oh, and two minor points: In my personalised version I have tuned down the roles-probabilities for all ships. But of course that's more a question of my own personal taste. And I still have objections against the use of has_military_jammer and has_military_scanner_filter in any ship (Military Manta Ray), unless it is a one-time appearance and motivated by a mission-storyline. Possibly hostile ships that don't appear on the scanner and cannot be targeted have a serious potential to make the game unplayable.

[Thargoid]

Thanks. You're last point actually related to the first one. The Mil Manta was planned for use in the mission I mention in the readme (the one I haven't gotten around to writing yet), although I must admit I did think military was a generic role (so perhaps it should have a low probability police role too - I'll fix that in the next release once I get the haulers etc running.

As to the scanner jammer etc, does that actually work fully? I know it doesn't for player ships, as I've got both on my SC and I still seem to get regularly scanned and shot.

[Commander McLane]

I am not sure. The only thing I know is that Giles put them into equipment.plist, so he supposedly intended to do something with them. But then he left Oolite. I don't know whether and inhowfar these items are actually supported by the code.

There is also a logical inconsistency with them. What makes the player immune against scanning from NPCs is the Cloaking Device. So I don't see any use for the player-version of EQ_MILITARY_JAMMER. NPCs don't actually have a HUD from which the player-blip could disappear!

For the same reason I don't see a use for the npc-version of has_military_scanner_filter in NPCs. As the thing that makes you untraceable for NPC is not EQ_MILITARY_JAMMER, it doesn't make sense to have a counter-device against that.

The only useful combination (for me) is NPC has_military_jammer, which changes its scanClass to CLASS_NO_DRAW (this probably works, at least NPCs with scanClass CLASS_NO_DRAW are possible, as I painfully observed lately), and player EQ_MILITARY_SCANNER_FILTER, which would reverse the effect and let the blips re-appear (don't know whether that works, effectively it would have to re-change the scanClass to whatever it originally was).

Anyway, the bottom line is that I have always stayed away from these.

[Eric Walch]

I am not sure. The only thing I know is that Giles put them into equipment.plist, so he supposedly intended to do something with them. But then he left Oolite. I don't know whether and inhowfar these items are actually supported by the code.

It's fully supported in the code but has some bugs when I tested with 1.69. (or was it 1.65?)

What does work is that NPC ships with the jammer are not visible by the player unless the player has the counter measure. In which case the ships show on the scanner as grey dots.

And as thargoid says it is not working the other way round. Ships still attack you when you have the jammer. However, looking in the code it was intended to work also in this case. There are a lot of checks for this devise in the player entity code. But the code has changed since and player is using much more from the generic ship code than before. And I don't think this part of the code has changed since Giles stopped with it.

There is also a logical inconsistency with them. What makes the player immune against scanning from NPCs is the Cloaking Device. So I don't see any use for the player-version of EQ_MILITARY_JAMMER. NPCs don't actually have a HUD from which the player-blip could disappear!

The EQ_MILITARY_JAMMER is just a simple version of the cloak. It only jams the scanner but you can still see the ship visually. I think it is nice that NPC can have defence against it.
I would not like when it would become buyable by the player, but it would be fun if the military borrowed this counter equipment sometimes to the player for special missions. e.g. against thargoids with the jammer (hint)

Hmm, I hadn't considered vertically aligned ships (or sea creatures)...

Hmm.... One problem with this: The docking computer just assumes the ship is wider than tall. And the slid is only about 65 meters high.
You could design it horizontal and put the texture around it so it looks vertical. That will work until you give it escorts or make them escorts. (you'll notice than what is the "real" upside)

[Commander McLane]

There is also a logical inconsistency with them. What makes the player immune against scanning from NPCs is the Cloaking Device. So I don't see any use for the player-version of EQ_MILITARY_JAMMER. NPCs don't actually have a HUD from which the player-blip could disappear!

The EQ_MILITARY_JAMMER is just a simple version of the cloak. It only jams the scanner but you can still see the ship visually. I think it is nice that NPC can have defence against it.
I would not like when it would become buyable by the player,

Simple version? It's three times more expensive, by far the most expensive item in the unaltered game. I assume that it is actually intended as an extension of the cloaking device, making you (or whoever carries it) invisible on screen and scanner.

[Commander McLane]

Shooting at the conger pods produces this error message:

Exception: Error: System.expandDescription: Invalid arguments (undefined) -- expected string.
Active script: "oolite-default-ship-script" 1.72.2
aquatics_conger_pods.js, line 20:
player.commsMessage((expandDescription(this.plea)),5);

which reveals two problems: (1) this.plea isn't defined (which is what causes the error; there is no this.plea in the script, I guess a c&p error), and (2) player.commsMessage means that you would hear it from anywhere in the system (not the player should send the commsMessage, but the ship that is shot at; probably not the subentity, but the mother; it's the same problem we had with the system-wide Thargoid death messages).

I just wonder why it took so long until the bug manifested itself on my system. Seems Congers aren't attacked very often...

[Thargoid]

Hmm, it didn't used to give those problems. Perhaps something in the Oolite version-up's has skewered it.

I'll give it a look when I get a moment and see if I can fix things up a little.

[Eric Walch]

Hmm, it didn't used to give those problems. Perhaps something in the Oolite version-up's has skewered it.

It also does with me. When you first released it there was no ship.commsMessage only a player.commsMessage. Since 1.72 we have a ship.commsMessage. Your cargo ship broadcasts its messages now directly to the player without range limit.

this.plea is coded correctly. It is broadcasted, but you (kaks actually) coded it a bit hidden:

Code: Select all

i.script.plea= this.subpleas[i.primaryRole]

[Commander McLane]

So why isn't it broadcasted on my system anymore, and I get the error instead?