Dla wygody tekst pozostawiam w języku angielskim.

If you would like a full explanation:

Spoiler

I don't usually explain what I do, but I've decided to start doing so. It might be useful, who knows.

This is quite an old and well-known bug, that’s why quests have always been written in a way to avoid it.
The core issue is that quests are initialized before affects, so the when login trigger fires before affects are loaded.

Have you ever tried to do something on login that involved affects?

e.g.:

• You want to check if the player has a mount when entering the OX map and dismount them.

• You want to polymorph them into mob 101.
  

Well, that wouldn’t work.

The common workaround everyone uses is simply adding a timer to the login trigger, even 1 second is enough.
That’s why this bug has never been considered a real problem: the workaround is simple and effective. If it works, it works.

Tylko zalogowani Zaloguj się, aby wyświetlić chronioną treść Ten post zawiera treści dostępne tylko dla członków. Zaloguj się lub utwórz konto, aby odblokować całą zawartość tego posta. Zaloguj się Utwórz konto

However, today I started wondering why this happens. At first I blamed the "slowness" of affect loading.
I then discovered that quests are simply loaded before affects.

Swapping the order (initialize affects before quests) does work, because queries are executed in FIFO order on the SQL thread.
At first I thought this wasn’t guaranteed and considered it unsafe, but after reviewing the SQL layer it’s clear the order is deterministic.
Still, I preferred a more robust fix: always using the quest_login_event, and delaying the login trigger until both PHASE_GAME and IsLoadedAffect() are satisfied.

Eventually, I traced it back to the exact piece of code that calls the login trigger, inside QuestLoad, at the end:

So, during loading it now checks if the character is in PHASE_GAME.
If not, it calls the quest_login_event timer, which will keep checking and delaying by one second until IsPhase is actually PHASE_GAME, at that point we are safely in-game.

Basically, those two lines of code, the sys_log with QUEST_LOAD and the trigger call, were just copy-pasted into the event if the conditions were met.
So I decided to keep the event and remove the direct login trigger.

Ok, now we will call the event everytime, let's see how it looks

It delays by one second until IsPhase is PHASE_GAME.
So let’s add an extra check: make it delay by one second until IsLoadedAffect() is true as well.

That's all.

If you want just the simple fix:

If you are using marty files you don't need this additional fix, he's already doing that.

IsLoadedAffect is only set if you actually have an Affect or LoadAffect won't load, which is a problem.
Not only for this fix, but in general, IsLoadedAffect is used in anti-exploit contexts.

It is necessary that they are loaded even if you do not have affect, so, you got another fix there

Edytowane 13 Października 202513 Paź przez Mitachi

Ciekaw jestem różnicy miedzy tym a starym martysamy ładowanego z RESULT_AFFECT_LOAD.

W dniu 12.10.2025 o 21:12, Dex666 napisał(a):

Ciekaw jestem różnicy miedzy tym a starym martysamy ładowanego z RESULT_AFFECT_LOAD.

Hi, this post is about fixing another issue, specifically the when login trigger in quests.

I made the when login trigger start only if affects have been initialized, to solve the problem explained above.

To make that work correctly, I added a simple logic: when initializing, it always sends an empty affect list.

This ensures that even if a character has 0 affects, the system still considers affects as loaded.

I later discovered that Martysama had already done something equivalent in his fixme402, which I wasn’t aware of before.

fixme402 simply makes LoadAffect run unconditionally, even if there are 0 affects, which is exactly what I did manually.

This change is essential, because otherwise, if the player has no affects, the when login quests would never start.

I suppose Marty faced the same issue when he added IsLoadedAffect to UseItemEx to prevent affect exploits.
Once he realized that items couldn’t be used with 0 affects, he made the same kind of fix.

So in short, his fixme402 and my latest code in QID_AFFECT are functionally identical, and that’s why I said not to use mine if you already have Marty’s fix
use only the actual fix to the topic issue, in the code block above.