Deleted67409046User

This sounds right intuitively, and there are other systems in the engine that sometimes need "shocking", like the idle animation system. I suspect it was done that way for efficiency's sake, so the game isn't really re-evaluating conditions on an actor unless it has to. Would be nice if any of this were documented :(

Thanks, at least I know I'm in good company. The closest to a working result I was able to achieve was by putting the actors into a second refcollectionalias when I want them to speak the lines, and conditioning the lines on that (and only that). That seems to work most of the time, but again sometimes it fails. What a headache. I'm thinking of giving up and adding code to the refcollectionalias to simulate idle dialogue via random timer. It's more work and less efficient, but at least I know I can make it work reliably.

So I have run into a weird problem with dialogue conditions. I have a refcollectionalias holding some NPCs, and I want them to speak random lines from a set of Idle Topic Infos. I created the dialogue, I made it conditional on GetIsAliasRef for that refcollection alias, and it worked exactly as desired. So far so good... But this makes the NPCs in that refcollectionalias say those lines all the time. I need them to only say the lines after certain events occur. So I added a HasKeyword condition to the dialogue, and made the script add the keyword to the NPCs when certain things happen. The problem is, when my script puts that keyword on the NPCs, they don't start speaking the lines. I have verified that the script works, the NPCs do have that keyword, etc. More puzzling, if I save my game and load it again, the NPCs start speaking the line. It's as if the condition function results are cached somehow, and are not re-checked until the game is reloaded. Am I missing something obvious here? I've tried various other ways to do the condition - using a faction instead of a keyword, using a linked ref, etc. Nothing seems to work. But in every case, once I save and reload, the condition is re-evaluated and the lines start working.

You get ActorValues directly from the ObjectReference. Use the ObjectReference.GetValue(actorvalue) function, e.g. ActorValue Property Health Auto Const Float CurrentHealth = akRef.GetValue(Health)

There are a couple of "portable container" mods on Nexus that already do basically the same thing, like Portable Duffle Bag. The only real difference between that mod and what you are asking for is that you want it to be equippable, which doesn't impact how this works. It's not hard to implement. You place a hidden container in a cell somewhere and make it a persistent reference. Then you have a backpack armor item which can be activated when it is out in the world. Activating the backpack runs a script fragment that opens the hidden container's inventory. You can make this happen by giving the player a perk with an "Add Activate" entry point so that the player can either [E] Take or [R] Open it, and the Open option runs the script fragment. Or you can put a script with an OnActivate event handler on the backpack, which pops up a menu letting the player choose whether to take the backpack, open it, and possibly other options.

No, the code will work as intended and will not generate script log errors. akBaseObject as Armor will simply return None if the cast fails, which means if akBaseObject as Armor will evaluate to false since a None object auto-casts to boolean false.

If you don't mind using F4SE, you could do this much more easily by looping through all the equipment slots with GetWornItem() to see if an armor is equipped there, and then doing UnEquipItemSlot() on each slot where an item is equipped. GetWornItem() returns a struct that holds the base object and other information about the worn item, so you could collect your ArmorForms using that. Like so: Event OnInit() ArmorForms = New Form[0] Int slot = 0 While slot < 30 Actor:WornItem wornItem = PlayerRef.GetWornItem(slot) If (wornItem) && (wornItem.Item as Armor) ArmorForms.Add(wornItem.Item) PlayerRef.UnEquipItemSlot(slot) EndIf slot += 1 EndWhile EndEvent I also changed your ArmorForms[] so it starts out as a zero-length array and grows as each form is added. This is slightly less efficient than preallocating a fixed array, but has the advantage that ArmorForms.Length gives you the number of forms so you don't need to track it separately.

Yep I think that's the inescapable conclusion. Best I was able to do is an OnEnterBleedout handler that calls ResetHealthAndLimbs() and then loop waits on IsBleedingOut, just like yours. I've tried the animation variable, applying stimpaks, etc, but the end result is always that if I make them do ActionBleedoutStop they just go right back down. Ah well it's not the end of the world, I just wanted it to be snappier. Fading the game in and out hides a multitude of sins ;)

Does anyone here know of a way to snap an actor out of bleedout quickly? I have tried resethealthandlimbs() followed by playIdleAction(ActionBleedoutStop). The actor gets up, but then goes right back down for the rest of the 6-7 seconds and then gets up on their own. I'd like them to get up and stay up. I also tried restorevalue(health, 999) instead of resethealthandlimbs(). Thanks!