Jump to content

modern warfare reaches 0 A.D.


Ilves
 Share

Recommended Posts

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.)

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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)

Link to comment
Share on other sites

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);

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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)

Link to comment
Share on other sites

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 :P

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

Recent progress:

r4_t62.jpg

r4_t62m.jpg

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)

  • Like 1
Link to comment
Share on other sites

  • 1 month later...

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.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

×
×
  • Create New...