Jump to content

Stan`

0 A.D. Project Leader
  • Posts

    17.022
  • Joined

  • Last visited

  • Days Won

    525

Posts posted by Stan`

  1. This has been discussed in a lot of threads. I think the aim is to keep things in english so everyone can participate and ideas are not spread and lost. Therefore the solution was try to speak english if you can ´t write te traduction next to it and hope someone on the forums or in the team speak both your languages.

  2. Wait...... Whaaat. Rada, If you leave who will I be, the phantom of those forums ? The guy that does what he is told ? Niektb doesn't lead me. And Rada, what about your game, our projects stuff you wanted to see ? I can't hold you back if you wanna disapear, but I will be very sad.

  3. Mind to submit a patch to trac ? (I believe we need to share everything we fix even if it's not reviewed) This is the idea of OpenSource.

    There is a ticket for it http://trac.wildfiregames.com/ticket/2679

    and this one seems related and useful for 0ad extended http://trac.wildfiregames.com/ticket/1550

    For the boats I assumed it didn't work.

    To fix the walking units, you'll have either to replace the mesh with one that doesn't have a walk /run anim, or disable those anims, and replace them by the steady one.

  4. Yeah, Problem is only there with animated meshes

    Sanderd Discussion

    Me : Hi, I'm sorry to annoy you again, but I looked at the code and don't see how to make animated mesh compliant with your system.

    Why do I want them :

    - Animated meshes on boats without losing animation, would be really nice especially for catapults on quinqueremes and archers.
    - Animated units. Ie : Hannibal could be scripted to be a unit garrisonned in an elephant and therefore giving him the ability to attack.
    - Animated meshes on gates.
    - Better understanding will allow having animals garrisonned in the corral, being visible, and also producing a little food income.


    What I don't understand.

    - How animated meshes are handled : Is there a function UpdateActor ?
    - Where should your got be modified.


    I'll be really grateful, if you could give me a way step by step on how to fix it (Because then I'd learn something) or just implement it.

    Sorry for the Hassle.

    Regards Stan.
    Him : Not sure what you mean. Turrets are meant to be separated from the parent in most ways. So the animations aren't set from the parent, but rather from the state of the turret itself. This allows the parent to be in the moving state (with the moving animation), but the turret to be attacking or idle.

    Turrets are entities like all other entities, and their animations are handled in different files. Like the units on walls are handled by their regular UnitAI. The patch in trac somewhere, with fixed turrets on those chariots, those animations are handled by a new AI component.

    me : So I should rather look in the unit ai. Js file instead of the garrison. Js ?

    him : UnitAI decides the animations of the units indeed.
    me : Should your garrison holder function call a updatanimation function ?

    him : Animations are managed by UnitAI, and it would be easiest to keep it that way. Else you get conflicting animation requests. See the siege tower that loses its garrison flag when it starts moving. That's because the garrison flag is an animation started by the GarrisonHolder, and the moving animation is started by UnitAI, and they override each other.

    I'm not sure why you want other animations for garrisoned units.
    me : Oh maybe that wasn't clear.

    If you don ´t have animations if you garrison units in the gates the gate stay closed and open close door only remove the obstruction making units go through the gate even if is it´s closed. If you do that on boats they stop rowing. If you do that on chariots ( not really useful) you lose the wheel animation. What I want is being able to garrison in any building without losing those moving anims.
    him : Ah, that's the TODO in GarrisonHolder (L563). You should be able to change the variant without changing the animation. Though that TODO will require a lot of work. Not only in the code, but also in the actors. As you need to have some way to to differentiate between animations that set the variant and animations that don't.

    One possibility is to have different combos. Like in the UnitAI SetGathererAnimationOverride. That replaces the default walk and run animations with animations with the right props. So you could have a walk_garrisoned, and a run_garrisoned. And when garrisoned, that combo of animation and props would be used (i.e. the wheels would turn, and the flag would be up).

    For the gate, it's a bit more difficult though, as it's not a walking animation. You should probably make 4 animation for all combos (like gate_opening_garrisoned). And in the Gate.js code itself differentiate between the garrisoned gate and the other case.

    And you'll probably need to special-case the gate inside the GarrisonHolder code too.
    me : Oh so it´s planned ? Okay so thatl what i thought we need to add different animations names. But why is it so complex. Can ´t we just tell the garisson functions to update the actors normally by making it separate ?
    him : Making the garrison thing to change the variant is rather easy. The problem is that animations override the variants. This is needed in most cases (you don't want a unit to attack while in the gather_meat variant, or it would just beat you with a piece of meat).

    So the TODO, as it's written there, is very hard to achieve. Manually fixing those things is a lot easier. Though the code is a bit less generic. I still think this will cause less problems in the future.

    me : I'm afraid I don't have enough knowledge, then. Do you plan to do it ?

    him No, I can't really find the time to do stuff now.
    me : Do you have a clear idea of what should be changed maybe I could be your hands ?
    him : For the gates, every gate actor should get 4 animation names for the combos between opening/closing and garrisoned/not.

    Then the Gate.js code needs to see if the gate is garrisoned or not when opening or closing, and pick the right animation. And the GarrisonHolder needs to check whether it's a gate, and also use the right animation when garrisoning.

    Probably some details to be figured out there.

×
×
  • Create New...