Hi, Amen Brick!
After comparing my version of your OXP to the current download version it seems they are exactly identical. So I guess there is no newer published version yet. Therefore I would like to share the things I have stumbled across when I examined the OXP. Some issues are probably already fixed on your machine, some others perhaps not yet. Anyway, I think it is worthwhile to release a new, improved version. So, here come my observations (and my apologies for sharing some quite lengthy observations):
In the abYacht-entry you have these lines, which make the whole plist non-working. There is one key and one value missing:
Code: Select all
<key>max_missiles</key>
<integer>6</integer>
<string>EQ_HARDENED_MISSILE</string>
<key>max_cargo</key>
<key>missile_launch_position</key>
<string>0.0 -11.0 -17.0</string>
I guess what you meant is this. I've put in the same
max_cargo value as for the player-version:
Code: Select all
<key>missile_role</key>
<string>EQ_HARDENED_MISSILE</string>
<key>max_cargo</key>
<integer>30</integer>
With these additions the shipdata.plist becomes a working plist. My plist-editor sorts working plists alphabetically by default. Therefore all remarks from now on follow in an alphabetic order.
One general remark first: As already mentioned here, if you don't want to see as many Biodomes in the Ooniverse as there are Boas or Cobras, you have to tune down their probability of appearing, read: their role-probability. In my personal version I have chosen values between 0.05 and 0.2, depending on the ship. You could of course also choose an even smaller value, if you for instance want to make Biodomes very rare; or a higher value, if you want Hospital-ships to appear more often.
Biodome: No specific problems. I guess the fact that it is completely unarmed and defenseless is deliberate. So there is only the issue of the role-probability. I have changed it to:
Code: Select all
<key>roles</key>
<string>trader(0.1)</string>
meaning that for every trader ship created by the game the Biodome has only one tenth the probability to become that ship than any ship without the specified probability.
Cruiseship: It seems to me that the combination of
Code: Select all
<key>max_missiles</key>
<integer>0</integer>
<key>missiles</key>
<integer>4</integer>
doesn't make much sense. The first one specifies that the ship cannot carry missiles at all, and the second one gives it four missiles? Seems contradictory to me. Not sure what the engine will make of it. Probably the ship won't fire missiles.
I've given it a role-probability of
trader(0.2).
There is one more cosmetic issue: The
weapon_position_foo-entries, except
weapon_position_forward, are - strictly speaking - superfluous, because the ship has - as most NPCs - only a forward weapon. There is no
aft_weapon_type defined, and NPCs generally cannot have sideways weapons.
Supercargo: The ship has no
aft_eject_position defined, which is perhaps only a cosmetic issue. It also lacks a definition of
ai_type, which could be more serious. Although I think, if called by the
system populator as
trader, it will automatically get a suitable AI.
Noticable about the Supercargo is that it cannot fit any extra equipment. While the Biodome has an ECM and the Cruiseship at least the chance to have an ECM (although no other equipment), the Supercargo has no possible upgrades at all. And the same is true for the Superlifter. Not being able to be outfitted with
any extra equipment, from ECM and fuel scoops over shield enhancements to heat shielding, even an escape pod, seems a little odd for these ships, although they possibly are meant to be quite basic and crude ships, without sophistication? I'm not sure.
More serious is the Supercargo's lack of defenses. It has no weapon at all (neither a
forward_weapon_type- nor a
aft_weapon_type-key), although interestingly there is a
laser_color defined. And again
max_missiles are set to zero. An invitation for piracy. For its defense the ship would completely rely on its escorts, but depending on the AI-handling probably escorts would never get set up. And of course for a ship without any weapons, the
weapon_position_foo-keys are completely superfluous.
As far as its role probability is concerned, I for my game have tuned it down to
trader(0.1).
Superlifter: For the missing extra equipment see above. Again no
aft_eject_position. And again it has no weapons or defenses at all. There are not even escorts planned. So in practise the ship will be completely at the pirates' mercy. And again, if there are no weapons installed, no weapon positions are needed.
My personal feeling is that the Superlifter is probably a rarer sight than the Supercargo, so I've reduced its role probability to
trader(0.05).
The
abBattleship comes far better equipped than the cargo ships, but what is most striking about it is that it will never appear in-game at all. It has no
First I wasn't sure whether this maybe was deliberately so, the whole shipdata-entry perhaps only a template? But it has a different paintjob than its two cousins, and it is neither marked as a template, nor do the other variants reference it. So what would it be? Most probably a militia-like ship, perhaps employed by a planetary government, or a faction of some kind? There isn't really a native role for that, so either it would need a custom AI and role, and would have to be placed in certain systems by a script. Or it could get the native role closest to the one sketched here, which would be hunter, again with a low probability. In that case it should have
Code: Select all
<key>ai_type</key>
<string>route1patrolAI.plist</string>
<key>roles</key>
<string>hunter(0.1)</string>
Reading again I see the
Code: Select all
<key>scanClass</key>
<string>CLASS_MILITARY</string>
which indicates a use as Navy ship. The only problem is that there is no native role for that. The game engine simply doesn't recognize military ships. Practically they are the same as police, the only difference being that CLASS_MILITARY ships don't fine offenders, they just shoot them. Apart from that, AI, appearance on the scanner, and behaviour are just the same as for CLASS_POLICE. So if you want to make them into specifically military ships, you would have to give them a custom role and a custom AI, and write a script that brings them into being.
The
Code: Select all
<key> has_energy_bomb </key>
<true/>
won't do anything, because of the extra spaces. Probably it is a disabled derelict of an experiment? But it's also there in the other two variants.
At least all Battleship-variants have a range of possible extra equipment, although I don't quite understand why these fairly big ships cannot have an ECM. They are not particularly agile, so they would seem vulnerable to missile attacks. Perhaps they just trust their superior shielding (read:
energy and
energy_recharge_rate)?
Instead they have a probability for having two quite exotic pieces of equipment:
Code: Select all
<key>has_military_jammer</key>
<real>0.40000000000000002</real>
<key>has_military_scanner_filter</key>
<real>0.5</real>
(numbers taken from the abBattleship-entry). The readMe announces these as cloaking equipment and detection of cloaked ships, but that's in reality not what they are (or are meant to be). The cloaking device has its own shipdata-key:
has_cloaking_device. The two devices enabled for the Battleship variants do something else. The first prevents the drawing of the ship's blip on the scanner, the second lets the blip of another ship, which has the first one installed, reappear (and I am not even sure if and how this works for NPCs). In any case, the ships themselves are and remain clearly visible and can be targetted and fired at. And a ship of this size will be hard to overlook anyway. So in my opinion at least the military jammer makes no sense for a Battleship. One could argue about the filter, but as no other ship in the Ooniverse has a military jammer (it was an experimental device, and Giles had probably some plans with it, but he didn't implement anything; and neither did anybody since), it seems pretty useless, too. For my game I have deleted both keys completely, in all three shipdata-entries.
The biggest and most striking flaw of all three Battleship variants, however, is again their complete defenselessness. They are sitting ducks, just waiting for being roasted slowly (I've done that repeatedly, and never got any response, except some lame manoeuvering). Again they have no weapons defined. I would at least expect a
Code: Select all
<key>forward_weapon_type</key>
<string>WEAPON_BEAM_LASER</string>
probably even a military laser, and probably even a rear laser (key
aft_weapon_type). They don't even fire missiles, although they have an impressing
Code: Select all
<key>max_missiles</key>
<integer>16</integer>
But they don't have the
Code: Select all
<key>missiles</key>
<integer>16</integer>
or any other number, so the number of missiles actually carried is always set to zero.
Also the
Code: Select all
<key>escorts</key>
<integer>16</integer>
looks impressing, although of the dozen or so police Battleships I met so far none had any escorts. I know that police escorts use to have the role wingman, but I don't know how escorts of police/military ships are set up by the engine. The route1PatrolAI (which is used for police, military, and hunters) has no
setUpEscorts-method, however there are a couple of
deployEscorts. This is either a bug in the AI, or police escorts are set up in a different way? I am not sure, there are other people on the board who have a deeper insight into the whole escort issue. Probably the number is too big for the engine to handle? Possibly there is an upper limit for escorts? I don't know.
The
abBattleshipPirate should probably have escorts (haven't met one yet). At least there are usually pirates with escorts, although again in pirateAI there is no
setUpEscorts. So probably the engine takes care of it somewhere else. The ship has the correct
ai_type set, although there is no
However, the system populator should take care of that all by itself. If you, though, at some point are planning to add pirate Battleships to the Ooniverse via script, they would be legally clean.
As it is meant to be a stolen ship, according to its name, I've given it only a low probability to appear:
pirate(0.05).
The
abBattleshipPolice has an
Code: Select all
<key>escort-ship</key>
<string>viper</string>
defined, and probably this is the reason why it doesn't get escorts. The
viper doesn't have the role
escort or
wingman, so it can't be chosen by the engine as escort (yes, escorting is a quite complex field in Oolite). Therefore either
viper-interceptor or
viper-pursuit would be a better choice for an escort-ship. Both have
wingman among their roles.
I don't understand the
Probably mistakenly copied & pasted from another shipdata-entry? A
carrier is defined as a ship you can dock with. With a police Battleship you can't, simply because it has no docking bay. Therefore it isn't a carrier. The two lines should be deleted. Or you have to give the ship a docking bay. This has to be done with a subentity that has the string "dock" in its name. But at this point there are no subentities defined for the police Battleship.
I again tuned the role probability down to 0.1. I don't think you would meet as many police Battleships as Vipers in every system.
Code: Select all
<key>scanClass</key>
<string>CLASS_Police</string>
is wrong and won't be recognized by the game. It has to be all capital letters: CLASS_POLICE.
I also think all three variants are too fast.
Code: Select all
<key>max_flight_speed</key>
<real>400</real>
seems quite speedy for a ship which has roughly three times the dimensions and about twenty times the volume of a CobraIII! One oddity this too big speed leads to is that the police variant outruns its escorts, which are considerably slower, and can't catch up. I have now reduced the top speed to 200 for all three variants.
abHospital: Again no
aft_eject_position, but a military scanner filter it doesn't really need, and neither ECM nor escape pods for evacuating the patients in case of an attack. At least it should be able to fire its six missiles. I have again tuned down its role probability to 0.1.
abYacht: Again the quite exotic military jammer among the possible equipment, but not even a fuel scoop? A lot of
max_energy, an incredible
energy_recharge_rate, a fast
max_flight_speed, military laser, hardheads: This is definitely an uber ship candidate. I don't want to see uber ships too often, even if you have already limited it to safer systems (why? with these specs the owner seems to be bound to surf especially through Anarchies): role probability set to
trader(0.05).
Finally the
player ship: Has some entries that don't make sense for player ships:
has_ecm and
missiles are for player ships defined in shipyard.plist, not in shipdata.plist,
likely_cargo is not a fixed value, but depends on what you have bought and/or scooped. So these are simply ignored in a player ship-entry. On the other hand, a desirable addition would be that of external views. Try the
custom_views-array of the Anaconda first, although the Yacht is almost two-and-a-half times as big (and still only 30t cargo capacity, compared to 750??), so the values could easily be doubled. Some of the specs are tuned down, if compared to the NPC-version. But it still is pretty much an uber ship (in my opinion).
Two remarks go to all entries: none of the ships has an exhaust plume. Is this on purpose, because they use a radically new form of in-system propulsion? It would need an
Code: Select all
<key>exhaust</key>
<array>
<string> ... </string>
</array>
for each ship. For how it works see the
documentation.
And the common problem of
case-sensitivity: All entries use capital letters in their
model-keys, like in
Code: Select all
<key>model</key>
<string>abYacht.dat</string>
however the corresponding dat-files are named in small letters only. This may and will lead to "file not found"-problems on case-sensitive systems.
And there is the evenly common issue of
unique naming. You have put your initials in front of some names, but not all of them. There may easily be another ship designer who creates a Biodome, a Cruiseship, a Supercargo or a Superlifter. If he does, your ships will be gone, because another OXP will most likely follow alphabetically
after yours. The same goes for the names of the dat-files and the texture files. All of that should better be named uniquely.
In the shipyard.plist there is only one problem: no equipment item must be listed in both the
optional_equipment and the
standard_equipment arrays. If every abYacht has a fuel scoop by default and already included in the retail price (this is the meaning of
standard_equipment), then it makes no sense that another fuel scoop is installed (and has to be paid for) in about 15 per cent of all the Yachts offered for sale (this is the meaning of
optional_equipment). So the EQ_FUEL_SCOOPS has to be deleted from one of the lists.
Finally two remarks as far as the whole OXP-package is concerned:
The folder "Images" is meant to contain
background images for mission screens, not screenshots from Wings3d. I don't suppose you plan to write a mission around your construction efforts in Wings, so this whole folder is not needed in your OXP. That would also save 800KB of space.
Players who are using a Mac wouldn't see these screenshots anyway, nor would they read your readMe, because they wouldn't open your OXP. This is because on a Mac your OXP is not a folder like on a PC, but appears as a single file. Therefore any readMe's, documentation, screenshots, or extras have to be placed
outside the OXP. It is best to create a mother-folder for your OXP. In that mother folder you put your OXP-folder (without the readMe and the Images inside), and then you place whatever you want to send with your OXP next to it in the mother folder. Now also Mac-users will appreciate your ship-designing work.
Hope these remarks are helpful for an upcoming new release of your OXP. I like the ships and think they are a nice addition to the Ooniverse, once the small problems are brushed out.
Greetings
CMcL
