Quest alias not filling with FF-type refs

[user537]

Greetings, this forum firsttimer and beginner modder here. Looking for help with an issue.
I have a quest alias with 'find matching reference - in loaded area' fill type, getisrace condition with mod-specific race being the alias fill criteria.
The alias gets filled perfectly fine when my char is next to the original NPC ref placed in the world, BUT it completely refuses to fill with generic ref (refid starting with FF) of the same NPC, be it a 'placeatme baseid' copy or a copy summoned with a spell (summoncreature type mgef) - no matter.
By now i have tried:
1. different fill criteria (haskeyword condition with proper assigned one to the baseid, getfactionrank with the faction baseid is in) - does not work, even though manual checks of those conditions via console return 1 both on original ref and FF-ref
2. having multiple quest alias with identical fill criteria - does not work, original ref gets into first alias, rest aliases remain empty (player char next to both original and FF-ref)
I still can force the FF-ref into alias through console by doing 'ssq <questid>; forcerefintoalias <FF-refid>' in console, after which both actors show the intended behaviour (final goal is to create a follower/boss who will be able to summon its own clones and via combat override packages they should be able to apply certain spells on each other).
I feel like i am missing something about the setup of the quest itself causing the described above issue, something like 'allow generic' flag like those 'allow dead', 'allow disabled' etc in there.
Anyone able to provide any insight? Thanks in advance.
P.S.  Skyrim LE

Edited April 9 by user537
defined game edition

[xkkmEl]

My alias fills do catch FF-refs without problems.  There must be something else about the target ref that is failing the alias fill conditions.

Test with a ActorBase that has its "unique" bit off.

Turn on the "allow reserved" flag.

Test with a quest reduced to this single alias.  The console will give you much detail on its evaluated alias fill conditions if you start the quest with "startquest myquest".  Minimizing the quest will simplify analyzing the output and reduce possible interactions with other aliases or preconditions.

[user537]

9 minutes ago, xkkmEl said:

My alias fills do catch FF-refs without problems.  There must be something else about the target ref that is failing the alias fill conditions.

Test with a ActorBase that has its "unique" bit off.

Turn on the "allow reserved" flag.

Test with a quest reduced to this single alias.  The console will give you much detail on its evaluated alias fill conditions if you start the quest with "startquest myquest".  Minimizing the quest will simplify analyzing the output and reduce possible interactions with other aliases or preconditions.

ActorBase already has unique flag off, with summonable and respawn flags on.
Alias is already set to 'allow reserved' - on, 'optional' - on, 'allow reuse in quest' - off; quest itself has ' start game enabled' - on, 'run once' - off.
Thanks for the idea with reducing quest to single alias. I will try that later, though i expect it will not fill the single alias at all when only FF-ref is nearby

[user537]

9 hours ago, xkkmEl said:

 The console will give you much detail on its evaluated alias fill conditions if you start the quest with "startquest myquest".  Minimizing the quest will simplify analyzing the output and reduce possible interactions with other aliases or preconditions.

Okay i have tested with both minimized to single alias and multiple of them present. When i make a 'startquest <questid>' console call (preceded with stopquest, as it is an always running 'start game enabled'), aliases (no matter how many of them present) indeed do catch all of the fitting refs nearby, be it original or FF-ref. But that is not enough. I will describe in 'expectation/reality' style:

Quest is running, original npc ref appears nearby. Expected: original npc ref gets into alias. Reality: matches.

Quest is not running, original npc ref and ff-ref appear nerby, quest is started. Expected: both orig and ff-ref get into aliases. Reality: matches.

Quest is running, original npc ref and ff-ref appear nearby. Expected: both orig and ff-ref get into alias. Reality: original npc ref gets into alias, second alias remains empty (not filled with ff-ref).

I think you got what i mean. Aliases do not catch ff-refs when those appeared nearby AFTER quest was started, and were not present at the quest startup moment. As the quest is expected to be always running, this will be constant issue for newer spawns.

I have thought of a workaround - making a script which would restart quest on effect start, and applying it to the summon spell mgef. But that is mere workaround, not a solution. Looking to figure out why ff-refs only get caught by aliases on quest init, but not on-the-run.

[xkkmEl]

Aliases fill only as part of the quest start process.  They do not scan continuously for matches.

If you want a second go at filling an alias, you must stop the quest and restart it.

With some care, you can put the quest in a continuous stop/start loop in order to check for new nearby matches every few seconds.  Do let the game engine breathe a bit between iterations.

[user537]

On 4/10/2024 at 1:20 PM, xkkmEl said:

Aliases fill only as part of the quest start process.  They do not scan continuously for matches.

Now that i think about it... actually the idea i came up with in the previous post might actually be not the workaround sort of thing, but the actual way to go. Aliases do not get cleared unless quest stops, do they?
Wrote something simplistic to apply on mgefs: 

Scriptname RestartQOnCast Extends ActiveMagicEffect

Quest Property QuestToRestart Auto

Event OnEffectStart(Actor akTarget, Actor akCaster)

QuestToRestart.Stop()
utility.Wait(2.0000)
QuestToRestart.Start()
	
EndEvent

 Hope this fulfills the needs. 
Thank you for your input. Now only to figure why do 'simultaneous' branches in combat override packages cause npc to ignore combat completely when they start, even though i do put wait procedure in simultaneous branch along with other stuff in order for it to be able to conclude in case something else fails...

[xkkmEl]

Replace the Utility.wait( 2.0) with

While QuestToRestart.isStopping()
	Utility.wait( 0.1)
endwhile

More robust, more responsive.

[user537]

1 hour ago, xkkmEl said:

Replace the Utility.wait( 2.0) with

While QuestToRestart.isStopping()
	Utility.wait( 0.1)
endwhile

More robust, more responsive.

I will keep this one and its syntax for future. However, in this particular case, it might be not useful because (at least on my machine) summoned ref tends to appear in the world with a little delay after mgef already started ticking on the caster. The 2 sec was to cover that mostly (reduced it to 0.5 though), not to cover the quest restart process. 0.1 may play bad joke if quest restarts faster after mgef start than summoned ref appears in the world...