Hey, I was wondering if you've seen http://www.gamesas.com/bgsforums/index.php?showtopic=861565&hl=.

Did you have any success fixing this?
Any hope for a soon update?


LP

No need to apologize, at all! This is all a learning experience for me - pretty much all of the C++ I know (beyond the intro course I'm taking) is from this project; I'm learning as I go along. Without this post, I probably never would have learned what the << operator did on ints like that.


No, I hadn't. Looks like he's doing things differently, but with similar effect. His is probably better (you're changing things in memory instead of creating a bunch of new nif's), but I suspect it's also much more difficult to write. This utility may be able to provide functionality more quickly than his can.

If at any point in the future, both of our utilities provide the functionality you need, you are almost guaranteed to be better off with scanti's, from what I understand.


I have literally spent the last week bashing my head against the BSA reader, going to rather extreme lengths to try to determine what was wrong with it.

Finally, during some testing last night, I stopped and read my debug print-outs more carefully, and realized that I had made a very, very dumb mistake while updating it to link zlib statically instead of dynamically. I had changed my list of BSA filenames to include the path, but had forgotten to change the BSA read function to stop including the path - so I was adding the path twice. Obviously, the BSA reader couldn't read what it could not find. This problem existed only in my version; the one currently available does not have this problem. Talk about shooting myself in the foot.

Much thanks to Scruggs, behippo, and Timeslip for their advice, suggestions, troubleshooting, and above-all patience with me as I tried to figure this out. And many apologies for wasting their time with such a stupid problem that I should have caught myself in the first place.

Now, as it turns out, there was a problem with certain BSA files - when I tried to copy the file into your folders, I didn't create any of the directories - I assumed Windows handled that for you. Turns out, it does not. I added a little bit of code to create any folders that you don't have, and voila, it works! Any BSA'd meshes whose folders did exist still worked - which is why the Iron Longsword I tested on worked, I already had a Weapons\Iron folder for other models. I did not have, for example, a Weapons\Club folder, for Club.nif, so when I tested the Club I very quickly realized what was wrong and fixed it.

I'm currently updating the tagging system to be (much) more robust, and I'm updating NifGetOffHand to return the model as a Torch instead of returning it as a Bip01 L ForearmTwist with a translation/rotation. Works much better, or so I am told; haven't tested it yet. The mesh is still used as a Shield in the CS, though, so the implementation should not change for any scripters who use the function (are there any? I know opaj was working on a better version of the demonstration plug-in, but I haven't heard from him in about a week...)

The updated version will be available probably tonight. I have two finals tomorrow though, so I may not have time to do all the testing I want to do tonight, in which case it will be tomorrow night.

After that, I can finally get working on those requests. Most of them should be available pretty soon.

Good to see this Plugin still being worked on.

Oh yeah, I'm pretty much always working on one of my projects, unless I'm busy with school. I just tinker too much and have a horrible weakness for scope creep. At least this is a project which really lends itself to incremental releases.

Update: New version up. No new functionality, other than that it works (well, and the tagging upgrade and the change to how off-handers are handled). After I get some confirmation from people that it functions for everyone else as it does for me, I'll upload it to PES and ElricM too.

I had just finished read the thread. Really fascinating what you could do with OBSE oo: Really makes me brush up my C++ skills :read: I suppose I owe you a thanks for that. That being said, this plugin really opens up the modding scene. This is as much revolutionary as OBSE it self ...

Looking forward for updates ... and well done

Thanks.

I'll probably have Low Post's request done before Christmas.

:o :celebration: :drool:


How will you call these commands?
*wants to start scripting right now* ^_^

[reference.]NifGetBackShield [ref:shieldObj] sound good? It would apply the change to Prn, and the translation and rotation from the model you sent me, to any shield that you pass in as the argument (OBSE standard reference or object syntax).

Alternatively, depending on how things look tomorrow, I might just put NifSetPrnNode, NifSetChildrenTranslation, and NifSetChildrenRotation (plus NifSetNthChildTranslation/Rotation).

If I use the latter, there's also going to be something like "NifEditStart" and "NifEditStop" (maybe NifEditCancel, too?), so that I don't create three new meshes when you do three different things, just the one mesh.

Sounds good.

If you use the latter, could you please tell me which values I'd have to use. I still don't understand where to search for the right value. :unsure:
To be honest, I don't really want to understand where they're located and what they mean.

By the way, I'd call it "NifEditFinish", instead of "NifEditStop". Seems more logical to me.
An a "NifEditCancel" is not necessary, but wouldn't hurt to have one.

Well, Set functions generally return True (1) when they work and False (0) when they don't. In theory, you could call them in a set command to store that value, test it, and if it failed for whatever reason, you could cancel, preventing the creation of an incorrect mesh.

In general, though, most of the kind of thing is done on NifScript's side anyway.

As for where those values are found, in NifSkope, if you hover over the Rotation values, a tool-tip pops up with the correct values.

The rotation of any NiAVObject is stored in a 3x3 matrix, which is really 3 unit vectors - one for x rotation, one for y rotation, and a third for z rotation. Like this:

| x1  y1  z1 || x2  y2  z2 || x3  y3  z3 |

Because they're unit vectors, the magnitudes of each is 1:

sqrt( (x1^2) + (x2^2) + (x3^2) ) = 1sqrt( (y1^2) + (y2^2) + (y3^2) ) = 1sqrt( (z1^2) + (z2^2) + (z3^2) ) = 1

What this means is you'll need to input 9 floats into NifSetChildrenRotation. In NifSkope, again, this matrix is displayed when you hover over the rotation field.

The numbers in NifSkope that you actually enter, which you can set to Axis or Euler, are ways of representing those matrices, but I'm not going to bother converting things; it's easier to just have the one. Especially since I don't actually understand precisely what those representations mean.

Finally, I found them.
Thanks for your patience.

OK, here's a dumb problem - I have a NifGetBackShield, but I have no idea if it worked correctly, because I don't know how these meshes are supposed to be used. Low Post, if you're around, wanna PM me an e-mail address so I can send you the current version of NifScript so you can test the function? I don't actually know how to test it, I don't know how the armor is set up in the CS and stuff.

Also, I wasn't certain how best to apply translation and rotation - should I add them on top of the translation/rotation the item already has, or should I force the values to the ones in the screen shot? Currently, I'm doing the former, though I suspect the latter may be what you actually want - hence needing you to test.

Super-cool project there, dude! :thumbsup:

Adding/removing/cloning NiGeometry objects in nifs on the fly would be a pretty awesome thing, especially if it could be applied to skeleton.nifs. Imagine all kinds of animated nodes (maybe particle systems, too) appearing on your body once you equip certain things (like the Orb effects for hero units in Warcraft III if anyone remembers those, heh).

I've also done quite a bit of tinkering with nifs and (to some extent) Niflib (no idea about OBSE's plug-in API though), so I'd gladly offer some help should the need arise

RegardingI'd say you should allow both options, in some cases absolute transforms are preferred where in other cases incremental ones would be less of a hassle.
E.g. in case changes applied to nifs can be made to display instantly in the game you could do some sweet scripted transform animations on meshes. Being able to use incremental transforms would save you from doing some extra math to translate those to absolute transforms.
In the end it doesn't matter much, so I guess you could file it under 'convenience feature', just my 2 cents

X.

Pretty sure no changes to Nif's are going to update immediately... I suppose perhaps in some cases with Disable/Enable, but I'm not sure about that.

I had sent a PM to the OBSE crowd about a possible change to how I handle changed Nif's, but they haven't gotten back to me on that. Since it will affect how Nif files are/are not saved, I'm somewhat hesitant to continue with this project until I have more info from them.

But X, seriously, any ideas you want to throw my way, I'd love to hear it. I don't know what features would be most desirable, really.

Since a complete implementation of Niflib into Oblivion's script engine to create whole nifs from scratch isn't exactly feasible I guess one should concentrate on some 'core features' that are often used in apps like NifSkope.
Those would include among others:

• copying/pasting/cloning branches
  
• editing node transforms
  
• changing node properties (material colors, texture paths)
  
• toggling certain flags (most importantly visibility)

That said, you'd need some nif tree-walking functions to get to those specific parts, maybe stuff like getNiNodeByName, getNthChild/Property, get/setFlags, etc. etc.

Copying/pasting branches and/or applying animation sequences to nifs dynamically could allow for a multitude of interesting effects. Imagine a different take on enchanted weapons; instead of receiving some generic ShaderEffect you could let a script handle nif manipulation based on the type of enchantment, e.g. adding an animated torch flame branch or some other pre-assembled effect branch a modder would provide for those purposes.
Or simply variations of generic items, e.g. ethereal stuff (like in Diablo 2) with modified alpha values, objects with increased scale ('150% size Iron Dagger? Hell, yeah!') or even modified shape if you consider adding manipulation functions down to the vertex level (e.g. randomly dented surfaces, elongated blade parts and the like)

X.

Ethereal was one that I'd actually intended to add, since I want to put them in ARES at some point. Unfortunately, in playing with the opacity in NifSkope, I found that weapons don't behave consistently - they'll be transparent at first, but eventually they'll suddenly become opaque again, and will stay that way until you refresh the model (sheathe/unsheathe or unequip/equip), which is frustrating.

Anyway, yeah, the rest I will look into. Need to bug the OBSE guys about an answer to my question.

OMG, man. I can't believe I missed this until now. This is amazing stuff, man. I can't wait to see what comes out of this project. :bowdown:

Ah, I think this could be a texture issue. A lot of the vanilla textures are saved using the DXT1 compression format which doesnt feature an alpha channel.
Trying to manipulate the material's alpha values like this is rather glitchy; re-saving the texture using at least DXT3 compression (which'll probably double the file size) and adding a NiAlphaProperty to the mesh node
produces better results (not without flaws since the engine's alpha transparency implementation is rather glitchy in general) :shrug:

X.

I had to add the NiAlphaProperty to the node, but then manipulated the Alpha value in the NiAVObject node (IIRC that's where it was), which worked sort of ok at first (as described).

Messing with the texture's a lot harder. Conceivable, but much, much further away. I have found a C++ library (LibSquish) for it (since yeah, I am interested in going there), but I haven't even downloaded it, much less attempted to use it.

CLS mentioned something about being able to change textures on the arrows in the Craftybits forums.
Or mabye it was dewshrine..
"Swapping out a texture for the default will lower how many meshes we will need to make"


Although now that Im thinking about it they may have just been talking about skinning the arrows 20 differant colours X-x
Might be worth a look for you dragoon
http://thewormhole.nfshost.com/forum/index.php/topic,1446.0.html

Definitely could be. I will look into it, but there's a lot of work I need to do on NifScript's back-end first, because I don't like the way files are handled currently. It's going to take a bit of testing to see how Oblivion reacts to what I want to do.

And, unfortunately, at the moment, I can't open NifScript because I cannot install the Windows SDK that you need for it. I've been focusing on ARES for the past couple of weeks, because I was also waiting on a response from the OBSE team about what I want to do with NifScript, so I'll have to renew my efforts to get the SDK working.

I agree with NRN R Sumo1 & Sjors, a texture-swapping ability would be most useful. I also help out occasionally at the Craftybits forums at The Wormhole, and I recently made an animated loom that is set up like a creature. I initially wanted to try doing a texture flipping animation (like what I saw on the Flame Atronach), but found I couldn't get it to work (the Flame Atronach's texture animation does not work in game neither, come to find out). So I used togglecreaturemodel instead, with the fabric part of the loom being different meshes with different colored fabrics to toggle on and off. But a texture swapping feature *might* save on scripting and eventual file size usage, just maybe...*wishes upon a star*

But yeah, awesome work you're doing here!

Koniption

Oh yes, changing the texture paths would be such an enormous boost to the current mod I'm updating. Just hoping this project isn't out of gas. :shocking: