-= Gametoast.com =-

"On Turrets", an essay by DarthD.U.C.K.

You may ask whats the point of this essay since there is already this tutorial about creating custom turrets and its really not difficult to set up the odf for one. You are right, if you just want to create a simple turret with a base and a barrel you dont need to read further. If you however want to set up more interesting turrets and understand how it works and what the parameters really do, then read on!

Setting up a turret seems pretty simple but once you are setting up one a little unusual, you will realize how complex and dynamic it actually is.
In the last Months I set up various more or less unusual turrets and will now explain everything as far as i experienced and deduced it.
In the following text you will find a complete explanation/guide of/through the set-up of turrets.

Here is the general hierarchy (in battlefront). A turret usually consists of a turretbase(turretnode) that rotates horizontally. On top of the base is the turrethead(aimer) which rotates vertically. Fixed on the turrethead is the actual cannon/barrel, which moves backwards when the turret fires. The firepoint is where the ordnance is shot from.

First off two general things: All objects in the hierarchy are optional, you dont need a turrethead, barrel or firepoint.
There are two kinds of turrets: The first is the weapon of a vehiclepilot, it doesnt have a Turretnode(base) because the player controls the vehicle itself. The second is an actual turret that standing around by itself or a copilots weapon fixed on a vehicle.


Hierarchy
Because one flyer/armedbuilding can have multiple turrets, the beginning of one is marked with this line: (vehicle) (armedbuilding)
It can be compred to the "WEAPONSECTION" of a pilot.

The turretbase
In the odf the turretbase is defined with the line: The turrets and cameras vertical rotation is controlled through the line: The turrets and cameras horizontal rotation is controlled through the line: If you dont set these values, Battlefront will assume that the limit is "-180 180".
Another very important line is this: It determines how much vertical rotation is done by the base. 0 is no pitching and 1 is all pitching.

For vertical rotationlimits negative value is upwardrotation and the positive value is downwards.
For horizontal rotationlimits negative value is rotation to the right and positive to the left.

It seems to be unnecessary to define a pitchlimit for the turretbase since it wont do any pitching in most cases. The reason for it is that when the player controls the turret, the turretnode takes control over it. That means that the yaw- and pitchlimits of the turretnode apply for the whole turret and that the aimer will rotate with it, even if hes not really a child of the turretnode in the models hierarchy.
A turretnode will always be alligned along the z-axis. You can however let it point backwards if you add 180 to both yawlimitvalues.
A turretnode will always aim in the exact same direction as the camera points.
If you dont have a turretnode you still need the rotationlimits because they apply for the camera as well.

A turretnode can have aimers.
A turretnode can have barrels.
A turretnode can have firepoints.

The turrethead
The beginning of an aimer is marked with this line: The head is defined with this line: The aimers vertical rotation is controlled through this line: The aimers horizontal rotation is controlled through this line: If you dont set these values, Battlefront will assume that the limit is "-180 180".

Because you can have multiple aimers you tell Battlefront that another one follows with this line: It seems to be unnecessary to define a yawlimit for the aimer if its overridden by the turretnodes anyway. The reason for it is that when the AI controls the turret, it does not need a turretnode, it controls all aimers seperately. You can notice that on vehicles like the stock gunship or fightertank where the maincannons always point forward when the player pilots them. When they are AI-piloted these move independently from the vehicle. If the turret has multiple aimers and the target is outside the limits of one, this aimer wont shoot.

This line allows the aimers to rotate outside of the given limits: I dont know what purpose that has. Its function is probably AI-exclusive.


It is possible to create a hierarchy of aimers, with his line: When put above "AimerNodename", this makes the aimer parent of all following aimers until the next aimer with this line is listed.
This will not work with a turretnode defined. You can however use it as substitute for a turretnode because it isn't automatically aligned along the z-axis.
A (parent) aimer will always aim so that it can shoot into the direction the camera points, it is not forced to point in the same direction.

If the weapon has multiple salvos, one aimer will fire one salvo.

An aimer can have barrels.
An aimer can have firepoints.

The barrel
A barrel is defined with this line: The recoilstrength of the barrel is defined with this line: If you dont set the recoil value Battlefront will assume that its zero.

Because you can have multiple barrels you tell Battlefront that another one follows with this line: If the weapon has multiple shots, one barrel will fire one shot.

A barrel can have firepoints.

The firepoint
A firepoint is defined with this line: If no firepoint is defined the ordnance will be fired from the next higher element in the hierarchy. if you have a barrel it will be fired from there. If you dont have a barrel it will be fired from the aimer.


Piloting
Pilot types
A turret/vehicle can have various pilottypes, they are defined with the line: These types are:

• none -used in the flyers in campaign that are animed through their vehiclespawn, together with the line:

  Code: Select all

  NeverCrashWhenUnpiloted = "1"

• vehicle -default, enterable by units
• self -selfpiloted, cant be entered by anyone
• vehicleself-the cool one: selfpiloted, but can also be entered by units
• remote -controlled through remote terminal

With the following line the turret will shoot even if it does not have a target: If you want to enable units to use their own weapons while being in a vehicle, follow this tutorial

Visible pilots
In order to make the pilot visible you have to add this line: In Walker vehicles, the following line is used, supposedly because the pilot has to move with the walkers animations. Through defining the pilots position, he/she/it automatically becomes visible and vulnerable.
The pilot will always look into the direction in which the turret/vehicle he controls aims.

You need to define an animation for the pilot with this line: You can find the names of stock pilotanimations in the "assets\Animations\SoldierAnimationBank\human_4"-folder.

You can also instead define a 9pose animation for the pilot with this line: This allows dynamic movement of the pilot controlled by the vehicles/turrets movement. It requires a special animation that has the frames 0-8, hence the name.
You can learn how to set up such an animation in this thread.
A 9pose is not only for vehicles but also looks cool on turrets. For example you can have the unit lean to the side when the turret rotates or grab the trigger all the time, even when its fixed on the cannon and rotates up and down.
Turret9poses are set up like this: It is possible to hide the pilot even though a position is defined with this line: Pilot deaths
It seems to be unnecassery to have a command that hides the pilot when there is a pilotposition and animation to make him/her/it visible in the first place. The reason for this is that pilots will automatically die and fall down when the vehicle/turret he controls is destroyed. Pandemic used the above command to prevent this in the flyer odfs because in SWBF2 they are only present in space and its pretty stupid that pilots fall down even though there isn't supposed to be any gravity in space.

There is however one line that controls how the pilot acts when the vehicle/turret is destroyed: Sadly there are only two types:

• fall -default, the pilot falls down in the usual stiff dead pose
• fly -the pilot falls down flailing until he hits and object, then switches to stiff dead pose.
  The later type makes the falling-down issue tolerable. I prefer a visible, falling down flailing pilot over a never visible one.

Camera

The camera will always point straight forward and the reticule will always be in the middle of the screen.
If you set a turretnode, the camera will automatically revolve around it. If you didn't define a turretnode because you need the turretbase rotated somehow you can still define the point around which the camera revolves with this line: You can define the cameras offset from the turretnode/mountpos with this line: there is another line: which does about the same, not completely but the effect is really similar.

To set up a cockpit view for the turret/vehicle, use this line: if you dont know how to set up a firstperson, follow this tutorial (pay attention to the note on the bottom)

The firstperson will be in the position of the turretnode/mountpos(?) or dummyroot(for vehiclepilots). You can offset it with this line: With this line you control the cockpits inertia/how much it sways The higher the value, the more it sways.

These two lines control how big the field of view is for first- and thirdperson is:
Examples
Gunship Wingturret, uses parent aimer instead of turretnode, 2 childaimers E-Web turret, with 9pose and firstperson *phew*That's really the biggest text i've ever written here.
Did I wrote anything wrong? Do you have a question about another command or a general one? Please post it.

Very nice comprehensive document on how turrets work. This should be in the everythingyouneedthread.

Very nice
just checking but does the pilot type vehicleself work on any enterable thing ie ships,turrets, and vehicles?

skelltor wrote:just checking but does the pilot type vehicleself work on any enterable thing ie ships,turrets, and vehicles?

Yes. Pilottype = "self" should work on any flyer or turret. Except Hovers do not work, I have found they cause a CTD. I do not know about walkers.
So to put it simply.

• Flyers (Xwing, etc) Pilottype = "self" Yes
• Turrets (Turbolaser, etc) Pilottype = "self" Yes
• Hovers (AAT, etc) Pilottype = "self" No
• Walkers (AT-ST, etc) Pilottype = "self" Unknown

it will work as long as the "self" tpye works. i doubt that it works for vehiclepilots of vehicles though. do the selfcontrolled flyers fly like they are controlled by normal ai-units?

DarthD.U.C.K. wrote:do the selfcontrolled flyers fly like they are controlled by normal ai-units?

Yeah, pretty much.

ah my friend, you finaly did it, great work on this, it is SO useful, i can´t describe
you taught me this when we work on the laat and i learned much, thx for this

Great work D.U.C.K. And thanks.