Spawning ships & AI

[Commander McLane]

OK I did this in the plist, seems to work:
"conditions" = ();

Please correct me if I'm wrong, otherwise I'm set now, thanks!

Seems reasonable.

[Thargoid]

Although you should consider why the condition was there in the first place, or as you may break something in the original OXP (either mission requirements or just the story and feel of the OXP).

Similarly if ships are borrowed from missions, be careful that they don't end up screwing up the original mission itself (as I recall has happened in the past with like_ships of the constrictor).

[m4r35n357]

Although you should consider why the condition was there in the first place, or as you may break something in the original OXP (either mission requirements or just the story and feel of the OXP).

Similarly if ships are borrowed from missions, be careful that they don't end up screwing up the original mission itself (as I recall has happened in the past with like_ships of the constrictor).

It's just the system restriction for the OXP in question, the ships are general-purpose, I have something slightly different in mind, but it's just a personal project for now until I get a better idea how it would fit in . . .
I am intrigued by the idea that I could pollute the original via like_ship, how does that work?

[Thargoid]

To take the constrictor example (as happened with RS).

Hypothetically you like_ship the trunk ship to "myConstrictor" and spawn that randomly in-game before the "real" constrictor has appeared. As the "real" constrictor has a ship script, that gets inherited by the like_ship'd version (unless you set the shipdata.plist up to override that) and so when you kill the myConstrictor the scripts shipDied actions fire and set mission variables etc as if you'd just killed the "real" mission constrictor.

The net upshot is you've now killed the constrictor and completed the mission before you've even been offered it, thus screwing it up.

As I said this very example happened in the past, and is a good (or bad, depending on how you look at it) example of what can go wrong with like_ship without fully checking and understanding what you're inheriting through it.

[m4r35n357]

To take the constrictor example (as happened with RS).

Hypothetically you like_ship the trunk ship to "myConstrictor" and spawn that randomly in-game before the "real" constrictor has appeared. As the "real" constrictor has a ship script, that gets inherited by the like_ship'd version (unless you set the shipdata.plist up to override that) and so when you kill the myConstrictor the scripts shipDied actions fire and set mission variables etc as if you'd just killed the "real" mission constrictor.

The net upshot is you've now killed the constrictor and completed the mission before you've even been offered it, thus screwing it up.

As I said this very example happened in the past, and is a good (or bad, depending on how you look at it) example of what can go wrong with like_ship without fully checking and understanding what you're inheriting through it.

Thanks for the explanation, I'll keep that in mind.

[Eric Walch]

Hypothetically you like_ship the trunk ship to "myConstrictor" and spawn that randomly in-game before the "real" constrictor has appeared. As the "real" constrictor has a ship script, that gets inherited by the like_ship'd version (unless you set the shipdata.plist up to override that) and so when you kill the myConstrictor the scripts shipDied actions fire and set mission variables etc as if you'd just killed the "real" mission constrictor.

Yes, I felt very sad about that some oxp's crippled the internal missions. In case of the constrictor, the script is now completely removed from shipData.plist, and the ship-script is only attached to the constrictor when spawned as mission ship. All possible thanks to new features introduced in 1.74

[Commander McLane]

I am intrigued by the idea that I could pollute the original via like_ship, how does that work?

It doesn't, as long as you change all unique identifiers. Those are:

• shipdata.plist entry name
• unique roles
• ship script
• file names, namely
  • texture name(s)
  • model name(s)
  • shader name(s) (if applicable; if the ship is using generic shaders, you probably don't need to rename them, but then you'd probably not copy them in the first place)
  • (unique) AI name

Generally all identifiers in your OXP should be unique, to avoid clashes with other OXPs.

Example: if you give a ship a generic entry name like 'destroyer' there is a fair chance that somebody else has had/will have the same idea, which will lead to clashes. Better name it 'maresnest-destroyer'. In the same way it's a good idea to precede all identifiers with a unique prefix, like for instance your name or the name of the OPX.

[m4r35n357]

I am intrigued by the idea that I could pollute the original via like_ship, how does that work?

It doesn't, as long as you change all unique identifiers. Those are:

• shipdata.plist entry name
• unique roles
• ship script
• file names, namely
  • texture name(s)
  • model name(s)
  • shader name(s) (if applicable; if the ship is using generic shaders, you probably don't need to rename them, but then you'd probably not copy them in the first place)
  • (unique) AI name

Generally all identifiers in your OXP should be unique, to avoid clashes with other OXPs.

Example: if you give a ship a generic entry name like 'destroyer' there is a fair chance that somebody else has had/will have the same idea, which will lead to clashes. Better name it 'maresnest-destroyer'. In the same way it's a good idea to precede all identifiers with a unique prefix, like for instance your name or the name of the OPX.

I have custom entry names, role names (both of which include the oxp name), ship scripts & AI, and I don't mess with the ships themselves, so from the above I should be OK, I think.