I'm coming along with this, but I need to know something to see if my current attempt is fruitless.

Walking an inventory gets you base object IDs. I can easily compare two base object IDs to see if the item has changed (within a margin of tolerance, I'd think).

What I can't figure out is whether there is a way to have the script eject an item from the container based on what it's found by walking the inventory. MoveTo seems to only work on references, unless I'm misreading things entirely, and since the ObjectID is already stored as a "ref" I can't see any way to convert it to a reference that MoveTo will work on.

I'm told that there will be some more inventory functions added into the next version, so what I'm wondering is if there is a workaround to have a script eject my item, or if I can give up on this and wait till v19.

For explanation, I want the script to scan for a helmet, log the first helmet it finds, and then...if it finds a second helmet...compare the two and eject the first if the second one is different from the first. I've thought of two possible ways to make the comparison, but no way to pass the information needed to eject the helmet.

Depends on your definition of different.
If you've got two objects with different formIDs that's fine. Use RemoveItem to remove one of them.
If you've got two objects with the same formID (e.g. two Steel Longswords) but different health values or enchantment charges and you'd like to remove, say, the one with the lowest health/charge, you're out of luck. RemoveItem can still be used to remove one of them but you can't predict which of the two will actually get removed.
Commands to allow access to individual item references in containers have been on the agenda for quite some time now but they are not trivial to implement. I don't believe we've committed to including them in 0019; we generally don't promise functionality until it is actually implemented. But the demand for it is high so it at least has some priority.

Cool.

I'm purely interested in visuals in this case. Basically, I just want the second helmet added to replace the first helmet added and so on. RemoveItem can bump them based on the ObjectID (I actually got that part), but the item has to go back to the player's inventory (I had hoped to "moveto" the item to the player and then force activate it to make the player pick it back up again).

Since that seems to be beyond my current capabilities, the next plan is to prevent the player from putting a second helmet into the container until the first helmet is removed.

Oh, and please, don't ever take anything I say in here as a demand. I have so little understanding of how all this works that I never have any idea whether what I'm talking about is easy, difficult or impossible.

Didn't take it that way, no worries.
If you're concerned about making sure the removed item retains its extra data (health, charge, etc) - which I assume you are - it sounds like Plan B, preventing a second helmet from entering the container, is the way to go for now.

This sounds very similar to something I'm already doing in http://www.gamesas.com/bgsforums/index.php?showtopic=1040141&hl=: In that mod, when the player activates a dead actor or a container, EE walks the actor/container's inventory, and for each item found that matches some criteria it has a random chance of removing the item. This is done in order to make finding good loot harder in the game.

But if the player closes the inventory of that actor/container, and later activates it with shift held down, all the removed items will be there, i.e. they're all put back.

The removal/adding back is handled in one of two different ways, depending on item type. If the item can be set to non-playable, I simply do so, since this makes the item invisible in the inventory - and then make the item playable again when it's "added" back. If the item cannot be set to non-playable, I use RemoveItem, but store its reference in an array. When adding the item back, I get the reference from the array and call AddItem.

You may look into that code if you want to. Most of it is handled in the Function script named "EElootTarget".

How about displaying an in-game reminder, like Pluggy's, when the OBSE co-save is missing ?

Co-saves can validly be missing if a game was not saved with obse running. Since we can't distinguish between that case and the case of a user deleting his co-save, I think we're better off assuming the user won't do that.

Hmm... similar request (that would at least allow a mod to be created to do that) - IsOBSEDataReset. Essentially, if no co-save were present or it were empty, this would return False and otherwise True. (sorry if this was implemented, I haven't had a computer for most of a month and still haven't had a chance to catch up with the OBSE stuff.)

I am pretty sure we don't have anything like that right now. It seems like it is reasonable to know if we've loaded a co-save, and I imagine it would be pretty easy to fire. I'll chat with scruggsy about this.

Thanks behippo

Is there no way to get refs to hostile actors chasing a player?

getfirstref 69 1

Then walk the refs to see who is targeting the player.

Thanks.

Actually for running away you want to use getfirstref 69 2 to check all of the cells. 0 is player's cell only, 1 includes the neighboring cells (3x3), and 2 includes 2 neighboring cells (5x5).

This code is fine when Door is in an interior cell, but prints when it is in a named exterior cell. Is this the expected behaviour?

ref r2set r2 to Door.GetParentCellstring_var sLet s := GetName r2printc "Parent Cell of Door: %z" s

What exterior cell/worldspace is the problematic door in?
And how are you obtaining Door?
Expect problems with this:

let Door := someOtherDoor.GetLinkedDoor; or similar

as the linked door's cell is not loaded if it's in an exterior.

Saw it just outside Memorial Cave and Echo. Didn't check elsewhere.
It was obtained from the parent of a triggerzone.


You're saying GetLinkedDoor is unreliable when one door is in an exterior and the other an interior?

No, it returns the correct door reference.
The problem is that the game unloads exterior cells it doesn't need. So you get the door reference, but the door reference's parent cell is not loaded. So GetParentCell returns null.

If this doesn't explain your issue please post full code, maybe post a formID or two for problematic doors.

No need; that explains it perfectly. Thank you.

A couple of requests for a rainy day:

A pair of functions to detect when (1) the player is leaving a cell and (2) arriving at a new cell

IsPlayerLeavingCell - would return true BEFORE the player leaves the cell, so non-persistent refs in the cell are still accessible and their ref vars are still valid. Useful for cleaning up any mess left behind, namely deleting PlaceAtMe'd refs, reenabling things and any other things not fixed by cell reset. (IsPlayerMovingIntoNewSpace only triggers when the player is at the destination cell).

IsPlayerEnteringCell - the opposite, of course. Useful, among other scenarios, for untouched vanilla cell or when onload blocks are not triggered. (IsPlayerMovingIntoNewSpace does not seem to trigger on token scripts, as far as I could test it).

Even better if they could be a one-shot-per-script, like GetGameLoaded.

Or are there workarounds for these? I can think of ways to detect entering a cell, but not leaving it (short of scripting the doors)

con_TCL - I was about to ask for this and noticed it is already in OBSE docs. But it does not seem work. Any chance of fixing it? I am planning on some cinematic camera movement in the future and would be nice to be able to toggle collision by script. A way to check if collision is on or off would also be useful. Again, it can be done by MenuTapKey'ing each letter - I use this a lot during tests, but sometimes it fails.

Could anyone clarify to me what still has to be done before this gets out of beta? I recall something about relocating a game load hook because of crashes, or something like that. Is that still the issue, and is that the only one?

Don't take it as a 'hurry up! I want this out of beta now', I'm just curious, as it seems to be a prolonged beta compared to the others I remember.

I wanted to reply with RunScriptLine and a function that returned if the global collision is disabled or not. But while looking for the exact name I came across two functions which might do what you need: http://obse.silverlock.org/obse_command_doc.html#IsGlobalCollisionDisabled and http://obse.silverlock.org/obse_command_doc.html#SetDisableGlobalCollision.

Hey, kyoma, thanks!
Just tested and they are exactly what I wanted.

Sorry for the trouble. On my behalf, I must say that, as there is a con_TCL, it never occurred to me looking for other similar functions. Against me is the fact that those are around since OBSE 10 and 11 and they are on the http://cs.elderscrolls.com/constwiki/index.php/List_of_Functions#C, which I check countless times every day.

@QQix and kyoma: This issue has come up before - which led to the Global Collision functions. You ought to be able to use those.


We know what the problem is, and we have a solution - however we have some concerns about the solution. We're contacting a BGS developer about our approach and whether it seems a good idea. If we get a good answer we'll have to roll out one more beta to test and be sure there aren't unintended side-effects. If our solution isn't kosher, we'll have to come up with another, more complicated solution.

We'll see how quickly our contact can get us an answer and we'll have a better sense soon of timing.

Also - real life has gotten quite hectic for both scruggsy and I - which has predictably slowed things down.