DragoonWraith, if you could return an array of the uv co-ords, a way to edit these and provide a way to set them again, that'd be awesome. :goodjob:

The recalculation of uv co-ords for what I want to do is straight forward (high school maths) once you can get and set the actual values.

Can't wait

Thanks for your reply, sounds awesome, we really hope you will get to this at some point!

Does this mean it would be possible to edit the *.kf on the fly ingame, just like the *.nif files? That would make dynamic animations possible, which is exactly what we want to achieve.

"A way to edit these"? All I was planning on was dumping them on you in an array_var and letting you handle any edits you want to make.

At any rate, definitely not happening until OBSE plugins can accept arrays as arguments, which they can't at the moment. Scruggs had mentioned a possible temporary work-around, so I'll ask him about that, though.


Yes, in theory, .kf files would be accepted and would work. Actually modifying the animation programmatically will be astoundingly difficult to do, in practice, though.

Update: NifSE v1.0 α:4 is now available on http://code.google.com/p/nifse/. This version fixes the deprecated functions to use the new system, removing the harddrive clutter they used to cause. I don't have any savefiles with existing models from those functions (i.e. using UV), so if someone who is actively using UV could test them, I'd appreciate (just install the new dll and see if it works through saves and stuff - please make temporary saves for testing!).

For those who missed NifSE v1.0 α1.3, which was available only through e-mail as it involved a pre-release build of OBSE v0019, the issues of loading meshes is also eliminated; meshes will work straight out of a load.

α:4 does not include any new functionality, merely eliminates those outstanding bugs. Changes to the way nif children are accessed (to match how it looks in NifSkope, hopefully) are next on my list, and when that's done I'll be releasing β:1. I'll look into the new requests (alpha, collision, etc) after that.

Also, for those who have noticed that the switch from α1.3 to α:4, I've changed how I'm storing the version information; the current version is 0x00010004 - 0001 is the major release, 00 is the minor release, 0 is the beta version, 4 is the alpha version. Non-alpha versions will have an F in the alpha place, and non-beta-non-alphas will have an F in the beta and alpha places. Long and short of it is that every later release will always have a higher number than those before it.

EDIT: Change of plans - there will be an α:5. Because I'm going to do a pretty thorough consolidation of functions... there's going to be a lot of change between them. Suffice to say, this system makes a lot more sense.

Thank you DragoonWraith for NifSE v1.0 α:4

PS: TESCS Wiki - http://tinyurl.com/TESCS -> this link is broken

Has anyone tested the old functions yet?

Anyway, thanks for that note on the broken link; I've replaced it with one that works.

An update: I've completely rewritten almost every function to change how NifSE interacts with the blocks in a Nif - it is now possible to refer to any block in the Nif, which means that the functions can much better support the underlying structure of the Nif. This will break all scripts from alpha 4 and lower, and it will not correctly load old .obse co-save files, either.

Also, cuz it came up - I've figured out what I'm pretty sure was causing crashes in the NifScript beta that UV used - at a guess, the meshes that caused the crash didn't have Prn nodes (or failed to load for some other reason), and then because of the way the functions were structured, no string was returned to the calling script. What I didn't realize at the time (but have since learned) is that a function that can return a string must always return a string. So now on a failure those functions return " " (returning an empty string didn't seem to work either).

Finally, alpha 5 is being delayed because I'm having some trouble with my nif-writing function - I can load up nif's, and the changes to the functions all seem to work just fine, but then when I write the nif again, Oblivion can't load it (nor can NifSkope, for that matter; I get an error message about the header being messed up, which is... very confusing, as I don't touch that at all).

EDIT: Solved that problem. Argh, that was several wasted hours.

The fates conspire against me.

I'm pretty sure my video card just died. It's over five years old, so I'm not overly surprised, but really?

I got a ton of graphical corruption, and then the screen went blank and I got my monitor's "No Signal" notice. I restarted the computer, saw the same graphical corruption on the BIOS screen, it goes to the Windows loading screen (the one with the blue bar going across the bottom repeatedly), and then it goes to the "No Signal" message again (after about as much time as it would typically take Windows to load). Seems it can't handle any graphics more intense than the (16? 32?) bit graphics used by the Windows loading screen. One worry is that even with the video signal not going out, I would assume it would still load - but I never hear the Windows startup sound. Not sure about that.

Going to try my brother's video card after he finishes watching... whatever it is he's watching. Hopefully he'll let me borrow it for the night so I can finish alpha 5 - I've tested about half the functions so far, and it seems so far, so good. Some weirdness with type derivation, but that should be a minor function for most applications. Or not. His video card has a 6-pin and 8-pin power connectors; my power supply only has the 6-pin. Argh.

Anyone familiar with video cards has any ideas on other things I might try, please do let me know.

Bake it. Sounds insane, but I fixed my 8800GT that way.

http://hardforum.com/showthread.php?t=1421792

It should give your card around 6 more months until it dies for good.

Well, it's getting thrown out anyway if I can't fix it, so I'll keep that in mind. For now, though, uh... I'd like to leave that as a last resort. I didn't freeze my harddrive, either, and I'm generally pretty pleased with that.

As an update: It's definitely the video card - if I boot into Safe Mode (i.e. continuing to use 16-bit graphics, assuming that's what those are), the computer works just fine, other than, ya know, being in Safe Mode (frustratingly, this so far has precluded my attempts to get NifSE off of it so I can continue working on it on my family desktop - Safe Mode doesn't seem to register my USB ports and I know it doesn't turn on any networking), but Windows proper causes "No Signal" from my monitor and booting into PartedMagic (Linux-based OS for harddrive diagnostics that I have from the HDD troubles) causes the screen to stay black (well, plus random graphical corruption) after it's done loading (never goes to "No Signal" though, which is weird for it to be in limbo like that).

It's definitely screwed.
Do you have a keyboard that uses a PS/2 connector? It should register in safe mode.

Huh. Come to think of it, my mouse and keyboard did work - and they're both USB. I dunno why the harddrive didn't... maybe I should try that again.

EDIT: Hey, lookit that - Safe Mode with Networking. And SVN works. OK, now all of alpha 5 is on Google code's SVN repository, which makes a quick checkout on my other computer trivial. Hey, I can actually work on this tonight! Very nice, thank you for that, Alex.

NifSE v1.0 a:5
Download on http://code.google.com/p/nifse/

This alpha version has seen massive refactoring, allowing NifSE to better reflect the underlying structure of nif's. This also makes the functions far more flexible, opening up new features that were previously unavailable (accessing sub-sub-nodes, for example). Because HeX_0ff has a vested interest in NifSE going to beta as soon as possible, and I've decided that b:1 will simply be a:5 after I get some 3rd-party testing done on it, I am releasing it now before I've documented everything on the Wiki.


Because of the lack of documentation and the substantial changes made to NifSE, this alpha is really, truly a test version. Those of you who have been working with the alphas, I expect you'll be able to do very little work on your own mods with this.

If you would like to help with NifSE, please install NifSE and the example plug-in, and allow the example plug-in to run its script (you'll get a MessageBox saying "Running NifSE test." or something to that effect). Try equipping the items that it gives you, try drawing them, and trying saving with them drawn and then loading. When you've done all that, please send me obse.log, NifSE.log, and if you have ConScribe, I'd love to see the log for that game session as well. This will allow me to confirm that NifSE is working on your machines as well as mine. If you experience a crash, please note which type (generic "has caused a problem and has to close", or something more specific like an index out of bounds runtime error), and still send me those files (my username at gmail).

Once I've received a few reports of successful operation and I've finished documenting all of the changes, I'll be rereleasing this as beta 1. At that point, everyone's going to have to do some rewriting; I do apologize for that, but these changes were very important to the future of NifSE.

The save crashes on load for me. I get the sound of a message box popping up - but then CTD. I got a ConScribe log, but not sure about the obse.log and NifSE.log - I can't see any files named like that in the OBSE folders at least.

ConScribe says:

hook mode 1: using main GetTickCount callcrit_sec_mode 2MemoryHeap Optimization Mode 0: Not optimizing MemoryHeapcritical section b32b80 overriden to spin 1500critical section b32b80 overriden to spin 1500Special crit. sec. 1 (@ A001210, thread 2E4) spin 2000 -> 2000Special crit. sec. 2 (@ A0011C0, thread 2E4) spin 1000 -> 1000Special crit. sec. 3 (@ C008B10, thread 2E4) spin 4000 -> 4000initialize2() running in thread 2e4Suppressing CRITICAL_SECTION Renderer+0x180 (18A076F4)===============================================Game Instance : 1 | Time : 08-26-2010 23-35-45===============================================Special crit. sec. 4 (@ C15BDE0, thread 2E4) spin 4000 -> 4000DW\NifScript\BearPelt.NIF

obse.log and NifSE.log should be in your main oblivion folder.

Thanks - and that explained the CTD as well. Was using OBSE 18...

I'll email results now that I know where the logs are.

NM

Huh... I'm surprised it crashed, though - with v0018, NifSE wouldn't have loaded, which meant the script should have just halted the first time it hit a NifSE function. Huh... Ah well, that's not really my problem. Responsible modders should be running checks against that kind of thing; the test esp wasn't really made 'responsibly' since it's just a test.

Anyway, checking me e-mail now.

Huh; I have an e-mail from Alex but not from you Arkngt. That was sent to dragoonwraith [at] gmail.com ?

EDIT: Anyway, Alex's e-mail showed at least one obvious error in the example plugin that I've fixed. There's also another error apparently with zlib. Argh. Looking into that.

EDIT2: Alex's problem seems to be related to his BSAs, which he recreated to use PyFFI'd meshes. A difference in compression apparently? I need to look into that... but that's honestly way outside my area of expertise.

Sorry, should have mentioned that I postponed the test until today as it was very late. Anyway, check your mail. I noticed no issues whatsoever ingame.

OK, between Arkngt and Alex, I'm fairly confident that the alpha works as planned. Thus, as soon as I get the documentation up (ugh, that's intimidating), I'll be releasing this as a beta.

Alex has found some issues with his re-packed BSAs - he PyFFI'd the meshes in Oblivion - Meshes.bsa, and then used OBMM to repack them. Something is getting messed up there when NifSE tries to read them - but Oblivion figures it out. I think the meshes are not compressed but their compression bits are set, leading to NifSE trying to decompress the uncompressed files, and failing. Which is very odd since OBMM and the code I'm using were both written by Timeslip, who knows about as much as anyone out there about BSA files. Anyway, I'll try some tests and I have at least one idea for fixing this.

I am reasonably certain that PyFFI'ing the meshes had no impact on their compatibility with NifSE; this is purely a BSA issue.

With thanks to AlexKapi, here's alpha 6 - no new functionality, but it should now read BSA files that have incorrectly-set compression bits. This should fix Alex's problem and hopefully avoid problems for others with similar BSA files.

That fixed my problems. No errors appear and everything now works fine.

Good, glad to hear it. I'm working through the documentation; probably about half done there.

The beta is released! http://www.gamesas.com/index.php?/topic/1114745-betarelzwipz-nifse-v10/