Turrets in Megaglest (Sir Modman Style)

[modman]

Clearly I am not the first to propose turrets in Glest.  In fact, I don't really care which engine implements them; I just want them!  Now, the way I think they can be implemented is simpler, in my opinion.

In my proposed system, each unit could have a turret on it.  It would make the most sense for buildings, though, of course.  In my system, the turret is independent of the building.  But first, let me define my terms:

Building The bottom unit which does not turn.  We can already make these!
Turret The unit placed on top of the building, which turns.

So each building can have a turret added relatively easily.  I think that this feature should be implemented because it has been requested multiple times.  I think my system is superior because the turret is totally independent of the building files.  It is therefore very simple to add/remove the turret, and is simple as well.  The file would look as follows.  Below (file names were chosen capriciously), building.xml is the building *.xml file, turret.xml is the turret *.xml file, building.g3d is the building model, and turret.g3d is the turret model.  Each also have their respective textures.

Code: [Select]

\building
   \images
        building_icon.bmp
   \models
        building.g3d
        turret.g3d
        building_texture.tga
        turret_texture.tga
    building.xml
    turret.xml
Building.xml is a normal *.xml file for a building.  But it should have a special line in it to tell the engine how to find the turret.  It could be as simple as follows:

Code: [Select]

<turrets="true" file="turret.xml">
Then the engine would know to look in turret.xml, which would have additional info, like the following:

Code: [Select]

<model="true" file="models/turret.g3d"/>
<height="##.##"/>
<rotation_speed>4</rotation_speed>
etc.
If the turret attacks, it is the building.xml which will define it, but the angle which the attack comes from should match up with the angle the turret is turned to.  The height is the cool thing in my system; you will place the turret model on top of the building model, and change the height value so it looks right.

[wyvern]

If this does come out and turrets are implemented I will ditch the mod I'm making as a private venture and I could just make it a megaglest mod.

[Zoythrus]

maybe we should combine your idea with mine:

https://forum.megaglest.org/index.php?topic=5224.0

that would make it easier

[softcoder]

So do we see the turret as a 'sub-unit' of the building or part of the building? Should it have different damage etc and enemies attack the building seperate from the turret? So would this be one unit or two and do we laready have support for rotation speed or would that indicate we simply animate the turret at the rotate speed?

[Omega]

The way I see it, the model is split into two parts. One part doesn't move, while the other is capable of rotating to face the target.

[Zoythrus]

ok, lets go with that...
 

[wyvern]

It sounds good and is actually realistic, for example a tankk can technically function without its turret(though not fight)

[Omega]

Turrets are best off limited to non-moving units for now. Something moving like a tank is more complicated, and as you pointed out, not totally priority. However, it would technically work the same, where the tank would rotate the turret when attacking, provided the foe is in range, but when moving, it would still rotate the entire body.

[Zoythrus]

what about having multiple turrets? like (if you read my thread), a huge battle base that is able to attack 5 targets at once. i think that things like turrets should not be restricted to just one

[wyvern]

Yeah it would also be nice if there were limited traverse turrets combined with the multiple turrets it would be a cool effect for the ww1 mod tanks

[modman]

So do we see the turret as a 'sub-unit' of the building or part of the building? Should it have different damage etc and enemies attack the building seperate from the turret? So would this be one unit or two and do we already have support for rotation speed or would that indicate we simply animate the turret at the rotate speed?

"Sub-unit" and "unit" would be the same thing.  My initial plan would be that the turret only has its own separate *.xml for simplicity; the turret would be killed along with the unit, and selecting either would select both.  It would be meaningless to separate them; otherwise we might as well make them separate units!

I think it would be best if the unit did not rotate in the animation, but the engine rotated the model.  Glest can already do this.  Otherwise, I think we would have to make two animations (one for clockwise rotation and one for anticlockwise), and then "cut" the animation directly to the appropriate place in the other animation.  Preferably, the turret would "follow" the unit as it runs around (like the Air Ballista already does).

what about having multiple turrets? like (if you read my thread), a huge battle base that is able to attack 5 targets at once. i think that things like turrets should not be restricted to just one

I think that is a separate issue, but I'll address it a bit.  I think that it would be useless IMO because all of the turrets would be pointing in the same direction in practice.  The second part -multiple attacks for one unit- is an idea I like, but is again, a separate issue.

[Zoythrus]

ultimately, i want this:



can we do this?

[Omega]

I say start with one basic turret. You can always expand from there. Let's not overcomplicate it at the moment.

My idea of how multiple turrets would work: Each one would be a different model and the XML would have to state where to place the model, relative to the position of the main part of the unit. Each turret, however, should be able to target a separate foe, otherwise they would be useless (barring eye candy).

[Zoythrus]

here's how i see the XML for the master unit:

Code: [Select]

<turret="yes">
     <turret name="turret1.xml" xyzoffset=0 0 0/>
     <turret name="turret2.xml" xyzoffset=0 0 0/>
</turret>
the XML for the turret itself would have things like rotation speed, damage done, model, and whether the turret can be manually selected and controlled (if not, it would attack on it's own).

[Mark]

The idea of having a moving turret could be cool.  It would certainly not be the important thing, but you could have horse archers, with the horse part moving and the man part shooting simultaneously, though that would take some serious coding.

here's how i see the XML for the master unit:

Code: [Select]

<turret="yes">
     <turret name="turret1.xml" xyzoffset=0 0 0/>
     <turret name="turret2.xml" xyzoffset=0 0 0/>
</turret>
the XML for the turret itself would have things like rotation speed, damage done, model, and whether the turret can be manually selected and controlled (if not, it would attack on it's own).

Good, but why would you want to select the base for the turret's shooter?  Unless there are multiple turrets per base, that seems unnecessary. 

[Zoythrus]

maybe if you wanted to override the auto-targeting of the turret and have it attack a specific unit.  and i plan on having multiple turrets on the same base! it would make things way cooler!

[gameboy]

I think prop points would work better than the position/height method, becoz then its easier and more precise. The prop points will be defined by bones or something and each prop point would be given a specific name, this name is then specified in the xml.

[John.d.h]

What's not precise about height and position?  As long as it'll take decimals, it could be just as precise, since Glest measurements correspond to those in Blender.  It would also likely require less programming since the engine already knows how to place stuff based on offsets (as it already does with projectiles) and less work for the modder because he/she wouldn't have to make extra modifications to the model.  Plus, the g3d format doesn't know how to store additional information like that, so that would be yet another thing to be programmed.

[gameboy]

well it could cause problems, especially for more intricate models. But yeah your right, it would require unnecessary programming, especially if u'll don't want to use props in other areas. But it'd be rather easy and would require no extra effort to place those prop points.

[Zoythrus]

i was thinking, is it possible to rotate an object like a turret diagonally? i.e. what if we need guns on a mech's shoulders? those arent level surfaces.

[gameboy]

for that, i think prop points would be ideal. For they not only allow horizontal movement but vertical too.

[Zoythrus]

for that, i think prop points would be ideal. For they not only allow horizontal movement but vertical too.

we seem to have reached a problem. prop points would be nice, but its alot of extra work...

[ZaggyDad]

for that, i think prop points would be ideal. For they not only allow horizontal movement but vertical too.

Yes, but if we did have "prop points" in the models, then you'd have to modify the model (which may be extremely hard if it's any good-sized model...) every time you wanted to add another turret. I don't know about you, but I think I prefer modifying XML over exporting a model every time I wanted to change a turret. If you really think it's that hard to find coordinates, then we should implement some kind of function in the G3D viewer to view the model from any of the sides in orthographic mode and click on a location to find the coordinates you want to place the turret on. And considering that that feature would also be useful for particle system origins too, it's probably a better to implement than prop points.

Edit: Actually, what might be even better is if we could just have some kind of sub-unit set at a certain coordinate on the parent unit. Then we could have turrets that do more than just attack, but could also do things like repair, build, harvest, or even possibly act as some kind of engine which, if destroyed, would cause its parent unit to be unable to move.

Btw, I think it would be better if it were set up so that the turret would be destroyed if its health got to 0, but would come back if the parent were repaired (is this what people were saying should happen?).

~Zaggy1024

[Zoythrus]

i think that in one of the XMLs, that the turrets should be tagged with something that could make them targetable. i think this would distinguish between two types of sub-units: turrets and hard points.

turrets are sub-units that cannot be individually targeted - they die when the parent dies.

hard points are sub-units that can be individually targeted - they can be shot at and destroyed.

but i have some concerns about hard points: can they be set to hurt the parent unit when destroyed? (has anyone here played Star Wars: Empire at War? think of the Battle Cruisers) can some hard points be crucial or optional to the master unit? (like, if you destroy an engine, it would instantly kill the master unit; or you could kill the guns, non-lethal, but it makes getting to the engine easier). could the hard points be repaired if destroyed?

[ZaggyDad]

i think that in one of the XMLs, that the turrets should be tagged with something that could make them targetable. i think this would distinguish between two types of sub-units: turrets and hard points.

turrets are sub-units that cannot be individually targeted - they die when the parent dies.

hard points are sub-units that can be individually targeted - they can be shot at and destroyed.

but i have some concerns about hard points: can they be set to hurt the parent unit when destroyed? (has anyone here played Star Wars: Empire at War? think of the Battle Cruisers) can some hard points be crucial or optional to the master unit? (like, if you destroy an engine, it would instantly kill the master unit; or you could kill the guns, non-lethal, but it makes getting to the engine easier). could the hard points be repaired if destroyed?

I don't think that any sub-unit should be unable to be targeted/destroyed, or at least that if we provide an option for that we shouldn't call them "turrets" or "hard points", but rather have the sub-unit tag be something like '<sub-unit path="turret.xml" x="0" y="0" z="0" targetable="true" />'. But what exactly is the use of having a sub-unit that can't be destroyed?

Another thing that could be really useful is if it could limit the axis that the turret rotates on, so that you could have the base rotate around the z axis (side to side) while the base's sub-unit, the machine gun itself, could rotate only up and down, so it would more like a real mounted machine gun. Just a thought, though.

~Zaggy1024