OK, update. Wrote a lot of code last night, all of which is untested thanks to unrelated computer issues (the drive with my My Documents folder is dying, which means my savegames and INI settings are currently inaccessible, and I can't run Oblivion until I either get them back or replace them - currently working on the former - this drive does not have any Oblivion-related work on it, though).

What we have (italicized functions need testing):

• NifOpen - opens a nif for reading and/or writing.
  
• NifClose - closes a previously opened nif, useful for freeing up some memory if you're done with it.
  
• NifGetPath - returns the path to a nif-file - useful if it's writable, since this is different from the path that was passed to NifOpen.
  
• NifGetOriginalPath - returns the path to the original file that a writable nif is a copy of.
  
  
• NifGetNumExtraData - returns the number of ExtraData nodes attached to the root of a nif.
  
• NifGetExtraDataIndexByName - returns the index number of a given ExtraData node. Useful for finding, for example, the Prn node.
  
• NifAddExtraData - adds an ExtraData node
  
• NifDeleteNthExtraData - deletes the specified ExtraData
  
• NifGetNthExtraDataName - returns the name of the ExtraData
  
• NifSetNthExtraDataName - sets the name of the ExtraData
  
• NifGetNthExtraDataType - returns the type of the ExtraData (as far as I can tell, Oblivion uses only String and BSXFlags ExtraDatas).
  
• NifGetNthExtraDataString - returns the value of a StringExtraData node. If the Nth ExtraData node is not a String, it fails.
  
• NifSetNthExtraDataString - sets the value of a StringExtraData node. If the Nth ExtraData node is not a String, it fails.
  
  
• NifGetNumChildren - returns the number of Child nodes attached to the root of a nif.
  
• NifGetChildIndexByName - returns the index number of a given Child node. Useful for finding, for example, the Scb node.
  
• NifDeleteNthChild - deletes the specified Child (removing said scabbard, perhaps).
  
• NifGetNthChildLocalTransform - returns the Local Transform matrix (4x4) of the given Child.
  
• NifGetNthChildLocalTranslation - returns the Local Translation vector (3) of the given Child.
  
• NifGetNthChildLocalRotation - returns the Local Rotation matrix (3x3) of the given Child.
  
• NifGetNthChildLocalScale - returns the Local Scale float of the given Child.
  
• NifSetNthChildLocalTransformTEMP - takes 16 floats and 2 ints, the 16 floats being the entries of a 4x4 matrix that will be the new Local Transform matrix, and the ints specifying which Child of which nif. Will be replaced to take an array when the ability to accept arrays as a parameter is added to OBSE's plugin API. Backwards compatibility will remain, however.
  
• NifSetNthChildLocalTranslation - takes 3 floats for the new Local Translation vector. Will be replaced as above.
  
• NifSetNthChildLocalRotation - takes 9 floats for the new Local Rotation matrix. Will be replaced as above.
  
• NifSetNthChildLocalScale - takes 1 float. Will not be replaced (no need).
  
• NifNthChildHasMaterial - returns whether or not the Nth child has a Material property node.
  
• NifGetNthChildMaterial - returns the name of the Material property.
  
• NifSetNthChildMaterial - allows you to set the name of the Material property.
  
• NifNthChildHasTexture - returns whether or not the Nth child has a Texture property node.
  
• NifGetNthChildTexture - returns the filepath to the Nth child's texture file.
  
• NifSetNthChildTexture - sets the filepath of the Nth child's texture property to a new texture file.

So, kind of a last call for new features for v1.0. The collision stuff is not likely to make it.

Also, Scruggs's new code doesn't quite fix the problem I was having with the load. He's looking into how to get me access to the .obse co-save file when I need it, though, so it should be fixed for final release. Many, many thanks to him for doing that; I know he's extremely busy and it's a rather non-trivial request.

Awesome stuff man! Thanks for all the hard work, can?t wait until you release! :hubbahubba:

Heh, no problem.

Release should have been tonight, but my stupid computer issues have prevented that. Will continue trying. Once I get the computer working, it should be a few quick tests and then an alpha release.

Do I take that you can finally start working on ARES now ?

:meh: Heh. Well, no, because this would just be the alpha test - I'd still need to rewrite the original functions since I've broken them, test those, and I'll need to integrate Scruggs's fix.

Once I've done all that, however, then yes, work on ARES should resume.

Ugh ... :bonk: What was that fix for anyway ?

None of those things should take very long, mind. Well, Scruggs's end might; like I said, it's rather non-trivial from what I understand.

Basically, the load callback that OBSE sends to plug-ins so they can initialize things occurs when Oblivion has finished loading a savegame. Unfortunately for me, this means I have not yet loaded the nif's saved to the .obse file, and so if Oblivion was looking for them during the load, it didn't find them. More importantly, now that I have them, Oblivion isn't looking any more - it's already given up and used the missing mesh marker. They'll work fine when Oblivion reloads the models, but that doesn't work very nicely in quite a few situations.

The solution that Scruggs is working on is to create a new callback that occurs before Oblivion starts loading things, but after the player has chosen to load a savefile. Currently he's got a system whereby I receive a message when this is the case, but that doesn't do me very good since I cannot access the .obse co-save file with the information currently available. So he's working on fixing that.

I have no idea how difficult that will be, but like I said, non-trivial. Scruggs is very busy, so personally I'm very happy that he's been generous enough to even look into it, honestly.

That fix should not be necessary for alpha testing, or even beta testing if it comes to that. Release would require it, though, as it would be rather ugly in normal play.

does this mean we can edit the texture path on items now?

If they work, yeah, sure. That's what they're there for.

I'm not entirely sure how that one will be used. I mean, if you have the textures ready-made, couldn't you just as easily have ready-made nif's that use them? I don't really see the advantage to changing them on the fly. Not without the ability to edit DDS files on the fly too, which I haven't done

(yet. I'd like to, if it can be done easily. Applying simple hue/saturation/filter effects to them would be something conceivably done through code, and I know of a C++ library for working with DDS files. That's a totally separate project that won't be happening any time soon, though.

Good news! Computer's back up and running (good lord that took too long), soooo... hopefully tonight for alpha, if not tomorrow. Well, assuming nothing truly explodes.

The alpha will be e-mailed directly to whoever wants to test it, but will not be released publicly on TES Nexus (oh good god, the complaints I'd get from everyone who updates without reading and borks the hell out of Unnecessary Violence). There may, or may not, be a beta, depending on how things go and whether Scruggs's code is available, but that will be released on TES Nexus, as will the final release (of course). The alpha will not support the original two (three) functions (and nothing will ever completely support the third one, though I'll make sure it works as well as it originally did, which I'm pretty sure was 'not at all'), but the beta and final release will.

The current list I have for the alpha is as follows:

• HeX_0ff
  
• Skyranger-1
  
• Pacific_Morrowind

Anyone else who wants in, just let me know. Obviously, feedback would be nice (and I'll definitely need quite a bit overall) but it's really no skin off my teeth to add another name to the e-mail list, so if you want it just to play with it, or get a head start on writing something, that's fine too.

EDIT: Update - the load function is currently causing crashes. Working on that. In other news - I've tested nearly every function. Adding and removing ExtraData nodes, and renaming Children are the only things that still need to be tested (and all but the first should be trivial).

EDIT 2: That's fixed, but there's some weirdness going on with adding the ExtraData nodes - it works fine, but the reported number of ExtraData nodes after adding one is wrong. For example, I had a nif with 2, and added one, and it claimed there were now 4. I added another and it claimed 8. And then I removed one and it claimed 12! Something screwy going on there. Will have to work on that tomorrow.

As mentioned in the OBSE thread, I guess I've decided to jump on the alpha test team.

The only significant functions I need for the Armor Stands is the ability to strip out the "skin" textures, and the ability to make a nif with collision and havok behave like a static item (specifically, change shields and weapons in order to make them stay where they are placed instead of falling to the ground).

The Skin thing it can already do.

As for messing with collision and havok, if you can give me the steps you take to achieve that in NifSkope, I can probably let you replicate it through NifScript. Like, if you wanted to make a random shield or weapon compatible with your mod, what would you do to it to create the static version?

Is there a way to generate a report on a NIF?

Because if there is, KOTN has the perfect set of information. A sword, a mace and a shield, with usable/playable versions and static versions for displaying on the KOTN armor stand.

I can go through by hand and try to pull out the difference information, but if it's possible to generate reports that can be compared that might be more precise.

Uh, hrm. I'd be worried trying to do that myself; I feel like I'd very likely miss something.

But Nif's can generate reports, though I don't know how thorough they are. But I can expose that in the alpha if it would help.

I don't actually have Knights of the Nine, though.

Sorry, what I meant was can I generate a report from the NIFs I have open on my computer which will show you what settings need to be changed to make a playable weapon into a static display item?

Otherwise, I can go through them and provide a list of what appears to be different about the two versions. Just post it here, I mean.

I assume you mean me - unless you forgot me?


BTW, do you need me to send an email adress to you, or do you just upload to some temp location and PM the url?

Baaaah! This is not the first time I've done that, either. They're similar names!

I'm really sorry, though.


Yeah, e-mail makes the most sense. Feel free to just e-mail me at dragoonwraith [at] gmail.com, and I'll send it to you when it's done. Hopefully tonight, if I can get this ExtraData thing sorted. Though I don't get home until late tonight, so I can't promise.

:P You are not the first one either - I even get PMs asking things about OSR. It?s just amusing IMO so don?t worry about it.


I?ll send the mail right away.

Okay, here's the differences that seem major between them. Let me know if this is any help.

MaceStatic								PlayableNothing								NiStringExtraData: SideweaponbhkRigidBody / Layer: OL_STATIC					bhkRigidBody / Layer: OL_WEAPONbhkRigidBody / Layer Copy: OL_STATIC				bhkRigidBody / Layer Copy: OL_WEAPONbhkRigidBody / Motion System: MO_SYS_FIXED			bhkRigidBody / Motion System: MO_SYS_BOXbhkRigidBody / Deactivator Type: DEACTIVATOR_NEVER		bhkRigidBody / Deactivator Type: DEACTIVATOR_SPATIALbhkRigidBody / Solver Deactivation: SOLVER_DEACTIVATION_OFF	bhkRigidBody / Solver Deactivation: SOLVER_DEACTIVATION_LOWbhkRigidBody / Quality Type: MO_QUAL_FIXED			bhkRigidBody / Quality Type: MO_QUAL_DEBRISShieldStatic								PlayableNothing								NiStringExtraData: Bip01 L ForearmTwistbhkRigidBody / Layer: OL_STATIC					bhkRigidBody / Layer: OL_WEAPONbhkRigidBody / Layer Copy: OL_STATIC				bhkRigidBody / Layer Copy: OL_WEAPONbhkRigidBody / Motion System: MO_SYS_FIXED			bhkRigidBody / Motion System: MO_SYS_BOXbhkRigidBody / Deactivator Type: DEACTIVATOR_NEVER		bhkRigidBody / Deactivator Type: DEACTIVATOR_SPATIALbhkRigidBody / Solver Deactivation: SOLVER_DEACTIVATION_OFF	bhkRigidBody / Solver Deactivation: SOLVER_DEACTIVATION_LOWbhkRigidBody / Quality Type: MO_QUAL_FIXED			bhkRigidBody / Quality Type: MO_QUAL_DEBRISSwordStatic								PlayableNothing								NiStringExtraData: SideweaponNothing								NiNode: ScbNothing								NiNode / NiTriStrips: Scb:0bhkRigidBody / Layer: OL_STATIC					bhkRigidBody / Layer: OL_WEAPONbhkRigidBody / Layer Copy: OL_STATIC				bhkRigidBody / Layer Copy: OL_WEAPONbhkRigidBody / Motion System: MO_SYS_FIXED			bhkRigidBody / Motion System: MO_SYS_BOXbhkRigidBody / Deactivator Type: DEACTIVATOR_NEVER		bhkRigidBody / Deactivator Type: DEACTIVATOR_SPATIALbhkRigidBody / Solver Deactivation: SOLVER_DEACTIVATION_OFF	bhkRigidBody / Solver Deactivation: SOLVER_DEACTIVATION_LOWbhkRigidBody / Quality Type: MO_QUAL_FIXED			bhkRigidBody / Quality Type: MO_QUAL_DEBRIS

The sword has a set of extra NiTriStrips that provide the scabbard. Not sure how that will affect things just yet.

@ Skycaptain - Got it. Don't have anything to send you yet, but I will when I get the chance.

@ Showler - I can (and have tested) deleting scabbards. There's a lot of people after that.

Anyway, OK... that's a lot of things to change, but I'm pretty sure Niflib gives easy access to all of that data. So these should be pretty trivial to implement. It's just a fairly large number of extra functions for me to test. I may end up writing them and giving them to you untested, if I feel like it's holding things up. I hope that's OK?

Also, you might want to try just straight-up deleting the Collision data from the nif and see if it works for your purposes. I think it would, if you have scripts positioning the thing anyway - pretty sure things with no collision are ignored by Havok. Try Delete Branch on the collision node (obviously save it as a separate copy), and see if that works? That would be much easier for me to implement on the short term. On the long term, I'll be implementing each of these, so don't worry about that.

You may also want to e-mail me as Skycaptain did, so I have it when I finish.

I'll give that a try when I get a chance to experiment.

One advantage seems to be that the six major changes are absolutely identical in weapons and shields, so it might be possible to make a single command to convert them.

Of course, if stripping the stuff out completely works, that's even better.

It won't work if the static version ever ends up "free" in the game world, cuz it'll just float and clip. But so long as you're positioning everything with script, that should be pretty trivial.

Having one function to set all six, I'm not going to do. That's what I did with the initial three functions, and I'm regretting it because I still have to support them. I'd much rather give you access to each thing yourself.

Ah, you know better about stuff like that.

In any case it would just be a cut and paste of six commands.

For my purpose, I'd be using a script to position the items and they should never be moved except also by script. The armor is already like that because biped armor models already lack collision and havok information, I think.

Ironically... no, not really. I don't know that much about nif's. I know some about their internal structure, but very little about how it's all used. I've said it before and I'll say it again - I am far from the most qualified person to be doing this project. Just, ya know, the most interested.


Use an OBSE user-function to avoid that, I'd think.


I think you're correct. Stripping the collision I think will work then, but you should give it a try to see. In any event, I'll add the ability to strip collision from meshes, and if you need those six functions I'll work on adding them for the beta and/or final release. Unless you can confirm before the alpha that you'll need them, in which case I'll try to get them in for the alpha.

Also, something that's been concerning me - children nodes are NiNodes. This is the same as the root. Any NiNode can have ExtraData, Collision, and Children of its own. Referring to these through functions might get very awkward (also, awkward for me to save, based on the way I have the save system working), but I have ideas for both of those problems. I've actually seen Children that have their own ExtraData, so it's not a nothing problem. I don't really know much about it, but it's been in the back of my mind recently.

I'm not using NifScript and haven't been following its development, but after seeing the talk about Universal Armor Stands in the OBSE thread, I thought I'd pop in and point out another potential use that sprang to mind.

Cobl provides a set of http://www.uesp.net/wiki/Tes4Mod:Cobl/Modding/Static_Alchemy_Equipment, which are scripted activators that a modder can place in a cell. Initially they look like empty alchemy equipment stands with no glassware in them, but when the player activates one while holding alchemy equipment, the script takes the equipment out of the player's inventory and copies its model path to the activator so it looks like the player's equipment was placed on the table. After that, the player can use the static alchemy equipment like normal alchemy equipment.

The trouble is that although the initial (empty stands) models are immobile, the real alchemy equipment models have Havok data, so when those models are copied to the static alchemy equipment, they can be bumped around, fall off the table, picked up with the Z key and thrown across the room, or whatever -- despite having names like "Stationary Alembic" when you look at them, and being intended to stay where the modder placed them.

If NifScript supports (or will support) removing Havok data from models for showler's armor stands, the same could probably be used to fix Cobl's static alchemy equipment. I'd be willing to take a shot at updating Cobl's scripts, though I'm not sure what their policy is on OBSE plugin dependencies (or whether Cobl is even being maintained now that Wrye is retired).