foamyesque

You can have as many loops as you like; the issue is that you put the loop in the OnInit block. As long as an OnInit block is running on an object, nothing else except other OnInit blocks can run on that object. It's to prevent races. Since your loop takes (a minimum of) 300 seconds it blocks everything else from running until that time is up. This behaviour is why it's generally recommended to keep OnInit blocks as small and fast as reasonably practical. OnUpdate events are shared amongst all scripts attached to the same object, which is why both quest scripts trigger it.

I'm not sure why you need to track the registry particularly. The registration's just a means to an end to change the state of these Seeker Droids, which they presumably track internally somehow. If you want to check on whether it's in Hold Position or Close Combat, just create a means to report that state whenever requested. SendModEvent would work, but it seems kind of overkill.

Some (though by no means all, or even most) exterior cells have editor names, and you can use COC to get to them. These typically include all cells in a city's worldspace (e.g., CityNameOrigin), and in small towns, the cell of the town itself. There's also usually named cells at or immediately surrounding named locations of various sorts, e.g. stables, entrances to dungeons, immediate city exteriors, and so on.

Noted. Thanks! I changed it up, I wasn't aware changing the state didn't end the current function abruptly. Which brings me to my next consistently recurring train of thought. What will force a script to drop what it's doing, besides "return"? Would this work? Or will it only read the current running function before before having issues? I have a feeling this will fail to run "MyFunc()" inside the "Waiting" state, and will run the one inside the empty state instead. That would makes since to me, but let's make sure I am not going insane here. What will happen there is, assuming it starts in the Waiting state and something triggers the OnActivate Event: The OnActivate event declared in the Waiting state starts processing. The first thing it does is put the script into the empty state, so any further function calls or event triggers will use the versions declared in the empty state. Then it proceeds to call MyFunct(), which will use the empty state version, and therefore not call MyFunct2(), so the script doesn't get put back into the Waiting state.

What happens if the call from OnPlayerGameLoad() is remarked out?

What could clear a quest alias aside from stopping/reset the quest, which isn't happening, or calling clear() directly on the alias? There shouldn't be anything AFAIK; a ForceRef to 'none' shouldn't do anything. There's a note in the wiki's talk page for ForceRef of someone having the same issue back in 2016, but I've used ForcedRef both script and console across saves without issue. Without more details on your scripting / quest setup it's hard to figure the issue. One possibility is that Quests that are Start Game Enabled will start twice, so depending on how exactly you've set up your force-fill it could be that they're filling on game start and then being wiped when the quest starts for the second time (e.g., OnInit events fire twice in this scenario).

Don't need to explicitly declare the empty activation in the Disabled state. Undeclared events fall back to their defaults, which is an empty block anyway. However, my suggestion would be to go to the Disabled state immediately on activation, regardless of whether or not the player has the gold, etc. Do all those checks there, and then either display the menu or go back to the Active state. This gives the smallest possible window for malformed input and should functionally guarantee that all the code finishes running, in either path, before a new trigger can start it again. For clarity I'd probably rename them from Active -> Waiting and Disabled -> Active.

They are, so there's something in your setup that's clearing them.

I'd generally recomment hitting up the CK wiki. But if you're creating fragment scripts with working properties and such you already have pretty much everything you need -- a working quest, you know how to navigate the CK, add & fill properties, etc. On the main Quest screen, at the top, there's a tab list. You should be familiar with it b/c you've been doing dialogue. At the far right there's one called Scripts, which is a list of all the scripts that're attached to that Quest (there's similar windows for anything that can have scripts -- MagicEffects, Aliases, various kinds of ObjectReference, etc), The buttons beside should be familiar and reasonably self-explanatory. Hit "Add", and create a new script (named as you wish) that extends Quest. This will open up the CK Papyrus editor & compiler with the scriptname line already generated. Write all your processing code -- GetOutfit, SetOutfit, etc -- here, in functions. Set properties per normal. Then change your TopicInfo fragments to say this: (GetOwningQuest() as ScriptName).SetBeggar() and (GetOwningQuest() as ScriptName).ClearBeggar() Using whatever function names/script name you choose. What this does is have the topicinfo fragments tell the *quest script* to run those functions (just as when you say Actor.SetOutfit(), you're calling a function that runs on the actor; only in this case, you're accessing code you yourself wrote, not the basic stuff that shipped with the game). Because Quests are script objects that are always loaded they are extraordinarily useful for persistent data storage and state tracking, and in this case you need one anyway for the dialogue :) (According to the Wiki TopicInfo script variables get cleared for memory reasons, so presumably that's what's been causing your issues, BTW)

Personally I think you should try to avoid putting significant code in fragments like this. I'd put all the outfit & alias manipulation into a Quest script with functions for the TopicInfo fragments to call. That will make troubleshooting (and data passing) significantly simpler.

Are you certain your code paths are being followed? You've got debug alerts in there. Do the expected ones fire? Is there anything in the CitizenOutfit property when you go to call the SetOutfity function directly after the releaseBeggar() function? In this case the relevant properties are script-driven. It's a TopicInfo, which means IIRC akSpeaker is an inherent autofill from the dialogue and citizenOutfit should be being pulled from the originalOutfit() function's GetOutfit() call.

I misspoke slightly: You also need to change the "EndEvent" to "EndFunction" to match the declaration :v

You can absolutely custom define new events and there's no difference whatsoever script-wise between the two. All events are functions, and you can convert a function to an event just by changing its declaration. Nothing will care. The distinction is purely a meta one for the programmer, to highlight things that are triggered by the game doing something.

Generally, it happens when a function returns a general class (e.g., a Form) when you know what you're after is a particular subtype (e.g. Armor) and you want to use functions specific to Armor on it.

There is also a SetOutfit() Actor function, though it lacks a corresponding one for GetOutfit(), which is why the SetOutfit side of things worked. How that interacts with the GetOutfit() ActorBase function, I have not tested.

No. Casting is only required if you're going from a general type to a more specific one (for example, ObjectReference -> Actor). Actor already extends ObjectReference, so it can be supplied without casting to anything that expects an ObjectReference, because all actors *are* ObjectReferences. Which also makes me wonder why you're bothering to store it twice.

In case anyone else is looking: All the holds have an XMarker in the capital that gets disabled or enabled by the Civil War quests and controls what guards spawn.

Quest *fragments* aren't something I like to deal with either, but *quests themselves* are an extraordinarily powerful and flexible resource. An awful lot of things are best accomplished via scripting either on a quest or a referencealias. This is because, amongst other things, the same object can be in multiple aliases simultaneously, which means multiple mods can modify the same resource with them. The alias-fill tool is the best way of finding something and exposing it for scripting. Aliases are handy for designing even non-generic quests because you can set up the logic and relations of each thing in the quest without needing to care about *what specifically* is in them, so that if for example you decide to swap your questgiver from Jarl Balgruuf to Kodlak Whitemane, or whatever, all you need to do is swap the alias instead of every single reference to them throughout your code/dialogue.

I mean, if you were using aliases, you wouldn't necessarily *need* to have custom scripts on the items themselves, which is useful if e.g. you don't want those scripts firing when the quest is no longer running. Personally pretty much every single thing you list off I'd put in as an alias just so that it's very clear to me, as I work through things, what I am working with and what their role is going to be. This is particularly true if I'm dealing with NPCs, since you may want to do things like override their AI packages, protect them, change their inventory, give them temporary scripts, etc.

Add the chest to a quest alias, and then modify its inventory in that alias. This is how the game does things like Meridia's Beacon. The item(s) will remain in the chest, through resets, until removed, but will not respawn.

One possibility is putting the exact same conditions on a magic effect, casting it on them, and then having a pingback from the ActiveMagicEffect if it worked. Bit clunky, though.

The distinction between Event and Function is for the programmer. It's to distinguish stuff that's generated by some triggering 'event' from stuff that isn't (which is a bit of a squishy line, in practice). Most events are tied to the game engine throwing them, but custom events can be created that are thrown by a script, for whatever reason. So it has some applicability if you're doing X extends Y stuff (even for yourself) or if you're providing a framework for others. SkyUI has some good examples of this, with a lot of custom UI events for managing MCM work. As far as the actual papyrus scripting engine is concerned though? They perform identically and can be treated identically in all respects.

For your purposes there shouldn't be any differences.

It's been a lifesaving proccess for me on more than one occasion!

As I understand it, your goal is a three-stage boss fight, where after the boss hits certain hitpoint thresholds, they move to the next stage. You were previously worried about the boss being oneshot, so I suggested you make them essential until they're in the final stage, but that has had the side effect of making their health bar refill to full, correct? My suggestion here is to change how you do the stage transitions. For example, currently you have them shift on, say, 1,000 HP remaining and 500 HP remaining. But what if instead you made going into bleedout the transition point, and just changed the maximum HP down a bit so that each full HP bar is effectively that stage's HP? That way, they drop into bleedout, you disguise that with whatever transition effects you want and increment the fight stage, and their health then restores to full to continue the fight.