Provient du message de erase & rewind
je te remercie pour la précision informatique qui tient à mon niveau de la subtilité (on a le droit d'être un noob en info). en tous les cas ça va dans le sens que j'évoquais, à savoir une augmentation du lag
ben non pas forcément, ou pas autant que certains le font entendre.
déjà, pour un perso buffé, si on check les buffs par buffeur, ça rend le calcul à 1 donnée à vérifier pour le cas des buffbots, et non plus 7, pur chaque buff. ( ça s'appelle optimisation de programmation, notion qui a l'air d'échapper à certains )
une seul donnée, voire 2 pour certains cas, c'est pas pire qu'un barde
apres comment ça marche, ben c plutot simple, comme le chant du barde, toutes les x secondes une demande de calcul est envoyée du type :
if{
(|locX.cible-locX.buffeur|+|locY.cible-locY.buffeur|)/2<range
then pulse = yes
}else{
pulse = no
}
où pulse est le chant/bubulle
maintenant pour faciliter les calculs et leurs nombres on peut dire que la modification n'entre en compte que sur les zones rvr, pour éviter d'avoir 3000 calculs à faire, et donc uniquement sur les personnes en zone rvr.
prenons en compte le cas où il faut vérifier pour chaque buff qui est le buffeur et tout, et où les buffs auraient une portée, avec une vérification toutes les 10 secondes.
dans le cas suivant disons que le buffboté portera le nom IG de Supairsiclair, et le clerc, euh le buffbot, de Buffbotdelamort. on va implanter dans le code une variable de check appelée pour la vérification que j'appellerais "check"
if{
newbuff
then x=0
mise à zéro d'une variable de boucle
y=0
mise à zéro des données des buffeurs
mettons ici une marque pour un goto soit /marqueur 1/
if{
il suffit là de vérifier à chaque "buffage" qui est le buffeur afin de centraliser les données en effectuant une boucle sur les buffs, disons estimés à 40 max par personne dans le jeu
x<40
then x+1
if {
x=1 then
check buff.x=buffeur.y
}else{
if {
check buff.x=![buffeur]
soit l'ensemble buffeur
then
check buff.x=buffer.y+1
au cas ou il y a un autre buffeur
}}
goto marqueur 1
}
---------------------------------
tout ceci se passant une seule fois quand il y a un buff de lancé, hors chants, pour calculer qui sont les buffeurs, et sont inclus dans le domaine [buffeurs]. passons ensuite au calcul de la distance des buffs. afin de pas me taper 5 lignes de plus, je précise qu'un tableau pourra etre créé pour définir quels buffs sont attribués à quels buffeurs, que l'on implantera avec la commande pulse.y, ce tableau existe déjà en jeu, pour définir quel buff est à quel buffeur
----------------------------------------
/marqueur2/
[buffeur]=nbrebuffeurs
z=0
y=0
on calcule le nombre de buffeurs inclus dans le domaine [buffeur] pour déterminer le nombre de boucles z mises à zéro au dessus
if{
z<nbrebuffeurs
then z+1
y=z
if{
(|locX.Supairsiclair-locX.buffeur.y|+|locY.Supairsiclair-locY.buffeur.y|)/2<range
then pulse.y = yes
}else{
pulse.y = no
}}else{
boucle 10 secondes
goto marqueur 2
voilà, en fait à chaque buffage, il y a une petite série de calculs non redondante à la vérification grace à un tableau qui centralise les infos sur les buffeurs ( ce qu'il y a actuellement en fait )
toutes les 10 secondes le prog vérifie la distance entre le buffeur et le buffé par ( holà ) 10 lignes de code de 30 occurences.
on peut rajouter dans cette vérification une vérification de la zone afin de voir si on est en zone rvr ( pas trop possible pour un serveur pvp... ) afin de limiter les calculs de 3000 clampins à 600 gus.
pour les histoires de lag, ça tiens pas la route par rapport à un petit code de vérif comme celui d'un reje endu, comparé aux informations échangées sur les skins, les déplacements, les actions de chaque perso/mob
cette vérif prend autant de calcul que de calculer de range d'un chant ( par exemple dans un groupe il y aurait la bt, l'endu, le rege vie, l'add dmg, le speed et les buffs )
ps : j'ai pas vérif le truc qui ressemble à un code, manque peut etre un "}", j'ai pas fait trop gaffe