t_spawn_item about source-x

[xwerswoodx]

I see what you mean, I don't think it's hard thing to fix but the problem is I am not sure if this is a bug or not, because I think they should decay in time and respawn after it's time ticked, but we may add some sort of FLAG in sphere.ini for it.

[Jhobean]

I see what you mean, I don't think it's hard thing to fix but the problem is I am not sure if this is a bug or not, because I think they should decay in time and respawn after it's time ticked, but we may add some sort of FLAG in sphere.ini for it.

If item is link with spawn point they should not decay.

[Jhobean]

Optimisation can be done and item generate with spawn point could have timer -1 direct without attr_decay

[xwerswoodx]

I said this because it's intentionally set decayed in source;

pItem->SetDecayTime(g_Cfg.m_iDecay_Item); // it will decay eventually to be replaced later

So I can add some flag for blocking to set decay time if someone doesn't want them to decay.

Or for a quick solution, you can add

On=@Spawn
TIMER=-1

inside the global item event (that defined in sphere.ini).

[xMirroRx]

Yes, I found exactly such a solution. Actually, the reason why I posted this here was to understand whether it was a mistake or not, and it was also annoying because when a different item was linked to the items created with t_spawn_item, all of these linked items gave warnings during saving. I wanted to let you know.

[Jhobean]

Good idea to set timer -1 on spawn

personnaly I did that (Remove attr Decay and set to -1 automatic after timer)

ON=@TIMER
ATTR &=~ 02
RETURN 1

If we want avoid changing some behavior, maybe we should modify nothing? Or set an ini switch...