Hmm, I'll take a look when I have more time. But IIRC, there was a similar discussion a long time ago and scruggsy had some say in it.

You asked who? :frog: Anyway, it shouldn't be very hard to add in general, so expect it... probably not the next beta of NifSE, but probably the one after.

As soon as I saw that you responded to this thread, I said "Oh no" :blush: Well, both of you guys have been around forever, so you're interchangeable Sorry 'bout that.

Would you add it to NifSE though? I ask because this seems to be part of the base CS, not NifLib. I don't think you even need to load a NIF to get it. GetDimensions, yes, but this one, I'm not so sure...

Considering there are only 3-4 required files and they all go in the same folder, probably not.

No, you don't have to though doing so doesn't really hurt anything.
If you're just reusing the same string_var to hold different strings you basically don't have to worry about destroying it. Menumode vs. gamemode makes no difference. There isn't really a concept of 'variable scope' in the scripting language.

Yeah, mostly just to say that having a single value to represent 3 dimensions didn't seem hugely useful.

Bounding box dimensions are easily accessible in the editor, not so much at run-time except for actors. I will need this info soon for some planned functionality so there's a good chance it'll show up in 0020. If necessary we can calculate it from the .nif the way the editor does, but it seems reasonable to think that it might be available at run-time e.g. on the havok side.

Great, that'd be fabulous. In my case, I'm just looking for something that will allow me to categorize items - sort of like "small", "medium" and "large". Therefore the single value of size works. Others may find it more useful to get the specific dimensions, but I would imagine that this would get quite difficult with complex collision meshes. So once again, that's where the single value helps. Guess it all depends on what you're doing with the data...

I was referring to GetDimensions. I thought these were roughly the same thing?

There's a size column in the object window of the CS. I was asking for a function that would retrieve this value. The size seems to be derived from the dimensions in the NIF, but it's a single value.

Here's the example I posted previously:

For example: folio04.nif
Dimensions of bhkBoxShape: x=1.5344, y=2.3025, z=0.4552
Minimum size: 0.4552

Size in CS: 19

I don't know how the CS determines this value, but it seems to be quite reliable if you want to classify objects by size. I used it previously to assign prices to the paintings I added to Imperial Furniture Renovated. I did this manually - not in a script or anything, of course. So for me, having a single size would allow me to classify items. Then I could use GetDimensions from NifSE to do finer manipulation of their position.

Also, size seems to be a reliable value even with complex collision. GetDimensions only works for simple box collision. I'd imagine you'd have to get the values for all the vertices for more complex collision - I haven't looked at what NifLib has for this.

Niflib can return each vertex's position as a 3-vector, from which you could calculate the volume of the mesh by hand if necessary. Be difficult and time-consuming, though.

It appears that the CS pulls the Size attribute from the TESModel base of the bound object. Haven't located where it gets populated yet but it is stored in TESModel::unk0C. TES4Edit identifies the attribute as the mesh's 'Bound radius'.

Yuck! I've actually editted vertices manually in Nifskope (yes, I'm a masochist). Looking forward to these functions being added to OBSE and NifSE :wink_smile:

So you're telling me that it's tantalizingly close, but I can't get at it, right? I see what you mean by bound radius though (it's labelled MODB - Bound Radius in TES4Edit). And this is set even for items with simple box collision, like books.

Quick request (which, knowing my luck, won't be possible because of X reason):

SetWaterInCell (pretty obvious what it does, but...) - essentially ticks off if the cell (interior) has water in it or not. Purge Cell Buffers / etc would likely be necessary to call after.
SetCellAsixterior - turns on the cell behaving as an exterior.
SetCellClimate (also pretty self-explanatory) - changes the climate for the given cell.

My guess is that, knowing Oblivion, these things will be hard-coded into the ESP file itself or something similar...

The attribute now appears to be vestigial - I can't seem to create a bound record of size > 0. The only records that do have a valid size are those found in Oblivion.esm. See if you had any luck creating a non-zero size object on your end.

Hmmm. Unfortunately it appears you are right. I have lots of items that I've created that have a size, but I probably created them by taking an existing object and giving it a new form ID. I also see quite a few that don't have a size, so it looks like it isn't reliable. Why do some of them have a size? Other than the fact that they are in Oblivion.esm, I mean. I guess the tools Beth used to create these items populated this value, but the CS doesn't. I guess we're left with GetDimensions from NIfSE after all.

The bound radius value generally doesn't update when you create an item, however, not having one on certain things will crash the CS unless they're manually added via tes4edit, like base light records. I've never been able to get one to be placeable without manually adjusting that value to something > 0.

If I could just squeeze into this discussion on GetDimensions...

I need bounding box data for exterior building meshes for something I'm working on atm. Thankfully QQuix has provided me with a bunch of hardcoded bounding box data which he has allowed me to use, as he's needed it for something similar to what I'm doing, but obviously if there was a way to do this more accurately programmatically that would definitely be better. Particularly when it comes to mod compatibility with mods that don't use vanilla meshes.

So basically what I'm saying is that there would be, at least some, demand for this.

If the radius of the bounding sphere is all that's needed, we can get you that.
EDIT: Added GetBoundingRadius. For the objects I tested, this is the same as the 'Size' reported in the editor, except a little more precise (the editor field is a rounded or truncated float).

Done, done, and done. Also added GetCellClimate. A SetCellWaterType will probably be in order.

Yeah, me too. QQuix wants to be able to enable/disable edges between path grid points when adding/removing buildings from the gameworld. So we'd like to simplify things to allow him to pass in the building object itself and have OBSE determine which edges intersect the building's bounding box. This would of course work for objects other than buildings.

Is there a testing version available yet?

Shortly, I expect.
Do you expect to have a reference to the object you're interested in getting the size of, or do you need to be able to get the size of base objects directly without having a reference?

Just a reference. I'll be mainly dealing with inventory items.

So without a reference you mean? Objects in inventories aren't references (no 3D data associated with them). The 3D data is where we're currently getting the radius from.
EDIT: nvm, turns out the size is also stored on the base model and more reliably matches the editor size anyway. But possibly zero for non-vanilla objects as shademe noted.
EDIT2: Added GetEditorSize.

Scruggs -- did JRoush ever get in touch with you about implementing a GetNthEI command, which returns an array fully describing the effect parameters? He proposed it as a solution to something I need from OBME, and we're both hoping it can be added to OBSE-proper and then extended by OBME, rather than being OBME-exclusive.

Not that I recall. No problem to add it - it would save some linked-list walking over calling multiple GetNthXXX commands for the same index. What is it supposed to provide a solution to?

No, I meant I only need it to work with a reference. I'm using getInventoryObject, which I thought returned a reference...

http://www.gamesas.com/index.php?/topic/1091638-wipz-formulatoresm/ needs fully-descriptive keys for a reliable cloneform database. Since you added the ability to read all the checkboxes on spell records in 0019, I'm set for vanilla effects.

But meanwhile, OBME compatibility is a top priority and http://www.gamesas.com/index.php?/topic/1116501-relz-oblivion-magic-extender-v10/page__view__findpost__p__16633850 for multiple reasons related to the (good for other purposes) design of OBME's relevant commands. This would fix it from top to bottom.

Having a core-OBSE version of the command is not essential for me, but the efficiency issues are definitely worth considering, and on a more petty level it would save me needing two completely different key generation functions.