equipment.plist question

[ADCK]

Firstly as mentioned above, if the missiles etc are not for player use, forget completely about equipment.plist. That's only for player equipment.

That was true in the past, but not since recent trunk changes having non-equipment missiles actually caused crashes (Eg Griffs thargons would cause the game to freeze, until he updated them to have an equipment.plist entry.)

Hence the equipment.plist.

[JensAyton]

Firstly as mentioned above, if the missiles etc are not for player use, forget completely about equipment.plist. That's only for player equipment.

That was true in the past, but not since recent trunk changes having non-equipment missiles actually caused crashes (Eg Griffs thargons would cause the game to freeze, until he updated them to have an equipment.plist entry.)

This is supposed to be fixed (and any crash triggered by an OXP is a serious Oolite bug that needs to be fixed), but you will get log noise. For 1.74 and forward, it is recommended that NPC missiles have an equipment.plist entry. For instance, the core equipment.plist has:

Code: Select all

(   /* Thargoid equipment, incompatible with non-thargoid ships. Not buyable because of its TL. */
    100, 1000, "Thargon",
    "thargon",
    "Alien drone ship.",
    {
        strict_mode_compatible = true; // Obviously this bit isn’t relevant for OXPs.
    }
),

The point is that both Oolite’s code and the scripting interface become more sane if NPC missiles can be treated as a type of equipment, have an EquipmentInfo etc.

Currently, for any missile type that doesn’t have an entry, the EquipmentInfo for thargons (as quoted above) will be used.

[Kaks]

First of all, we're now talking trunk features, which are possibly subject to change, so everything I'm going to say might or might not be relevant when 1.74 is ready to be released...

Now that that's out of the way, I really want to expand on what Ahruman said above: until quite recently, NPCs didn't really have equipment or missiles as such: they had a series of flags indicating whether a piece of equipment was on board or not, and which type of missiles would magically appear whenever they wanted to fire a missile.

That meant that

1) if you wanted to add new types equipment to an NPC ship, you simply couldn't. You were stuck with exactly the NPC equipment allowed in the core game.

2) You could define anything as missiles for an NPC. You could create thargoids firing cobra3s, or coriolis stations, or asteroids. However you could only have one type of 'special' missile, or get the engine to choose missiles for you. In the latter case, he engine itself would not know which missiles would be on board, but would create a missile at random, with the role defined only a few milliseconds before firing, chosen between all possible missiles. The actual concept of missile slots was entirely bypassed for NPCs, so the max missiles was the amount logged when the ship was created, and the counter could only go down by one every time the NPC decided to fire a missile.


Now, what's happening in trunk is:

1) equipment: NPCs equipment handling is now possible: equipment can be added, removed, and new abilities can be added to NPCs - for example, an NPC can now be scripted that takes advantage of external fuel tanks.

2) missiles: we can now remove & add missiles at our heart's content, detect and change whatever missiles are stocked by npcs. (For example, no more surprise Q-mine in between normal missiles! - if an NPC has a Q-mine, we can detect it now. Before it was impossible to do so.)


TODOs:

- I don't think NPCs' equipment gets damaged (& destroyed in strict mode) in battle yet, so we'll need to implement that.

- Add a compatibility mode that will add missile_roles items to the equimpent list, if not defined. Some thinking required, so that we don't end up generating a 'coriolis station missile'...

Apologies for the rambling, but I hope I've been able to at least hint at the new possibilities open for NPC scripting!

[Eric Walch]

AAs for things being broken etc, Ahruman or Eric - can you elaborate a bit more on what is broken at the moment (as from "our side" in OXP-land it seems to work), and what exactly will be entailed with the current fix and will need changing in OXPs etc.

I was also not that happy with the change at first as it broke several of my oxps. But in 1.74 NPC ships can now also have equipment. They already had it in some way, but now it will be implemented in a way it is just as scriptable as player equipment. That means you can award or remove EQ_ECM etc. I already started to use it in some scripts and it proofed a very flexible addition.

Now NPC can have equipment, there was no reason to not add also missiles as equipment. Up until 1.73.4 missiles were just generated on launch. That means the ship could just launch any entity with any role. But by making it equipment it must be handled like any other equipment.

That means it must be added to the equipment.plist and it needs some special endings so Oolite knows it is mend to be a kind of missile. The benefits of all this is that the missiles are now fully scriptable and because the missiles are now created on ship spawning you can target a ship and ask for its "equipment" and it will return an array of equipmentInfo. (I updated the wiki with this equipment list last week)

EDIT: I see Ahruman and Kaks beat me with a reaction)

[JensAyton]

That means it must be added to the equipment.plist and it needs some special endings

The suffix requirement was actually supposed to be removed some time ago, but I apparently forgot. I’m adding a is_external_store key to the extra info dictionary. Note that "_MISSILE" and "_MINE" also imply requires_empty_pylon.

[Lestradae]

That means it must be added to the equipment.plist and it needs some special endings

The suffix requirement was actually supposed to be removed some time ago, but I apparently forgot. I’m adding a is_external_store key to the extra info dictionary. Note that "_MISSILE" and "_MINE" also imply requires_empty_pylon.

Sorry for being a bit on the slow side here, but if even you guys are contradicting each other ... so will the "_MISSILE" and "_MINE" suffixes be nescessary for NPC missiles in the future or not?

Will for example:

Code: Select all

<key>missile_role</key>
<string>EQ_HARPOON_NUKE3_MISSILE</string>

... still work as intended for NPC ship entries, provided that "EQ_HARPOON_NUKE3_MISSILE" is defined in equipment.plist?

And could it be replaced by "EQ_HARPOON_NUKE3" and still stay a missile, NPC and player alike?

[JensAyton]

Will for example:

Code: Select all

<key>missile_role</key>
<string>EQ_HARPOON_NUKE3_MISSILE</string>

... still work as intended for NPC ship entries, provided that "EQ_HARPOON_NUKE3_MISSILE" is defined in equipment.plist?

Yes.

And could it be replaced by "EQ_HARPOON_NUKE3" and still stay a missile, NPC and player alike?

As of a few minutes ago, yes.

[Kaks]

Sorry for being a bit on the slow side here, but if even you guys are contradicting each other

No problem about the question you asked, but how are we contradicting each other?

[Thargoid]

OK, so I'm now hopelessly confused, starting with which of 1.73.4 and 1.74 is broken and which is fixed, and going onward and downwards from there.

Frankly other than being slightly absurd, for me there wasn't anything wrong with using missile_role and having ships fire off other ships as missiles.

For example it is a good way to get around the launch queue limitations for stations sending out a large number of defense ships quickly. Simply have them launched as missiles, whereby you get a much more realistic response (a nice squadron of defenders in the fray quickly, rather than waiting several minutes for them to come out in dribs and drabs via the normal launch queue).

Sorry guys, but whilst I can see that having NPCs use equipment "properly" certainly has some merits and benefits, it looks to me like fixing one area of things has de-facto broken others.

[Kaks]

Thargoid, the simple answer is: without changing it at a fundamental level, you wouldn't be able to do any equipment/missile scripting at all.

To wax lyrical about it, up to 1.73 NPC missile & equipment scripting is but a pale imitation of the real thing.

Perhaps you missed the significance of

- Add a compatibility mode that will add missile_roles items to the equimpent list, if not defined. Some thinking required, so that we don't end up generating a 'coriolis station missile'...

In other words, the plan is that non-equipment 'missiles' will be treated as equipment, which was something already mentioned on the griff thargoid's thread iirc. That means that most, if not all, of the pre-1.74 oxps should still work exactly the same way once we've finished coding the new scripting stuff.

As far as realism is concerned, a station keeping 20-odd ships ready to launch within seconds of a red alert doesn't sound too realistic to me.

Still, it's well doable in trunk as is, if you're willing to define those missile-like defenders as a specific type of - well - station equipment.

Once again, in 1.74 the 'extra' step of registering them explicitely as equipment should be optional, even though - personally - I'd be inclined to make sure that interceptors being used as missiles were defined in the same way as all other stuff being used as missiles. I'm kind of a consitency freak, I'm afraid.

[Thargoid]

That means that most, if not all, of the pre-1.74 oxps should still work exactly the same way once we've finished coding the new scripting stuff.

Methinks the best option will be to bring the italics there to pass (or at least much closer) and then see what works and what doesn't.

But I also have to wonder as we're yet again having quite a fundamental shift in coding practice for OXPs to follow (after all the player.ship stuff for example in the past) isn't it about time we had a pause and perhaps even the fabled next stable release as a benchmark, as it's getting tiring again having to keep recoding OXPs as bits of the code veer off in a new (and better) direction?

[Commander McLane]

But I also have to wonder as we're yet again having quite a fundamental shift in coding practice for OXPs to follow (after all the player.ship stuff for example in the past) isn't it about time we had a pause and perhaps even the fabled next stable release as a benchmark, as it's getting tiring again having to keep recoding OXPs as bits of the code veer off in a new (and better) direction?

I don't see your problem here. Everybody knows that we are going through a series of test releases of Oolite during which the scripting engine is completely overhauled (actually more like completely re-programmed). This series started with Oolite 1.67, and it is going to end at some point in the future with the MSNR, whatever version number it will bear.

Everybody who scripted anything using the new scripting engine since Oolite 1.67 knew beforehand that until the MNSR everything is subject to permanent re-programming. Therefore it really cannot be a surprise that things actually do change, and scripts have to be adjusted.

If you don't like it, don't script anything before the release of the MNSR.

[Thargoid]

Mainly the way that the next stable release keeps getting mentioned and joked about ("mythical" for example) and things are always changing. Yes I know all the highly obvious stuff you mentioned.

If you read what I actually wrote my thinking is that it would be nice to have new baseline soon, simply because our current one (1.65) is now so hugely out of date compared to what current test versions can do as to be more laughable than keeping on referring to its successor as mythical or similar.

[Frame]

why fix something that is not broken :/

What makes you assume it wasn’t broken? The way equipment was handled before was very broken indeed.

That it seemed to work in regard to missiles only, That it was tied into how all Equipment and so on is going to be handled by the code, was not clear.

I guees it was one of those, "we are not supposed to do that, but we do"

But I did note that missiles are now an array(which is cool for adding/removing external things on a model)

I think that Oolite has developed beyond the 1 suffix though, the MNSR should be renamed to Oolite 2...

[Cody]

the MNSR should be renamed to Oolite 2...

That would fit with Griff being called Oolite 2 Art Director.