I am making a trigger zone in front of a thrown to make NPC bow whenever they happen to pass by in front of it.

I am a little more knowledgeable than I use to be about these animations, just enough for me to worry about what I am doing now. (oh for the bliss of ignorance...)

When I add a child (CS idle animations tab) under the "character\male\idealanimations"

the NEXT one down "RaceMenuAnimations" gets marked as changed.

I am worried I am making the mod dirty this way.
Should I add the idle as a sibling instead?



Also, I have tried prayer and onehandonswordkneeling animations so far and do not entirely like them for my application. Any suggestions on the animation to use?

I've seen that happen too. Just mark the record to be ignored after adding all your idles.

My apologies to 2 experienced modders, but that is incorrect. Idle anims are like dialogue topics in that they are implicitly chained. Therefore if one inserts an idle anim into an ESP, at least one change will be registered:

• The new anim itself with the anim previous to it stored within the DATA subrecord,
  
• If the anim is inserted before another, then that one will be changed to reflect the new anim as the previous anim.

Truth be told, I don't know what effect that would have on gameplay, but it does result in CS errors when such a "cleaned" plugin is merged with the base ESM. It is possible that if the position of a new idle anim is altered after creation, that there may be IDLEs registered as changed that were in fact "changed back," but I would leave the determination of which IDLEs for which that condition holds to the professionals.

HTH,
Steve

I see ... that's quite interesting. Thanks for correcting me :thumbsup:

um...so I just leave it as is and try not to worry about it then?

I do not see what other choice I have then as I am doing this correctly (as per the wiki)

right?

If you like, send me the ESP along with the name of the added anim and I can take a brief look in Gecko. My bet is that you're doing it just fine though.

Steve

I've wondered about this myself as well. I created an entire new animations category within the listing, and the same thing happened, the animation category after it shows the * as if it was been modified.

All I know is that all the other mods I looked at that are well known which add new animations put in their own category within the listing, and it's the same result.

No idea of what kind of conflicts could occur due to this, maybe none, because in all truth there is no true modification made of the category that is just below the new one? (apart from the idle animation order changes)

I tested in the Cs like 3 well known mods that have animations added.. I figured they all did it.. so I may as well too

I did some testing of that a while back. Unfortunately, the thread seems to have been purged. I basicly used four mods, two that added idles to the start of the tree and two that added idles to the end of the tree, as shown below.

Adding to start of tree:

+ SomeIdleGroup
- NewIdle *
- OldIdle*
- AnotherOldIdle
- ...

Adding to end of tree:

+ SomeIdleGroup
- OldIdle
- ...
- AnotherOldIdle
- NewIdle *

As far as I remember, if you add the animations to the start of the tree, it may overwrite idles from other mods that add animations to the start of the tree, whereas adding it to the end of the tree would not overwrite either, ie. be clean. My recollection may be wrong, so you may want to test it (and the POC mods have long since dissapeared, so ...).

I create a new branch at the top of the tree in PiiiP that's used to hold all of my idles. I don't think it conflicts with DR5, which adds it's own branch and a few idles to the main branch.

Ya, I added a new branch (completely new animation folder area) to the main listing just above UniqueIdleAnims.. and of course that aforementioned main branch listing shows the * at it now.

Again i've seen a number of well known mods doing the same thing, all I can say is if it causes an issue in testing/release with other animation providing mods, I can do what was reccomended and try adding my anims to the bottom of a pre-existing animation group (like UniqueIdleAnims)..

I did try making a completely new major category for the animations for the mod, and failed every time. Seems the Cs will only let me add to the Male/IdleAnims area.

Ah well, water under the bridge really, beta testing will hopefully reveal any issues, and can make modifications if needed.

Nice topic btw, I had never found a topic regarding this many months back through searching, and always wondered what the deal was.

First of all thanks to the people in http://www.gamesas.com/bgsforums/index.php?showtopic=1075507 thread for helping me out and pointing me here, I don't want to bump it again.

So...can any of the people involved here say how it works now? Does adding an idle on top of the list cause compatibility problems with other mods that do the same? If it does, is it safe or even possible to delete the unwanted changes (removing the dependancy on the previous list) from the mod, either by ignoring it in the CS or with TESEdit? Does it cause any bugs, problems?

Dwip and I tested this when he released his prayer idles mod. It showed as a conflict in TES4Edit, so I was worried something would break between his mod and one of mine that also sets up and idle. We both came to the conclusion that neither mod was being blocked out and it made no difference where in the load order they went.

I think Steve Carrow is right on figuring that it behaves like the dialogue system and adjusts for the problems during game load.

Thanks, that's good to know!

If that is correct about the order of anims, then what would it mean by the editorwarning giving an error of 'could not find the previous idle' when the new idle is placed at the top of the tree, moved down to the bottom and then receiving the same error? I'm inspecting Mr. Siika's Farmanimals and TES4Edit shows it to have these errors. Since I'm using the resource, I would prefer to not have these errors.

my mistake, I merged it to an esm and forgot that it is considered modified at that point. At this point, once merging to an esm, how may you stop editorwarnings from reporting this as errors, when it is not?

i've encountered this same issue in the CS for morrowind whenever loading the master files for morrowind, tribunal, and bloodmoon at the same time because the expansions add animations, dialog topics, greetings, journal entries, etc to the top of the list and it generates a rather long string of error messges. it's never actually affected the way the game runs tho as far as i could tell. i would assume the same thing is happening with the oblivion CS. I would just ignore it. yes, you will get an error message in the CS but it should still function without issue in game. the only way i can think of fixing the error messages is to edit the entries into the master file. the only issue with that is that if anyone else who doesn't have your modified master file opens your mod in the CS they will get an error message. but it should still load everything fine. At least that's the way it worked with the morrowind CS.

I think I would tend to agree with you, however, with approximately 18 idles reported as errors (when they are not), and errors reporting that objects are attached to the wrong cell (when they only straddle an adjacent cell (when I deem they are not errors), the EditorWarnings.txt file tends to get full when you are working on a large heightmap. Which, in hand, creates problems for script writers using CSE. Sorry if this is getting off subject, but I'm trying to achieve a clean mod by fixing this idle animation issue, now that I've cleaned everything else up but this. :thumbsup: I think I found the answer to my earlier question now after checking the new features on TES4Gecko's latest update. I'm going to remove the animations entirely, and reenter them with only TES4Gecko.

This thread was resurrected (for good reasons) and after I reread it all again it would seem that this conclusion still stands:



But the Wiki is telling moders to put the idles at the bottom?
Unless I get feedback on this telling me not to do so I will be editing that out of the wiki.

See here:

http://cs.elderscrolls.com/constwiki/index.php/Idle_Animations

it is under the heading of compatibility.

If I understand this correctly putting the ildes at the bottom means that Pick Idle in your script will have to HOPE that all the other idles do not trigger as the manager searches the list all the way down to your idle.

Please tell me if I am incorrect on this, I am not an expert on the idles but most of the experts on moding oblivion are sometimes too busy to edit the wiki.

It looks to me however from the edit history that maybe "The Magician" did the entry and then "Qazaaq" did an edit? If so I would not presume to know more about the idles than they, but if they did not originally create that entry I am uncomfortable with leaving it As Is with out anymore discussion on this.

spooky;
I was following this thread a while back. Like you, I read and followed the info on the wiki and was experiencing some mysterious problems.
The strangest thing was that if I put my idle animation on the bottom like the wiki suggests, the animation would not play, ever. If I placed the animation on top everything worked fine.

my conclusion was that the "must return a file" flag, in one of the oblivion animations stopped my animation from being played.

I started testing by placing my animation one step below each time, and see if it would play. But I gave up before encountering the problematic idle, I was too close to releasing my mod and the excitement overcame my curiosity.
if you decide to work on this issue, to clarify it once and for all, please share your results.

Well...all I am planning to do for now is remove the recommendation from the Wiki to put the idle at the bottom of the tree UNLESS you use OBSE "PlayIdle" which I believe (need to test this) will force the idle to play even if there is an idle above it in the tree that would play first (or stop your idle from playing ) when using the vanilla command "pickidle".

The wiki edit was done as I have not received any feed back suggestion that I should not do so.

Wait, what? You didn't receive feedback in the one minute you waited between the Discussion page entry, and the edit to the page? Are you serious?

Anyway, I don't have a problem with the edit per se; the section removed regarding compatibility was added by Qazaaq and TheMagician; I'm sure they had reasons for doing so, so I suggest that someone interested in this contact them (I know Qazaaq is still around on the forums in the Fallout section). I don't know anything about Idles, so I can't really comment. I'm only interested in making sure that the correct information gets put up there. There are great modders here saying one thing, and great modders who wrote that page saying another thing: the two really should talk and figure out what's going on.

Well, Steve was right about the fixes, after I removed my Idle anims from the master and then merged back with TES4Gecko, the CS no longer reported errors. I believed the anims were marked modified in a patch esp, then merged to master and never lossed the flag. The records are the same as they always were, except that I created new FormIDs, not sure what you did to remove that flag Steve, but :goodjob: for TES4Gecko. I hope you get yours resolved as well Spookyfx

:confused:

er...no I had this up in the air for a couple of days (see my Post on April 20th ). And I am confident in my edit but I was trying to be fair by not just doing a hit and run edit with out any "shout out" at all.

In the past I have waited a week before making wiki edits but did not get any response at all. Sorry I guess this time I felt confident enough about this that I was not going to wait that long this time. As you know there are not that many moders that have the time to keep the Wiki up to date. I am trying to do my part even though I am busy myself.

Good job catching this, spookyfx. As I mention in the talk page, my own contribution was merely an image and a short paragraph of description. I didn't test the issue myself, since it wasn't pertinent to my work at the time, but assumed it was correct based on my understanding of records and conflicts.

The fact is that adding an idle anywhere but at the bottom of the tree will show that other idles have been changed. It's great to hear that these changes won't produce conflicts, but removing the note about compatibility is not the entire answer: a note clarifying this issue for other modders would be a great addition, otherwise people will continue to ask whether or not it is an issue and possibly resurrect the deleted changes! :teehee: I would make the change myself, but I haven't done any testing on idle compatibility to base it on and I've already contributed more than enough to creating this confusion. :tongue:

Thanks for contributing to the wiki!