21 réponses à ce sujet

[Mordicus]

Je continue à travailler sur mon mod sonore pour ajouter des effets ambiants. Il y a deux mods qui ajoutent des sons extérieurs (pluie, vent, etc.) à l'intérieur des maisons, celui de Kirel (Kirel Interior Weather), qui est très intelligent et qui est compatible avec n'importe quel autre mod (sons ajouter dynamiquement par scripts), et le bon vieux ASE, avec ses scripts indigestes.

Le seul ennui avec les scripts de Kirel, c'est que l'on entend toujours la pluie à l'intérieur des maisons et des  cavernes, même lorsqu'on est au sous-sol, ou très loin de l'entrée. Ce qui n'est pas réaliste. Du coup j'essaie de voir si on peut drastiquement alléger les scritps d'ASE.

ASE utilise plusieurs scripts avec la variable globale _ase_zstart suivante qui effectue un check exhaustif de la position du PC... C'est déjà très lourd :

begin _ase_get_zstart_stone01

	if ( getpccell "Vos, chapelle de Vos" == 1 )
		set "_ase_zstart" to 173
	elseif ( getpccell "Vos, ferme d'Ulvil Llothas" == 1 )
		set "_ase_zstart" to 12
	elseif ( getpccell "Vos, ferme de Thilse Aralas" == 1 )
		set "_ase_zstart" to 269
	elseif ( getpccell "Vivec, la Tête de Lézard" == 1 )
		set "_ase_zstart" to -114
	elseif ( getpccell "Vivec, les Fleurs d'Or" == 1 )
		set "_ase_zstart" to -117
	
		..................
		
		(LA LISTE EST TRES LONGUE !)
		
			..................

	elseif ( getpccell "Caldéra, tour de garde de la mine" == 1 )
		set "_ase_zstart" to 1013
	elseif ( getpccell "Caldéra, palais du gouverneur" == 1 )
		set "_ase_zstart" to 147
	elseif ( getpccell "Fort Silène, tours" == 1 )
		set "_ase_zstart" to -1125
	elseif ( getpccell "Fort Silène, prison" == 1 )
		set "_ase_zstart" to 267
	elseif ( getpccell "Fort Silène, Intérieur" == 1 )
		set "_ase_zstart" to 94
	endif

	player -> startscript "_ase_get_zstart_stone02"
	player -> stopscript "_ase_get_zstart_stone01"

end

Puis, lorsque le PJ entre dans une maison en pierre, voici le genre de scripts qu'ASE va lancer (encore très lourd... ) :

Spoiler

begin _ase_in_stone

short done_once

short enter_delay_active
float enter_delay_timer

float px
float py
float pz
float pz_saved
float pz_start

short init_swells
short pos_state
float zlevel
float zlevel_check
float az
float dist_accum
float rnd_dist
float rnd_stay
float rnd_stay_elapsed
float moving_elapsed

short rnd_sound
short snd_playing
float snd_length
float snd_length_saved
float rnd_start_time
float start_time_elapsed
float snd_playing_elapsed

dontsaveobject

; Takes care of initialization upon player changing cells
; from interior to interior or exterior to interior.
if ( cellchanged == 1 )
player -> startscript "_ase_get_zstart_stone01"
set enter_delay_active to 1
set enter_delay_timer to 0
set done_once to 1
endif

; Takes care of initialization upon loading a savegame
; if player saved game in interior. Cellchanged does not
; equal true when this happens.
if ( done_once == 0 )
if ( player -> scriptrunning "_ase_get_zstart_stone01" == 0 )
player -> startscript "_ase_get_zstart_stone01"
endif
set enter_delay_active to 1
set enter_delay_timer to 0
set done_once to 1
endif

; This routine needs to be in here or when entering
; some interiors, the game crashes. It has something
; to do with positioning the activator too soon after
; entering.
if ( enter_delay_active == 1 )
set enter_delay_timer to enter_delay_timer + getsecondspassed
if ( enter_delay_timer < 0.50 )
return
else

if ( player -> scriptrunning "_ase_get_zstart_stone01" == 1 )
return
elseif ( player -> scriptrunning "_ase_get_zstart_stone02" == 1 )
return
elseif ( "_ase_zstart" == 0 )
set pz_start to player -> getpos z
else
set pz_start to "_ase_zstart"
set "_ase_zstart" to 0
endif
set pz_saved to pz_start

set zlevel to 0

set snd_playing to 1
set snd_length_saved to 0
set rnd_start_time to ( random, 11 )
set rnd_start_time to rnd_start_time + 2
set enter_delay_timer to 0
set enter_delay_active to 0
endif
endif

set px to player -> getpos x
set py to player -> getpos y
set pz to player -> getpos z
setpos x px
setpos y py

; Tracks the player's position when going
; up or down a flight of stairs. The variable,
; zlevel, is used as an addition to the activator's
; postion. I would have used the ranges in the
; sound dialog, but even a range of 255 isn't
; enough and it fades in and out way too quickly.
set zlevel to zlevel + ( ( pz_saved - pz ) * 0.46 )
set zlevel_check to pz + zlevel
if ( zlevel_check > pz_start )
set zlevel to 0
endif
set pz_saved to pz

if ( getcurrentweather > 5 )
set az to pz + zlevel
setpos z az
if ( getsoundplaying "_ase_in_stone_dust01" == 0 )
stopsound "_ase_in_stone_rain01"
stopsound "_ase_in_stone_rainthun01"
playloopsound3dvp "_ase_in_stone_dust01", 1.0, 1.0
endif
elseif ( getcurrentweather == 5 )
if ( getsoundplaying "_ase_in_stone_rainthun01" == 0 )
set init_swells to 1
stopsound "_ase_in_stone_rain01"
stopsound "_ase_in_stone_dust01"
playloopsound3dvp "_ase_in_stone_rainthun01", 1.0, 1.0
endif
elseif ( getcurrentweather == 4 )
if ( getsoundplaying "_ase_in_stone_rain01" == 0 )
set init_swells to 1
stopsound "_ase_in_stone_rainthun01"
stopsound "_ase_in_stone_dust01"
playloopsound3dvp "_ase_in_stone_rain01", 1.0, 1.0
endif
else
if ( getsoundplaying "_ase_in_stone_dust01" == 1 )
stopsound "_ase_in_stone_dust01"
elseif ( getsoundplaying "_ase_in_stone_rainthun01" == 1 )
stopsound "_ase_in_stone_rainthun01"
elseif ( getsoundplaying "_ase_in_stone_rain01" == 1 )
stopsound "_ase_in_stone_rain01"
endif
endif

; This routine creates the random rain swells.
if ( getcurrentweather > 3 )
if ( getcurrentweather < 6 )
if ( init_swells == 1 )
set pos_state to 1
set moving_elapsed to 2
set rnd_stay to ( random, 13 );close position
set rnd_stay_elapsed to 0
set rnd_dist to ( random, 176 )
set rnd_dist to ( rnd_dist + 100 ) / 100
set dist_accum to 0
set init_swells to 0
endif
if ( moving_elapsed < 1.50 )
set moving_elapsed to moving_elapsed + getsecondspassed
if ( pos_state == 0 )
set dist_accum to dist_accum + rnd_dist
else
if ( dist_accum > 0 )
set moving_elapsed to 0
set dist_accum to dist_accum - rnd_dist
else
set moving_elapsed to 2
set dist_accum to 0
endif
endif
else
if ( rnd_stay_elapsed < rnd_stay )
set rnd_stay_elapsed to rnd_stay_elapsed + getsecondspassed
else
set moving_elapsed to 0
set rnd_stay_elapsed to 0
if ( pos_state == 0 )
set rnd_stay to ( random, 13 );close position
set pos_state to 1
else
set rnd_stay to ( random, 5 );far position
set pos_state to 0
set rnd_dist to ( random, 176 )
set rnd_dist to ( rnd_dist + 100 ) / 100
endif
endif
endif
set az to pz + dist_accum + zlevel
setpos z az
endif
endif

if ( snd_playing == 1 )
set snd_playing_elapsed to ( snd_playing_elapsed + getsecondspassed )
if ( snd_playing_elapsed >= snd_length_saved )
set start_time_elapsed to 0
set snd_playing to 0
return
else
return
endif
else
if ( snd_playing_elapsed >= snd_length_saved )
set start_time_elapsed to ( start_time_elapsed + getsecondspassed )
if ( start_time_elapsed > rnd_start_time )
if ( getcurrentweather == 5 )
set rnd_sound to ( random, 8 )
set rnd_start_time to ( random, 11 )
set rnd_start_time to rnd_start_time + 2
if ( rnd_sound == 0 )
set snd_length to 3.79
elseif ( rnd_sound == 1 )
set snd_length to 8.73
elseif ( rnd_sound == 2 )
set snd_length to 7.75
elseif ( rnd_sound == 3 )
set snd_length to 7.97
elseif ( rnd_sound == 4 )
set snd_length to 5.71
elseif ( rnd_sound == 5 )
set snd_length to 16.73
elseif ( rnd_sound == 6 )
set snd_length to 3.49
else
set snd_length to 6.37
endif
else
set rnd_sound to -1
set rnd_start_time to 10.00
set snd_length to 10.00
endif
set snd_length_saved to snd_length
set snd_playing to 1
set snd_playing_elapsed to 0
else
return
endif
endif
endif

if ( rnd_sound == -1 )
return
endif

if ( rnd_sound == 0 )
if ( getcurrentweather == 5 )
playsound3d "_ase_in_stone_thun01"
endif
return
endif

if ( rnd_sound == 1 )
if ( getcurrentweather == 5 )
playsound3d "_ase_in_stone_thun02"
endif
return
endif

if ( rnd_sound == 2 )
if ( getcurrentweather == 5 )
playsound3d "_ase_in_stone_thun03"
endif
return
endif

if ( rnd_sound == 3 )
if ( getcurrentweather == 5 )
playsound3d "_ase_in_stone_thun04"
endif
return
endif

if ( rnd_sound == 4 )
if ( getcurrentweather == 5 )
playsound3d "_ase_in_stone_thun05"
endif
return
endif

if ( rnd_sound == 5 )
if ( getcurrentweather == 5 )
playsound3d "_ase_in_stone_thun06"
endif
return
endif

if ( rnd_sound == 6 )
if ( getcurrentweather == 5 )
playsound3d "_ase_in_stone_thun07"
endif
return
endif

if ( rnd_sound == 7 )
if ( getcurrentweather == 5 )
playsound3d "_ase_in_stone_thun08"
endif
return
endif

end

Est-ce que quelqu'un a une idée pour alléger tout ça, ou un autre moyen totalement différent avec des scripts bien plus léger afin d'entendre les sons extérieurs du temps dans les bâtiments ? (idéalement : près des portes et des entrées pour les grandes cells intérieures, partout dans la cell intérieure si celle-ci est réduite: maisonnette, tente, etc.)

[Orann]

Dans l'Archipel de Pertevue, Okensh a intégré un son très sympathique.

En fait, quand on est à l'intérieur des maisons impériales (donc avec toit en ardoises), on entend à l'intérieur la pluie percuter les ardoises.

Il y a un script global qui met à jour une variable en fonction du weather et qui permet, même à l'intérieur de savoir s'il pleut à l'extérieur (je crois que la fonction getcurrentweather ne fonctionnait pas bien à l'intérieur c'est pour ça qu'on a eu recours à ce script gloabal).

Ensuite, il s'agit simplement d'un marker de son disposé dans chaque intérieur au niveau des toits qui diffuse le son quand la variable indique qu'il pleut...  

[Mordicus]

Orann, le 23.09.2006 à 13:30, dit :

Ensuite, il s'agit simplement d'un marker de son disposé dans chaque intérieur au niveau des toits qui diffuse le son quand la variable indique qu'il pleut...  

C'est intéressant je regarderai comment vous avez fait. (peux-tu me donner le nom du script global ?)

En fait, le gros avantage du système de Kirel c'est qu'en fonctionnant uniquement avec des scripts globaux, les sons intérieurs se produisent également dans les cells nouvelles ajoutées par des mods, sans besoin de marqueur. Autrement dit, si je vais sur Kalendaar, ça marchera partout...

L'inconvénient, c'est que pour éviter que ces sons extérieurs soient entendus dans certaines cells (grottes profondes, sous-sol ou caves de grandes maisons), il faudrait placer un marqueur pour réduire ou annuler le son... Sauf si il y avait moyen de connaître par une variable la taille d'une cell intérieure et/ou sa position (de la cell ou du PJ) par rapport au niveau du sol... Ce qui, je crois, est impossible.  

Donc le système ASE, bien que manuel, se révèle plus sûr, sauf que les sons ne seront pas entendus pour les cells ajoutées par les mods (Kalendaar par exemple), à moins d'ajouter des marqueur manuellement. En revanche, avec ce système (qui ressemble au votre), on peut faire en sorte que les sons soient entendus uniquement dans les petites demeures et dans près des portes... Par chance, ASE a déjà des marqueurs dans la plupart des cells intérieures, ce qui permet de ne pas avoir tout à refaire).

[Orann]

Effectivement, mon script ne résoudra pas ton problème...

Je me suis rendu compte que le script global a disparu de l'Archipel    Donc j'en ai refait un autre:

Spoiler

begin A_P_temps

if ( menumode == 1 )
return
endif

if ( getinterior == 1 )
return
endif

if ( cellchanged == 1 )
if ( getcurrentweather == 0 )
set A_P_temps to 0
elseif ( getcurrentweather == 1 )
set A_P_temps to 1
elseif ( getcurrentweather == 2 )
set A_P_temps to 2
elseif ( getcurrentweather == 3 )
set A_P_temps to 3
elseif ( getcurrentweather == 4 )
set A_P_temps to 4
elseif ( getcurrentweather == 5 )
set A_P_temps to 5
elseif ( getcurrentweather == 6 )
set A_P_temps to 6
elseif ( getcurrentweather == 7 )
set A_P_temps to 7
endif
endif

Et voici celui qui est mis sur les activators (tout simple).

Spoiler

begin A_P_son_pluie_interieur

if ( menumode == 1 )
return
endif

if ( A_P_temps >= 4 )
if ( CellChanged == 0 )
if ( GetSoundPlaying "A_P_pluie_interieur" == 0 )
PlayLoopSound3DVP "A_P_pluie_interieur" 1.0, 1.0
endif
endif
endif


end

Voila...  

[Nenfëa]

Hello !

Voilà quelques idées pour améliorer les performances in-game. Elles ont malheureusement toutes l'inconvénient d'être très compliquées à mettre en place...

1) Sous-traiter le jeu des sons à des "sous-scripts" globaux.
Tu aurais un script global qui détecte le nom de la cell "principale" (par exemple, pour "Vivec, les Fleurs d'Or", le nom détecté serait uniquement "Vivec") grace à GetPCCell (à noter que si le joueur est dans la cell "Vivec, les Fleurs d'Or", un "GetPCCell "Vivec"" renverra 1 ).
Ce script principal lancera un sous-script global dédié aux sons de Vivec seulement. Ca fera donc moins de tests in game, mais ça oblige à créer un grand nombre de scripts globaux associés au mod.

Un exemple :

Spoiler

Begin Main

if ( getpccell "Vos" == 1 )
	StartScript SecondaryVos
elseif ( getpccell "Vivec" == 1 )
	StartScript SecondaryVivec
...
else
	Return
endif

StopScript Main

End

Begin SecondaryVivec

Short doOnce

if ( CellChanged == 1 )
	StartScript Main
	Set doOnce to 0
	StopScript SecondaryVivec
	Return
endif

if ( doOnce == 1 )
	Return
endif

if ( getpccell "Vivec, la Tête de Lézard" == 1 )
	set "_ase_zstart" to -114
elseif ( getpccell "Vivec, les Fleurs d'Or" == 1 )
	set "_ase_zstart" to -117
...
endif

Set doOnce to 1

End

etc...

2) La seconde idée est de passer par des scripts locaux associés à des activateurs invisibles, je ne la redéveloppe pas !
Ses avantages : c'est surement la meilleure en termes de performances, pas besoin de tests tournant en permanence.
Ses inconvénients :
- elle implique de créer un grand nombre d'activateurs invisibles et de scripts qui leurs seront associés
- elle implique de modifier toutes les cells qui nous intéressent en ajoutant un activateur pour chacune d'entre elles, ce qui implique un énorme travail et des risques d'incompatibilités diverses
- elle ne permet donc pas de gérer les cells ajoutées par mod


3) La troisième est une idée bâtarde : des activateurs avec des scripts locaux lanceraient des scripts globaux chargés de jouer les sons. C'est surement la pire méthode, elle a tous les inconvénients de la méthode précédente (avec éventuellement un peu moins d'activateurs à placer, mais ça se discute) pour des performances moindres.






Une idée pour améliorer la méthode de Kirel...
Quand on entre dans une cell, s'il s'agit d'une cell intérieure ET que la cell précédente était une cell extérieure (c'est à dire que le joueur vient d'entrer), on déplace un activateur invisible aux pieds du joueur avec PositionCell (la détection du changement de cell se ferait via un script global). Sinon, l'activator reste à sa place.

On teste ensuite la distance entre l'activateur et le joueur et on ne joue le son que s'ils sont assez proches. Sinon, on ne fait rien.






Pas d'autres idées pour l'instant... ce ne sont pas des solutions miracles, loin de là, mais elles permettront au moins d'alléger un peu la quantité de code qui tourne in-game !

[vor]

je me rappelle plus trop des commandes, mais il me semble qu'on peut avoir le x,y,z d'un objet et du pj en script.

pour la hauteur du sol, l'extraire sur un objet près de la porte, ou directement le z de la porte.
pour la taille de la cell, on peut approximer entre d'un coté les coordonnées de la porte, et de l'autre, celles d'un objet en fond de cell, ou simplement sur les z respectifs

c'est lourd, mais c'est possible

[Nenfëa]

vor, le 23.09.2006 à 16:11, dit :

je me rappelle plus trop des commandes, mais il me semble qu'on peut avoir le x,y,z d'un objet et du pj en script.

C'est la fonction "Objet->GetPos axe" !

Citation

pour la hauteur du sol, l'extraire sur un objet près de la porte, ou directement le z de la porte.
pour la taille de la cell, on peut approximer entre d'un coté les coordonnées de la porte, et de l'autre, celles d'un objet en fond de cell, ou simplement sur les z respectifs

c'est lourd, mais c'est possible

Malheureusement, rien n'empêche une porte de cell intérieure d'être à l'altitude -3847264 : l'altitude de la porte d'entrée ne correspond pas forcément à l'altitude qu'elle devrait normalement avoir...
Ca avait d'ailleurs causé pas mal de soucis à Gilbertus dans Kalendaar, car Sarah chutait d'une hauteur vertigineuse au changement de cell et mourrait quand le joueur entrait dans certains endroits !

[Mordicus]

Nenfëa, le 23.09.2006 à 16:09, dit :

Une idée pour améliorer la méthode de Kirel...
Quand on entre dans une cell, s'il s'agit d'une cell intérieure ET que la cell précédente était une cell extérieure (c'est à dire que le joueur vient d'entrer), on déplace un activateur invisible aux pieds du joueur avec PositionCell (la détection du changement de cell se ferait via un script global). Sinon, l'activator reste à sa place.

On teste ensuite la distance entre l'activateur et le joueur et on ne joue le son que s'ils sont assez proches. Sinon, on ne fait rien.

Hummmm....  
Ca m'a l'air d'une très très bonne idée, et c'est un peu dans cette direction que j'espérais aller. Reste à voir si j'arrive à scripter ça et à l'insérer dans les scripts de Kirel... Vais voir, vais voir... Merci, merci Nenfëa!  

Cela obligera peut-être à utiliser la commande "getdistance", mais dans une cell intérieure cela ne devrait pas trop influencer les performances je pense.

Citation

Malheureusement, rien n'empêche une porte de cell intérieure d'être à l'altitude -3847264 : l'altitude de la porte d'entrée ne correspond pas forcément à l'altitude qu'elle devrait normalement avoir...

Comment peut-on savoir l'altitude d'une cell intérieure dans le TESC ?

Edit : et merci aussi Orann pour le script J'aurais sûrement besoin de changer les activateurs et les scripts pour l'extérieur aussi, ceux de ASE étant trop lourd encore...

[Nenfëa]

Mordicus, le 23.09.2006 à 16:31, dit :

Citation

Malheureusement, rien n'empêche une porte de cell intérieure d'être à l'altitude -3847264 : l'altitude de la porte d'entrée ne correspond pas forcément à l'altitude qu'elle devrait normalement avoir...

Comment peut-on savoir l'altitude d'une cell intérieure dans le TESC ?

Tu peux utiliser l'idée de vor et tester l'altitude d'un objet à la porte (cell du joueur juste après qu'il soit entré dans la cell, par exemple) !

Quelque chose comme :

Begin AltitudeTest

float altitude

if ( CellChanged == 1 )
	Set altitude to ( player->GetPos z )
endif

...

End

... avec AltitudeTest en script global.

De rien, et bon courage pour scripter tout ça !

[vor]

euh, pour "la hauteur du sol", la hauteur absolue, cad par rapport au zéro, ne sert qu'à trouver le "zéro" relatif de la cell intérieure.
Que la cell se trouve intescs au-dessus des nuages, ou dans l'autre sens si l'on admet un monde tamrielien sphérique, loin "en-dessous" du noyau de la planète ne gêne aucunement.

quand on entre dans une cabane ou une grotte, on traverse bien une porte à téléportation pour se retrouver avec une porte dans le dos dans la cell. Ces deux portes sont censés être les deux farces d'une seule et même porte. Donc, par rapport au monde extérieur, immédiatement après avoir franchi la porte, le pj se trouve à la même altitude. Conceptuellement c'est facile à imaginer. La hauteur absolue de la porte interne ne sert qu'à établir la valeur du sol à l'entrée, le "zéro relatif" (j'ai l'impression de me répéter là ), et rien d'autre pusqu'aucune interaction n'a véritablement lieu avec l'extérieur à partir de ce moment.

Ce qui définit la hauteur de la cell (sous-sol avec bruit atténué jusqu'à zéro, ou étage avec bruit amplifié), c'est la hauteur relative d'un objet à cette extrémité de cell, relative à celle de la porte : c'est un travail sur les différences de hauteur.

imaginons un 1er niveau de sous-sol à moins 3 mètres par rapport à une entrée de grotte. Que la cell entière se trouve repérée à l'altitude +258000 ou -3700222 ne fait aucun problème par rapport à la différence de niveau de 3 mètres, qui est la grandeur testée pour savoir si on est loin de l'entrée ou pas.

j'espère avoir été clair  sur cette précision

[Nenfëa]

Merci pour les précisions, je n'avais pas vu les choses sous cet angle ! Le problème de l'altitude des cells n'en est en effet plus un si on procède par différence de la position actuelle du joueur et de celle de la porte d'entrée vers l'extérieur.

[Mordicus]

Intéressant, intéressant... Merci pour ces idées   . Du coup j'ai pas mal de questions. Dans l'ordre :

1- Je viens d'écrire à Kirel qui n'est pas d'accord pour qu'on reprenne, incorpore ou modifie son mod. On peut en revanche le traduire (je m'y attendais un peu à la lecture de son readme...). Donc plusieurs choix: a) j'envoie paître le gus et ses scripts (il faudrait que j'arrive à tout réécrire moi-même différemment); b) je camembérise et ça restera tel quel; c) je camembérise et je fais un patch externe; d) je fais tout autrement (méthode avec activateurs sur la base de ASE)...

2- Concernant le mod de Kirel : en fait, j'ai été trompé par les sons de ASE. La pluie n'est pas entendue dans les grottes, les sanctuaires daedriques et autres endroits spéciaux. Uniquement dans les maisons et les tentes, ce qui est mieux. Mais il y a un truc gênant malgré tout : lorsqu'on entre dans un chateau, on entends le son de la pluie (ça fait un peu bruit de pluie sous une bâche...). Je pourrais changer le son mais ce qui est embêtant c'est d'entendre le bruit de "la pluie sous le toit" (ou du vent violent) quand on entre dans un fort par exemple (je ne sais pas encore ce que ça donne dans Vivec, mais ce ne serait pas terrible).

3- La raison pour laquelle Kirel n'a pas essayé d'arrêter le son de la pluie dans les grandes maisons, ou dès qu'on s'éloigne des portes, c'est qu'il pense que ça ne va pas marcher dès qu'on s'approche d'une autre porte ou d'une fenêtre par exemple. Il pense aussi à des problèmes lors de téléportation dans une cell interne. C'est en effet à voir, mais bon, entendre le bruit de la pluie quand on est dans la cave de fort Molène, ça fait très bizarre. Peut-être qu'il faudrait des activateurs pour les forts.   (je ne vois pas comment différencier autrement les forts des maisons en pierre...).

4- Question par rapport à la méthode ASE, par activateurs : si un mod modifie la même cell interne, il va forcément effacer un activateur placer manuellement ? (les données n'ont aucune chance de se superposer ?). La méthode manuelle est peut-être lourde, mais puis ASE dispose déjà d'un certain nombre d'activateurs mis en place, il n'y aurait qu'à les réutiliser. Le problème est que je ne sais pas comment ils exactement sont situés, et s'il y en a partout, à voir... Autre question : un mod avec des centaines d'activateurs placés dans les cells internes est-il une uzine à gaz ?   (conséquences sur les perfs ?)

5- "Le problème de l'altitude des cells n'en est en effet plus un si on procède par différence de la position actuelle du joueur et de celle de la porte d'entrée vers l'extérieur." - Pour revenir à l'exemple des forts et des maisons (puisque dans les grottes, temples et tombes le problème ne se pose plus), je crois que la seule chose raisonnable serait de placer un activateur juste derrière la porte qu'on entendrait lorsqu'on serait près de l'entrée, et sur une surface presque aussi large qu'un maison classique. Ainsi, dans une maison classique (genre Balmora), on entendrait le bruit de la pluie presque partout au niveau du RC, la porte n'étant jamais loin, mais plus dans les caves et les étages. Dans les forts, la pluie ne serait entendue aussi que près de la porte. Tant pis pour les autres sorties vers des cells extérieures. Pour les grandes maisons, tant pis aussi pour les fenêtres... (à moins de scripter les fenêtres des quelques grandes demeures ?    peu de mods y touchent, non ?).

Suggestions bienvenues...  

Citation

les deux farces d'une seule et même porte

Joli lapsus !  

[Nenfëa]

Mordicus, le 24.09.2006 à 14:37, dit :

2- Concernant le mod de Kirel : en fait, j'ai été trompé par les sons de ASE. La pluie n'est pas entendue dans les grottes, les sanctuaires daedriques et autres endroits spéciaux. Uniquement dans les maisons et les tentes, ce qui est mieux. Mais il y a un truc gênant malgré tout : lorsqu'on entre dans un chateau, on entends le son de la pluie (ça fait un peu bruit de pluie sous une bâche...). Je pourrais changer le son mais ce qui est embêtant c'est d'entendre le bruit de "la pluie sous le toit" (ou du vent violent) quand on entre dans un fort par exemple (je ne sais pas encore ce que ça donne dans Vivec, mais ce ne serait pas terrible).

Tu peux éventuellement référencer tous ces endroits par script global, vérifier si le joueur s'y trouve quand il change de cell, et ne pas jouer les sons si c'est le cas.
L'avantage, c'est qu'en passant par un script global (ou une série de scripts globaux sous-traités comme dans le 1) de mon premier post), tu évites de modifier physiquement ces cells.
L'inconvénient, c'est que ça fait beaucoup de tests in-game et que ça ne gère pas les lieux ajoutés par mod.

Citation

4- Question par rapport à la méthode ASE, par activateurs : si un mod modifie la même cell interne, il va forcément effacer un activateur placer manuellement ? (les données n'ont aucune chance de se superposer ?).

Normalement, ça devrait aller sans soucis, mais je sais que Kalendaar avait des problèmes avec certains mods modifiant Seyda Nihin - pourtant, seule Sarah et Tordu le rusé y sont présents... (du au fait qu'il s'agit d'un esm et non d'un esp ?!)
A voir, donc, mais en multipliant les cells retouchées par le mod, tu accrois les risques d'incompatibilité - même si en théorie, il ne devrait pas y en avoir !

Citation

Autre question : un mod avec des centaines d'activateurs placés dans les cells internes est-il une uzine à gaz ?   (conséquences sur les perfs ?)

En termes de mémoire vive utilisée, c'est probablement la méthode la plus efficace : le code qui est executé à chaque frame est spécifique à la cell, il n'y a donc pas 50000 lignes de tests inutiles dans ce cas précis !
En termes de place sur le disque dur, c'est autre chose : tu risques d'avoir un esp et des sauvegardes bien plus imposants (!) qu'avec une méthode par scripts globaux. Celà dit, c'est moins handicapant que d'avoir un jeu qui rame à mon avis !
Enfin, en termes de risques de bugs et d'efforts, c'est surement la pire méthode : tu pourras très facilement placer par erreur un activator là où il n'a rien à faire, tu accrois les risques d'incompatibilité, et tu auras un très grand nombre d'activators à placer.

[Mordicus]

Merci Nenf' !

Nenfëa, le 24.09.2006 à 16:03, dit :

Enfin, en termes de risques de bugs et d'efforts, c'est surement la pire méthode : tu pourras très facilement placer par erreur un activator là où il n'a rien à faire, tu accrois les risques d'incompatibilité, et tu auras un très grand nombre d'activators à placer.

En fait, j'ai regardé, ASE a place déjà des activateurs partout, dans pratiquement tous les intérieurs (et le patch de notre Bunk wiwilandais poru Bloodmoon rajoute également des activateurs intérieurs sur Solstheim). Donc j'ai juste un travail de contrôle à faire, en rajouter ou en replacer quelques uns au besoin. Et évidemment à revoir les sons...

Et puis, à la réflection, cette méthode permet d'être très précis (notamment de placer des activateurs près des fenêtres et des portes si ce n'est pas déjà fait...). Et comme je vais peut-être rajouter quelques sons, d'avoir des sons spécifiques selon l'endroit où l'on est (pas forcément pour les effets météos).

C'est en fait tentant, et comme tu l'as dit, pas de scripts globaux supplémentaires qui tournent en permanence ("il n'y a donc pas 50000 lignes de tests inutiles dans ce cas précis !")... Un conflit avec un autre mod, si j'ai bien compris, risque tout simplement de faire sauter mes activateurs dans une cell, n'est-ce pas ?    (donc au pire, on perdrait les effets météo d'une cell intérieure... si dehors il fait mauvais temps). J'ai bon ?

Reste à savoir s'il faut ajouter un script global comme l'a fait Orann ou rester sur les scripts de ASE... Car ASE utilise des scripts drôlement complexes pour un activateur "météo", comparé à la solution d'Orann :

Spoiler

begin _ase_in_stone

short done_once

short enter_delay_active
float enter_delay_timer

float px
float py
float pz
float pz_saved
float pz_start

short init_swells
short pos_state
float zlevel
float zlevel_check
float az
float dist_accum
float rnd_dist
float rnd_stay
float rnd_stay_elapsed
float moving_elapsed

short rnd_sound
short snd_playing
float snd_length
float snd_length_saved
float rnd_start_time
float start_time_elapsed
float snd_playing_elapsed

dontsaveobject

; Takes care of initialization upon player changing cells
; from interior to interior or exterior to interior.
if ( cellchanged == 1 )
player -> startscript "_ase_get_zstart_stone01"
set enter_delay_active to 1
set enter_delay_timer to 0
set done_once to 1
endif

; Takes care of initialization upon loading a savegame
; if player saved game in interior. Cellchanged does not
; equal true when this happens.
if ( done_once == 0 )
if ( player -> scriptrunning "_ase_get_zstart_stone01" == 0 )
player -> startscript "_ase_get_zstart_stone01"
endif
set enter_delay_active to 1
set enter_delay_timer to 0
set done_once to 1
endif

; This routine needs to be in here or when entering
; some interiors, the game crashes. It has something
; to do with positioning the activator too soon after
; entering.
if ( enter_delay_active == 1 )
set enter_delay_timer to enter_delay_timer + getsecondspassed
if ( enter_delay_timer < 0.50 )
return
else

if ( player -> scriptrunning "_ase_get_zstart_stone01" == 1 )
return
elseif ( player -> scriptrunning "_ase_get_zstart_stone02" == 1 )
return
elseif ( "_ase_zstart" == 0 )
set pz_start to player -> getpos z
else
set pz_start to "_ase_zstart"
set "_ase_zstart" to 0
endif
set pz_saved to pz_start

set zlevel to 0

set snd_playing to 1
set snd_length_saved to 0
set rnd_start_time to ( random, 11 )
set rnd_start_time to rnd_start_time + 2
set enter_delay_timer to 0
set enter_delay_active to 0
endif
endif

set px to player -> getpos x
set py to player -> getpos y
set pz to player -> getpos z
setpos x px
setpos y py

; Tracks the player's position when going
; up or down a flight of stairs. The variable,
; zlevel, is used as an addition to the activator's
; postion. I would have used the ranges in the
; sound dialog, but even a range of 255 isn't
; enough and it fades in and out way too quickly.
set zlevel to zlevel + ( ( pz_saved - pz ) * 0.46 )
set zlevel_check to pz + zlevel
if ( zlevel_check > pz_start )
set zlevel to 0
endif
set pz_saved to pz

if ( getcurrentweather > 5 )
set az to pz + zlevel
setpos z az
if ( getsoundplaying "_ase_in_stone_dust01" == 0 )
stopsound "_ase_in_stone_rain01"
stopsound "_ase_in_stone_rainthun01"
playloopsound3dvp "_ase_in_stone_dust01", 1.0, 1.0
endif
elseif ( getcurrentweather == 5 )
if ( getsoundplaying "_ase_in_stone_rainthun01" == 0 )
set init_swells to 1
stopsound "_ase_in_stone_rain01"
stopsound "_ase_in_stone_dust01"
playloopsound3dvp "_ase_in_stone_rainthun01", 1.0, 1.0
endif
elseif ( getcurrentweather == 4 )
if ( getsoundplaying "_ase_in_stone_rain01" == 0 )
set init_swells to 1
stopsound "_ase_in_stone_rainthun01"
stopsound "_ase_in_stone_dust01"
playloopsound3dvp "_ase_in_stone_rain01", 1.0, 1.0
endif
else
if ( getsoundplaying "_ase_in_stone_dust01" == 1 )
stopsound "_ase_in_stone_dust01"
elseif ( getsoundplaying "_ase_in_stone_rainthun01" == 1 )
stopsound "_ase_in_stone_rainthun01"
elseif ( getsoundplaying "_ase_in_stone_rain01" == 1 )
stopsound "_ase_in_stone_rain01"
endif
endif

; This routine creates the random rain swells.
if ( getcurrentweather > 3 )
if ( getcurrentweather < 6 )
if ( init_swells == 1 )
set pos_state to 1
set moving_elapsed to 2
set rnd_stay to ( random, 13 ) ;close position
set rnd_stay_elapsed to 0
set rnd_dist to ( random, 176 )
set rnd_dist to ( rnd_dist + 100 ) / 100
set dist_accum to 0
set init_swells to 0
endif
if ( moving_elapsed < 1.50 )
set moving_elapsed to moving_elapsed + getsecondspassed
if ( pos_state == 0 )
set dist_accum to dist_accum + rnd_dist
else
if ( dist_accum > 0 )
set moving_elapsed to 0
set dist_accum to dist_accum - rnd_dist
else
set moving_elapsed to 2
set dist_accum to 0
endif
endif
else
if ( rnd_stay_elapsed < rnd_stay )
set rnd_stay_elapsed to rnd_stay_elapsed + getsecondspassed
else
set moving_elapsed to 0
set rnd_stay_elapsed to 0
if ( pos_state == 0 )
set rnd_stay to ( random, 13 ) ;close position
set pos_state to 1
else
set rnd_stay to ( random, 5 ) ;far position
set pos_state to 0
set rnd_dist to ( random, 176 )
set rnd_dist to ( rnd_dist + 100 ) / 100
endif
endif
endif
set az to pz + dist_accum + zlevel
setpos z az
endif
endif

if ( snd_playing == 1 )
set snd_playing_elapsed to ( snd_playing_elapsed + getsecondspassed )
if ( snd_playing_elapsed >= snd_length_saved )
set start_time_elapsed to 0
set snd_playing to 0
return
else
return
endif
else
if ( snd_playing_elapsed >= snd_length_saved )
set start_time_elapsed to ( start_time_elapsed + getsecondspassed )
if ( start_time_elapsed > rnd_start_time )
if ( getcurrentweather == 5 )
set rnd_sound to ( random, 8 )
set rnd_start_time to ( random, 11 )
set rnd_start_time to rnd_start_time + 2
if ( rnd_sound == 0 )
set snd_length to 3.79
elseif ( rnd_sound == 1 )
set snd_length to 8.73
elseif ( rnd_sound == 2 )
set snd_length to 7.75
elseif ( rnd_sound == 3 )
set snd_length to 7.97
elseif ( rnd_sound == 4 )
set snd_length to 5.71
elseif ( rnd_sound == 5 )
set snd_length to 16.73
elseif ( rnd_sound == 6 )
set snd_length to 3.49
else
set snd_length to 6.37
endif
else
set rnd_sound to -1
set rnd_start_time to 10.00
set snd_length to 10.00
endif
set snd_length_saved to snd_length
set snd_playing to 1
set snd_playing_elapsed to 0
else
return
endif
endif
endif

if ( rnd_sound == -1 )
return
endif

if ( rnd_sound == 0 )
if ( getcurrentweather == 5 )
playsound3d "_ase_in_stone_thun01"
endif
return
endif

if ( rnd_sound == 1 )
if ( getcurrentweather == 5 )
playsound3d "_ase_in_stone_thun02"
endif
return
endif

if ( rnd_sound == 2 )
if ( getcurrentweather == 5 )
playsound3d "_ase_in_stone_thun03"
endif
return
endif

if ( rnd_sound == 3 )
if ( getcurrentweather == 5 )
playsound3d "_ase_in_stone_thun04"
endif
return
endif

if ( rnd_sound == 4 )
if ( getcurrentweather == 5 )
playsound3d "_ase_in_stone_thun05"
endif
return
endif

if ( rnd_sound == 5 )
if ( getcurrentweather == 5 )
playsound3d "_ase_in_stone_thun06"
endif
return
endif

if ( rnd_sound == 6 )
if ( getcurrentweather == 5 )
playsound3d "_ase_in_stone_thun07"
endif
return
endif

if ( rnd_sound == 7 )
if ( getcurrentweather == 5 )
playsound3d "_ase_in_stone_thun08"
endif
return
endif

end

Comme ce sont des scripts locaux qui ne se chargent que dans les cells intérieures ce n'est peut-être pas gênant, mais ça semble lourd...  

[Nenfëa]

Mordicus, le 24.09.2006 à 16:57, dit :

Un conflit avec un autre mod, si j'ai bien compris, risque tout simplement de faire sauter mes activateurs dans une cell, n'est-ce pas ?    (donc au pire, on perdrait les effets météo d'une cell intérieure... si dehors il fait mauvais temps). J'ai bon ?

C'est une façon optimiste de voir les choses !
Je ne sais pas vraiment, mais il y a toujours le risque que le bug n'ait pas lieu sur ton mod mais sur l'autre, et là tu ne peux rien présupposer de se qui se passera - simple message d'erreur ? Retour sous Windows ? Perte de la sauvegarde ? Impossible à dire !
Et même si l'erreur se fait dans ton mod, je ne parierai pas sur des conséquences aussi bénignes !
Celà dit, en théorie, tant que tu ne fais qu'ajouter des objets à la cell sans modifier des qui existent déjà, ça ne devrait pas poser de problème. Il y a après tout beaucoup de mods qui modifient la même cell et restent pourtant bien compatibles entre eux !

Citation

Reste à savoir s'il faut ajouter un script global comme l'a fait Orann ou rester sur les scripts de ASE... Car ASE utilise des scripts drôlement complexes pour un activateur "météo", comparé à la solution d'Orann.


Comme ce sont des scripts locaux qui ne se chargent que dans les cells intérieures ce n'est peut-être pas gênant, mais ça semble lourd...  

Le script ASE est aussi lourd parce que :

1) L'activator suit le joueur (seulement en partie pour l'altitude : quand le joueur descend de deux pas, l'activator descend d'un pas seulement pour que le son s'évanouisse progressivement).

Spoiler

; Tracks the player's position when going
; up or down a flight of stairs. The variable,
; zlevel, is used as an addition to the activator's
; postion. I would have used the ranges in the
; sound dialog, but even a range of 255 isn't
; enough and it fades in and out way too quickly.

Ce n'est peut-être pas très utile dans des petites cells ?

2) Si j'ai bien compris, l'activator utilise des scripts globaux pour savoir où il se trouve et doit donc "attendre leur réponse" avant de jouer les sons. Si tu places un activator par cell, cette partie est inutile.

3) Le mod gère le rechargement dans la cell - sans quoi, aparemment, le son ne serait pas joué. C'est inutile si tu choisis la méthode d'Orann.



A toi de choisir, la méthode d'Orann est bien moins lourde mais celle d'ASE gère mieux l'évanouissement des sons quand le joueur peut s'éloigner beaucoup de l'entrée !

[Mordicus]

Ben on va tester tout ça... Merci encore le poisson !  

A priori un truc plus léger à la Orann ne ferait pas de mal à ASE... Je pense que le rendu ne sera pas bien différent d'après ce que j'ai pu déjà testé.

[Orann]

Le problème avec le système utilisé dans l'archipel de Pertevue, c'est que dans les grandes cells, il faut plusieurs activators et que le son semble venir de quelques endroits précis... Mais bon, dans mon cas, je n'avais pas pensé à un autre système donc j'avais trouvé les inconvénients inférieurs aux avantages (du son de pluie en intérieur quand il pleut...).

Après pour des effets complexes à la sauce Mordicus ( ), je trouve que le fait de faire suivre le joueur par l'activateur permet effectivement de compenser cette aspect "pluie en un endroit précis". Donc je te souhaite bon courage  

[Mordicus]

En fait (après divers tests...) le problème est là :

Avec ASE, comme avec le mod de Kirel, lorsqu'on s'éloigne de l'entrée d'une grande maison (genre cave ou sous-sol), l'activateur suit encore... Par exemple: dans la dernière pièce tout en bas de la guilde des guerriers de Balmora, où sont les entraîneurs, qui n'a ni porte vers l'extérieur ni fenêtre, on entend aussi bien la pluie que si l'on était au 1er ou 2ème étage devant la sortie... Donc c'est pas terrible (surtout pour une maison en pierre épaisse!). Il faudrait en revenir à ce système dont parlait Vor avec un calcul de la différence de niveau entre les deux portes, intérieure et extérieure... Mais le problème resterait complexe : en montant d'étage ou en avançant loin à l'intérieur d'une maison au même niveau (maison qui n'aurait ni fenêtre, ni d'autres portes, on aurait la même chose...). Et je ne suis pas sûr d'arriver à scripter ça.

Je ne vois pas - hélas    - de meilleur système que de déplacer les activateurs de ASE près des portes donnant vers l'extérieur, et d'en rajouter (aux portes et aux éventuelles fenêtres). Ce serait le plus réaliste, mais c'est sans doute fastidieux... Je vais essayer de voir si ça reste humainement faisable, et surtout si on peut éviter les erreurs dont parlait Nenfëa...     Sinon, il faudra ce contenter du système d'ASE qui, à part pour les grandes cells intérieures, n'est pas si mauvais.

Pour l'aspect "pluie à un endroit précis", ça resterait logique lorsque si les activateurs sont placés près des portes. Le problème est d'arriver malgré tout à obtenir un son diffus, pour qu'on l'entende en peu plus loin quand même. En jouant sur les réglages de la distance du volume, ça devrait être jouable    (en fait je dois regarder, j'avoue que les réglages Min et Max de chaque ID son ne sont pas encore bien clair pour moi...). Reste à voir ce que cela donne sous une tente par exemple, où la il faurait qu'on entende partout le même son à intensitée égale...

Encore un truc qui aurait dû être pensé dans le moteur du jeu...  

[vor]

pour la compatibilité, je ne vois personnellement aucun réel problème si les choses sont faites proprement. Je m'explique :
le mod rajoute des sons via des scripts sur des activateurs (grosso admino, euh grosso modo ), ni plus, ni moins. Il ne doit donc absoluement pas modifier un seul objet dans une seule cell ; cela donne la compatibilité avec ceux qui les modifient.
Si les activateurs sont judicieusement placés, soit à des endroits "uniques", c'est tout bon pour la compatibilité avec des mods qui rajoutent des objets à droite à gauche.
Avec un nom/id spécifique au mod, on gagne aussi en "découplage".

piste : il semble d'usage de placer les activateurs à l'endroit exact des objets, chose évidente. Cela ferait-il une grosse différence dans l'audition du son s'il était placé par exemple juste dessous, hors zone atteignable par le pj ? De plus, on n'est pas forcé de coller un script à un activateur (possibilité de confusion de nom/id avec autre mod), on peut utiliser un misc-item petit, par exemple (dans underground, c'est des bouteilles    )...


ensuite, la gestion de distance. Ce qu'on peut faire pour z (pas le chien de la pub), on peut aussi le faire pour x et y : c'est du calcul de la longueur d'un segment connaissant les deux points d'origine. donc pour de grandes cell au même niveau, ca va, je crois que le système de scripts permet quand même le calcul de ce genre d'équations sans mettre le cpu à genous.

[Mordicus]

Encore des conseils ! Merci, je prends !  

J'ai déjà commencé avec des activateurs invisibles placés juste devant les portes (difficile à ce niveau de trouver des d'objets pour les dissimuler)... et après quelques tests et quelques réglages, j'obtiens un trés bon rendu, bien plus réaliste qu'avec ASE et Interior Weather. On peut surtout placé les activateurs exactement où l'on veut, donc fini le bruit de l'eau sous la tente dans les caves des forts de la Légion...

Ce sera plus long, mais je fais ça le plus proprement et le résultat devrait être à la hauteur pour le petit plus qu'il apporte. Et du coup, ASE a fait déjà un gros régime !  

Pour les mods ajoutés, qui n'auront pas de sons en intérieur, je laisserai des instructions pour utiliser les mêmes activateurs pour ceux qui veulent, c'est aussi simple.

[Nenfëa]

vor, le 25.09.2006 à 09:16, dit :

ensuite, la gestion de distance. Ce qu'on peut faire pour z (pas le chien de la pub), on peut aussi le faire pour x et y : c'est du calcul de la longueur d'un segment connaissant les deux points d'origine. donc pour de grandes cell au même niveau, ca va, je crois que le système de scripts permet quand même le calcul de ce genre d'équations sans mettre le cpu à genous.

Juste une petite idée : il serait même possible de pondérer le déplacement de l'activator pour un rendu plus réaliste, par exemple de faire se déplacer l'activator d'un demi-pas pour chaque pas que fait le joueur en x ou en y, mais de ne le faire se déplacer que d'un quart de pas pour chaque pas que fait le joueur en z (la dissipation du son serait plus importante en changeant d'altitude).

Mordicus, le 25.09.2006 à 09:25, dit :

(difficile à ce niveau de trouver des d'objets pour les dissimuler)

Plutôt que de les cacher, tu peux aussi prendre des activators invisibles ! (regarde celui du son sound_whisper, ou quelque chose d'approchant)
Et si tu optes plutôt pour des misc items, il doit être tout à fait possible d'en créer en leur collant ce même meshe invisible.

[Angora]

Mordicus, le 23.09.2006 à 14:02, dit :

L'inconvénient, c'est que pour éviter que ces sons extérieurs soient entendus dans certaines cells (grottes profondes, sous-sol ou caves de grandes maisons), il faudrait placer un marqueur pour réduire ou annuler le son... Sauf si il y avait moyen de connaître par une variable la taille d'une cell intérieure et/ou sa position (de la cell ou du PJ) par rapport au niveau du sol... Ce qui, je crois, est impossible.  

Estimer la taille par script, c'est impossible.

Par contre, la distance par rapport au sol, c'est faisable avec un script global. Attention cependant, ça provoquera de drôles de résultats dans les faux extérieurs, comme Longsanglot, et aussi avec les guides de guildes et les portails des forteresses.

L'idée, c'est d'avoir un script global qui garde en mémoire la position Z du personnage. On utilise GetInterior pour savoir s'il est dedans ou non. Quand il y a un cellchanged, et qu'il est dedans, c'est que le personnage vient de franchir une porte. On peut donc garder sa position Z à cet instant comme référence pour le niveau de la porte. En l'utilisant comme référence, ça permet d'estimer l'altitude du personnage par rapport à la porte à tout moment.

Après, on peut facilement continuer. S'il passe d'un intérieur à un autre, c'est qu'il s'enfonce plus profondément dans le "donjon". On calcule le nouveau point de référence d'après la dernière position avant le changement de cellule relative à son point de référence, et le nouveau point de référence.

Beaucoup de calculs, mais des calculs simples : soustractions uniquement.