Familiar are invincible if scripts are inactive

[RiwsPy]

La mort du familier est gérée par son script.
Mais certains éléments, notamment certains états bloquent l’exécution des scripts, c'est notamment le cas pour :

• Charme
• Confusion
• Débilité mentale
• Berserk
• Panique, dans une moindre mesure

Dans ces états, le personnage ne tombera pas au sol car son script n'est plus actif.
Plusieurs pistes sont envisageables :

• Gérer l'effet via l'objet JOMINHP1 (un peu comme les trolls) avec des limitations
• Gérer l'effet via un autre personnage (compliqué)
• Protéger le personnage contre ces états
• ... ?

[11jo]

Exceptionnellement on pourraient ajouter un bloc aux Baldur.bcs

IF
	TriggerOverride([ANYONE],!Global("JO_JOIN_IS_TRAVELER","LOCALS",0))
	TriggerOverride([ANYONE],State_To_Deal_With))
	TriggerOverride([ANYONE],HPLT(Myself,2))
THEN
	RESPONSE #100
		SetInterrupt(FALSE)
		SmallWait(1)
		SetGlobalTimer("JO_JOIN_TIMER_DEAD","LOCALS",ONE_TURN)
		SetGlobal("JO_JOIN_SLEEPING_DEAD","LOCALS",1)
		ChangeEnemyAlly(Myself,NEUTRAL)
		SetSequence(SEQ_DIE)
		Wait(2)
		ReallyForceSpellRES("JOIN648",Myself)
		SetGlobal("JO_Myself_AllowDead","LOCALS",0)
		TriggerOverride([ANYONE],Dissipe_State_To_Deal_With)) // ou simplement dissipé par JOIN648.spl
		SetInterrupt(TRUE)
END

Bon je suppose que en l'état ce ne sera pas suffisant, et que ANYONE n'est peut-être pas une solution viable.

Vois-tu quelque chose de possible dans cette idée ?

[11jo]

Ah et sinon peut-être :

Dans baldur.bcs

IF
	TriggerOverride([ANYONE],!Global("JO_JOIN_IS_TRAVELER","LOCALS",0))
	TriggerOverride([ANYONE],State_To_Deal_With))
THEN
	RESPONSE #100
		CreateCreature("JO_JOINV") // Invisible creature
		Continue()
END

Et la creature disposerait d'un bcs contenant un bloc pour chaque Traveler potentiel

IF
	TriggerOverride("Kivan",!Global("JO_JOIN_IS_TRAVELER","LOCALS",0))
	OR(4)
                 StateCheck("Kivan",Charmed)
                 StateCheck("Kivan",Berserk)
                 StateCheck("Kivan",....)
                 StateCheck("Kivan",.....)
THEN
	RESPONSE #100
		SetInterrupt(FALSE)
		SmallWait(1)
		SetGlobalTimer("JO_JOIN_TIMER_DEAD","LOCALS",ONE_TURN)
		SetGlobal("JO_JOIN_SLEEPING_DEAD","LOCALS",1)
		ChangeEnemyAlly(Myself,NEUTRAL)
		SetSequence(SEQ_DIE)
		Wait(2)
		ReallyForceSpellRES("JOIN648",Myself)
		SetGlobal("JO_Myself_AllowDead","LOCALS",0)
		TriggerOverride("Kivan",Dissipe_State_To_Deal_With)) // ou simplement dissipé par JOIN648.spl
		SetInterrupt(TRUE)
		Continue()
END

[RiwsPy]

C'est possible, c'est proche de la solution "autre personnage".
Il faut à minima remplacer les TriggerOverride([ANYONE] par TriggerOverride("%Death_var%", donc autant de bloc que de PNJ.
Tout ça dans baldur, ça fait beaucoup.

[11jo]

Histoire de ne pas avoir plein de blocs dans baldur.bcs, ne peut pas se contenter de Anyone, dans ce cas qui que se soit sous l'un des effets convoqueras la créature, mais son script personnel ne réagiras qu'aux travelers si l'un d'entre eux est bien sous les effets escomptés

Baldur.bcs // Juste 1 bloc

IF
	TriggerOverride([ANYONE],!Global("JO_JOIN_IS_TRAVELER","LOCALS",0))
	TriggerOverride([ANYONE],State_To_Deal_With))
	!Exists("JO_JOINV")
THEN
	RESPONSE #100
		CreateCreature("JO_JOINV") // Invisible creature
END

à la fin JO_JOINV.baf

IF
	!TriggerOverride([ANYONE],!Global("JO_JOIN_IS_TRAVELER","LOCALS",0))
	!TriggerOverride([ANYONE],State_To_Deal_With))
	!InMyArea(FAMILIAR) // ou on ajoute tous les familiers potentiels
THEN
	RESPONSE #100
		DestroySelf()
END

[RiwsPy]

Non, [ANYONE] est indépendant de la condition du TriggerOverride.

TriggerOverride([ANYONE],!Global("JO_JOIN_IS_TRAVELER","LOCALS",0))
Ne veut pas dire : la première personne trouvée avec JO_JOIN_IS_TRAVELER != 0.
Mais : est-ce que la première personne trouvée a JO_JOIN_IS_TRAVELER != 0, ce qui est complètement différent.

[11jo]

IF
	OR(46...)
	            TriggerOverride("%Death_var_1%",State_1_To_Deal_With))
	            TriggerOverride("%Death_var_2%",State_1_To_Deal_With))
	            ...
	            TriggerOverride("%Death_var_1%",State_2_To_Deal_With))
                    TriggerOverride("%Death_var_2%",State_2_To_Deal_With))
                     ...
	            TriggerOverride("%Death_var_1%",State_3_To_Deal_With))
                    TriggerOverride("%Death_var_2%",State_3_To_Deal_With))
                     ...
	!Exists("JO_JOINV")
THEN
	RESPONSE #100
		CreateCreature("JO_JOINV") // Invisible creature
END

Un bloc lourd mais un seul bloc.

IF
	OR(4...)
	            TriggerOverride([GOODCUTOFF],State_1_To_Deal_With)
	            TriggerOverride([GOODCUTOFF],State_2_To_Deal_With)
	            TriggerOverride([GOODCUTOFF],State_3_To_Deal_With)
	            TriggerOverride([GOODCUTOFF],State_4_To_Deal_With)
THEN
	RESPONSE #100
		CreateCreature("JO_JOINV") // Invisible creature
END

Ou

IF
	OR(4...)
                    SpellCastOnMe([GOODCUTOFF],State_1_To_Deal_With)
                    SpellCastOnMe([GOODCUTOFF],State_2_To_Deal_With)
                    SpellCastOnMe([GOODCUTOFF],State_3_To_Deal_With)
                    SpellCastOnMe([GOODCUTOFF],State_4_To_Deal_With)
THEN
	RESPONSE #100
		CreateCreature("JO_JOINV") // Invisible creature
END

Ou

IF
	OR(4...)
	            CheckStat(([GOODCUTOFF]),1,State_1_To_Deal_With)
	            CheckStat(([GOODCUTOFF]),1,State_2_To_Deal_With)
	            CheckStat(([GOODCUTOFF]),1,State_3_To_Deal_With)
	            CheckStat(([GOODCUTOFF]),1,State_4_To_Deal_With)
THEN
	RESPONSE #100
		CreateCreature("JO_JOINV") // Invisible creature
END

[RiwsPy]

Un bloc avec un OR(46) n'est pas mieux que 46 blocs de une ligne ^^
Tu peux le faire ainsi, et après refaire 46 blocs dans le script de la créature pour cibler le bon personnage.
Ça reste lourd.

On pourrait plus simplement faire une créature avec 46 blocs en continu qui ne soit pas baldur. Mais est-ce mieux ?

Je vais regarder s'il est possible de gérer seulement ces cas via l'item.

[11jo]

Les exemple avec GOODCUTOFF sont pas à peu près fonctionnel non plus ?

Avec l'item on aura juste la possibilité de les protéger des effets ou d'autres choses sont possibles ?

On pourrait plus simplement faire une créature avec 46 blocs en continu qui ne soit pas baldur. Mais est-ce mieux ?

ça devrait pas être trop gênant, elle fait un tour de script puis disparaît, enfin c'est comme ça que je l'imagine.

[RiwsPy]

Les exemple avec GOODCUTOFF sont pas à peu près fonctionnel non plus ?

GOODCUTOFF va filtrer plus mais la problématique restera la même, le script s'arrêtera sur le premier personnage trouvé.
Il sera peut-être bon mais il n'en ciblera pas d'autres. On a besoin de pouvoir cibler tout le monde.
La seule solution me semble être de faire un bloc pour chaque Death_var, ou peut-être un IF massif si on arrive à tout traiter en une ligne.

Avec l'item on aura juste la possibilité de les protéger des effets ou d'autres choses sont possibles ?

L'idée c'est de simuler le bloc avec ReallyForceSpell.
Si je limite cet effet aux states mentionnés plus haut, ça pourrait être une alternative intéressante.
Ça sera sans doute plus limité, mais ça devrait être fonctionnel.

ça devrait pas être trop gênant, elle fait un tour de script puis disparaît, enfin c'est comme ça que je l'imagine.

Je ne pense pas que se soit une bonne idée de la désactiver.
On ne sait pas vraiment quand ces cas vont se produire.
Donc on aura besoin de checker un peu tout le temps.

[RiwsPy]

J'ai fait des tests.
Ce qui est sûr c'est que je ne peux pas lancer le timer JO_JOIN_TIMER_DEAD.
Pour le reste, il faudrait peaufiner.

Ça fonctionne mal pour le STATE_CHARMED car il reste charmé. Faut creuser.
Ça fonctionne pas pour le STATE_PANIC, la dissipation ne fonctionne pas, je dois creuser aussi.
Pour STATE_CONFUSED et STATE_BERSERK, il s'immobilise debout. Peut-être en rajoutant un délai mais ça fait beaucoup de délai entre le moment où l'object s'active, le personnage tombe puis s'immobilise.
Pour STATE_FEEBLEMINDED, c'est bien.

Par contre pour réinitialiser des variables comme JO_Myself_Valid ou JO_Myself_InParty c'est pertinent.

[11jo]

Ok, te casse pas trop la tête sur les STATEs non plus, au pire on fera comme tu as dis et les familiers seront protégés contre ces effets particuliers et difficilement gérables.

D'ailleurs cela sera surement plus cool pour les joueurs, même si c'est un peu grosbill quand même.

[RiwsPy]

C'est carrément grosbill même.

À minima je vais pousser la base pour les variables et la débilité mentale. On pourra peaufiner plus tard.