haama's the current curator of Cobl, if I recall correctly.

Are there really that many different models for alchemy equipment?

I'd think with a limited number of meshes to deal with, it would be easier to provide pre-modified meshes than to introduce a Nifscript dependency to Cobl.

That'd be a good fallback for players who don't have NifScript, but a driving design goal behind all Wrye's stuff is extensibility and interoperability. I think it'd be in the spirit of Cobl for it to work correctly with all alchemy equipment, even ones added by mods.

Yup, if I can get Showler's thing working, then you could also do this. Feel free to e-mail me ( dragoonwraith [at] gmail.com ) if you're interested in the alpha. That goes for everyone. Showler, I got your e-mail, so you're good.

It's remarkable what you achieved so far! You're doing a damn good job on this.

Just a question out of interest, because I've seen the many new functions like accessing nodes' children and removing them... would it some day be possible to also "add" child nodes? Nothing fancy, rather like opening one NIF file as the source and another as the target and then "merging them" in an automated way. Of course one has to require the armature NiNodes needed for this are all present, else the function will fail, as NifSkope does when you didn't transfer those nodes prior to the NiTriShapes/Strips you're really interested in.

It would be the same as we all can do already the manual way via NifSkope. But being able to let your scripts do that during runtime would improve not only my own mods.

So is this possible, maybe in the future? Or is it just too much to even consider currently?

I'm planning on doing that, yes. I'm pretty sure it's possible. NifAddChild would be in this, except that there's just way too much to do to set one up from scratch.

I've been watching the NifScript project with interest, but I don't think it would warrant being added as yet another dependency for Cobl for this particular instance. I'm sure that there will be other innovative reasons to consider including it later on though.

Cobl provides two modes for static alchemy items. One with OBSE enabled, and one without OBSE enabled.

The OBSE enabled version uses the copymodelpath function to copy the model path. When I coded the scripts for that portion, I did mean for the player to be able to pick up and move the objects around. They were stationary in the fact that you couldn't pick them up into your inventory, not that they couldn't move at all.

The non-OBSE enabled version was more interesting to implement since I'm a scripter/coder, but had to do some actual modeling. I went through a bunch of scripting options that worked, but were flawed...ultimately I created new animated models. I merged each of the standard apparatuses levels (apprentice through grandmaster) into a single nif, and switched between them with different animation groups using a vis controller. For the empty stands, I just removed the glass portion of the apparatuses, and merged a pestle with a piece of paper for the empty mortar & pestle. For these, they are all immobile. I meant for the two options to be available to the end modder to choose between.

I provided the models and scripts to haama, but I don't recall exactly how he implemented them. I don't know if the OBSE version is automatically used if OBSE is present, or if the modder was allowed to choose which version to use. Really, the non-OBSE version worked out so nicely that I personally use a custom version of it in my games.

So, what I guess I'm saying is that this might simply be solved by using the non-OBSE version of the scripts. This might mean getting haama to change the scripts slightly so that the OBSE version isn't automatically used. I coulda sworn though that the modder was allowed to choose between the two modes :shrug:

I'm surprised: it sounds like you're saying that what I thought was a bug is actually a feature. Given the limitations of Havok and the Z key, I'd actually prefer that the objects be immobile; otherwise there's not much difference from just putting regular alchemy equipment on the table and using http://www.tesnexus.com/downloads/file.php?id=5478.

As far as adding a NifScript dependency to Cobl, I figured the new code could be put within IsPluginInstalled/GetPluginVersion checks so that the dependency is completely optional. If it isn't, degrade gracefully by using pre-made immobile models for the stock equipment and just using CopyModelPath (the way it currently works) for mod-added ones.

The UESP page I linked to in my previous post doesn't mention any way to choose the OBSE or non-OBSE implementation, but I'll have to take a look at the scripts sometime to see if it's there but just not documented. If I can switch to the non-OBSE implementation, that'd work for my own preference, but I still think it'd be fun to try doing it with NifScript.

Well, it's a feature that was a bug. Or, a bug that was a feature. I liked the idea of the player having some say in where the alchemy set was placed, so I wasn't concerned that the CopyModelPath affected havok. I couldn't do anything about it anyway. I realized that it had its limitations though, so I made the non-obse version to be immobile. It was all about choice.

I just glanced at the COBL script and didn't see any way to choose the implementation. It's pretty heavily changed from what I submitted though, so haama would be the best person to ask. It would be extremely trivial to add a customized script that only uses the non-obse approach. Just strip out the OBSE check, save it as a new script, and let modders choose to use it.

You're right that it could be set up with the IsPluginInstalled check. It certainly wouldn't hurt. And, the fact that it'd be fun to do is always a good reason to mess with it :hubbahubba:

Considering the possibilities that NifScript open up, I'd be surprised if Cobl didn't use it at some point regardless.

Is it me or does niflib doesn't offer a way to do a switch on node->GetType()?
Apparently it returns a class, why didn't they make it an enum?

DragoonWraith if you have any tips working with this lib I'd welcome them, I'm quite confused at the moment .

edit:
Ok and is it me or is it VERY slow(and buggy)?
Trying to open rockgreatforest970.nif(apparently takes a few seconds to parse...):

Error: End of file reached prematurely.  This NIF may be corrupt or improperly supported.Last successfuly read object was:====[ Object 6 | bhkRigidBodyT ]====

I think I may end up recoding my own parser for this...

Hmm - what are you doing with Niflib?

At any rate - I have found Niflib excellently done, fast, responsive, and stuff just works as expected. The documentation is incredibly thorough. I can open several nif's per frame while running Oblivion without noticeable slowdown.

GetType() returns a class because it has member functions that are reasonably useful - GetTypeName(), IsSameType(), and most importantly, IsDerivedType(). Also operator<(), but I'm not sure what that's there for.

What's your code for opening the Nif?

I just made a quick thingie to test it:

void Load_Mesh(){	unsigned long index;	NiObjectRef root=ReadNifTree("rockgreatforest970.nif");	NiNodeRef node = DynamicCast(root);	if(node==NULL) throw L"Error casting first object...";	vector refs=node->GetChildren();	for(index=0;indexasString() << endl;	}}int _tmain(int argc, _TCHAR* argv[]){	try {		Load_Mesh();	}	catch(exception &e)	{		cout << "Error: " << e.what() << endl;	}	catch(...)	{		cout << "Unknown Exception..." << endl;	}	return 0;}

You should include the optional Niflib::NifInfo second argument in ReadNifTree; I don't think that's what's causing the error but without it you will not be able to save Nif's correctly (you just pass it to ReadNifTree, and then hold onto it until you pass it back to WriteNifTree). I assume "rockgreatforest970.nif" is in your working directory? Have you tried passing the full path just to be sure?

Also, what's the L in the throw L"Error casting first object." line? That looks... wrong. Again, probably not the source of your trouble.

I don't want to save nif files, just read them(it's for my oblivion renderer).
Yep it's in the active directory(it reads it up to a point as the exception indicates).
The L indicates wide char string.
Just forgot to add catch(WCHAR *wcharexception) in the exception catch list(just used it as I use it to throw critical errors around in my renderer, force of habit).
I can't believe I implemented havok to get stuck on this...

I tried to add the NifInfo just in case and got the same error...
Ok just realized that the lib I grabbed may be outdated, grabbing the current version through svn...

edit:
Alright, used the last revision and it worked just fine .

Oh, well that's good! Glad to hear you've gotten it working.

On the NifScript end: I want to do a bit of refactoring, as currently I'm maintaining vectors of pointers (actually Refs, which are a type of smart pointer used by Niflib) to the various sub-nodes of the root, but if the list itself changes (i.e. adding or deleting one), I need to refresh the list - and honestly I think it would just be easier to keep using their lists. Unfortunately, the ExtraData list is a List, not a Vector, which... kinda svcks. Still deciding how i want to use that.

Feature request:

Ability to switch between Normal-grip and Backwards-Gripped mode (AKA "Starkiller" or "Galen Marek" mode)

Not sure what kind of useage it would get, but it would be a good feature to have nonetheless.

That... means absolutely nothing to me.

I assume you mean Normal versus Reverse grip - and that could be done with the rotation functions. However, doing so may not look right on some weapons, and definitely won't look right with the attack animations.

Yeah... reverse-grip is exactly what I meant. I'm not sure what the actual name for it is called.

Wikipedia says Reverse Grip is what it's called. *shrug*

Anyway, status update is that I've been a bum and haven't done much with this recently. I think it's time to call it quits on adding features (I'm just going to remove NifAddExtraData for now; does anyone even want that?), and send out the alpha this weekend, I think.

And for those who have this bookmarked or whatever: http://www.gamesas.com/index.php?/topic/1089336-alpha-nifse-v10/.

We'll shut this one down then.