Talk:OnInit

While usually not a great idea, Using OnInit can be used on unfilled alias' by doing the following

Event OnInit()

If GetRef() != None

code here

Endif

EndEvent

--The above methodology only works for aliases that create references on quest initialization.--

For a more generalized method, that works for quest and aliases regardless of filled state. Bear in mind, that depending on settings, both may receive two overlapping Init Events, one after the other on quest start or reset.

Each PASS of a OnInit - all variables are reset to editor defaults, including private variables. STATES will also be reverted to default. No "Check for validity pattern" will work under this conditions barring external storage of the doonce variable, which is wildly impractical.

Int _iEntry  ;-Consider this the entry pin

Event OnInit() ;-hits once, and then hits again almost immediately afterwards
	Initialize()
EndEvent

Function Initialize()

    ;-generate random number and STORE to local variable.
	_iEntry = Utility.RandomInt(1000, 99999)
	Int MyEntry = _iEntry
	
    ;-yield here, allow thread 2 to clear thread 1's _iEntry
	Utility.Wait(6.0)
    
    ;-only the last call that entered has valid iEntry after yield
	If (_iEntry == MyEntry)
		Debug.Trace("We're initialized!")
	Else
		Debug.Trace("Rejected bad entry")
	Endif

EndFunction

Observations from testing:

• OnInit() cannot stack with other local events !EXCEPT itself in some circumstances! Forms that stack twice? Anything that happens IN the first OnInit is entirely unknown to the second. DoOnce bools, Counters, states will all be reverted to default settings by the second, allowing it to repeat the actions performed by the first.
• The above the method shown works better with STRING values as opposed to integer values - the goal is entropy - you do not want conflict.
• When OnInit() stacks, nothing else comes in between them, no other events are processed aside from OnInit()-OnInit() again - well within the 6 second yield from the first. If the event were to somehow stack several times(force tested with rapid start/stop on quest in a loop) -> the very last call processes the do once. Each stack waits, each stack stores it's entry pin, each subsequent stack comes back in, clears that entry pin - the very last stack survives.

-- GrandBulwark 05:00, 30 April 2026 (MST)