Oops, had overlooked your long post. I think I can answer one or two questions.
Simon B wrote:The cougar and cruiser to have military varients. Coyote to have a high-tech only ultra-fast version. (Star Runner?)
For ultrafast ships see also about anything Charlie ever designed (the ships which are named after birds of prey).
Simon B wrote:*** Is there an existing frangible ship someplace? ***
Lots of them. Most notably the
Imperial Courier, all ships from
military.oxp and
renegades.oxp. And of course the very famous
Darkwheel Cobra (which resembles the Cobra as seen on the cover page of the Dark Wheel novella). And some others as well.
Simon B wrote:I wanted to make the Tuatara frangible, so you could blow it up in three bits. Maybe script a spin if one pontoon gets destroyed, and a player action to jettison pontoons maybe? (Does this sound doable to you guys?)
The trouble is that I need the exhaust to go away when an engine is blown off. I tried just adding the exhaust to the engine model in the shipdata.plist - but it didn't render. I'm guessing you cannot have subsystems of subsystems - which would be sane-ish.
So, say, a jettison action would have to change the whole model assigned to the player to be the life-section only. With two pontoons, dead, floating off at angles.
I'd also need (death?) actions for the cases where one or other engine is the first to go or the main section goes. If the first two, I need another action for the next destroyed model.
Much of this seems (somehow) doable. But only by using some tricks. Of course the basics are that whenever a model is frangible, you can shoot and destroy its subentities one by one, and the main entity, together with the rest of the subentities will fly on. They still make up one "super entity", if you will. This leads to some obvious issues in your case:
- If the main entity is killed, the whole thing disappears. There are no subentities without a main entity.
- Main entity and subentities do not care how they are actually connected. Example: Take the Hognose towing a ship, or the GRS Ship towing a buoy. In both cases the towing ship is the main entity, and the towed object, the towing line, and the attached hook are three subentities. If you manage to get close enough to shoot at the towing line and take it out, the rest of the bunch continue to be in unity. The Hognose or GRS Ship still tows whatever is attached to it, although the visible connection is gone (because actually everything is one entity). The same would apply to a ship's pontoon if attached by a small bridge. If the whole thing is frangible you can kill the bridge, but ship and pontoon would still act as if connected. No way of overcoming this.
- And as you have already discovered, subentities cannot have subentities. Which also means that you can't have partial frangibility. You can't group some subentities into a cluster that can only be taken out as a whole. And you can't exempt some of your subentities from frangibility. It's a take-it-or-leave-it for the whole ship.
What you can (and have to) do with scripting (in your case a bundle of ship-scripts, which BTW also replace the legacy death_actions), is to nonchalantly replace your ship with a completely different one altogether. So let's say you are firing on your enemy's pontoon and blast it to oblivion. As you observed, the exhaust would continue to exist. Makes no sense. So in the this.shipDied-part of the ship script you would remove the whole ship and replace it with a different model that is lacking the pontoon
and the respective exhaust. You would of course need to check whether the other pontoon has already been destroyed or still does exist, and choose the replacement model accordingly. This has the bonus that the replacement models (left pontoon only, right pontoon only, no pontoons at all) could have reduced speeds in their shipdata. So the crippled ship would lose thrust and speed (and probably manoeuverability as well).
There is no really satisfying method of removing the existing ship yet (replacing it is no problem), but there will be one in 1.72.
I doubt strongly, though, that this replacement-technique will work for player ships (for the game engine the player
is his ship; if you remove the ship, what is left of him?). Which might be a drawback for your plans.
Simon B wrote:I have noticed that NPCs can get more than one laser to a facing if they are using multi-models. (Don't see how this could work with a player. )
It doesn't.
Simon B wrote:A single ship is excessively dangerous if it has more than 2 weapons on each facing. I'm thinking 3-6... I can use a cluster of legs like a starfish wrapping prey. (So I only need one model repeated.) I can use the traditional SF spot of light for a power supply/engine, and little red balls for missiles. Make it frangible so it's fun to blow up.
So, if I give it three forward military lasers, and a collection of ECM hardened missiles? (Nukes?) And script carefully - it shows up and attacks everything!
All of that has been said and done before. It's kind of the point of the above mentioned
military.oxp and
renegades.oxp. For the cluster of legs see especially the Hydra. I'd strongly suggest that you study these.
And yes, before you ask: If a subentity that carries a laser is destroyed, the laser stops working. Which is BTW the most satisfying tactic to take on a Hydra: Kill all its nasty laser needles one by one, and then slowly roast its (defenceless) main entity.
Although I have to say: A ship with a couple of front
military lasers would be a formidable opponent. The existing multiple-laser ships (the
Weeviloid Hunter is also notable, as the first of its kind and basically a design study for the use of multiple lasers and subentities on ships) only have beam lasers in their subentities. Which gives a player with one military laser an advantage, because of the smaller firing range of a beam laser.
Simon B wrote:Now ... what does it take to destroy a station?
As it is now, only enough firepower. (And we are talking about
magnitudes more here than any ship in Oolite could or should ever have.) Main stations were programmed to be indestructible, however, in previous versions of Oolite. And they are still immune to q-bombs, although I don't know why and how that works, and the immunity does not extend to energy bombs.