Author Topic: Rotating Turrets ect.  (Read 6246 times)

myles

  • Technician
  • ****
  • Posts: 113
    • View Profile
    • Myles Lambert's Portfolio
Rotating Turrets ect.
« on: 6 December 2008, 14:23:14 »
Hey!
I was wondering how possible it would be for Glest to have rotating turrets, so for the defence towers or tanks in Glest a turret on the top could be a seperate G3D file that would rotate to look at what ever it was shooting at.

Idanwin

  • Guest
Re: Rotating Turrets ect.
« Reply #1 on: 6 December 2008, 18:19:41 »
This one has already been mentioned many times (by me...).
A must!!!

Together with shoot while moving.

titi

  • MegaGlest Team
  • Airship
  • ********
  • Posts: 4,240
    • View Profile
    • http://www.titusgames.de
Re: Rotating Turrets ect.
« Reply #2 on: 7 December 2008, 01:28:39 »
Are rotating turrets not possible yet in glest 3.1.2. There is a trick with energy power which makes a turret turn but not move.
Simply create a moving unit which never has enough enrgie to move. This unit is your rotating turret. I never really tried it yet , but it was posted several times.
Try Megaglest! Improved Engine / New factions / New tilesets / New maps / New scenarios

hailstone

  • Local Moderator
  • Battle Machine
  • ********
  • Posts: 1,568
    • View Profile
Re: Rotating Turrets ect.
« Reply #3 on: 7 December 2008, 05:09:59 »
Maybe it could be incorporated into skills. ie turn_left_skill and turn_right_skill.
Glest Advanced Engine - Admin/Programmer
https://sourceforge.net/projects/glestae/

mictes

  • Guest
Re: Rotating Turrets ect.
« Reply #4 on: 7 December 2008, 10:06:07 »
Titi: Yes, but the Thread points to another thing.
For Example: A Tank-turret.

daniel.santos

  • Guest
Re: Rotating Turrets ect.
« Reply #5 on: 10 December 2008, 02:57:26 »
I agree, maybe somebody can post a feature request bug for it? :)  First, we'll need a new command type: "attack_moving".  Note that the "Hold Position" commands map to a type of "attack_stopped" and that the type "attack" means travel into range and then begin (while not moving) attacking.  Thus, we get into a lot of other complications, like why do you want to move when you are already close enough to attack.  Well, the reasons are obvious, but have a lot of other implications.  You may just want to be able to get from point A to point B and also shoot stuff while you're at it.  But you may want to be moving to attempt to avoid getting hit.  This opens up a WHOLE new can of worms, one that's still in my journal, but not yet in the bug database, and that's chance to hit and leading shots.

myles, wasn't it you that posted the request earlier this year for soldiers to be able to lay down or crawl on their bellies and have a lower chance to be hit?  Well, I think this would be the time frame to include that.  A moving target should be more difficult to hit for two main reasons: 1.) accuracy in leading your shot and 2.) predictability/changes in movement.  Defending units could also have a natural chance to "dodge" attacks and attacks (currently 0%) and attacking units a chance to hit their targets (currently 100%).  This would add a lot of complications to the game dynamics, but they could be comfortably ignored by mods that do not wish to use them, and dodge chance remains 0% while chance to hit remains 100%.

So back to rotating turrets, a lot of the new proposed animation enhancements (some are partially coded in 0.3) allow for gluing together different models and frames of animations, so a similar principle can be utilized to support rotating turrets and other movement + attacking animations.  Here's a list of what I think will be involved briefly:
  • New command type: attack_moving.
  • Ability to restrict rotation speed -- this is currently calculated on a "what looks good" basis.
  • Ability to restrict attack direction based upon current rotation of unit.  Currently, if you want to attack a unit behind you, the attack begins immediately, even though the attacking unit is still rotating and hasn't faced it's target yet.  Implementing this restriction will mean that you can only attack targets x degrees off center of your rotation (possibly zero).  So if I'm shooting a fireball, I may have some kinetic control over it's path so I can shoot it 15 or 20 degrees off from the direction I'm facing (as an example), but if I'm a cannon, I must face exactly where I want my shot to hit.
  • Addition of secondary rotation -- this will require another model glued together with some mechanism discussed above (still have to figure that one out) and secondary rotation will be applied to that.
  • Ability to also restrict secondary rotation speed and attack direction.
  • Secondary rotation to optionally include pitch rotation restrictions, so moving a cannon to aim at an air target may cause a delay in firing.
  • Possible need for an "aim" command.  This gets tricky because at currently, units only execute one command at a time. The exception for this is "set meeting point" which can be either queued or take immediate effect, bypassing whatever commands are being executed (and it doesn't behave like a true command anyway).  However, it's likely that you may have tanks that are either stopped or moving and anticipate enemy units arriving from a particular direction (other than the direction you are facing) and want to tell them to face that way in anticipation.  Thus, the "aim" command can't replace the existing command, but it would be more of meta-data on how to execute the current command.  That will require some new infrastructure in the game code to implement and can be skipped in initial phases, I just don't see how it wouldn't eventually become necessary.
The rest of these aren't necessary for turret support, but seems (to me) to be important and related.
  • Chance to dodge (currently 0%) - I already have a chance to fall down in an earthquake setting in the "fall_down" skill type, which isn't the cleanest way to do this.  So perhaps we need some new base stats to manage these things more cleanly.
  • Chance to hit (currently 100%, meaning that it will always hit location it intends to, although the target may no longer be there when the shot arrives).  If an attack fails the check for chance to hit, they will fire off-target, but the attack should be allowed to possibly hit somebody else instead (even a friendly).
  • Ability to lead shots, so a unit will aim for where it looks like their target will be when their shot arrives.
  • Ability to have skills or command alter chance to dodge and hit.
  • AI enhancements to accommodate all of this.

That's obviously a lot of stuff and it wont be done soon, but I believe it can be done.

modman

  • Guest
Re: Rotating Turrets ect.
« Reply #6 on: 14 December 2008, 02:53:56 »
Would the rotated climb property do this?  Otherwise, what is it?

daniel.santos

  • Guest
Re: Rotating Turrets ect.
« Reply #7 on: 14 December 2008, 03:13:09 »
No, "rotated_climb" is something that was commented out in Glest long ago.  I think I figured out what it was supposed to be at one point, but I forgot (should probably be removed?).

gameboy

  • Guest
Re: Rotating Turrets ect.
« Reply #8 on: 14 December 2008, 09:48:20 »
Quote from: "daniel.santos"
Chance to dodge (currently 0%) - I already have a chance to fall down in an earthquake setting in the "fall_down" skill type, which isn't the cleanest way to do this. So perhaps we need some new base stats to manage these things more cleanly.
can you, at the moment, set a unit to fall with a particular attack, say an Ent it has an attack in which he beats the ground so hard that it shakes (kin'a like a mini earthquake), all unmounted units in the area fall down, can you do that?

daniel.santos

  • Guest
Re: Rotating Turrets ect.
« Reply #9 on: 15 December 2008, 08:53:03 »
hmm, I think that should already work using the earthquake feature.  Unfortunately, it may also hurt the ent.  Copy and paste the earthquake attack from the priestess in FPM and then set the duration to shorter, like one second or so.  If it isn't yet possible to specify that the earthquake shouldn't harm the attacker or the attacker's team then it should be possible.  Also, the chance to fall is still based upon the unit's fall_down skill and the intensity of the earthquake at the location the unit resides in.  If the unit occupies more than one cell, than the greatest intensity of any cell occupied is used for the check and it's done once per second.

hailstone

  • Local Moderator
  • Battle Machine
  • ********
  • Posts: 1,568
    • View Profile
Re: Rotating Turrets ect.
« Reply #10 on: 18 December 2008, 03:20:46 »
Quote from: "daniel.santos"
No, "rotated_climb" is something that was commented out in Glest long ago.  I think I figured out what it was supposed to be at one point, but I forgot (should probably be removed?).
If it's dead code it should be removed imo unless it can be revived and put to use.
Glest Advanced Engine - Admin/Programmer
https://sourceforge.net/projects/glestae/

modman

  • Guest
Re: Rotating Turrets ect.
« Reply #11 on: 21 December 2008, 04:37:12 »
So the earthquake is sort of like a splash that is from an attack with zero range?

John.d.h

  • Moderator
  • Airship
  • ********
  • Posts: 3,757
  • I have to go now. My planet needs me.
    • View Profile
Re: Rotating Turrets ect.
« Reply #12 on: 21 December 2008, 08:04:31 »
There should also be a way to limit a turret's rotation to within a certain angle.  I was thinking this would be good for a mounted archer, whose "turret" would be his upper body.  He could turn to shoot enemies in front of him or to the sides while staying in motion, but he couldn't turn all the way around to shoot an enemy directly behind him.

modman

  • Guest
Re: Rotating Turrets ect.
« Reply #13 on: 22 December 2008, 01:40:39 »
To tell the engine what to rotate on what, the unit needs to be separated into two parts.  The first is on the ground, and the second rests at a defined height above the first.  In this way you can set the second object to be however high above the first as you wish.  Both could be animated.

Omega

  • MegaGlest Team
  • Dragon
  • ********
  • Posts: 6,167
  • Professional bug writer
    • View Profile
    • Personal site
Re: Rotating Turrets ect.
« Reply #14 on: 28 December 2008, 03:38:55 »
Like have a seperate mesh that is named something like rotate or something. The engine could recognize that seperate mesh and rotate it. Don't know if it's possible, but it's an idea...
Edit the MegaGlest wiki: http://docs.megaglest.org/

My personal projects: http://github.com/KatrinaHoffert

daniel.santos

  • Guest
Re: Rotating Turrets ect.
« Reply #15 on: 29 December 2008, 09:49:07 »
Omega, your method would require a new model format, but I think that's needed anyway.  One of the things about archers and such rotating a "turret" is that we don't want a stiff upper body that rotates at the waist.  Instead, we want the body to stretch around as they rotate and have their bow, arrow and hands mesh be fully rotated to face the target position, although the rest of this model will probably not rotate all of the way.  With a cannon, machine gun, etc. this is easier, but with a body, it gets tricky.  This will require some bone weighted skeletal animation.

modman, The earthquake can be on any attack of any range.  Think of it as a special type of splash damage that has a visual effect of warping the landscape and the additional effect of knocking down units.  It can be done from range or at point blank.  However, it is currently slightly hacked in the engine to cancel its self after the 1st use (this is to keep the FPM priestess from walking into her own earthquake, DOH!)

Omega

  • MegaGlest Team
  • Dragon
  • ********
  • Posts: 6,167
  • Professional bug writer
    • View Profile
    • Personal site
No, it won't be easy...
« Reply #16 on: 30 December 2008, 02:12:39 »
Quote from: "daniel.santos"
(this is to keep the FPM priestess from walking into her own earthquake, DOH!)
:O Can't imagine seeing that. How many times have I killed my own units in games like first person shooters? (I told them to get outta my way when I was firing, but did they listen? Nooooo)
Quote from: "daniel.santos"
One of the things about archers and such rotating a "turret" is that we don't want a stiff upper body that rotates at the waist.
You're right. The archer doesnt look quite so bad when he turns to face a unit, but a cannon shouldnt have to. I wonder if it would be possible to have a mesh with an animation that could be 'called' by the program to play, such as having an animation for just the rotating part that would be rotated by the game and then have the animation played.
Quote from: "daniel.santos"
Omega, your method would require a new model format
If a new format would be created, gae would still have to be compatible with the old one, to allow compatibility. But what would it be? g3d v.5? Or a new format such as g3da (Glest 3D Advanced)? [The name is the least thing to worry about. It could be even .g4d, no one will kill you because of this - @kukac@] But a new format would also require a new g3d viewer... So many upgrades would be needed, so I dont think that rotation would be neccessary. Why not worry with more important things like better multiplayer (that wont boot people out), or an in game map viewer...?
Edit the MegaGlest wiki: http://docs.megaglest.org/

My personal projects: http://github.com/KatrinaHoffert

daniel.santos

  • Guest
Re: Rotating Turrets ect.
« Reply #17 on: 4 January 2009, 18:13:28 »
Quote from: "omega"
If a new format would be created, gae would still have to be compatible with the old one, to allow compatibility. But what would it be? g3d v.5? Or a new format such as g3da (Glest 3D Advanced)? [The name is the least thing to worry about. It could be even .g4d, no one will kill you because of this - @kukac@] But a new format would also require a new g3d viewer... So many upgrades would be needed, so I dont think that rotation would be neccessary. Why not worry with more important things like better multiplayer (that wont boot people out), or an in game map viewer...?

Actually, multiplayer is my priority right now.  However, that shouldn't preclude future planning.

I do believe that a new model format is both necessary and warranted.  You should always support older formats.  Currently, both Glest and GAE support all 3 original formats (you can still load very very old models) and it would be crazy to remove that.  What do you mean by "So many upgrades would be needed"?  The g3d viewer uses the shared libglest, which is where model management is done, so probably no changes needed at all, or at least VERY few there.

divineauthority

  • Guest
Re: Rotating Turrets ect.
« Reply #18 on: 5 January 2009, 13:31:53 »
I think the problem may be that Glest works off the vertex data (correct me if I'm wrong) whereas it would be useful to work off the bone data instead. However, as previously mentioned, this would require a complete overhaul of the modelling system. If it worked off bone data then you could create an animation in which the model rotates (preferably using a single bone), the angle would have to be calculated in game by the engine and then the bone rotated by that amount.

Because Glest uses vertex data, I think it might be impossible.

daniel.santos

  • Guest
Re: Rotating Turrets ect.
« Reply #19 on: 12 January 2009, 20:27:55 »
Indeed you are correct!  Perhaps I wouldn't say it would require a "complete overhaul", but a pretty "major" overhaul for sure.  I would want to continue to support older animation formats, but current Glest model/animation files contain one or more frames of animation (vertex data) there no bone or weighted bone animation.  That is something I would like to add, but there are items here and there that come ahead of it, so we'll see how that works out. :)  To see a discussion of all proposed ideas for animation enhancement, look for the GAE 0.3 planning thread.  Sadly, my original posting appears to have gotten truncated and didn't make any sense before, but I restored it from Google cache (thank God for that!!)  (google cache link)