Is it a problem of a format change or is it a problem of using the unpacker? What exactly did you do? In case it's a format change try to get an old version sample, unpack it. Then use the script on the new format and report exactly what happens. have done the tempmodel.pck Does mean what? Does this...

the point is to understand that the format is big endian. Then the rest is simple (shown for the last submesh only): from the pic you can see the start of vertices (0x3196C, directly after the last face index (FI) of the previous submesh). Startaddress of first face index of last submesh is 0x359B0....

ok, that didn't help, to be honest (there's nothing new compared to what you provided so far. :D ) Anyway, I got one animation working, not perfectly but in a decent way (more or less). Here's a short guidance but I can't guarantee that it will work for 3dsmax versions other than the one I use (2013...

(Don't even know why it took so long for those guys to understand that it's big endian and half floats. :D well, Mr shakotay, and I don't even understand WHY it took 2.5 hours to understand that this nif is not big endian? :D (well, I was fooled by the vertices starting at an odd address...) FantFr...

These NIF files version is 20.3.1.1 read here: https://github.com/niftools/nifxml/pull/47 For some unknown reasons there was a 10 month period of inactivity up to now (but I didn't bother to search for more infos). (Don't even know why it took so long for those guys to understand that it's big endi...

But that's the ones which were already included in the Model and Animation folder of your previous upload, aren't they?

What I meant was a model (.lmt, .mod) which you could successfully create a working animation from using Surveyor's tools. Or don't you have such?

Thank you!
I'll see what I can do. But don't expect it too soon.

btw: it could be helpful if you provided one model (.lmt and .mod) where the generated .ms files create a working animation in 3dsmax.

If I had realized , of that mistake in the bones, but do not try to change and I tried it to rename the bones gives inseperado result , would have to find which are the bones indicated or names of the bones. :( The author is the user Surveyor Thx, but Surveyor's last post is from 4 years ago. Is th...

Yes, I've tried and the rip was screwed, well, no surprise. :D There's some problems with analysing, too many missing objects, some missing faces though I've made some progress: cordoba.JPG (I know there's people on Xentax who could handle this better but I remember only one of them who cared for c...

Hi, I wanted to know what the problem with this script , apparently does conflict , em003_0.ms , here is the problem: noda = getnodebyname"em003_bone_62" There's no such bone created in em003.mod.ms but em003_bone_0 up to em003_bone_43 Seems most of the bone numbers in the first script don't match....

shakotay, why'd you delete that post? I was just coming here to reply to it. After I reread Gh0stBlade's post and your reply I found that: I assume that 0xFFFF is a valid triangle index based on what Gh0stBlade is saying. this is true. If as shakotay said those are not actually indices, then obviou...

using hex2obj (view link in my sig):

Thx - I changed the signature to lowercase but BRRES Viewer v1.3.1, 3 Jan 2011 By Kentilan doesn't recognize it (maybe a matter of endianess?). There's a brres-splitter, but it doesn't produce an output because a signature like 'MDL0' is missing in the staff05.brres . Even worse, there's no strings ...

That's 4 byte wiped out. Why? These 01 00 00 00 might be some kind of marker. It's experience that tells me the face indices must start at 0x21AA (00 00 01 00 02 00). You also ignore the very last two bytes yet they are 0x00. yes, I always reduce it to the min. :D There is no reason to put them by ...

0x21AA 336
Vb1
32 20
0x906 197
020000
0x0 255

to be used with the (compressed) staff bdae.

(Don't ask me for this weird plane attaced! )