Inventory references are different from "true" references. They're called references because you refer to individual items rather than base objects, but in Oblivion's sense of the word, a reference is only a 3D, in-game representation of an object.

Nope, GetInventoryObject returns the base objectID. The word b]Object[/b] in its name is enough to tell that it returns an Object ID and not a reference, which the description also says.

Don't be fooled by the fact that the result can be stored in a "ref" variable. The ref variable still points to the base Object ID in such cases.

Grrrr. I wondered about that. I saw that it returned the Object ID, but I've always seen the results stored in a reference... So I don't imagine there'd be any way to get a reference to these objects then? I might wind up with zero radii for some items... Most are vanilla, but I need to be prepared for custom objects as well. They are 3D, in-game representations, but they aren't static objects.

Ok. How much info do you need? Currently you get:
effect code, range, area, duration, magnitude, cost, name, plus 'seff' containing script effect info if present: script, school, visual effect code, hostility.
Anything else you need from it?

It's correct to store the results in a reference variable. It's more than a little confusing that a 'reference' variable type can be used to store non-reference objects but that's the way the scripting language works.

You cannot get actual references to items in inventories - they don't exist in the gameworld so they don't have location, 3D data, etc.
OBSE has 'inventory references' which let you treat inventory items sort of like real references, but they will not be useful here (again, no associated 3D data).

Ok, so this means I will only get reliable data for base objects from Oblivion.esm? Also which functions are you adding? GetBoundRadius or GetEditorSize or both?

Not exactly. Editor size appears to be determined by the .nif's collision object. No collision, no size. It's not a question of whether or not the object is defined in Oblivion.esm or a plugin.

Added both since they do different things and return different values under some circumstances.

If you can find out how the MODB field is calculated, it'd be possible for Bash to add it to all relevant records in the Bashed Patch.

Might make the patch fairly large...

It is calculated when the object is placed into the gameworld (that is, dragged from object list into render window). This means that most 3D objects (mod-added or vanilla) will already have it, unless no references to them exist.

Oh, is that how it works! It was really puzzling me because some custom objects I had created had sizes while others didn't. Ok, so I might be alright then, in this particular case.

Now if you were doing a mod where you wanted this info but didn't necessarily want objects in the gameworld - could you get the CS to calculate it by creating a reference to them (by plopping one down somewhere), save the plugin, and them remove them again? I suppose you could also just place them in an unused cell somewhere, but it'd be nice to just be able to delete them. Or is this a lot of unnecessary effort?

Yeah, that'd be one way to do it.

Wouldn't the Test Cell work for that??

Yeah, that's what I was thinking actually. But it sounds like I don't even need to keep the references once the size info has been generated, so I could get rid of them. I don't actually need to do this right now, but I wanted to make sure I understood how this info is generated.

Awesome, thank you! *gets to work on latest project*

Try placing a reference, and then hitting "Undo", see how that goes.

Actor value when relevant. Looks good otherwise.

JRoush should probably be consulted on the array structure and key names, particularly because those SEFF-only fields are available for all effects with OBME. Probably best if empty fields are absent from the array, too, rather than containing zero. Edit: PM sent, hopefully he drops by today.

... *cough*

Anyway, if I could make a request on this it would be what tejon has suggested: omit the actor value and ScripEffecttInfo fields unless they are actually relevant.

This does bring up the thought of using arrays to represent other game classes. If you can make an array out of an effect item, you might do it with inventory items, object refs, etc. I'm not sure if it's a good idea or a bad one, but I suspect it will come up again in the future.

Ok, done.
Yes, it can be useful to represent a game object as an array/pseudo-struct. I don't think it's really worth it (convenience aside) except in cases like this where it prevents us having to walk a linked list multiple times to get a set of info for a single object.

Active effects would be the other obvious contender, then. Could actually be useful if there were GetAECodes2 and GetAECasters2 which returned arrays of arrays.

On that same note, "GetEffectItems" to return all the EI arrays for a magic item would be awesome.

Any hint on when this might happen?

And if I could add another request. I'd like to be able to access the 'Public Area' checkbox in the cell's interior data tab. If I understand your code properly, it's basically the same as Behaves Like Exterior, so it's a cinch to add.

It's currently in progress.

Added SetCellIsPublic and IsCellPublic.

SUPER big macho wild request here....

NewCellObjectJustPlaced

To detect that a new object was just added to the player's cell.

The reason I am asking for this is that I have tried almost everything including getsoundplaying (to hear the shock travel sound) to try to detect the instant that a shock spell is cast by an activator.

I am trying to detect when a shock spell is shot by an activator. The shock spell travels too fast to pick it up unless I scan the cell every frame. I do not want to do that.
I can pick up the actors shock spells because I run a scan at the moment an actor starts their cast animation but activators do not have cast animations.


Edit: Can I use the OBSE command GetNumRefs every frame without dragging down the frame rate? If so than this would do the trick (I hope).

scn aaDPCMFastQuestfloat FQuestDelayTimelong NumRefsInCelllong NumRefsInCellOldBegin gamemodeset FQuestDelayTime to .001set NumRefsInCell to GetNumRefs 34 1if NumRefsInCell > NumRefsInCellOld messagebox"worked"  set NumRefsInCellOld to NumRefsInCell    if aaDPCMMainQUEST.ProjRadar > 2 || aaDPCMMainQUEST.ProjRadar == 0       set aaDPCMMainQUEST.ProjRadar to 2;-- Activator has no cast anima so need this here        elseif NumRefsInCell < NumRefsInCellOld      set NumRefsInCellOld to NumRefsInCell    endifendif

Edit: I tied this and OH YES it works very well! It does not "seem" to hurt the frame rate and now that I think about it I can replace MANY other little scripts in my mod with this for detecting things like newly summoned creatures, shot arrows and other such detections. So in the end removing those from the mod and using this may balance out the frame rate this command may or may not consume. This will miss the rare occurrence of a object added and one removed at the same time just before this command is issued, but I can live with that unless you guys have a way around that.

If something like this is possible, I would imagine one or more new http://obse.silverlock.org/obse_command_doc.html#Events, like OnCast and OnFireArrow. I imagine those could be useful, but have no idea how easy they are to add.

IIRC, GetFirstRef will always return the most-recently placed reference first, so you could just use that.

Also, most of the time, I'd guess that there would not be enough projectiles in the air to make a full GetFirst/NextRef loop (only on projectiles) be particularly degrading to speed, even every frame...

Minor request for the next build: Check-out or get the latest revision from the repo before compiling - CSE's latest build depends on the changes I'd made and I was planning on a public release. Planning being the operative word. Thanks.

That reminds me, could the ini definitions be moved to the GameAPI header? Right now they're in between the commands and I need to redefine them in order to use it, while this isn't a big deal it seems logical to put the ini stuff in the GameAPI (just like the gamesetting stuff).