[zookeeper]

See attached image. The turret would basically behave like a hybrid of single-part and multi-part turrets: it would have a visible moving arm which would rotate up and down and left and right on its own (unlike a multi-part turret, which has the barrel only rotating up and down while the base spins), of course within the bounds of the turret's FOV.

There doesn't seem to be any good way to simulate this using a regular multi-part turret at the moment. Having an invisible base to which the arm would be attached to doesn't work, since if the turret is tracking you and you fly over it, it can't continue tracking you without first spinning the base around 180 degrees.

[attachment deleted by admin]

[Vasudan Admiral]

Yeah but if you fly right over it that's the only time the turret will misbehave if you have an invisible base as opposed to a correctly code-implemented arm-only version.

Compared to the prospect of delving into the crazy turret code, I'd say that's a very small price to pay.

[Aardwolf]

That's the second part of what he posted.

I was originally going to say something like that, but then I read the second part and decided not to. You can probably get a little better by setting the base's rotation time to very nearly zero, but you'll still end up with a weird-looking rotating stick thing.

As for a temporary fix, just make the actual base invisible and make the apparent base be part of the hull mesh. Only problem then is the destroyed turret model.

[Vasudan Admiral]

Well you're talking about little ball-and-stick turrets basically, and the only noticable difference between an actual ball-and-stick turret and a multipart turret with an invisible base is going to be when you fly right over it and are watching it carefully; the stick will rotate weirdly for a second before it is pointing at you again.

Honestly I don't think such a small hiccup is worth the time to code a solution nor the possability of breaking the delicate turret code.

[zookeeper]

The problem with the multi-part turret approach isn't that it looks weird - with symmetric arms like this you wouldn't really be able to see if it's spinning or not. The problem is that it takes a lot of time to spin that 180 degrees, and while you can set the spin speed to be really fast, it'll also change the speed at which the barrel elevates, so you'd end up with a glitchy turret which pretty much instantly changes to point whichever way it wants without needing to visibly rotate the arm.

If there was a way to change the speed at which the base spins and the speed at which the arm elevates separately from each other, then sure, that approach would work adequately.

[Nuke]

bob's original multipart code could do something like this, however it was never implemented presumably because it broke collision detection, and somone else's (keldors?) code was used instead.

i wish we could set upper and lower limits (relative to starting position) on turret rotation instead just an upper limit. that would also make this and many other types of turrets possible. awhile back there was an idea to make turrets modular. just dont think anyone ever got around to it/wanted to do it.

[Vasudan Admiral]

Nuke: http://www.hard-light.net/wiki/index.php/Subsystems#.24Maximum_Barrel_Elevation:
Wanderer has been doing some cool things with turrets - also check out the Turret Base FOV bit.

Anyway I'd just set the turret rotation speed to something reasonable and leave it at that to be honest. People aren't going to notice or be bothered by it if it doesn't *quite* rotate exactly as a ball and arm turret would.

[Nuke]

we have a maximum, now wee need a minimum, and we need those maximums and minimums to be completely arbitrary.

[Vasudan Admiral]

But that's exactly what they are - the minimum for the barrel elevation is defined by the usual thing in the POF file. "$fov=180" there will define a half-sphere firing arc for a turret, and $Maximum Barrel Elevation: 90 will chop a 90° cone out of the top of that sphere, forming a kind of doughnut shaped line of sight.

[Wanderer]

Umh... not quite...

But that's exactly what they are - the minimum for the barrel elevation is defined by the usual thing in the POF file. "$fov=180" there will define a half-sphere firing arc for a turret,

Exactly so

and $Maximum Barrel Elevation: 90 will chop a 90° cone out of the top of that sphere, forming a kind of doughnut shaped line of sight.

And no... Maximum barrel elevation defaults (essentially to 90) and is valid only from 0 (barrels leveled) to 90 (barrels pointing at turret normal). So to get doughnut shaped thing you would need to set $fov=180 and max barrel elevation to say 45.

[Aardwolf]

HEY!

Couldn't this be done by making the turret's normal be 'up', constraining the horizontal movement to only be on one side of the turret, and constraining the vertical to go from -90 to 90?

Edit: Dunno if it's doable really, or how to do the destructible base part, but... w/e.

Edit II: Er... the above statement assumed a side-mounted turret.

Edit III: Illustration:

[Wanderer]

Yeah.. I tried to explain that same idea to Zookeeper and others couple of days (weeks ?) back but it seems i couldn't explain it clearly enough.

[Aardwolf]

Talking to him on IRC... he still seems confused, I'm not sure what about.

[Vasudan Admiral]

Oh right I thought the maximum angle setting worked the same way as the FOV. I like the way it's an actual max angle of elevation for the arms a lot better than what I described.

As for the idea yeah I see what you both mean - that should be exactly what they need.

[zookeeper]

Right, I'll try to figure that stuff out then.

[Aardwolf]

Oh right I thought the maximum angle setting worked the same way as the FOV. I like the way it's an actual max angle of elevation for the arms a lot better than what I described.

As for the idea yeah I see what you both mean - that should be exactly what they need.

Actually I don't know for certain that it is.

Hopefully Wanderer can enlighten us.