Alright, the docs wording, example, etc, just kinda threw me off..

I'll play around with it, see if I can't get it doing what I need..(mainly not targeting certain item types, hopefully that works the same as RemoveAllItems, in that the menu actually updates properly..)

Rats...that gives the same -1 return.

I am guessing this means that the command "GetBoundingRadius" only works on ref that were placed in the game-world by the CS?

Docs say:
GetBoundingRadius - returns the radius of a sphere large enough to entirely contain the 3D geometry of the calling object.
(radius:float) reference.GetBoundingRadius


Is there no way to get the "size" of a weapon or shield thta is held by the player?

Currently no, but they have geometry despite not being actual references so their dimensions can be had. Another one for the todo list.

...........

:flamethrower:

Hoping for:

Exposing the "active" enemies that are keeping the actor "In Combat" (any actor, player included). Not sure if the list is a linked list, an actual array, or created from scanning, would be nice to know.

A means of blocking any actor (player included) from casting spells (silence usable ones as well). Doesn't appear to be any AI method of stopping them from doing so. Not sure if this is possible, but it would be nice.

Waiting for the tracing functions. Those are sorely missing, so used to having that kind of ability with other engines.

Means of intercepting Disposition checks between two actors, so you can make them bitter enemies or super friends without having to resort to factions (which are not 100%) nor is setting the actor Evil. Or even the ability to alter the AI's final decision on what the actor will do with respect to another actor.

A ForceFlee that isn't combat driven.

Ability to dynamically populate disposition list in a faction (so that a faction could be built from scratch on game load, to set default dispositions with every other faction in the game currently). Wouldn't solve the issues with actors still liking/disliking others in that faction, as multiple factions alter the final disposition.

GuruSR.

Ah, okay, so that was for the inventory issue. Yes, you should use the Inventory Reference remove, since it's really used on an inventory (containers are actually objects with an inventory), technically so are cells, but I've never tested that.


The advantage: Unplayable Quest items receive a higher priority for scripts, cannot be seen in inventory, cannot be removed by RemoveAllItems (because it skips quest marked items). This is useful for tokens. Disadvantages: Well, aside from the script getting a higher priority than normal, you can't move them unless they do it themselves with RemoveMe (container ref) or you specifically remove it by ref.RemoveItem. RemoveAllItems won't move it because it's a quest item, plus some other mods may "avoid" it because it is a quest item. Most of the time a token you want it Quest/Unplayable, two benefits in one, can't lose it, gets decent priority.


Well, the "reach" of the weapon would help there. I've used it to determine the size of the weapon, since it's reach is how far out it swings from the hand on the player. As for shields, you're pretty much going to have to use the bounding box for it to determine it's size, but unfortunately it's not available for it, if a collision box could be read, then you'd have your answer for anything, if that is at all possible.

GuruSR.

Really? This is what works..

Is there not a more intuitive way to do this? Because, this just seems like a bad idea.. (Edit: Technically, I guess there is nothing wrong with it, but, still, it's not very user friendly..)

Edit2: Actually, on further inspection, this method has tons of pitfalls to overcome, it's going to take what should be a single script, and turn it into a whole big ordeal.. I'm going to have to write probably at least 3-4 scripts to handle what was previously one line of code..

scn aaaRemoveItemsref Itemref Item2array_var Itemsarray_var Iterarray_var Iter2array_var InvRefsBegin Function {}	Let Items := Player.GetItems	ForEach Iter <- Items		Let Item := Iter["value"]				Let InvRefs := Player.GetInvRefsForItem Item		ForEach Iter2 <- InvRefs			Let Item2 := Iter2["value"]			Item2.RemoveMeIR aaaInventoryChest		Loop			Loop	ar_Null Items Iter Iter2 InvRefsEnd

Not the case, to the best of my knowledge. ExtraContainerChanges::RunScripts simply walks through the item list and calls their scripts in the original order they were added.

Is there any way to detect other OBSE plugins during query (or load)? Or should I just check for the actual files directly?

Don't think the API exposes a command that does that. You'll have to walk the plugins folder manually (You can use the IDirectoryIterator interface in the Common project).

If you're trying to remove all the player's items:

ref itemforeach item <- player  item.removeMeIR aaaInventoryChestloop

If you wanted to remove all of one particular item type:

foreach item <- player.getInvRefsForItem whateverItem  item.removeMeIR aaaInventoryChestloop

You can get rid of ar_null - it's unneeded (remember our previous discussion about sv_destruct?) and it doesn't work the way you've written it.

One way around is to get the base object FormID of the weapon or shield and PlaceAtMe a new object in the game world, get its dimensions with GetBoundingBox and, then, remove it with DeleteReference.

Problem is that, for PlaceAtMe'd references, GetBoundingBox will only return the real dimension the next frame.

Hmmm . . . when I tested GetBoundingBox some time back, it returned the largest dimension from the center of the mesh. Now, it seems it returns the largest dimension from the geometric center.
Scruggsy, have you changed it? Or my memory is tricking me?

Example: the mesh for WeapIronLongsword has its center on the hilt.
From the center to the tip of the blade = 70 units
From the center to the other end (at the hilt) = 10 units
Total length = 80 units
GetBoundingBox used to return 70 (the largest dimension)
Now it is returning 40 (half the length)

Both approaches have pros and cons. I am just curious of the implemented behavior of the function.

ForEach Item <- Player

Doesn't work, whether that's CSE being difficult, or what, I can't tell ya.. It was the first thing I tried.. Regardless, I can't use this method anyways, it doesn't hide the sounds, and this code fires every time you open your inventory..

	Let FormID := ToString(GetRawFormIDString Item)	Let LockedList["key"]->FormID := LockedItem

Also, been guessing at your syntax for the last hour+ on that..

I've tried every variation imaginable, none of them actually look at the string.. $(FormID), etc, etc,., etc,. etc,.. For an hour+...

	Let FormID := GetRawFormIDString Item	Let LockedList->FormID := LockedItem	Let FormID := GetRawFormIDString Item	Let LockedList[FormID]:= LockedItem	Let FormID := GetRawFormIDString Item	Let LockedList->$(FormID) := LockedItem	Let LockedList->$(GetRawFormIDString Item) := LockedItem	Let LockedList->GetRawFormIDString Item := LockedItem

Should I keep listing em?

No, explain what you're trying to accomplish instead.

Haven't changed it, but you should not be getting anything from GetBoundingBox when called on a non-actor/non-projectile. Did you mean GetBoundingRadius? That one hasn't changed either.

I'm trying to use the FormID of the object as a key for a StringMap..

I've tried every variation imaginable, the only thing that might actually work, is just handing it the object ref, however, ar_HasKey complains about that...

This is why I ask so many "stupid" questions, I get tired of guessing at what OBSE expects.. No offense, it's just, not any fun..

Syntax is let array[key] := value so

let lockedList[GetRawFormIDString item] := lockedItem

Thank you, that one went through.

Look, I really do appreciate all the work you do on OBSE, so I hope you don't take offense, it's just, I try my best not to come here and harass you constantly, so generally, by the time I do come here, I'm very, very, annoyed.

---

Edit@Edit: I did try that syntax, in one iteration, but something must have been off about it..

Come here sooner then? It's what the thread is for.

Well, according to the CS information, scripts run based on priority, items with the Quest flag are given a higher priority than those that aren't. I would assume that any object/actor that has a script on it would inherit the item's flags. Thus the engine would give a higher priority to the threads running those scripts. They may all start at the same time through an iteration as you mentioned, but the engine (according to the CS) should provide a higher priority.

I can't see it being just actor based (though from what I've seen of the engine, wouldn't put it past them to have done so), as Quest Item was meant to make sure that those items and their scripts are properly processed with a higher priority than the normal ones.

Can this be confirmed please.

GuruSR.

Priority applies only to quests. Object scripts run once per update, i.e. once per frame for objects in the player's cell; there is no higher priority than that. The engine does not create separate threads to run individual scripts.

Yes, I meant GetBoundingRadius (copy paste mistake)

Funny:

With the WeapIronLongsword, it behaves like mentioned:
The mesh for WeapIronLongsword has its origin on the hilt.
From the origin to the tip of the blade = 70 units
From the origin to the other end (at the hilt) = 10 units
Total length = 80 units
GetBoundingRadius returns 40 (half the length)

With the AnvilLCHouse03 (the static that I tested previously)
From the origin to the western wall = 550 units
From the origin to the eastern wall = 1000 units
Total length = 1550 units
GetBoundingRadius returns 1050 (actually 1047.95)

Anyway, it is not half the length, like the sword.
And it is not the largest dimension from the origin of the mesh, as I assumed earlier.

Did some more precise measuring of the AnvilLCHouse03 and:
Bounding box dimensions are: X: 1557 . . Y: 910 . . Z: 611
A sphere centered on the mesh origin should have a radius of 1160 (from the mesh origin to the outermost corner)
A sphere centered on the geometric center of the mesh should have a radius of 950 (half the 3D diagonal length of 1904)

Not sure how GetBoundingRadius calculates the result of 1050

(measurements calculated in game by placing XMarkers on opposite corners of the bounding box and using GetDistance to get the values)

That would be too easy.

Seriously though, I guess I could do that, but in return it would be nice if I weren't made to feel stupid for doing so. Which seems to happen quite a bit more often than I care for around here. I'd rather guess for three hours than ask, and feel talked down to.

I program in a lot of languages, and it can be hard to keep track of every minor quirk, and detail of each one. So I make mistakes, and sometimes ask stupid questions just to be sure about things. But, when you basically speak 20+ languages, especially languages as complex as programming languages, that tends to happen.

Anyways, I'm heading to bed, I'm tired.

Well I sincerely hope I haven't contributed to that. The thread is here for help/requests/discussion, and the docs are admittedly less than perfect, so please feel free to ask/pester/complain to your heart's content.

Ok, except the CS does state that NPC's marked quest also receive a larger range of operation (meaning their scripts run in places non-quest scripts do not, but is that also so for objects).

GuruSR.

Edit: P.S. Gripe and complain, well, I would, but I doubt you're an oil tycoon to rant at about gas prices.

Edit 2: P.S.S. Thread is nearing limit.

I'm having problems getting OBSE (19 or 20) to load with my Steam version. I copied the 3 .dll files into my oblivion and usually run the game via Wyre Bash (which, incidentally, does not show the green check box for OBSE) but no command screen appears and it doesnt load. I did try the Steam version of the obse_loader.exe and although it ran obse I lost my main menu (for reasons beyond me)

I am not new to OBSE and have had it running on other installs, although this is my first Steam install.

Any and all help is appreciated.