also a problem with trees is that they (most) are spt (speedtree) files... which Niflib doesn't read... retexturing them is doable with hex editing though so if you can do the heavy lifting part of editing the external files direct from Nifscript then that would probably work (presuming you can make OB load models) I would think.
Pacific Morrowind

@ DragoonWraith:
Yes, I can see that trees are a hard thing to do because there in a different file type, but can you not start with something simple to prove the current NifScript system works.

Like a house and let its roof texture change over time. Here is one of my resources showing some houses and there different seasonal textures.

SB Resource - Farm House Extension:
http://tesnexus.com/downloads/file.php?id=25060

I don't expect the texture paths to change in front of me, so if a model reload is needed just enter the house and exit it to show us the new one.

Yes, but couldn't you do the same thing by just having the different houses set up ahead of time, and switch the models with SetModelPath, or swap house references with Enable/Disable?

Anyway, since I know how the ability will probably be there. Just not sure why you need it.

I THINK this is a really silly thing to say, because I'm not nearly as familiar with how things work as I'd like to be... would it be possible to use texture repathing to change ground textures? Like, to simulate snowfall during inclement weather? That'd be pretty neat, if impractical. I think it's a silly thing to say because I don't know if the ground is even a .nif... like I said, not familiar

Pretty sure the ground's texture is set in the CS. Which means that kind of thing would probably be something you have to ask Scruggs.

Anyway, tentative list of things v1.0 should be able to do. Things that are certain are in italics.

• Open a nif either read-only or for editing, with the edits going to a separate copy of the nif.
  
• Close a nif, telling NifScript to remove it.
  
• Get a nif's path (useful for finding the path of the edited copy).
  
• Get the number of ExtraData nodes that a nif has.
  
• Get the name of each ExtraData node that a nif has.
  
• Get the type of ExtraData that each ExtraData node is.
  
• Get the value of any StringExtraData nodes that the nif has.
  
• Set the value of any StringExtraData nodes that the nif has.
  
• Delete any ExtraData node that a nif has.
  
• Get the number of children that a nif has.
  
• Get the name of each child.
  
• Get the type of each child.
  
• Delete any child.
  
• Get the local transform of any child.
  
• Set the local transform of any child.
  
• Get the local translation of any child.
  
• Set the local translation of any child.
  
• Get the local rotation of any child.
  
• Set the local rotation of any child.
  
• Get the local scale of any child.
  
• Set the local scale of any child.
  
• Get the name of the material property of any child.
  
• Set the name of the material property of any child?
  
• Get the path to the texture of any child.
  
• Set the path to the texture of any child.

Is there anything else people really want in v1.0?

I'm not really sure what options all that already exposes, but one really nice thing would be the ability to alter collision/havok properties so that weapons/shields can be put on display.

What would you need to alter? If you just need to remove it entirely, that I can probably add easily, since I already grab the collision object of a nif when I load it. If you need to change some setting on it... eh, it's still probably pretty easy to do. Yeah, I suspect that can make v1.0 pretty easily.

A question for modellers - thanks to some testing by SkyRanger-1, it seems a child node can have more than one of a given property - multiple Material properties, multiple Texture properties, etc - does anyone know how the game handles this? I don't even really know what that means. Is there any meaningful reason for doing this? I guess my question is, should I include the ability to specify the Nth Texture property, for example? Or is it safe to assume that a child node will only have one (meaningful) texture (or whatever) property, and just always use that one. And if that's the case, how do I know which one is the one that the game is going to use?

Also, I'm going to look to do an alpha test soon. But with a lack of mods to test it on, that means that I need scripters to test it - I could write a test script (in fact, have done so), but what I really need is for people who aren't me to try scripting with it, in case they try something I didn't think of and haven't prepared it for. It should fail elegantly (as in, put an error message in NifScript.log, return 0/false for Set functions, and otherwise keep quiet about it), but there's always the possibility of that not happening. I know SkyRanger-1's interested; is anyone else?

Finally, I'll probably also need to test that I haven't broken Unnecessary Violence. If I could get a volunteer who plays the game quite a lot and runs the mod, I'd love to drop off a new version of NifScript once the alpha test starts, just to make sure I didn't break anything in it. HeX_0ff, I don't know what kind of testing you use, but if you've got some kind of automated testing thingy, that'd also be pretty sweet. Just so I can be sure that it will still work if people update NifScript and not UV (can't imagine why anyone would do that, but who knows?)

It's been a while since I looked at it. I'll have to reinstall nifskope and play around a bit. I think it involved changing a couple of specific settings in the nif file, but I can't recall off-hand what type of settings those were.

That's fine, just let me know where you found in NifSkope, and I should be able to replicate it in NifScript.

In other news, my installation of NifSkope doesn't seem to be working. Gives me some error about an incompatibility with my video card drivers. No idea when or why this started; it used to work. I'm using the latest drivers. *shrug* I may try to reinstall it to see if that helps, but in the meantime, pictures of settings in NifSkope you want access to would be helpful.

I can easily give you that info;
here: (from the (edited version by Amorilia) of my first PyFFI spell), its in Python don't know if you know that at all but the class name1(name2) if the item isn't set in name1 it uses name2's settings for it.

    class CollisionTypeStatic:        layer = 1        motion_system = 7        unknown_byte1 = 1        unknown_byte2 = 1        quality_type = 1        wind = 0        solid = True        mass = 0    class CollisionTypeAnimStatic(CollisionTypeStatic):        layer = 2        motion_system = 6        unknown_byte1 = 2        unknown_byte2 = 2        quality_type = 2    class CollisionTypeTerrain(CollisionTypeStatic):        layer = 14        motion_system = 7    class CollisionTypeClutter(CollisionTypeAnimStatic):        layer = 4        motion_system = 4        quality_type = 3        mass = 10    class CollisionTypeWeapon(CollisionTypeClutter):        layer = 5        mass = 25		    class CollisionTypeNonCollidable(CollisionTypeStatic):        layer = 15        motion_system = 7

that's for all the most common types; and all those settings are on the bhkRigidBody - and layer is also on each subshape.

don't know - but if it uses only 1 I would assume that it would use the first one. (otherwise it would no doubt use the last one)... I think you can just say first one.

I'd definitely b interested in that... let me know when the alpha is ready for testing.

unfortunately too busy personally for that :sob:... barely getting in my modding last few weeks.
Pacific Morrowind

Heh, honestly, the NifSkope representation would probably be easier for me to work with. But at any rate...

Do know some Python; the technical term for that is polymorphism.

OK, so... what would you want to do with these? I mean, Niflib probably has all of this too - though the names are different, which is sort of confusing - but what kinds of operations are you trying to perform? These are just some data structures which may or may not be related to what you want to do.


For now, that's what I do.


Sweet. Currently have a bit of a hiccup (see below), but hopefully soon.


Hey, no problem - I know all about that. Heh.

Anyway, hiccup, as promised: When you load a game, the game looks for nif's before my plugin can make them. Even once my plugin's made them, the game has already decided to use the missing mesh marker and you can't change its mind on that without refreshing the model as normal. All kinds of situations where that's not ideal (weapons being the most obvious, but also situations where there are a lot of instances of the mesh in sight - as might be the case with the proposed seasonal changes mod), and I have absolutely no way to do anything about it. I've PMed Scruggs, hoping he has an answer, but I really don't have a lot of hope that he will.

So, what do people think about this? Is this still workable?

Scruggsy is a god and a saint. Problem likely solved; he has to run some tests but he's got a neat solution I hadn't even thought of.

uhm what I meant was that for the types of collision listed you would want to set the bhkRigidBody.%listedsetting% to %listedarg%. Those names are the same as the Nifskope names except no capitals and underlines instead of spaces.

something that I am continously thankful whenever I use any OBSE functions.... great that he was able to solve that issue as well!
Pacific Morrowind

OK, here's what I can do with bhkRigidBodies:

Return Type		Function Name (Arguments)OblivionLayer 		GetLayerCopy () constvoid 			SetLayerCopy (OblivionLayer value)Vector3 		GetTranslation () constvoid 			SetTranslation (const Vector3 &value)QuaternionXYZW	 	GetRotation () constvoid 			SetRotation (const QuaternionXYZW &value)Vector3 		GetLinearVelocity () constvoid 			SetLinearVelocity (const Vector3 &value)Vector3 		GetAngularVelocity () constvoid 			SetAngularVelocity (const Vector3 &value)array< 12, float >	GetInertia () constvoid 			SetInertia (const array< 12, float > &value)Vector3 		GetCenter () constvoid 			SetCenter (const Vector3 &value)float 			GetMass () constvoid 			SetMass (float value)float 			GetLinearDamping () constvoid 			SetLinearDamping (float value)float 			GetAngularDamping () constvoid 			SetAngularDamping (float value)float 			GetFriction () constvoid 			SetFriction (float value)float 			GetRestitution () constvoid 			SetRestitution (float value)float 			GetMaxLinearVelocity () constvoid 			SetMaxLinearVelocity (float value)float 			GetMaxAngularVelocity () constvoid 			SetMaxAngularVelocity (float value)float 			GetPenetrationDepth () constvoid 			SetPenetrationDepth (float value)MotionSystem 		GetMotionSystem () constvoid 			SetMotionSystem (MotionSystem value)MotionQuality 		GetQualityType () constvoid 			SetQualityType (MotionQuality value)

Giving access to these is likely not very difficult. Anything else could be.

Update!

Getting and setting the local transform/translation/rotation/scale of child nodes seems to work. Haven't actually tested transform because I haven't the foggiest idea what it's supposed to look like. Setting the rotation hasn't seemed to do very much but then I'm not certain that the numbers I plugged in would do much of anything, really. Not certain. I hope those of you looking to fiddle with those are up on your linear algebra...

Anyway, also have successfully gotten the name of a child's material node. In the particular case in question, it came out "5 - Default" - not sure how useful that is, but it is what it is. Hope you can use it. Haven't gotten as far as setting it - does anyone actually want to do that? Also, side note - some of the Niflib documentation confirmed that a "valid" node should never have more than one of a given property. I won't be supporting any "invalid" nifs, then, and what happens if you have one is explicitly undefined.

I'll poke the texture stuff some this week, and then I'll send out the alpha. I wanted to wait for Scruggs fix on the loading issue, but he's been very busy and I figure this kind of testing, at least, should be pretty trivial even with that bug. Updating for the new code shouldn't be too hard.

I've also confirmed that my changes to the code have broken NifScript for Unnecessary Violence. I'm going to have to rewrite those functions to work with the new system. This is disappointing, since I really wanted to never look at those again, but I'm not going to break backwards-compatibility. I fear a headache, honestly.

take your time, you're doing something incredible

HeX was rewriting a lot of stuff for his new version of Unncecessary Violence.

Yeah, I know, but I can't rule out people upgrading NifScript without updating UV. Or the possibility that other mods use those functions without me knowing about it.

Any known mods exist that add just the dual wielding support from NifScript other than UV? Is it pretty difficult to create a mod just for this function?
I'm not happy with the current dual wielding offerings on TESNexus. http://www.tesnexus.com/downloads/search.php

Thanks

I seem to recall the when DW first released NifScript, he also produced a PoC plugin that had basically the functionality you're asking after. Out of curiosity, why not just go for UV?

cool! would be great to get a hold of that basic scripted mod you mentioned. I find UV to cumbersome and I have the rare nvidia freeze bug mentioned in the readme. I wasn't impressed with the sneaky .ini activation either. Actually turned me against the mod right off the bat.

Well, you're welcome to make the mod if you wish. I'm not; I quite like HeX_0ff's work, and the INI activation is necessary to protect your savegame, so while the snarkiness is a bit over the top, it's a good measure to put into place.

Making a mod that allows you to stick a weapon in your off-hand to be used as a shield should be pretty trivial (yes, the Proof of Concept plugin did this much; no, I won't be releasing that again - it's an awful, buggy mess, and you do not want that thing running in a savegame you care about - it will cause bloat and very likely cause items to disappear). Doing anything more than that is fiendishly difficult, which is why Unnecessary Violence is such an excellent mod.

i'm curious will yo u be fixing the crash bug related to switchign weapons to off hand in UV ie switching blades that use Vanilla meshes to off hand causes a CTD

Thanks for the reply DragoonWraith. To bad the PoC mod is buggy. If it weren't for the terrible crashes and freezing I experienced after using UV, I might of taken more time to get acquainted with all the controls, but my game would never hold up long enough. Maybe after the next UV release, I will try it again.

Wasn't aware that changing the .ini value added save game stability. It's just that the mod was already complicated to begin with. It felt almost like I was being punished for not knowing enough tech to install a mod. Not really appealing to a player. Maybe for a modder. Oh well, I'll watch for the update.

According to HeX, that will be fixed in the next UV release, along with shield-on-back functionality across the board and lots of other fixes... for any more news, he'd be the one to ask. Though DW might know, it's not his mod, and he's not the one responsible for keeping track of it

It depends whether or not that bug was due to what I was doing or not. If HeX says he's fixed it, I'd lean towards it not being something I'm responsible for? But I'm not really sure.

That, or he's assuming that I will fix it for the next release. He seems to be assuming he'll be able to do shields-on-back, which I'm pretty sure he needs the new code for... Though yes, once he has it that should be trivial I think?