wowgetoffyourcellphone Posted December 4, 2016 Report Share Posted December 4, 2016 (edited) http://trac.wildfiregames.com/changeset/18265 http://trac.wildfiregames.com/ticket/2324 I test this with the infantry_death.xml variant file by name the deaths like this: <variant name="Death"> <animations> <animation file="infantry/general/death/inf_02.psa" name="Death1" speed="700"/> <animation file="infantry/general/death/inf_03.psa" name="Death2" speed="500"/> <animation file="infantry/general/death/inf_04.psa" name="Death3" speed="400"/> <animation file="infantry/general/death/inf_06.psa" name="Death4" speed="500"/> <animation file="infantry/general/death/inf_07.psa" name="Death5" speed="400"/> </animations> <props> <prop actor="props/units/blood_01.xml" attachpoint="root"/> </props> </variant> Death1, Death2, etc. as the ticket and commit claim. This does not work and give me many headache when I tried to make it work. I was making my own variant files and naming the animations these way and it would not work. Spend 2 hours trying to make it work only to fail. So, I tried to change the names in existing variant file and behold it did not work either*. So the feature is a bug. It is very important for enrique's awesome new meshes and animations that this feature work too. By "not working" the dude just stood there while the prop went ahead and did the animation. Edited December 4, 2016 by wowgetoffyourcellphone Quote Link to comment Share on other sites More sharing options...
vladislavbelov Posted December 4, 2016 Report Share Posted December 4, 2016 Shouldn't frequency="1" be there in the <group><variant frequency="1" name="Death">...</group>? 1 Quote Link to comment Share on other sites More sharing options...
wowgetoffyourcellphone Posted December 4, 2016 Author Report Share Posted December 4, 2016 (edited) 13 minutes ago, vladislavbelov said: Shouldn't frequency="1" be there in the <group><variant frequency="1" name="Death">...</group>? I am trying this now, thanks. EDIT @vladislavbelov: Your suggestion now makes both the base unit dude and the prop do their death animation (thank you!), but they do not sync as they should based on them having the same name="death1", "death2" etc. Any more idea? @sanderd17 @wraitii @Enrique Edited December 4, 2016 by wowgetoffyourcellphone Quote Link to comment Share on other sites More sharing options...
vladislavbelov Posted December 4, 2016 Report Share Posted December 4, 2016 15 minutes ago, wowgetoffyourcellphone said: @vladislavbelov: Your suggestion now makes both the base unit dude and the prop do their death animation (thank you!), but they do not sync as they should based on them having the same name="death1", "death2" etc. Any more idea? if I'm not mistaken they shouldn't be synced (because name just for an animation control), probably it should be synced in that way: <variant frequency="1" name="Base"> <animations> <animation file="units/death1.psa" name="Death" speed="50"/> </animations> <mesh>skeletal/horse.pmd</mesh> <props> <prop actor="props/units/blood1.xml" attachpoint="root"/> </props> </variant> <variant frequency="1" name="Base"> <animations> <animation file="units/death2.psa" name="Death" speed="50"/> </animations> <mesh>skeletal/horse.pmd</mesh> <props> <prop actor="props/units/blood2.xml" attachpoint="root"/> </props> </variant> ... Quote Link to comment Share on other sites More sharing options...
wowgetoffyourcellphone Posted December 4, 2016 Author Report Share Posted December 4, 2016 (edited) I mean this, i think i'm not being clear, sorry. Both the dude and the cape use the same death animations. death_a.dae and death_b.dae. These are variations of death. So I am try to get the dude and the cape to use the same death animation at the same time - synced. so yeah, I am using the name for animation control, to control that the cape and the dude use death_a at the same time and death_b at the same time. I think what is supposed to happen is that the dude chooses one of the 2 death variations and it is passed to the prop. The problem might be that I am setting the animation variation names in a variant file (and this might not be compatible with the variation selection feature Im try to use here). Edited December 4, 2016 by wowgetoffyourcellphone Quote Link to comment Share on other sites More sharing options...
vladislavbelov Posted December 4, 2016 Report Share Posted December 4, 2016 2 minutes ago, wowgetoffyourcellphone said: Both the dude and the cape use the same death animations. death_a.dae and death_b.dae. These are variations of death. So I am try to get the dude and the cape to use the same death animation at the same time - synced. So the unit and the prop are different actor with different animation files? Quote Link to comment Share on other sites More sharing options...
wowgetoffyourcellphone Posted December 4, 2016 Author Report Share Posted December 4, 2016 Just now, vladislavbelov said: So the unit and the prop are different actor with different animation files? Same animation file (for reasons). It all works fine if i just use one death animation, but when i use the 2, they become unsynced and sometimes don't use the same animations. I thought it was possible to set a name in the actor that they would both use and so use the same animations together. Quote Link to comment Share on other sites More sharing options...
vladislavbelov Posted December 4, 2016 Report Share Posted December 4, 2016 9 minutes ago, wowgetoffyourcellphone said: Same animation file (for reasons). It all works fine if i just use one death animation, but when i use the 2, they become unsynced and sometimes don't use the same animations. I thought it was possible to set a name in the actor that they would both use and so use the same animations together. I'm not sure that it's possible yet: sync different actors for animation with the same name and file, especially if actors described in different files. Quote Link to comment Share on other sites More sharing options...
wowgetoffyourcellphone Posted December 4, 2016 Author Report Share Posted December 4, 2016 (edited) http://trac.wildfiregames.com/ticket/2324#comment:8 Quote Animations can be defined inside <variant> elements, and variants can be chosen by name. So if the selection is set to "Walk", and there's a "Walk" variant, the <animations> set of that variant will override the other animations. So the only possible animations will be the ones walking. Then you can just select one by frequency, and store the name to reuse for it's props (when appropriate). In case you don't need a a prop to have the same animation, you don't need to give a name to your animation, but it should be clear from the variant name when the variation should be used. So you can have a variant like this, and it will pick a random one: <variant name="Walk"> <animations> <animation file="infantry/general/walk1.psa" frequency="1" speed="250"/> <animation file="infantry/general/walk2.psa" frequency="1" speed="250"/> </animations> </variant> Or a variant like this, and it will save the name for the props: <variant name="Walk"> <animations> <animation file="infantry/general/walk1.psa" frequency="1" name="walk1" speed="250"/> <animation file="infantry/general/walk2.psa" frequency="1" name="walk2" speed="250"/> </animations> </variant> The last example there is what I am trying to achieve. I saved the names "death1" and "death2" in the dude's actor death variant file just like in the example (but death instead of walk). Then in the cape file I use death1 and death2 as the animation names and they do not sync. :/ Edited December 4, 2016 by wowgetoffyourcellphone Quote Link to comment Share on other sites More sharing options...
vladislavbelov Posted December 4, 2016 Report Share Posted December 4, 2016 (edited) 53 minutes ago, wowgetoffyourcellphone said: http://trac.wildfiregames.com/ticket/2324#comment:8 The last example there is what I am trying to achieve. I saved the names "death1" and "death2" in the dude's actor death variant file just like in the example (but death instead of walk). Then in the cape file I use death1 and death2 as the animation names and they do not sync. :/ There is frequence="1" again, but in the animation. Also "it will save the name for the props", probably you need to do this for unit: <variant frequence="1" name="Walk"> <animations> <animation file="infantry/general/walk1.psa" frequency="1" name="walk1" speed="250"/> <animation file="infantry/general/walk2.psa" frequency="1" name="walk2" speed="250"/> </animations> </variant> And for prop: <variant frequence="1" name="walk1"> <animations> <animation file="infantry/general/walk1.psa" frequency="1" name="walk1" speed="250"/> </animations> </variant> <variant frequence="1" name="walk2"> <animations> <animation file="infantry/general/walk2.psa" frequency="1" name="walk2" speed="250"/> </animations> </variant> Or even without variations: <animations> <animation file="infantry/general/walk1.psa" name="walk1" speed="250"/> <animation file="infantry/general/walk2.psa" name="walk2" speed="250"/> </animations> I'm not sure, I'm searching in the source. Edited December 4, 2016 by vladislavbelov 1 Quote Link to comment Share on other sites More sharing options...
wowgetoffyourcellphone Posted December 4, 2016 Author Report Share Posted December 4, 2016 (edited) 10 minutes ago, vladislavbelov said: And for prop: <variant frequence="1" name="walk1"> <animations> <animation file="infantry/general/walk1.psa" frequency="1" name="walk1" speed="250"/> </animations> </variant> <variant frequence="1" name="walk2"> <animations> <animation file="infantry/general/walk2.psa" frequency="1" name="walk2" speed="250"/> </animations> </variant> I will try this now. This is pretty much my last try for now. ediT: No, that is not working. Looks like the example @sanderd17 gives here is exactly how I am try to do it, but it is not working. http://trac.wildfiregames.com/attachment/ticket/2324/actorFormat_variationnames.diff (see the cavalry_javelinist_b.xml and cavalry_javelinist_b_r.xml examples) Edited December 4, 2016 by wowgetoffyourcellphone Quote Link to comment Share on other sites More sharing options...
vladislavbelov Posted December 4, 2016 Report Share Posted December 4, 2016 29 minutes ago, wowgetoffyourcellphone said: ediT: No, that is not working. Looks like the example @sanderd17 gives here is exactly how I am try to do it, but it is not working. Have you tried the last one way? Quote Link to comment Share on other sites More sharing options...
wowgetoffyourcellphone Posted December 4, 2016 Author Report Share Posted December 4, 2016 yes, I tried 'death1' and 'death2' like your examples. Didn't work. Quote Link to comment Share on other sites More sharing options...
vladislavbelov Posted December 4, 2016 Report Share Posted December 4, 2016 (edited) I mean the way where no variations, only animations: 40 minutes ago, vladislavbelov said: Or even without variations: <animations> <animation file="infantry/general/walk1.psa" name="walk1" speed="250"/> <animation file="infantry/general/walk2.psa" name="walk2" speed="250"/> </animations> It's for the prop, not for unit. Edited December 4, 2016 by vladislavbelov Quote Link to comment Share on other sites More sharing options...
wowgetoffyourcellphone Posted December 5, 2016 Author Report Share Posted December 5, 2016 14 hours ago, vladislavbelov said: I mean the way where no variations, only animations: It's for the prop, not for unit. I've done it that way and every way we talk about in this thread and more! lol 1 Quote Link to comment Share on other sites More sharing options...
Radagast. Posted December 6, 2016 Report Share Posted December 6, 2016 (edited) Is it in sync at first and only after the first loop gets out of sync? Can not test it here because I do not have this patch/revision. There is one inconsistency in the code, but it is not relevant, maybe I'm approaching leper's thinking because it may be nit-picky, yet confusing to set m_Looping only once explicitly and the other time use the default: Index: ps/trunk/source/graphics/UnitAnimation.cpp =================================================================== --- a/ps/trunk/source/graphics/UnitAnimation.cpp +++ b/ps/trunk/source/graphics/UnitAnimation.cpp @@ -233,13 +231,27 @@ it->time = fmod(it->time + advance, duration); // Pick a new random animation CSkeletonAnim* anim; if (it->model == m_Model) { // we're handling the root model // choose animations from the complete state anim = it->object->GetRandomAnimation(m_State); m_AnimationName = anim->m_Name; // if we use a new animation name, // update the animations of all non-root models if (it->anim->m_Name != m_AnimationName) for (SModelAnimState animState : m_AnimStates) if (animState.model != m_Model) animState.model->SetAnimation(animState.object->GetRandomAnimation(m_AnimationName)); } else // choose animations that match the root anim = it->object->GetRandomAnimation(m_AnimationName); if (anim != it->anim) { it->anim = anim; - it->model->SetAnimation(anim, !m_Looping); + it->model->SetAnimation(anim); } There you have it what a patch novice is writing here. One must not conclude when only having looked at a diff. Here the check for m_Looping was not shown in the change set. oO Edited December 6, 2016 by Radagast. had a look at the diff only, without context, which is a bad thing 1 Quote Link to comment Share on other sites More sharing options...
Radagast. Posted December 6, 2016 Report Share Posted December 6, 2016 (edited) Just to be sure, Is this what you are doing? <variant frequency="1" name="Death"> <animations> <animation file="infantry/general/death/inf_02.psa" frequency="1" name="Death1" speed="250"/> <animation file="infantry/general/death/inf_03.psa" frequency="1" name="Death2" speed="250"/> <!-- ... --> </animations> </variant> And for the props: <variant frequency="1" name="Death"> <animations> <animation file="infantry/general/inf_02.psa" frequency="1" name="Death1" speed="250"/> <animation file="infantry/general/inf_03.psa" frequency="1" name="Death2" speed="250"/> <!-- ... --> </animations> </variant> Edited December 6, 2016 by Radagast. 1 Quote Link to comment Share on other sites More sharing options...
Radagast. Posted December 6, 2016 Report Share Posted December 6, 2016 (edited) What does do not sync mean? (dude idle and prop correct animation?) It may be that you have to tweak the speed attribute: http://trac.wildfiregames.com/wiki/AnimationSync Edited December 6, 2016 by Radagast. Quote Link to comment Share on other sites More sharing options...
Enrique Posted December 6, 2016 Report Share Posted December 6, 2016 Does not sync means that animations do not pick the same variants, so they end up playing different animations. 1 Quote Link to comment Share on other sites More sharing options...
wowgetoffyourcellphone Posted December 7, 2016 Author Report Share Posted December 7, 2016 17 hours ago, Radagast. said: Just to be sure, Is this what you are doing? <variant frequency="1" name="Death"> <animations> <animation file="infantry/general/death/inf_02.psa" frequency="1" name="Death1" speed="250"/> <animation file="infantry/general/death/inf_03.psa" frequency="1" name="Death2" speed="250"/> <!-- ... --> </animations> </variant> And for the props: <variant frequency="1" name="Death"> <animations> <animation file="infantry/general/inf_02.psa" frequency="1" name="Death1" speed="250"/> <animation file="infantry/general/inf_03.psa" frequency="1" name="Death2" speed="250"/> <!-- ... --> </animations> </variant> Yes, his is exactly the format I am use at the moment. 18 hours ago, Enrique said: Does not sync means that animations do not pick the same variants, so they end up playing different animations. Enrique is right. They play different animation even if they are properly given the same names. Quote Link to comment Share on other sites More sharing options...
Radagast. Posted December 8, 2016 Report Share Posted December 8, 2016 (edited) Thank you then. Got 0 A.D. working on voidlinux and it looks like there is something wrong. Depending on the actor XML it can even lead to a segmentation fault.While the Animation system differs from 0 B.C. I saw there is an infinite loop. Somewhat unrelated to the sync issue though. SYNC / EQUAL ANIMATION ISSUE And when the animations not even are picked accordingly as you two said then it is also excluded that the Desync speed variation to not have units look too uniform is responsible. Maybe I can get to something when I relearn the 0 A.D. code. If so then I will provide the patch(es). It was bad enough that I did not provide the water patch back then because it was such a small issue that it was embarrassing and I was sure people would take me apart when I provided such a small fix. This way Ykkrosh could get the gems that he deserved much more because this is a coding giant. Apropos, he is still working on 0 A.D.? Helping you busy history colleagues out is the least I can do. If someone else is quicker so, don't hesitate to fix it. It will okay to me, I do not need credit, for me it's enough if those busy people is being helped. Edited December 8, 2016 by Radagast. Quote Link to comment Share on other sites More sharing options...
wraitii Posted December 8, 2016 Report Share Posted December 8, 2016 Hm, you guys were right, the code was completely bonkers. I should have fixed it by now, let me know after the auto build if you find bugs New format if you want props to sync with a main actor: <animations> <animation file="infantry/general/inf_02.psa" name="Death" id="death1" speed="250"/> <animation file="infantry/general/inf_03.psa" name="Death" id="anotherdeath" speed="250"/> <!-- ... --> </animations> To clarify: -no need to use named variants, just put all your animations inside one <animations> block. -"name" now must refer to an animation type (e.g. "walk", "death", "idle"). -You can use frequencies as before. -"id" is now the parameter used to sync across props. If an animation has an ID, all props will try using an animation with the same name and ID. You may have several animations with the same ID. I'll try adding tests for this later because it's quite annoying to check manually. 3 Quote Link to comment Share on other sites More sharing options...
Radagast. Posted December 9, 2016 Report Share Posted December 9, 2016 (edited) Good work. Still got no farther than to the infinite loop and fixing my vim which also segmentation faulted suddenly. The latter is fixed now. This Model, Object, prop relation and animation picking is complex, the animation name is rewritten at all corners, e.g. with the m_State. I still know this from the Animation rework. So I wondered how it could be so easy by reusing m_AnimationName as sander coded it. That's the first time I saw sanderd17 err on something. Though I liked his easy solution, simplicity rules and the major benefit still is that we do not need a new actor format version in 0 A.D. as in wraitii"s first version. MANDELBROT ACTOR DEFINITION I start to wonder if instead of fixing the infinite loop it was not easier to redesign to allow entity on entity which not suffers from this. This is getting mind twisting to fix. Not sure if it is worth the edge case of same actor as a prop of the same actor definition again. Mandelbrot actor so to say. Might be useful for procedural actors like chaining / interconnecting orient carpets. Edit: It might be wise to restore the idx kind of anim handling as before the 2 commits by sander and code the ID attempt freshly to be sure of no further regressions though I saw you evaded the m_AnimationName conflict. Edited December 9, 2016 by Radagast. 1 Quote Link to comment Share on other sites More sharing options...
Radagast. Posted December 9, 2016 Report Share Posted December 9, 2016 (edited) There is some crucial information missing artists should be aware of before we will be able to unleash the full powers of the new code: It is not guaranteed that the equal-ID animations are chosen because a later variant can override those name's mapping, replacing all the animations found in an occurrence of a variant with the same name in an earlier examined group. (one variant per group is chosen) We will be responsible to ensure that there are no animations from other variants that overwrite those that we linked using the name,id combination. THIS IS DESIRABLE BEHAVIOR because it allows for removing the via ID linked animations by providing an animation with the same name but without an ID. This may be vital to understand. Of course the name,ID link animation can be overridden per actor by defining an animation within an equally named variant that also defines the same name and id combination. Note the variant name must not necessarily be equal for linking animations as long as the animation names and ids match and the animations are loaded. VARIANT NAME CASE NOT IMPORTANT Furthermore note that the Variant names case does not matter while the animation names' does. Use lowercase to avoid random errors. For consistency we may want to use lower case for animation names too? (attached a patch to #2324) Or is there a special reason for keeping its case other than confusion? I could not find a place where these names are transformed to lower case internally in comparisons with e.g. State which means that the simulation code has to use lower case and the animation names too but this may be fragile. Correct me if I got something wrong. I did not test it ingame if it works, I only read the code and thought this should be clarified so that artists do not have to read the code themselves. MANDELBROT ACTOR DEFINITION of course is bogus. My workaround is to stop at a certain number recursions as defined via extra attribute. This is neither correct behavior nor useful other than for chaining actors like oriental carpets randomly by defining a recursion number. And even then it is only linear stacking, so it may only suit for constructing a modular tower to the clouds if settlers wanted to do this. Edited December 9, 2016 by Radagast. Quote Link to comment Share on other sites More sharing options...
wowgetoffyourcellphone Posted December 10, 2016 Author Report Share Posted December 10, 2016 Hi, can haz autobuild? http://trac.wildfiregames.com/changeset/19031 1 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.