Workarounds for six old demands - including multiple lasers!

[Cmdr. Maegil]

Using an OXP weapon, I noticed that ships that I expected to destroy with it often survived direct hits. I concluded that was because I was hitting the ships' subentities.
Even so, I decided to ask, as it might be of use for future reference on someone's oxp:

I imagine that if an subentity isn't frangible, any damage it receives is transmitted to the main entity, but what if they are indeed frangible?

"Shoot the turrets!"
If the turrets are frangible, they can blow up independently, but how does it affect the main entity - will it receive no damage at all, or only as much as the subent's previous energy level, or any other amount?

[JensAyton]

When a destructible subentity is hit, the parent takes 1 % of the damage. (The subentity takes 100 %, so weapons are technically more efficient in this case.)

[Cmdr. Maegil]

1%? Is this tweakable?

Just out of curiosity, does this behaviour extend to the player frangible subents - and if so, do they direct the damage to the correct shield bank?

[JensAyton]

1%? Is this tweakable?

Nope.

Just out of curiosity, does this behaviour extend to the player frangible subents - and if so, do they direct the damage to the correct shield bank?

It looks as though player subentities won’t be protected by shields, but the bleed-through damage will go to the shields.

[DaddyHoggy]

So...

if I created a Cobra MKIII that was covered in a mosaic of tiny sub-entities (like ERA on a tank but even smaller) - then every time one was hit by a laser it would be destroyed completely but only 1% of damage would be transferred to the main ship? So, that's a good way of protecting yourself from the worst effects of a Mil laser then? Or have I missed something? (since a Mil laser can quite effectively chew its way through your shields and into your energy banks - thus risking damaging equipment too)

[Commander McLane]

So...

if I created a Cobra MKIII that was covered in a mosaic of tiny sub-entities (like ERA on a tank but even smaller) - then every time one was hit by a laser it would be destroyed completely but only 1% of damage would be transferred to the main ship? So, that's a good way of protecting yourself from the worst effects of a Mil laser then?

That's the main feature of the DW Cobra. Its many subentities make it quite difficult to kill. It's especially noticeable if you're using NPC shields, because you see lots and lots of explosions, and still the ship glows red with every hit.

So yes, it works quite well as a (temporary ) protection against my Mil laser, making the agony much longer.

[Cmdr. Maegil]

The truth is, I've been behaving somewhat underhandedly, trying to squeeze my doubts on other threads and only making oblique questions.
In any case, my ideas had matured enough that I was already trying to get some work done for show before starting to ask for more specific help.

Obliqueness nonwithstanding, it seems my questions raised eyebrows and now DaddyHoggy made a suggestion which natural development would eventually lead to my intentions.

Therefore it's time to come clean. I was trying to turn the Kirin into a extremely automated beast of war. I guess everybody knew that already, but not the scope...

First of all, the subents: turn the player entity to a singularity and the player's entire ship to a subentity - it gives you complete control over the damage received and of destroyable kits, enabling you to simulate extreme danger when the player itself is quite safe; If the code decided it was time for te ship to be destroyed, it could auto-eject the crew...
...and the player singularity, by replacing the mortal shell of a subentity with a isHulk NPC and fly away with an escape capsule-shaped body - FLY YOUR ESCAPE CAPSULE YAY!!!!!!!!!!!!!

Then, there's the autopilot. I tried to merge the Autoskim and TAF reset OXPs to "give the bridge to your #1", which is to say, allow the ship to be piloted by the AI... I've almost got it running, it should set the ASC's target as its own, get there, and (if dockable) dock - even auto-engage hostiles (I still can't auto-change the ASC itself, though) - PLAYER AUTOPILOT YAY!!!!!!!!!!!!!


As for the ship itself...<roll drums>


The basic concept derived from this sentence on [wiki]Shipdata.plist[/wiki] entry for missile_launch_position:

This position should lie outside the bounding box of the core entity and not just outside of the ships mesh. Default value: (0, -4, 1)
If the position does lie inside the bounding box, the launch position is shifted along its direction until the launched missile lies outside the bounding box of the central entity. (Bounding boxes of subentities are ignored) The collision radius of the launched missile is taken into account. The collision radius for a plain missile is 4.52 meter.

This means that if the entire ship is a subent and you can reduce the missile's collision radius to a singularity, you can station missiles and mines right by the mesh.

Moreover, if they are launched by the player (not spawned), the owner isPlayer. This should mean that their subent lasers equate to the player's lasers even though they are on a NPC - REAL PLAYER MULTILASERS YAY!!!!!!!!!

"And how to fire-control the mine's laser subents", you may ask, "if they're controlled by the mine? Won't they open fire on anything that crosses the sights, regardless of your will?"
Since there isn't a handler to fire lasers as there is for missiles, I figured out a workaround: put the player ship's laser position elsewhere, pointing at a buoy fixed to the player's position. If the buoy is hit, the lasers are ON, and the subents go to an attack AI - they'll fire on their own, but probably only if the player is aligned...
"So, unless aligned, they won't fire? How daft!"
Well, the mines don't necessarily share the same position as the player - they must remain outside the mesh. Which means that a mine's scan won't be precisely centred with the player So you can bind another singularity just outside the player's range, but still inside the mine's and make it its target (accuracy =10).
Now, each time you press fire, the laser flag goes ON and the subents already have a nice target to attack - and if the player's target is in the way, so much the worse for it...


It doesn't end there: if they fire submunition with nullAI, a set speed (+player speed) and the same alignment as the ship, you get a railgun which causes isPlayer collision damage - isPlayer MISSION-FINISHING PRIMABLE EQUIPMENT YAY!!!!!!!!!!!!!
A further development: target an enemy, determine the space-time intersection point of the target's vector and a that of an unfired "bullet", and you get a rudimentary firing predictor. Changing the "main weapon" to the railguns and affixing a (singularity) target to that point allows to autolock-on to it, showing where to fire the railguns to hit the target n seconds later.

"What about the turrets", you may ask. Using one or more extra entities (depending on how the collision code works), you can have extra fire control centres throughout your ship. One singularity sets scan range to 3Km radius and is affixed at the same distance, you'll scan more or less the same area as the turrets' range. Either make the turrets on this facing subents to the scanner mine, or if that makes for a huge collision radius, associate each turret to a different mine and bind their target to the scanner mine (stopping it will deny the turrets new targets, so they'll become inactive) - TURRETS WITH INDEPENDENT TARGETING AND FIRE CONTROL YAY!!!!!!!!!!!!!

If instead of adding ball turrets, one digs a foxhole on the hull mesh and binds an armed, spherical rotating attack mine into it, it can function as a much more powerful and precise turret (holding as many singularity laser subents as desired). If the mine's "forward" area is cut off, one can add "laser barrel" subents without changing the collision radius, making it visually multibarreled.
The fit can even be quite tight, as long as it doesn't touch the mesh. It shouldn't be able to shoot the ship, as if it goes below its clear field of fire it'll also leave the scanner mine's range, resulting in a target lost message - LASER TURRETS YAY!!!!!!!!!!!!!!!!.

There are more ideas where these came from, but this is the basic for this project.

[JensAyton]

Don’t you have a boat to deliver or something rather than violating my poor, sensitive game? ;-)

[Cmdr. Maegil]

Ahruman, don't worry so much - nobody is forced to DL any OXP...

Regardless of that, OXPs can, and are used to, expand entire niches - the latest being the miner, an occupation which most people consider as being below them, at least until someone decided to enhance the role with a dedicated ship.

The role I really want to develop is one that most players consider off-limits (at least for themselves), as it completely overshadow the normal ships: the military.
Unfortunately, some military ships are by far too downgraded to balance for their strong points - to the same standards as the civilian core ships... (I've made my objections on this regard while replying on another thread)

The Kirin is the closest thing so far to a player battleship, but it isn't quite there, so I decided to try and make it into what I consider a "balanced" Navy light frigate - BTW, IMHO the Galnavy frigate is utterly unbalanced for its size and role; more like an oversized, under-armed placebo made just for show, and could very well benefit from a complete overhaul (especially now that Thargoid spawned new Thargoids).

In any case, these are NOT ships to appear on the open market - I have another project in mind, but it isn't mature yet. Basically, you have to join the navy and play Oolite more in the line of a space shooter (but not exclusively), to be able to fly them and command entire formations - and then again, you'd have to be at least a Captain to get to fly a Kirin, or a Vice-Admiral for the Behemoth, so it's not about making it overly easy (the enemies should be tough enough to call for the navy to get involved), but rather rewarding the players with bigger commands, better military gear and tougher missions.

As for my Kirin... what can I say? I <3 my Kirin...

[Wildeblood]

A further development: target an enemy, determine the space-time intersection point of the target's vector and a that of an unfired "bullet", and you get a rudimentary firing predictor. Changing the "main weapon" to the railguns and affixing a (singularity) target to that point allows to autolock-on to it, showing where to fire the railguns to hit the target n seconds later.

That is a good idea. Do you have a working demonstration we can download and test?

[Cmdr. Maegil]

No demo, but I think the following formula might work:this.predictor.position = player.target.orientation.vectorFormard.magnitude.multiply ( player.target.orientation.vectorForward.magnitude.divide (player.ship.orientation.vectorForward.add (this.projectile.speed)));

Define a projectile.speed (normally 5000m/s?, but for testing reasons let us make it 500), spawn something and bind it to that position, and it should get closer or farther from the target according to his speed and trajectory.

[JensAyton]

I think you want direction rather than magnitude.

[Cmdr. Maegil]

The predictor is somewhere in front of the target.
IINM, Its distance from the target = its distance from the player multiplied by (the target's speed divided by (player speed+bullet speed)

[JensAyton]

Regardless of what you actually want, foo.magnitude.multiply() won’t do anything useful since magnitude is a number. :-)

[Cmdr. Maegil]

Regardless of what you actually want, foo.magnitude.multiply() won’t do anything useful since magnitude is a number.

Ah! I must declare the vector itself before multiplying it by a number... Thanks!

this.predictor.position =
[b]this.ship.orientation.vectorForward.direction[/b].multiply
(this.ship.orientation.vectorForward.magnitude.multiply
(this.ship.orientation.vectorForward.magnitude.divide
(player.ship.orientation.vectorForward.magnitude.add
(this.projectile.speed))));

EDIT:it's the correct position, but it'd disappear the moment the player changed target; its reference entity must be the player.target (as this.ship), not the player itself.
I?ve changed it, and will tinker with this tonight; the predictor itself isn't too difficult to make... maybe tomorrow I'll have something usable.