Aller au contenu


[résolu] Placer Un Static Sous Le Personnage


  • Veuillez vous connecter pour répondre
4 réponses à ce sujet

#1 Doublevil

Doublevil

Posté 29 août 2009 - 13:22

[EDIT : Sujet résolu, voir réponse numéro 4]


Bonjour,
Alors voilà, je fais pour mon propre usage un sort qui est censé placer un rocher sous le PJ et le faire monter jusqu'à un certain point (le rocher soulève alors le PJ).
Mon rocher, "CC_magicRockp", est donc en "reference persists", il est initialement placé à un endroit d'où je peux le surveiller pendant test, il monte correctement, mais ne se place pas sous le PJ : en fonction de la fonction utilisée pour le positionner, il disparaît ou ne bouge pas.

Voici le code, avec
Begin _CC_Global_EarthSpell
;Script global qui, quand le joueur lance le sort "Appel de roc", fait apparaître le rocher sous le sol
;Ensuite le rocher monte jusqu'à un certain point où il s'arrête.

short progress
short jpZ
short jpX
short jpY
float timer

if ( player->GetSpellEffects, "_CC_magie_terre" == 1 )
	if ( progress == 0 )
		(...) ;Vérification de si le PJ est en intérieur ou en l'air, ...
		else ;Si le PJ peut lancer le sort
			Set jpX to "player"->GetPos, x
			Set jpY to "player"->GetPos, y
			Set jpZ to "player"->GetPos, z
			Set jpZ to jpZ - 200
			
			;Ici, on active une seule des 4 méthodes séparées par une ligne vide
			
			;CC_magicRockp->SetDelete 1
			;PlaceAtPC "CC_magicRockp" 1 1 1
			
			;CC_magicRockp->Position jpX, jpY, jpZ, 0
			
			;CC_magicRockp->SetDelete 1
			;PlaceItem "CC_magicRockp" jpX jpY jpZ 0
			
			;CC_magicRockp->SetPos x jpX
			;CC_magicRockp->SetPos y jpY
			;CC_magicRockp->SetPos z jpZ
			
			Set progress to 1
		endif
	endif
endif

(...) ;Définition de ce qui se passe lorsque progress = -1

if ( progress == 1 )
	Set timer to timer + GetSecondsPassed
	if ( timer < 3 )
		CC_magicRockp->MoveWorld z, 100
		Set jpX to CC_magicRockp->(GetPos x)
		Set jpY to CC_magicRockp->(GetPos y)
		Set jpZ to CC_magicRockp->(GetPos z)
		CC_magicRockp->SetDelete 1
		PlaceItem "CC_magicRockp" jpX jpY jpZ 0
	else
		Set progress to 0
		Set timer to 0
	endif
endif

end

Le rocher est censé se téléporter sous le joueur (ou en tout cas au niveau du joueur, juste pour des tests, à ajuster quoi) dans la première condition, vous l'aurez compris.
Ce script est un script global qui n'est donc attaché à rien, démarré à l'endroit d'obtention du sort.
Le rocher, lui, n'a aucun script attaché.

J'ai retenu 4 méthodes différentes pour téléporter le rocher sous le joueur mais aucune ne fonctionne correctement :
1) CC_magicRockp->SetDelete 1
    PlaceAtPC "CC_magicRockp" 1 1 1
Avec cette méthode, le rocher initialement placé ne disparaît pas malgré le SetDelete 1, un nouveau apparaît sur le PJ et ne bouge pas, il est intangible.

2) CC_magicRockp->Position jpX, jpY, jpZ, 0
Avec cette méthode, le rocher initialement placé disparaît et rien ne réapparaît. La console ne me répond rien quand je lui demande la position de CC_magicRockp, bref, il a disparu.

3) CC_magicRockp->SetDelete 1
    PlaceItem "CC_magicRockp" jpX jpY jpZ 0
Avec cette méthode, le rocher initial ne bouge pas, rien n'apparaît et le rocher initial monte. Si on est sur le rocher initial quand on lance le sort, il porte le PJ comme il faut.

4) CC_magicRockp->SetPos x jpX
    CC_magicRockp->SetPos y jpY
    CC_magicRockp->SetPos z jpZ
Avec cette méthode, enfin, le rocher initial disparaît et n'a plus de position, comme pour la 2).



Bref voilà, tout ça pour dire : "Môman, comment on fait pour déplacer un static sous le PJ ?"
Si vous avez des idées (solutions ?)... merci d'avance de les partager.



[EDIT : Sujet résolu, voir réponse numéro 4]

Modifié par Gilgamesh-, 29 août 2009 - 21:42.


#2 elendell

elendell

    Mécano Dell'Arte


Posté 29 août 2009 - 16:26

Bonjour Gilgamesh,

Je pense que la principale cause de tes difficultés vient du fait que, le rocher étant un static et non un activateur, tu fais tout avec un script global. Y a-t-il une raison à cela ?

Avec un script local, tu n'aurais aucun problème. Le script global lancerait juste le "PlaceAtPC" suivant les conditions voulues (sort lancé, extérieur, etc.) et le local ferait tout le reste. Ce serait bien que tu mettes éventuellement l'intégralité du script. Mais il y a quand même des erreurs dans cette partie essentielle.


Voir le messageGilgamesh-, le 29.08.2009 à 14:21, dit :

short jpZ
short jpX
short jpY
Les coordonnées comportent des décimales. Ces variables doivent donc être déclarées en "float".

Voir le messageGilgamesh-, le 29.08.2009 à 14:21, dit :

1) CC_magicRockp->SetDelete 1
    PlaceAtPC "CC_magicRockp" 1 1 1
Avec cette méthode, le rocher initialement placé ne disparaît pas malgré le SetDelete 1, un nouveau apparaît sur le PJ et ne bouge pas, il est intangible.
"PlaceAtPC" place une nouvelle référence de rocher mais ton script est un global qui ne peut fonctionner sans problème que si l'objet est unique. Tu lui dit de faire dans la même frame une suppression + un placement et peut-être même (difficile de savoir avec le script incomplet) un "MoveWorld" et un placement supplémentaire d'une autre référence.

Voir le messageGilgamesh-, le 29.08.2009 à 14:21, dit :

2) CC_magicRockp->Position jpX, jpY, jpZ, 0
Avec cette méthode, le rocher initialement placé disparaît et rien ne réapparaît. La console ne me répond rien quand je lui demande la position de CC_magicRockp, bref, il a disparu.
Quoi qu'en dise le MSfD, je n'ai jamais réussi à utiliser "Position/PositionCell" avec des variables. Et ce n'est pas faute d'avoir tout tenté.
Il est fort probable (et tu peux le vérifier en y allant) que le rocher soit positionné à 0, 0, 0, 0.

Voir le messageGilgamesh-, le 29.08.2009 à 14:21, dit :

3) CC_magicRockp->SetDelete 1
    PlaceItem "CC_magicRockp" jpX jpY jpZ 0
Avec cette méthode, le rocher initial ne bouge pas, rien n'apparaît et le rocher initial monte. Si on est sur le rocher initial quand on lance le sort, il porte le PJ comme il faut.
Mêmes causes que pour "PlaceAtPC". J'utilise "PlaceItem" sans problème avec un objet qui se remplace toutes les 4 frames (justement à cause de l'impossibilité d'utiliser "Position" avec des variables). Mon premier "PlaceItem" est fait par un script global mais il n'y a pas de "SetDelete" dans la même frame. Ensuite, c'est le local de l'objet lui-même qui en place un nouveau pour le remplacer, toutes les 4 frames.
Par contre, il fait en même temps un "disable" suivi d'un "return" en début de script, pour qu'il arrête de se mouvoir avant le "SetDelete" qui se fait (toujours dans le local) 2 frames plus tard. C'est bien sûr le remplaçant qui continue le déplacement.

Voir le messageGilgamesh-, le 29.08.2009 à 14:21, dit :

4) CC_magicRockp->SetPos x jpX
    CC_magicRockp->SetPos y jpY
    CC_magicRockp->SetPos z jpZ
Avec cette méthode, enfin, le rocher initial disparaît et n'a plus de position, comme pour la 2).
Normalement, "SetPos" devrait fonctionner sans souci car c'est un objet. (Avec des acteurs, il y a des risques car le jeu ne vérifie pas forcément la position finale mais chaque "SetPos" l'un après l'autre, et dans ce cas, la position intermédiaire peut générer un placement dans un tout autre endroit pour éviter une collision).

Mais tu dois essayer de nouveau avec les variables en "float". Il y a des chances que ce soit ce qui l'empêche de trouver la position et dans ce cas, il le placerait encore une fois à 0, 0, 0, 0. A part ça, il faut bien sûr que tu ais Tribunal pour l'utiliser avec des variables (locales).

Il y a aussi quelque chose que je ne comprends pas à la fin du script :

Voir le messageGilgamesh-, le 29.08.2009 à 14:21, dit :

if ( progress == 1 )
	Set timer to timer + GetSecondsPassed
	if ( timer < 3 )
		CC_magicRockp->MoveWorld z, 100
		Set jpX to CC_magicRockp->(GetPos x)
		Set jpY to CC_magicRockp->(GetPos y)
		Set jpZ to CC_magicRockp->(GetPos z)
		CC_magicRockp->SetDelete 1
		PlaceItem "CC_magicRockp" jpX jpY jpZ 0
	else
		Set progress to 0
		Set timer to 0
	endif
endif

end

Tu fais dans le même bloc un déplacement, une suppression et un placement de nouvelle référence et ce, à toutes les frames pendant 3 secondes !  ;)

De plus, je ne sais pas si c'est une erreur de frappe mais la condition première est "if ( progress == 1 )". Or, "progress" est mis à 1 dans la même frame dans le bloc au dessus et ce bloc de dessus est déjà sensé faire un placement.

PS : Quand ça fonctionnera, tu auras probablement un autre problème. Quand on place un objet, ses données de collision ne fonctionnent pas tant que le PJ ne change pas de cellule. Le rocher montera mais ne soulèvera donc plus le PJ. La collision fonctionnait dans ta solution 3 car c'était le rocher déjà en place et pas celui placé par script.

L'astuce qui m'avait été indiquée par Von Zeeple est simple : Il faut faire un "disable" suivi d'un "enable" et c'est normalement suffisant.

#3 Doublevil

Doublevil

Posté 29 août 2009 - 17:29

Bonjour et merci,

Citation

Je pense que la principale cause de tes difficultés vient du fait que, le rocher étant un static et non un activateur, tu fais tout avec un script global. Y a-t-il une raison à cela ?
En fait, j'ai pensé pouvoir tout faire avec mon script global. Je me doutais bien que ça marcherait mieux avec un script local sur le rocher mais je voyais pas trop comment organiser tout ça (ce que je devais attacher au rocher, ce que je devais garder pour le script global). En fait en y repensant et grâce à toi ça m'a l'air simple. Je vais donc essayer comme ça.

Citation

Les coordonnées comportent des décimales. Ces variables doivent donc être déclarées en "float".
Owiii quel boulet x) Le pire c'est que je ne m'en serais certainement jamais rendu compte. Merci.

Citation

"PlaceAtPC" place une nouvelle référence de rocher mais ton script est un global qui ne peut fonctionner sans problème que si l'objet est unique. Tu lui dit de faire dans la même frame une suppression + un placement et peut-être même (difficile de savoir avec le script incomplet) un "MoveWorld" et un placement supplémentaire d'une autre référence.
Je ne pensais pas que ça posait problème de faire une suppression puis un placement dans la même frame ;)
Le MoveWorld, je le fais après avoir attendu une seconde en fait, mais j'ai supprimé cette partie du script, la pensant inutile.

Citation

Quoi qu'en dise le MSfD, je n'ai jamais réussi à utiliser "Position/PositionCell" avec des variables. Et ce n'est pas faute d'avoir tout tenté.
Il est fort probable (et tu peux le vérifier en y allant) que le rocher soit positionné à 0, 0, 0, 0.
Ah, dommage, c'était ma préférée :lol:
Mais la console ne me dit rien quand je lui demande la position du rocher, j'en ai conclu qu'il n'était plus dans le jeu, enfin ça m'aurait dit "0" si il avait été placé en (0,0,0)... sauf si le jeu ne peut pas donner la position d'un objet qui n'est pas actuellement "chargé" (?).

Citation

Mêmes causes que pour "PlaceAtPC". J'utilise "PlaceItem" sans problème avec un objet qui se remplace toutes les 4 frames (justement à cause de l'impossibilité d'utiliser "Position" avec des variables). Mon premier "PlaceItem" est fait par un script global mais il n'y a pas de "SetDelete" dans la même frame. Ensuite, c'est le local de l'objet lui-même qui en place un nouveau pour le remplacer, toutes les 4 frames.
Par contre, il fait en même temps un "disable" suivi d'un "return" en début de script, pour qu'il arrête de se mouvoir avant le "SetDelete" qui se fait (toujours dans le local) 2 frames plus tard. C'est bien sûr le remplaçant qui continue le déplacement.
Bon après avoir relu 5-6 fois je crois que j'ai compris le principe :paladin: . Mais pourquoi 2 frames plus tard le SetDelete et pas une seule frame ?

Citation

Normalement, "SetPos" devrait fonctionner sans souci car c'est un objet. [...]
Mais tu dois essayer de nouveau avec les variables en "float". Il y a des chances que ce soit ce qui l'empêche de trouver la position et dans ce cas, il le placerait encore une fois à 0, 0, 0, 0. A part ça, il faut bien sûr que tu ais Tribunal pour l'utiliser avec des variables (locales).
D'accord... et pour Tribunal, je me suis rendu compte que je ne l'avais pas chargé avec le TESCS, ça prend quand même en compte les modifications et les ajouts de fonctions ? J'ai pas fait attention. Enfin de toute façon si j'utilise une fonction Tribunal, le module en sera dépendant donc autant le charger.

Citation

Tu fais dans le même bloc un déplacement, une suppression et un placement de nouvelle référence et ce, à toutes les frames pendant 3 secondes !
Euuh... oui et alors ? :mdr: En fait je ne croyais pas que ça pouvait poser problème, ça ne me paraît pas si lourd que ça, franchement.

Citation

De plus, je ne sais pas si c'est une erreur de frappe mais la condition première est "if ( progress == 1 )". Or, "progress" est mis à 1 dans la même frame dans le bloc au dessus et ce bloc de dessus est déjà sensé faire un placement.
Comme dit plus haut, j'ai choisi de supprimer l'attente de 1 seconde que j'avais mis en place en postant mon code. J'aurai du le mettre en entier décidément.

Citation

PS : Quand ça fonctionnera, tu auras probablement un autre problème. Quand on place un objet, ses données de collision ne fonctionnent pas tant que le PJ ne change pas de cellule. Le rocher montera mais ne soulèvera donc plus le PJ. La collision fonctionnait dans ta solution 3 car c'était le rocher déjà en place et pas celui placé par script.

L'astuce qui m'avait été indiquée par Von Zeeple est simple : Il faut faire un "disable" suivi d'un "enable" et c'est normalement suffisant.
Alors ça ça m'avait posé problème déjà auparavant. Je pensais que la suppression et le placement de l'objet mettait à jour les collisions. En fait, j'utilisais avant ça disable et enable à chaque frame (tu les mets dans la même frame hein ?) mais le rocher était alors mal texturé après lancement du sort. Il portait des textures issues d'un peu n'importe où dans la même cellule je crois, et un rocher avec une texture de cheveux d'Aldmer, c'est moche. En plus, ça plantait quand je m'approchais du rocher (en fait les textures changeaient selon la distance de vue, et quand on était trop près ça plantait le jeu). Quand j'ai désactivé les disable-enable, ça l'affichait correctement.
J'ai cru remplacer l'effet de mise à jour des collisions par une suppression et un replacement. Mais donc à quoi ça sert la suppression et le replacement ? J'ai cru comprendre qu'il y avait un problème si le "véhicule" sortait de sa cellule initiale et que ça servait à corriger ce problème, mais dans mon cas, finalement, comme le rocher ne se déplace que sur l'axe Z, ça n'est pas nécessaire, si ?

Je ne donne pas mon code en entier, je vais tout refaire en global et en local, je le donnerai (en entier, cette fois) si il ne fonctionne toujours pas.
Merci beaucoup en tout cas d'avoir pris le temps de me répondre de manière aussi complète.

#4 elendell

elendell

    Mécano Dell'Arte


Posté 29 août 2009 - 18:41

Voir le messageGilgamesh-, le 29.08.2009 à 18:28, dit :

Je ne pensais pas que ça posait problème de faire une suppression puis un placement dans la même frame ;)
A moins de savoir précisément comment fonctionne le moteur du jeu dans toutes les situations, il ne faut pas prendre de risque inutile.
On a tous rencontré des bugs bizarres qui ne se produisent que dans un cas précis. Laisser 2 frames avant de faire "SetDelete" par exemple est une vieille habitude, la plupart du temps inutile. Mais j'ai plusieurs fois rencontré des situations où une instruction n'était validée qu'après une frame de décalage et où j'ai dû modifier mes scripts à cause de ça. Par exemple, des "Get" ou encore ce que faisait remarquer avant-hier alliop sur "CellChanged". Là, le jeu reçoit dans la même frame l'instruction de supprimer un objet et celle de le placer. Logiquement, elles devraient se dérouler dans l'ordre où tu les as écrites mais est-ce que la suppression est totalement terminée et validée avant qu'il lise l'autre instruction ? (Je te rappelle que si une inscription pointe une "ID" qui n'est pas unique, le jeu la fera faire au premier de ces objets qu'il trouvera).

Voir le messageGilgamesh-, le 29.08.2009 à 18:28, dit :

Mais la console ne me dit rien quand je lui demande la position du rocher, j'en ai conclu qu'il n'était plus dans le jeu, enfin ça m'aurait dit "0" si il avait été placé en (0,0,0)... sauf si le jeu ne peut pas donner la position d'un objet qui n'est pas actuellement "chargé" (?).
Il peut donner la position même si l'objet est dans une autre cellule. Si je te dis qu'il est probablement placé à 0, c'est parce que confronté au même problème dans mes essais, j'avais cherché mon objet disparu (je suis tenace quand quelque chose m'échappe !). Et chaque fois, je le retrouvais à 0. Mais je ne te l'ai pas affirmé car il peut toujours y a voir une différence de circonstances (Je suis tenace mais aussi prudent dans ce que j'affirme).


Voir le messageGilgamesh-, le 29.08.2009 à 18:28, dit :

pour Tribunal, je me suis rendu compte que je ne l'avais pas chargé avec le TESCS, ça prend quand même en compte les modifications et les ajouts de fonctions ? J'ai pas fait attention. Enfin de toute façon si j'utilise une fonction Tribunal, le module en sera dépendant donc autant le charger.
Les fonctions sont dans l'exe et pas dans l'esm. Donc, elles devraient logiquement être actives même sans charger l'esm. Mais c'est une bonne habitude de rendre le "mod" dépendant à l'extension qu'il faut avoir pour l'utiliser. J'ai réalisé dernièrement que j'utilisais "PlaceAtMe" dans un "mod" que je ne voulais initialement pas rendre dépendant à Bloodmoon. Certes, le "mod" n'était pas dépendant de l'esm de Bloodmoon mais celui qui n'aurait pas eu Bloodmoon installé aurait eu un message d'erreur (et sans doute un crash).

Voir le messageGilgamesh-, le 29.08.2009 à 18:28, dit :

Citation

Tu fais dans le même bloc un déplacement, une suppression et un placement de nouvelle référence et ce, à toutes les frames pendant 3 secondes !
Euuh... oui et alors ? :paladin: En fait je ne croyais pas que ça pouvait poser problème, ça ne me paraît pas si lourd que ça, franchement.
Ces instructions sont contradictoires et font doublon.

Voir le messageGilgamesh-, le 29.08.2009 à 18:28, dit :

Alors ça ça m'avait posé problème déjà auparavant. Je pensais que la suppression et le placement de l'objet mettait à jour les collisions. En fait, j'utilisais avant ça disable et enable à chaque frame (tu les mets dans la même frame hein ?) mais le rocher était alors mal texturé après lancement du sort. Il portait des textures issues d'un peu n'importe où dans la même cellule je crois, et un rocher avec une texture de cheveux d'Aldmer, c'est moche. En plus, ça plantait quand je m'approchais du rocher (en fait les textures changeaient selon la distance de vue, et quand on était trop près ça plantait le jeu). Quand j'ai désactivé les disable-enable, ça l'affichait correctement.
J'ai cru remplacer l'effet de mise à jour des collisions par une suppression et un replacement. Mais donc à quoi ça sert la suppression et le replacement ? J'ai cru comprendre qu'il y avait un problème si le "véhicule" sortait de sa cellule initiale et que ça servait à corriger ce problème, mais dans mon cas, finalement, comme le rocher ne se déplace que sur l'axe Z, ça n'est pas nécessaire, si ?
Pour les détails, il te faudra faire des essais parce que ça fait longtemps et je ne m'en souviens plus. Mais de toutes façons, tu ne dois pas le faire à chaque frame et effectivement, il n'y a pas la problème des changements de cellule dans la hauteur. Mais tu as quand même besoin de le faire une fois puisque tu vas placer le rocher (avec le script global) et qu'il devra avoir une donnée de collision avant même que le PJ ne change de cellule. Essaye avec la console de placer le rocher et tu comprendras de suite car tu pourras passer au travers.

#5 Doublevil

Doublevil

Posté 29 août 2009 - 21:38

Citation

A moins de savoir précisément comment fonctionne le moteur du jeu dans toutes les situations, il ne faut pas prendre de risque inutile. [...] Logiquement, elles devraient se dérouler dans l'ordre où tu les as écrites mais est-ce que la suppression est totalement terminée et validée avant qu'il lise l'autre instruction ? (Je te rappelle que si une inscription pointe une "ID" qui n'est pas unique, le jeu la fera faire au premier de ces objets qu'il trouvera).
Je trouve complètement illogique de lire une instruction avant que l'exécution de la précédente soit terminée. Je partais du principe que le moteur du jeu était logique, erreur de débutant je suppose.

Citation

Ces instructions sont contradictoires et font doublon.
Je ne vois pas en quoi ;)
Enfin, je déplace le rocher et je le supprime puis en fais apparaître un autre à la dernière position de l'ancien pour mettre à jour les données de collision.
D'ailleurs...

Citation

de toutes façons, tu ne dois pas le faire à chaque frame et effectivement, il n'y a pas la problème des changements de cellule dans la hauteur. Mais tu as quand même besoin de le faire une fois puisque tu vas placer le rocher (avec le script global) et qu'il devra avoir une donnée de collision avant même que le PJ ne change de cellule. Essaye avec la console de placer le rocher et tu comprendras de suite car tu pourras passer au travers.
Je ne comprends plus là. Le système enable/disable, c'est pour quoi faire ? Et le système de placement/suppression ?
Jusqu'à présent je croyais que enable/disable servait à rendre les collisions actives mais là tu me dis que je dois utiliser le système de placement/suppression pour activer les collisions.








[EDIT]
Voilà, c'est bon, tout fonctionne. Je détaille et je donne mon script au cas où quelqu'un voudrait faire un truc qui s'en approche, un jour (on ne sait jamais !).

Alors j'ai un script global appelé par un activateur invisible près de l'endroit où on obtient le sort.

Le script global s'occupe de détecter le lancement du sort, et, si les conditions nécessaires à son lancement sont réunies, fait apparaître le rocher sous le joueur.
Voici mon script global :
Begin _CC_Global_EarthSpell
;Script global qui, quand le joueur lance le sort "Appel de roc", fait apparaître le rocher sous le sol
;Ensuite le rocher monte jusqu'à un certain point où il s'arrête.

short progress
float timer

float pX
float pY
float pZ

if ( player->GetSpellEffects, "_CC_magie_terre" == 1 )
	if ( progress == 0 )
		if ( GetPCJumping == 1 )
			MessageBox "Vous ne pouvez pas lancer ce sort lorsque vous êtes en l'air."
		elseif ( GetInterior == 1 )
			MessageBox "Vous ne pouvez lancer ce sort qu'à l'extérieur."
		elseif ( "player"->GetPos z < 0 )
			MessageBox "Vous ne pouvez pas lancer ce sort lorsque vous êtes dans l'eau."
		else
			Set pX to "player"->GetPos x
			Set pY to "player"->GetPos y
			Set pZ to "player"->GetPos z
			Set pZ to pZ - 400
			PlaceItem "CC_magicRock" pX pY pZ 0
		endif
	Set progress to -1
	endif
endif

if ( progress == -1 );Pour éviter que l'effet réapparaîsse alors que le rocher n'a pas encore disparu.
	Set timer to timer + GetSecondsPassed
	if ( timer > 5 )
		Set progress to 0
		Set timer to 0
	endif
endif

end

CC_magicRock est un activateur auquel est attaché un script qui le fait monter jusqu'à un certain point au bout duquel il s'arrête de bouger.
Voici son script :
Begin _CC_magicRockScript

short progress
short update
float timer

if ( progress == 0 )
	Set update to update+1
	Set timer to timer + GetSecondsPassed
	if ( timer < 3 )
		MoveWorld z 120
	else
		Set timer to 0
		Set progress to 1
	endif
	
	if ( update >= 3 )
		disable
		enable
		Set update to 0
	endif
endif

if ( progress == 1 )
	if ( player->GetSpellEffects "_CC_magie_terre" == 1 )
		Set progress to 2
		disable
		return
	endif
elseif ( progress == 2 )
	Set progress to 3
elseif ( progress == 3 )
	SetDelete 1
endif

end
Je vais peut-être encore l'améliorer (faire en sorte que le rocher rentre sous terre au lieu de disparaître purement et simplement) mais peu importe.

Merci beaucoup Elendell d'avoir pris le temps de m'aider :paladin:

Modifié par Gilgamesh-, 29 août 2009 - 21:42.





0 utilisateur(s) li(sen)t ce sujet

0 membre(s), 0 invité(s), 0 utilisateur(s) anonyme(s)