I've been struggling getting this model to Max and back off and on for days now. Since as far as I know, there's no way to load a .nif/.kf combination for non-characters/creatures, and adding a .kf to the .nif just seems to crash the GECK, currently I have my animated wall exported from max as a ".nif w/ animation" back into Nifskope and displaying the animation properly. Unfortunately when I select it as a model in GECK, I get this:

[img]http://imgur.com/v8bLE.png[/img]

So I go back to Nifskope and compare the old and new model and instead of the original's nice and neat:

BSFadeNode    NiControllerManager        NiControllerSequence            NiTransformInterpolator                NiTransformData            NiTransformInterpolator                NiTransformData            NiTransformInterpolator                NiTransformData            [etc]

The one exported from Max (after renaming the root node) is:

BSFadeNode    NiNode        NiNode            NiNode                NiTriStrips                    [...]                NiTriStrips                    [...]            NiNode                NiTransformController                    NiTransformInterpoloator                        [...]                    Ninode                NiTriStrips                    [...]                NiNode                    NiTriStrips                        [...]                    NiNode                        NiTransformController                            NiTransformInterpolator                                [...]

I can try to copy+paste the new data into the original format, but I can't make much sense of the new one at all. The Transform interpolators are just kind of randomly sprinkled throughout the rest of the tree, and I'd like to get some feedback on whether or not this really is the problem and if this is the way to fix it, or if I'm missing some crucial setting somewhere that magically makes it actually work right.

I export as nif w/ manager, for my animated models. There are several things to edit in nifskope to get animated models to work though. Not hard for me now, but it wasn't the easiest thing to figure out a solid workflow.

Knowing the Block Types does not help in the slightest -> the actual files would be more helpful.

I'm using Max 2009 with the latest niftools and "nif w/ manager" just exports an nif that doesn't animate at all in Nifskope and seems to have some incorrect texture assignments. Does "w/ manager" mean I'm supposed to get an extra window to configure beyond the normal one? Because I get no such thing



Sorry, I thought the hierarchy would be telling since the second file has no NiControllerSequence nodes and therefore no defined animation groups (the dropdown in the upper right corner of Nifskope is empty, yet Nifskope does play the animation).

Here are the relevant files: http://stashbox.org/1025835/nv_deathfakewall02.zip
nv_deathfakewall02.nif - Unchanged file from FNV
nv_deathfakewall02.kf - Animation pulled out of .nif which I imported into Max since Max wasn't importing the animation of the above file
nv_deathfakewall02_backward.kf - Reversed animation saved out of max, cannot get this merged into the above .nif, even if I delete the original animation from the .nif (Resulting file does not play the animation in Nifskope, and crashes GECK if I try to load it)
wwnFakeWall_Backward_13.nif - "nif /w animation" Export from Max, displays perfectly in Nifskope, implodes when loaded into GECK.

Edit: Ideally I would like to get together a file that has three animations: Open, Close, and a quick close-open of only the last stage of the animation. I'll be happy enough if I can do them in separate files on separate references and swap them manually for each animation though.

no, nif w/ manager just exports the file structure more or less correct in the nif, the actual sequence will be slightly broken unless fixed though.

This is just an exact duplicate of nv_deathfakewall02.nif everything is still intact.



This is not reversed, most likely the way you reversed it in Max was the incorrect method -> also you did not re-name the sequence from forward to anything else and that is why its not appending as NifSkope will only add one of each viable sequence -> so no 2 Forward sequences.



The most likely reason this does not have any Sequences is you did not set them up in Max before exporting as its impossible for the exporter to just divine what you want it to export if its not defined in the Scene itself.

Look up Dope Sheet tutorials for how to set these up or you can just read my http://sites.google.com/site/saidenstorm/oblivion3dsmaxanimationtutorial, it covers proper setup for exports out of Max and works for 99% of all game exporters, with some bits post export alterations local to Oblivion -> the differences going from Oblivion to FO3/FONV are not enough to even write another tutorial as it would cover a paragraph at best, just compair to Vanilla.nifs.



Open and Close are game engine only animation sequences and there are not any Fast versions of either -> if you want this level of functionality you are going to need to script the doors anyway so you might as well just use any of the normal Sequences that can be called from script and keep everything cleaner -> also I have never used Open/Close together with any of the Normal Sequences on any doors or containers but I have tried to use normal sequences on the engine based SpecialIdles for Projectiles and they will not work at all with the two different types mixed together into the same .nif, so I doubt Open/Close are any different.

Strange, then it must be the Niftools importer treating them differently. As I said, the .NIF imports with no animation and I can't import the .kf alone, I only get animation in Max by importing the .nif, then the .kf.



What is the correct method? I scaled the keys in the dope sheet -100%. I do not know of a reset x-form equivalent for keys. I am aware that I did not have a renamed sequence, I attempted to replace the animation in the original file, but obviously the attach .kf "spell" makes other changes to the file. I can confirm that exporting the .kf with a different sequence name still does not get me a reversed animation in Nifskope, unlike the exact same exact scene exported as an Nif w/ Animation.



The "forward" sequence is imported into Max fine and is thus present, hence the conflict with the .kf.



I don't see anything in your tutorial that is different from my current scene, other than exporting as NIF w/ Manager which gives me a completely non-functional mesh in Nifskope (No animation, half of the textures are missing/black)

Edit: Comparing to Vanilla .nifs is what I was doing in the first post, the exported .nif bears no hierarchal resemblance to the original of the same file, so it's hardly a matter of checking for small differences.




I am perfectly capable of manipulating the keys to achieve the animations I desire, in fact it's easy enough to just change the speed in Nifskope. I was talking about having three animations in one file as the end-result I'd like to achieve but like I said, it's not really any big deal if they're separate objects in-game as long as I can get it to work at all. Not sure what scripting the door has to do with it though, I have to script the door just to "playgroup forward 1", I don't believe there's any other way to get this asset to animate (none I can find, anyway) as it's placed in the game as a simple static object. Being that the whole issue is that there's no close animation for this door, I don't imagine there will be any hard-coded conflict with the forward animation from a static object and an animation that does not exist in the vanilla game.

I appreciate all the help, but nothing I do seems to work. I've exported the file over fifty times trying different things and have had no luck. Now I've lost the import settings I used yesterday and am getting incorrect textures on export, so I have to go figure that out again first. If you can tell me how to reverse the keys in a permanent way other than scaling them so that the changes will show up in an exported .kf file, that should bypass all my other problems. The .kf not exporting backwards makes no sense to me, since the .nif from the same exact scene plays as intended in Nifskope.

Silly texture mistakes of my own aside, http://stashbox.org/1026263/wwnFakeWall_Backward_68.nif exporting Nif w/ Manager with the exact settings from your tutorial... No animation whatsoever. I've tried getting rid of the NiNode between the root and NiControllerManager to make it match the original closer, but it complains that "Link points to wrong block type"

Okay I've narrowed down the option that prevents a "Nif w/ Manager" from working in Nifskope.

If I export from max as an Oblivion-version file it works fine :brokencomputer:

Of course, FNV won't accept such a file. :banghead:

the animation is there, it's just broken like I said. and you need to fix it for it to work.

just compare with a vanilla animated nif to see why your anim doesn't play.

all I did was reorganise it so that Corners01 was the root node, added everything as a child node/extra data to that. then changed it to a BSFadeNode
deleted the old scene root
ticked animation in the BSX flag

i think all i did was fix the sequence. the data in the controlled blocks array isn't quite right, you have to add the NiMultiTargetTransformController as the controller and add in that it is a NiTransformController in the Controller Type.

then that [censored] will play in nifskope at least.

Add that to what? http://stashbox.org/1026308/wwnFakeWall_Backward_91.nif you mentioned and it matches the original fairly closely, but still not playing the animation and it crashes the GECK now.

you didn't fix the sequence at all.

in the NiControllerSequence, you haven't added the NiMultiTargetTransformController as the Controller for each of the controlled blocks. in the NiControllerSequence block details, expand the controlled blocks array, in each of the controlled blocks, the Controller and the Controller Type are still blank. = no worky.

might as well delete the NiStringPalette, F3 onwards don't use these.

Ah, that explains why I couldn't find the type value. I changed... something else :whistling:

Edit: Okay it animates in Nifskope again, but... well... http://stashbox.org/1026340/wwnFakeWall_Backward_102.nif, implodes in GECK (see first post for image)

your shader set up is incorrect.

disable SF_Shadow_Map and SF_Shadow_Frustum. these are automatically enabled when you use a standard max material on the asset. And there isn't anyway to properly step up the games shaders in the niftools material afaik, I haven't looked at it in nearly a year though, and just got used to messing with shaders in post.

Woo, finally http://stashbox.org/1026640/wwnFakeWall_Backward_107.nif in-game.

Playgroup Backward 1 isn't showing the animation though, and now that I think about it, trying that on the original (where the animation was called 'Forward') failed silently as well :\ Possibly it's reserved (though how the original would work in that case I don't know). I tried changing the Name string of the NiControllerSequence, but it doesn't recognize it in-game (Animation Group 'Backward02' not found for parameter Animation Group). I tried renaming it 'Forward' but silently fails that way same as 'Backward'.

Is there somewhere else I need to change the name of the animation, or is it SUPPOSED to be either Forward or Backward and something's just still broken? Ideas? .-.

no idea, it played in the GECK model viewer for me, and loaded without warnings, except one mesh object has a parallax map but doesn't have the parallax shader enabled.

not sure, you don't have it set up as a door or anything though right, it's an activator?

It's a static actually, like the original. I could try making it an activator, but I don't think you could activate it without any collision anyway, could you? The original had collision around the sides but not the center, so it's not much loss. Collision with the center was handled by disabling some collision markers in the original vault. I'll try enabling the parallax shader... or actually, probably delete the parts that have it. I was going to do that anyway once it was working.

yeah, you'll have to throw a box at or some thing to test.


i would just steal that collision back i suppose.


you might get an error that the anim can't find a node it is supposed to be targeting, i doubt it will screw anything up, but you can always go back a remove them from the controlled block array and reorganise the list to fully get rid of it.

anyway, I dunno why it won't play, only think i can think of is try making it an activator :shrug:. Or it'll be down to saiden or trial and error. to help, I'm a bit busy to really test it for you, and on a crappy laptop for a few weeks as well.