Question: <key>roles</key> functions

[Lestradae]

Hye,

is it possible to combine ...

Code: Select all

<key>roles</key>
<string>player hunter trader pirate</string>

... and simultanously have a ship that is buyable (player) and will be picked by the game in a hunter, trader or pirate role or does it have to be divided into ...

Code: Select all

<key>roles</key>
<string>player</string>

... and ...

Code: Select all

<key>roles</key>
<string>hunter trader pirate

... separate from each other to work?

Please, someone in the know drop me a short line.

I didn´t find a single example of a working combination of the roles "player" and NPC-roles, that`s why I ask.

Thanks in advance

L

[LittleBear]

Not sure but it would have some odd results. A lot of OXPs scan for the role player (meaning the player!) to send messages or to check who killed them. So I guess it might mean Oolite thinking that an action taken by an NPC was actually done by the player! Safer and should have the same effect would be to do the NPC version with the roles for the NPCs Eg:-

Code: Select all

<key>myship_npc</key>
<dict>
<key>roles</key>
<string>hunter pirate</string>
<key>autoai</key>
<string>true</string>
[rest of stats here]
</dict>

then just do a like_ship for the player version with

<key>myship_player</key>
<dict>
<key>like_ship</key>
<string>myship_npc</string>
<key>roles</key>
<string>player</string>
</dict>

The player version would then by identical to the NPC version except for role. You'd need the auto_ai on so that hunters behave like hunters and pirates like pirates.

[JensAyton]

Not sure but it would have some odd results. A lot of OXPs scan for the role player (meaning the player!) to send messages or to check who killed them. So I guess it might mean Oolite thinking that an action taken by an NPC was actually done by the player!

No. NPCs will not have the primary role player, so scanForNearestShipWithRole:/scanForNearestShipWithPrimaryRole: will not find such ships. scanForNearestShipHavingRole: could find such a ship, but now you mention it I’m going to explicitly delete player from the role set when spawning NPCs, starting in 1.72.

[Commander McLane]

Anyway, Lestradae, you should take the example from the original Oolite shipdata.plist: There is always an extra entry for the player versions, with the entry name anyship-player. This has the added advantage that you can give it slightly modified specs from the NPC-versions. (In fact quite a few ships from the original set are different in their specs in player and non-player versions, starting from the all-famous CobraIII itself!)

For instance you probably would want to determine the extra equipment for a player ship in shipyard.plist, not by the has_something-keys in shipdata.plist. But you also could want to make it faster or slower, more or less agile than the NPC version. For a couple of ships in the original set there are even different entries for trader, pirate, or hunter version.

[Lestradae]

Hye,

thanks to all of you for your extensive answers!

They allow me to now rephrase the question:

Can I do the following (under 1.71 AND the planned 1.72 when the player role is no longer an NPC option) WITHOUT breaking any missions or stuff from other people:

Code: Select all

<key>roles</key> 
<string>player hunter trader pirate</string>

... because if I can, the biggest of the upcoming THREE new versions of the Realistic Shipyards is going to make the Ooniverse a much, MUCH bigger place ...

So, repeat: Can I do the above coding example without collisions or breaking other people`s oxps or stuff with any ship or not?

Hoping for replies

L

[Commander McLane]

The answers seem to imply that you can without breaking anything (except perhaps your own OXP).

My question is still: Why would you want to do this? Player ships are a little different from NPC-ships, so why mix them up?

[Lestradae]

Hye!

The answers seem to imply that you can without breaking anything (except perhaps your own OXP).

That would be fine ... how could I break my own OXP with doing this? When answering, keep my scripting "skill" level in mind, please

My question is still: Why would you want to do this? Player ships are a little different from NPC-ships, so why mix them up?

I did deliberately get a bit vague on that one because I don`t want to post spoilers about my upcoming third Edition (the other two are going to stay & be upgraded, too) ... well, what the heck.

OK, here`s the reason: There will be an as said 3rd version of my OXP with many, MANY ships merged into it. So that someone who downloads the whole bundle immediately has hundreds of ships to choose from.

Now this is about game balance. The player will have many more options what to do in the beginning, middle, veteran & ultra-high-end gaming; and the game should present more challenges to cope for that.

So many more ships will have roles they didn`t have before. Just to make that clear: I`m not going to give any role to any ship, I want it to be atmospherically fitting into Oolite (and I know this is very important to you ) so there will be no Dredger police or player thargoid carrier

But, the Ooniverse, to make up for the enhanced player options, will also have enhanced risks. It will be a much rougher place with the Realistic Shipyards Ultimate Edition in it. At the same time, I want my OXP to stay compatible game-balance-wise and atmospheric-wise and most important code-wise with anything else OXPish that is thrown in.

To do that, I do an extensive re-write of roles for literally hundreds of ships. You might understand why I`m not thinking about any further differentiations just yet: I`m going mad with the scope as it is. Perhaps might do later. When and if I have recovered from doing this here now.

Have a nice day (hope to have answered your question?)

L

[Kaks]

I agree with commander McLane.

If you really, really want to make the ooniverse a much bigger place, having 2 versions of the same ship using like_ship & a changed roleset is the one way that would cause less problems.

I've got to say I'd find it a bit confusing if a ship created exclusively for npc use, like a Black Baron ship, would show up for sale in a different galaxy. To the best of my knowledge, nobody leaves the Black Baron's service. It would kind of 'break' my concept of the oolite universe, and if enough of these anomalies keep cropping up, they would make the game feel a lot less 'real', at least to me, and - in my opinion - would be an obstacle to using your oxp...

Cheers,

Kaks.

[Lestradae]

Hi Kaks!

If you really, really want to make the ooniverse a much bigger place, having 2 versions of the same ship using like_ship & a changed roleset is the one way that would cause less problems.

Noted! I will do as you two say to be on the save side ... it will be much, much more work but hey, I got myself into it.

I've got to say I'd find it a bit confusing if a ship created exclusively for npc use, like a Black Baron ship, would show up for sale in a different galaxy. To the best of my knowledge, nobody leaves the Black Baron's service.

No, I`m not doing anything like that!

The OXPs I am merging are 95%+ ship OXPs, I didn`t touch ANYTHING that has conditions or missions attached, as, for example, ZZ-Oo-Haul or Commies or the like. Realistic Shipyards will still rewrite their player ship prices according to the formula but do nothing else with it!

Typical OXPs I merged (and am going to add/rewrite roles) are ones like "morrigan" or "rusty ships".

I want the whole thing to be also fitting if you play a mission OXP that has nothing to do with the Realistic Shipyards!

It would kind of 'break' my concept of the oolite universe, and if enough of these anomalies keep cropping up, they would make the game feel a lot less 'real', at least to me, and - in my opinion - would be an obstacle to using your oxp...

I have been thinking a lot about how to do this without what you say happening. I think it will fit into Oolite atmospherically. It will just make everything bigger, but if you fly a, say, Asassins mission there should be no difference.

As nothing can be to anyone`s liking, there will be two other versions of Realistic Shipyards which will not have this extreme enhancement in. The Strict Edition actually has nothing in but only rewrites the shipyard.plist. The Standard version will do that, add-in seven new high-end ships and an alternate shipyard that will appear from time to time in random systems.

So you get to choose on top of it anyways what you want in and what not. That the "E/Oo-lite" feel stays in is important to me too.

Cheers

L

[Commander McLane]

Lestradae, I still haven't understood why you want to give all ships the role "player" in the first place. What do you want to achieve with this?

Giving any ship the role "player" makes it recognizable to AIs of NPC ships (and to the whole scripting system) as the ship the player is actually flying. There is meant to be only one ship with role "player" flying in the Ooniverse at any given time.

So I simply don't understand why all the Boas, Cobras, Asps, Adders etc., that populate the system I am in, should have the role "player" as well. I simply cannot imagine any purpose for this. Why should for instance a bounty hunter from Random Hits or Anarchies, or a Black Monk Gunship, which is explicitely created by the respective OXP in order to attack the player, attack a random trader, hunter or police ship instead? Because that is the only purpose of assigning the role "player" to a ship.

So, again: What do you want to achieve by giving all ships the role "player"? Please explain it as precisely as possible, because I have the suspicion that what you actually want to achieve, is not achievable by this, but by doing something completely different. But I haven't yet understood what you actually want to achieve.

For instance: As you hopefully know by now, a ship is not made available to the player by giving it the role "player". For making it available it needs a shipyard.plist-entry. So the role and the availability in a shipyard are two different pairs of shoes.

A ship that is meant to be flown by the player needs basically two things: a shipdata.plist-entry with the role "player" only, and a corresponding shipyard.plist-entry. Without the entry in shipdata.plist it will never become available to the player. I don't actually know what would happen without the role "player" in its shipdata.plist-entry, but probably it would be messy.

So for any ship that has no shipyard.plist-entry and therefore is not available to the player, a role "player" simply makes no sense, except confusing the AI-mechanism of the game.

So, please, give us a little more explanation.

[Lestradae]

Hi Commander McLane,

there is a simple explanation: I will solve the roles thing in the way you and Kaks suggested: by adding an equivalent "like ship" with EITHER the role "player" OR any other role.

I NEVER intended to get an NPC ship with the role: player! (I would also have no idea what purpose that should have). And yes, I know by now that I need to make an entry in the shipyard.plist too to make something buyable. So this part is just a misunderstanding due to sloppy "explanation" on my part

I imagined (and possibly wrongly so) that the game simply wouldn`t choose the role "player" for an NPC ship, and as far as I understood Ahruman, this is going to BECOME true in 1.72.

Therefore it would have been simpler to do a role attribution of say ...

"player pirate hunter"

... with a shipyard.plist entry for buyability; then, in one go, I imagined, the game will choose this ship for NPC pirate and hunter roles AND it will become buyable with the same stats as those NPCs ships.

You understand why this would be much less work? I could do away with the etc. blabla likeship addition and just change the roles ...

Have I made myself understandable now or did I create even more confusion?

I would still like the simpler version to work but if problems are to be expected I`ll do it the way you say ...

Thanks for your feedback by the way, can make my OXP only better

L

[LittleBear]

I think you're right and doing it this way won't break anything on 1.72 but it would break Assassins, Random Hits, Boyracers, Anarchies (to name but a few) on 1.71 and below. These OXP do use the scanForNearestShipWithRole: which would pick up an NPC that included the role player when the AI of the OXP ship / station meant to find THE player!

An advantage of having different versions for each role is that you can tweak the likely equipment a ship of the same type has depending on whether its appearing as a trader, hunter or pirate. Eg: You might want to give the trader version a lower chance of carrying shield boosters (say) in order to simulate the fact that someone who is trading might well have spent his cash on a large cargo bay and filling it with stuff, whereas a hunter would be more likley to have spent his cash equipping the ship for combat. Or perhaps give hunters a rear laser but not traders.

[Lestradae]

Hi!

I think you won't break anything on 1.72 but it would break Assassins, Random Hits, Boyracers, Anarchies (to name but a few) on 1.71 and below.

Then it`s out of the question for me on doing it the simple way As repeatedly said, I will solve this the way Commander McLane suggested.

An advantage of having different versions for each role is that you can tweak the likely equipment a ship of the same type has depending on whether its appearing as a trader, hunter or pirate. Eg: You might want to give the trader version a lower chance of carrying shield boosters (say) in order to simulate the fact that someone who is trading might well have spent his cash on a large cargo bay and filling it with stuff, whereas a hunter would be more likley to have spent his cash equipping the ship for combat.

You`re definitely right there ... but it will have to come later. The workload I put onto myself is enough for now and, I believe, the month after the triple release in front of me

Cheers

L

[Commander McLane]

Okay, now I have understood what you want to do.

It might even work. I don't know, because it has never been tried before.

But even if it would work, I would still advocate maintaining the distinction between player ships and NPCs. It is cleaner, although it is admittedly a little more work, because you need an extra shipdata.plist-entry for the player-variant of any ship.

If you examine the original shipdata.plist (the one inside your Oolite.app (you're on a Mac, aren't you?)), you will see that it doesn't even use the like_ship-key. Player ships and non-player ships are simply two different worlds, so each ship is defined as an entity of its own.

Look at the shipdata-keys: In the NPC-ships you don't find view_position_foo, simply because noone's going to look out of their window. And of course you don't find the custom_views-array, for the very same reason.

Both of these are of course there - and needed - for player-ships. But in player-ships instead you won't find any has_foo-key (like has_ecm, has_escape_pod, has_scoop etc.). These keys determine whether an NPC-ship will be added to the Ooniverse with the corresponding equipment. But for a player-ship they make no sense, as the pre-installed equipment is determined by shipyard.plist, not by the shipdata.

If you want to create one single shipdata.plist-entry for every shiptype, which covers both player-ships and NPCs, you would of course need all the relevant entries in it, both view_position_foo and has_foo. So either way, whether the ship would finally be spawned as player or as NPC, it would have a lot of superfluous keys in its shipdata.

And although I don't think that would be harmful (and I am reasonably sure there are a lot of ships out there, which, due to use of like_ship, actually carry this superfluous ballast with them), it is just not clean scripting.

NB: What I said about those shipdata.plist-keys that are needed for a player-ship only, but not for an NPC, has of course some consequences for your work: If you make ships available to the player that haven't been intended so by their scripters, one important step on the way is that you give the player-variant view_positions. So you need to insert the four keys view_position_aft, view_position_forward, view_position_port and view_position_starboard for each ship you plan to make buyable. And then of course you have to assign sensible values to them. Which will also require that you playtest each of the ships, looking through all its windows yourself and firing a laser in each direction, in order to check that the view_positions and laser_positions don't interfere (which can in the worst case make his own laser invisible for the player; not a good condition for successful aiming and shooting exercises).

And in the most ideal of all Ooniverses you would then do the same for the external views, so the custom_views-array. This also has to be inserted to each player-ship's shipdata, and of course to be adjusted to the specific ship's size.

If you are really aiming for an Ultimate Edition, I think that's what everybody would expect.

[JensAyton]

I think you're right and doing it this way won't break anything on 1.72 but it would break Assassins, Random Hits, Boyracers, Anarchies (to name but a few) on 1.71 and below. These OXP do use the scanForNearestShipWithRole: which would pick up an NPC that included the role player when the AI of the OXP ship / station meant to find THE player!

As I stated yesterday in this very thread, scanForNearestShipWithRole: will not see such NPCs as the player, because it only searches by primary role. NPC ships would have “player” in their role set, but never as the primary role, so this problem does not exist. In older versions of Oolite, only the primary role was stored, except in some exceptional (buggy) cases, so this shouldn’t be a problem there either. Whether it’s a useful thing to do is another matter.

If you examine the original shipdata.plist (the one inside your Oolite.app (you're on a Mac, aren't you?)), you will see that it doesn't even use the like_ship-key.

I think this is mostly a historical curiosity.