modern warfare reaches 0 A.D.

[leper]

Limiting the rotation shouldn't be a problem (The 360° animation is just to test how it works out). Rotating to a specific point would be done by just playing the animation to the point where the rotation angle fits to the target's location.

The elevation angle can be done with another animation (relative to the first). Recoil should work the same.

(The last two points will probably need some changes to the current animation system (see the ticket linked above), but the first point (turret rotation) should only require some small changes.)

[zoot]

Limiting the rotation shouldn't be a problem (The 360° animation is just to test how it works out). Rotating to a specific point would be done by just playing the animation to the point where the rotation angle fits to the target's location.

The elevation angle can be done with another animation (relative to the first). Recoil should work the same.

(The last two points will probably need some changes to the current animation system (see the ticket linked above), but the first point (turret rotation) should only require some small changes.)

What is the advantage of using the animation system? Why not rotate it directly the same way that e.g. a unit is made to face its target?

[MishFTW]

Wow this game sounds really promising. Great work so far

And Mythos_Ruler, it wouldn't hurt to share some of the tanks fighting the soldiers screenshots on Facebook, etc (if its alright with Ilves)

[leper]

What is the advantage of using the animation system? Why not rotate it directly the same way that e.g. a unit is made to face its target?

The rotation of the unit is coupled to cmpPosition so we would need to add a position component to the turret (as in two entities in one) and add code to UnitMotion and some more files just to keep both entities in lockstep. So that would mean adding more (in my opinion) code to the simulation side for a purely graphical effect.

Using the animation system (which needs some improvements anyways (see gates)) and improving that can also be used for more stuff in the future (catapults on ships, parthian shot, etc.) gives us some more generic (read reusable) code that doesn't look like duct-taped to some components.

One possible problem with the animation system approach could be having to animate props which is currently not possible. (Maybe someone who knows our animation system better than me could give us some input on this)

[wraitii]

From what I understand, this would also be used in the simulation code to calculate things when shooting. It seems to me like this makes more sense as a new (optional) component for each entity.

[zoot]

The rotation of the unit is coupled to cmpPosition so we would need to add a position component to the turret (as in two entities in one) and add code to UnitMotion and some more files just to keep both entities in lockstep. So that would mean adding more (in my opinion) code to the simulation side for a purely graphical effect.

Since each prop is a separate mesh, the engine or renderer must have some concept of its rotation. Would it be that bad/hard to have a function doing something like gudo suggested? Perhaps more like:

this.PropFaceTowardsTarget(prop_id, this.order.data.target);

[leper]

wraitii: The projectile attachpoint maybe needs to be rotated too (or one could just put that at the same place as the rotation axis of the cannon). It will probably get a component but for firing at the target there isn't anything to be done.

zoot: That function is needed anyways. Rotation is done by graphics/Model. I'm not saying that just setting rotation wouldn't work for turrets, but for cavalry archers it'd probably look bad.

[zoot]

zoot: That function is needed anyways. Rotation is done by graphics/Model. I'm not saying that just setting rotation wouldn't work for turrets, but for cavalry archers it'd probably look bad.

Ah, true. But isn't that a separate case from turrets / turning siege weapons? It seems a bit painful to have to create a rotation animation for each axis for every turret you want to add (and in a modern warfare game you'll probably want quite a few turrets) when the engine can do it on the fly.

Seems there are really two problems: rotating the projectile attachpoint and rotating/twisting the actual mesh. The former problem can probably be solved with a shared solution. The latter problem can be solved either by rotating the mesh directly or by cueing an animation somehow, like you suggest.

[leper]

It seems a bit painful to have to create a rotation animation for each axis for every turret you want to add (and in a modern warfare game you'll probably want quite a few turrets) when the engine can do it on the fly.

Then you still need to figure out the boundaries and set those values (in the actor or entity xml). I don't think rotating the turret/gun/... sounds that bad, but how would you do something like recoil?

Yes there are two problems, but I think getting a proof of concept for turret rotation would be a good start. Setting the projectile prop point can be done later, when we know where the gun is.

[zoot]

Then you still need to figure out the boundaries and set those values (in the actor or entity xml). I don't think rotating the turret/gun/... sounds that bad, but how would you do something like recoil?

Recoil seems suited for doing with ordinary animation because it doesn't depend on any simulation parameters. Rotation is dependent on the position of the target, so it needs a bit of extra logic.

Yes there are two problems, but I think getting a proof of concept for turret rotation would be a good start. Setting the projectile prop point can be done later, when we know where the gun is.

Not quite sure how to 'attack' it yet. My concept of entities etc. isn't strong enough that I can tell where it would be natural to add this.

[leper]

Take a look at FaceTowardsTarget in UnitAI.js (though you should only need to get the target's position and pass it to some yet to be written function) (The code from gudo is pretty much all you need to do in UnitAI.js (maybe I'll post my own version of that later, but it doesn't really differ))

Some other files to look at: CCmpPosition.cpp and CCmpUnitMotion.cpp (just to see how the unit is rotated), CCmpVisualActor.cpp (where I'd probably try to add the function from above), and Model, Unit, UnitAnimation and some of the Skeleton* files (the last ones in source/graphics, the CCmp ones in source/simulation2/components)

[Gen.Kenobi]

Hmm... This could be easily solved if the engine supported "parenting" in Blender. I mean, if we'd parent the projectilie point with the turret, it's rotation would be almost "automatic", following the mesh's rotation without the need for adtional codding for different stuff (I guess). At least that's the way it's done in C&C Generals.

Also, recoil could be also calculated by the enigne, if we''d ought to have a realistic physics system

[Zaggy1024]

Hmm... This could be easily solved if the engine supported "parenting" in Blender. I mean, if we'd parent the projectilie point with the turret, it's rotation would be almost "automatic", following the mesh's rotation without the need for adtional codding for different stuff (I guess). At least that's the way it's done in C&C Generals.

Considering the turret rotates around one point, it would probably work to just have the projectiles originate from the center of the turret.

[Mythos_Ruler]

It's a simple thing to put the projectile prop point on the turret mesh, which is a prop. It should work fine. it works for ranged cavalry.

[zoot]

Oh, the projectile attach point is defined in the model. I see.

[historic_bruno]

A rotating turret would be pretty easy (I think) if we had finer control of animations. Though I'm pretty sure we can't combine animations, so it wouldn't be able to move and rotate the turret at the same time, unless we added that capability. Another option is some kind of entity propping system. Currently all props are visual actors, attached to a parent actor, but they all belong to a single entity. With entity propping, we could attach entities to a prop point, and they would follow the parent entity, but still be able to interact separately in the game. Not sure how well that would work or how flexible it would be, but it would get us closer to units propped on ships, walls, etc. That hardest part would be handling how the propped entity interacts with the simulation, can it move around relative to the parent, can it be attacked, what happens when the parent is destroyed, etc.

[Ilves]

Recent progress:

Meanwhile, I still would like to request the code files of my Black Eagle tank, which Mythos Ruler so awesomely implemented. Can it already move like a unit ingame?

(and if possible - also get to know why my attempts resulted in poor skin)

[Gen.Kenobi]

Saw it yesterday!

It's looking great!

[av93]

How it's going? Rogue Republic finally will use Pyrogenesis engine?

[CTLN7]

It is going well, we just had an new year update :

http://www.moddb.com/games/rogue-republic/news/new-year-update10

[Lion.Kanzen]

the game is a mod from 0.AD?

[CTLN7]

Yeah but sadly we lack a programmers support to implement stuff ingame .

[zoot]

Any particular reason you don't go open source like 0 A.D. has? Surely, you would be able to get many programmers if you did...

[quantumstate]

I also agree about the lack of openness possibly putting off programmers. Also it is pretty hard to tell if you will use pyrogenesis (are you planning to?). Also in the summary you mention "C++\C# coder" when pyrogenesis uses a mix of C++ and javascript. I would personally be looking for quite a lot more technical information before contacting you.

[Mythos_Ruler]

It is going well, we just had an new year update :

http://www.moddb.com...w-year-update10

Nice update. Loving the T-90 renders.