-= Gametoast.com =-

I try to turn Slave 1 in to the turret, and everything works fine, except strange bug: hp_fire points appear in correct positions, but when I try to rotate them, they fly far abowe, or deep down. It seems, they are use aimer_y, or dummyroot nulls (not sure), as rotation center. I try different combinations, but probably I missing something. Here the pic:
http://www.freeimagehosting.net/ps7sh And the .odf: Please help.

Lets break down the image

• the barrel geometry pivots correctly
• the firepoints are child of the barrel geometry
• the firepoints pitch as the barrels pitch
• the ordnance comes from the wrong location

Did you freeze the geometry transforms before or after setting up the hierarchy?
Have you looked at this turret msh in Unwrap3D to see if the firepoints stayed where they are supposed to after exporting?

You could try reducing the number of firepoints in the ODF to two and see if you still have this problem. About three years ago I was messing around with a turret that was supposed to fire a missile from four different locations and I encountered a similar problem until I reduced the firepoints to two. It's almost as if there was a limit on the number of firepoints a turret could have before things go wonky. I didn't have enough interest to investigate this further though. The hailfire droid is a vehicle and can fire eight projectiles, so maybe try turning that into a turret for testing firepoint limits.

Well, here the pic from Unwrap3D, and I think, everithing ok: I am freeze each geometry, after put it under null, but before adding new null. As I read from tutorial, I must not freeze nulls, so, I did not do it. And my hp_fires stay as unfreezed nulls. I try to add new hp_fires, as geometry cone under hp_fires nulls, and freeze them, but result is the same.
I am also, try reduce count of barrels/firepoints to 2, and even to 1, but it's change nothing.
May be you have some other ideas?

Everything in your image looks fine. Try moving this:
TurretNodeName = "aimer_y"
under this:
BUILDINGSECTION = "TURRET1"
property subsection in the ODF. Is your ODF an existing template from the modtools? If so, which one?

My ODF mostly based on bespin AAA turret, and some parts from turret tutorial.
I try to put
TurretNodeName = "aimer_y"
under
BUILDINGSECTION = "TURRET1"
but have no result. Still, when I just disable it:
//TurretNodeName = "aimer_y"
my ordance become appear in correct places, even, after pitch rotate, but I loose ability to yaw rotate of the Slave corps. So, if the problem is realy in ODF, it is cud be nice, to know, how to set up it correct...

So you are saying the way you would like it to works is:

Yaw (aimer_y) turns the ship body
Pitch (aimer_x) just tilts the gun barrels up and down

If so then the body of the ship should be under aimer_y and aimer_x should be a child of the ship

So
Dummyroot
aimer_y
Slave1_body (not sure if that is what you call slave1_turret_main)
slave1_tur
aimer_x
tur_gun_holder_poly

Yes, it should be work, just like in ep2, Kamino scene, but here is a little misunderstending:
slave1_turret_main it is not the body, it is just small cube primitive, and I use, it as static turret "main part". So, by using your instructions, it become no needed, and I just delete it. Here the list of interpritations:
Dummyroot
aimer_y
slave1_tur - Slave1 body
aimer_x
tur_gun_holder_poly - Slave1 barrel holder

It is sad to say, but after deleting slave1_turret_main primitive, I do not see any difference, except some change of the view position.

Actually I said I wasn't sure if that was the real ship body
The fact it was just a cube as the static turret main part is good.

Hate to do this to you but put it back in, the the hierachy would be this:
Dummyroot
slave1_turret_main
aimer_y
slave1_tur
aimer_x
tur_gun_holder_poly

Will add more just checking some things
Edit:back
Had a look at com_weap_gun_turret.msh and the tur_bldg_laser.odf which are the turrets used on Kamino.
There are two meshes (not including hp_active and hp_fire which are also meshes but not important at this time) main_mesh and turretgun_mesh.
Thing being is the meshes are not used as the aimers nulls are. The two meshes are enveloped to these nulls and that is how they are controlled.
So it's hierarchy is

com_bldg_gunturret (null being the same as dummyroot)
-- main_mesh (the main mesh of the turret) and on same level turretgun_mesh
---- basenode (null)
------ main_cylinder (null)
-------- turret_main (null)
---------- hp_fire (mesh)

The main_mesh is enveloped to basenode and main_cylinder nulls and the gunturret_mesh is enveloped to the turret_main null

So you can see by those nulls how they relate to the odf they just use the null names for the aimers yaw (aimer_y) = main_cylinder and pitch (aimer_x) = turret_main. Turret1 is just a nice name to call the building and turret section

Hope this helps you figure out your turret. Even though the one I show here was done via envelope proper parent child hierarchy of actual mesh bits should work too.

Oh and if you do freecam in the above mentioned turret the lasers do not come out the end of the barrel as you move it up and down it changes which may or may not have something to do with the eyepoint offset trackoffset etc

By using your ODF sample, and hierarchi instructions, I start new scene, and made quick, simple turret, for sample. Still, the problem isn't gone: Even worster: my old doppelgunger bug is back, and now, I can't discard it. Well, actualy some nulls, from your instruction, I am not use (basenode, and main_mesh), because they was no needed, and has no any effect, but, overall, I almost strongly follow it...

this bug normally happens when the roationlimits are set improperly. could you post the current odf?

Sure, here the odf of my sample turret (it is almost similar to stock com_bldg_gunturret) : And here the from my turret Slave: