Oolite Bulletins

It looks like a destroyer.

nice.

It more reminds me of the spacing-guild ships or the whale-aliens from startrek (insertRomanNumeral).


edit: oh and welcome back.

Dei'-v2 wrote:

ovvldc wrote:

Looks like something out of Homeworld 2..

best wishes,
Oscar

Hm. There are some similarities in design philosophy, but it doesn't actually resemble any particular ship, or even the general design characteristics of either race.

Argh! Not that again!

I'm missing something, aren't I?

There was an animated discussion about someones textures, who did not take kindly to the comparison.

as to the turret problem...
what is it you want to achieve? precisely?


I had trouble placing turrets on subentities, but you may try placing a 'cap' on top of the turret, blocking it from firing 'upwards' (or rearwards).
This will prevent the turret from firing (do not fire on self).
However, this may not prevent it from facing (tracking a target) upwards though, unless you have it facing 45degrees down as per default, which may still be a problem with longer barrels.

I think what Dei'-v2 wants is a turret with two articulation points – that is, the base of the turrent rotates in one plane, and the cannon on that base elevates in another, as with a real-world naval gun turret. This would match the design in the picture.

This can’t be done with the current special-cased turret sub-entity code. It should become possible in 1.70 using JavaScript, essentially reimplementing the turret tracking in a ship script. It would be desireable to have a general mechanism for such turrets built into the game, but I can’t promise anything.

Ahruman wrote:

It would be desireable to have a general mechanism for such turrets built into the game, but I can’t promise anything.

Since i have never seriously looked upon code that reflects a 3d world enviroment such as oolite and opengl and DirectX i can´t tell exactly why.. but here comes

I do know that In Freespace 2, that had those kind of turrets with 2 with two articulation points, the turrets base would only rotate on 1 axis. so if you put the turrets base somewhere that required it to rotate on two axis to look right.. it just looked stupid when it did so.. cause it could as written only rotate on 1 axis... this was a code limitation...

So my point is that it may be more difficult than one might think, since the gun of turret have to rotate relative to the base´s orientation.. which is cool and easy as long as the model rotates only on a 1 axis, but gets Quite mathematical once it s not..

Sure it can be done, however CPU Cycle wise i think it is very exspensive as it will require some rather heavy computation with floating point numbers. which is also the why it was not supported in freespace 2 unless the turret was only rotating on 1 axis.

It might be wise to do the same to save some head ache and some CPU cycles...

Cheers Frame...

ummm... huh?

Are you suggesting waldo-turrets?

OOLite turrets already use 3 axis of rotation.

All a battleship-like turret needs is support for animated junctions of two subobjects.
the entire object can rotate around its y axis.
while the barrel-object needs to rotate around any defined axis relative to the turretobject's orientation.

Maybe it would be smart to have the barrels and turret try to face_target independent from eachother. With restricted freedom to move they will minimise the angle between faceZ and the target_vector.
(fire when target.to.Z.angle <= accuracy parameter)


The tricky bit about big ships is getting them to NOT face their targets...
atv least for me, as I put guns on bigships on the sides mostly. Love broadsides.

@A-man:
I can live without cool big guns.
Put it on the list above trumble-manifest entry though.

edit:
Enabling sub-subentities for some object-types may make this possible.

May be wise to hardcode restrictions, to prevent it being used in other objects though. As infinite recursion in entities would not be advisable for any program. (entity A has subentity B, which has subsubentity A, which has subobject B with subsubentity A...ad infinituum)

Arexack_Heretic wrote:

ummm... huh?
the entire object can rotate around its y axis.
while the barrel-object needs to rotate around any defined axis relative to the turretobject's orientation.

Bingo... However... i´m pretty sure if it where so easy... why did they put limitations on turret behaviours in Freespace 2..

Because it was to exspensive in CPU cycles to have it calculate the Pivot of the barrel-object eachtime the base of the turret turned a bit... which im pretty sure it will have to-do.. remember if a turret is tracking a target it would move a little all the time. add to that if the mothership turns.. calculations has to made again all over..

on a side note... yeah ships needs a classification and turrets need a way if being able to do independant targeting... A capital ship would never engage anything but another capital ship.. however if a "fighter" is deamed hostile, the turrets should still be able to engage it, and launch defense ships...

... uh, Frame, I think that's really a non-issue. I don't mean to be crass, but your reasoning strikes me as being somewhat dubious in any case.

It's more likely that somewhere during production that they simply decided that, considering the focus of the game, it was not worth the effort of animating the turrets. I find this especially likely since you're talking about Freespace 2, which came out about the same time as Homeworld 1, a game which had articulated battleship style turrets.

As for the turret style, with rotating turret/pivoting gun, yeah, that's what I was aiming for.

Dunno if this would require continuous calculation....I'm not aware how the current turret code works, let alone something with more complexity.

The problems in Freespace2 may have arrisen from how their engine was setup in the first place. Mebbe Oolite's OO code is more able to subdivide calculations.

As I see it, the SU model would be represented on the mainentity as just the origin-point, while the SU orientation is a seperate function within the orientation frame of the mainentity. (ie XYZ axis are derived from main-entity*quaternion)

The SE object orientation would need to be recalculated anyhow to determine target aim.

I could be mistaken offcourse, I'm no mathwiz, but I do not see why it should take too many resources.


..................
This is how I would imagine such a mechanism to work:

ship orientation determines referenceframe of turret.
turret remembers Y-rotation relative to this frame and the elevation-rotation of the barrels.
Each cycle do:
-Check whether barrels have fired in [rechargetime] seconds.
IF so do: check barrels-Z is within [a] degrees of target.
IF so do: Then fire.cannon
IF not: Barrel-X track.target + turret-Y track.target

A battleship-style turret would not be particularly CPU-intensive (I wouldn’t suggest doing it in JavaScript if that were the case) or hugely difficult. Thing is, there are lots of features I’d like to do that aren’t very hard individually; it’s doing all of them that takes an effort. :-)