Suggestions et idées

[cristab]

Et c'est quand environs?  :ohmy

On sait pas.

moi je sais un jour a une certaine heure ^^

[Infu]

:ok:

[Syg]

Pour le bug que tu signales Infusion, je ne pense pas que ça vienne du script
Tous les véhicules crées ont le même temps de respawn = 30 minutes.
Les véhicules présents sur le serveur ont le temps de respawn par défaut = 2 minutes sauf les packers qui ont un temps de respawn de 30 minutes (car certains les utilisent pour le stunt).

++
Syg

[Wasabi]

A oui C'est possible d'ajouter des tank Et faire comme l'hydra bloqué les tir et lui faire le respawn de 30 minutes Car Pour stunt sa sert quand meme
Et sa je pense pas que sa sera accepte Faire un virtualworld avec un Tec9 pour stunt aussi ?
Et faire une course de vortex ou de bateau avec des ramps comme un trial ?

Voila quelque idée :)

++

[Infu]

Pourquoi pas, moi je suis pour...ça peut être bien :).

[Watash]

A oui C'est possible d'ajouter des tank Et faire comme l'hydra bloqué les tir et lui faire le respawn de 30 minutes Car Pour stunt sa sert quand meme
Et sa je pense pas que sa sera accepte Faire un virtualworld avec un Tec9 pour stunt aussi ?
Et faire une course de vortex ou de bateau avec des ramps comme un trial ?

Voila quelque idée :)

++

Ouais, pour le tank ça serait cool. Par contre je vois pas en quoi le Tec9 aide à stunter... ?

[Wasabi]

Le mountain bike mais sa sert pas a grand chose alors on l'oublie elle :P

[Vicolaships]

/

[Infu]

[HS] Ah le retour de la ships ! :o [/HS]

Je ne sais pas si ça été proposer, mais, je tente quand même.

Imaginons nous sommes en Race, course paisible sans NOF etc...Quand tout-à-coups des barils d'explosifs tombent du ciel.
Un message disant: "Un baril est proche de vous faites GAFFE !!" avertirait le joueur pour qu'il s'écarte.

_____

Où comme dans Mario kart :p.
Quand tu casses une caisse (ou autre) une action aléatoire apparaît; après, plus qu'a savoir visé pour l'envoyé à son adversaire.

__

Bonne chance aux codeurs s'ils prennent mon idée :)

++ fufu

[S!m]

Salut,

Non, malheureusement Adju, je ne connais pas la position des joueurs entre le CP.
Donc j'affiche le dernier CP passé par le joueur, c'est la seule information dont je suis sur
.
J'aurais aimé le faire aussi dans le speedo mais ça demanderait beaucoup de calcul pour savoir quel joueur est devant tel autre (et de plus, je ne suis pas sûr de savoir le faire).
Et comme SAMP se déroule sur une carte ouverte (contrairement aux jeux de course où on ne peut pas sortir du circuit), il se peut même que ce soit impossible à déterminer.

++
Syg

désolé de remonter ce post d'une page, mais je voulais simplement rappelé à messire Syg que nous en avions discuter il y a peut-être 2 ans et il m'avait suggéré une méthode.
Bien sur, il y a un certains volume de calcul mais j'ai tout ce code dans mon dernier fs de course qui traine... si vous voulez y jeter un oeil, je peut le passer en PM.

++Sim++

[cristab]

Sim auras le droit a une fleur ^^

[Syg]

@Infusion :
Vas dans le dm stadium, on peut tirer des barils explosifs sur les autres (touche tir secondaire comme pour les rampes) ou en déposer derrière soi (touche tir).

@Sim :
Passe le en PM, si tu veux mais je devrais certainement en réécrire une bonne partie (nom de variable, intégration dans le script de Lalu, ...).

Après réflexion, je vois au moins deux méthodes (je pense que tu utilises la première) pour faire ça.
1° méthode : Calcul de la distance entre le joueur et le CP suivant.
Il est très facile de calculer la distance entre le joueur et le CP suivant et donc de comparer cette distance avec la distance d'un autre joueur (même si on multiplie les calculs). Le joueur ayant la distance la plus courte est certainement celui qui est en tête.
Mais cette méthode fonctionne très mal si le trajet entre deux CP n'est pas plus ou moins en ligne droite.

2° méthode : Calcul de la distance parcourue par le joueur après un CP.
Ici, on ne parle pas de la distance entre le joueur et le CP (ligne droite) mais bien de la distance parcourue (courbe quelconque).
Cette méthode nécessite moins de calculs que la précédente (de plus, la distance parcourue par le joueur est calculée en permanence dans le script de Lalu).
Dans ce cas, le joueur qui à parcouru la distance la plus grande après un CP est certainement celui qui est en tête. Ici, peu importe le trajet entre les CP puisque la distance est calculé en fonction du chemin emprunté par les joueurs. Par contre, il n'est pas impossible qu'un joueur se trompe de route et soit premier alors qu'il est deuxième.
Cette méthode est plus fiable que la première si les joueurs ne se trompent pas de route et ne prennent pas de chemin de traverse (ce qui est rarement le cas lorsque les CP sont positionnés de manière à être visibles depuis le CP précédent).

Donc OK, j'ai répondu trop vite et trop catégoriquement à Adjudant mais c'est juste parce que quelle que soit la méthode, le résultat risque d'être faux (et je n'aime pas trop l'à peu près).
Mais bon, hier, mon fils (Tixy) jouait à NFS Underground 2 et j'ai remarqué que parfois, la position affichée est erronée (on se retrouve 4° parce qu'on a pris un raccourci alors qu'il est évident qu'on est premier).
Mais je n'ai pas menti, à l'heure actuelle, la seule info que j'ai dans une course est le dernier CP passé par le joueur.
Mon seul petit mensonge c'est quand j'ai dit que je n'étais pas sur de savoir le faire.

Reste que la fiabilité de ces méthodes est fortement mise à mal par le fait que les courses se déroulent sur des circuits ouverts. De plus, le nombre de comparaison de distance entre les joueurs augmente plus vite que le nombre de joueurs.
Avec deux joueurs, une seule comparaison suffit. Avec trois joueurs, il en faut 3, avec 4, il en faut 6 (3+2+1) et avec n joueurs, il en faut (n-1)+(n-2)+.....+3+2+1=n(n-1)/2.
Par exemple avec 8 joueurs, il faut 8*7/2=28 comparaisons.
Ce chiffre est toutefois un maximum, il est inutile de comparer les distances de joueurs qui n'en sont pas au même CP.

Donc je pense que je vais utiliser la deuxième méthode et on verra bien ce que ça donne dans une course avec 15 joueurs (105 comparaisons).

Il reste néanmoins une 3° méthode qui est la combinaison des deux premières (un genre de triangulation) mais il se peut que les erreurs des deux méthodes s'ajoutent au lieu de s'annuler. De plus, la quantité de calcul sera beaucoup plus importante et risque de gravement entamer les performances de la machine dans le cas d'un course à laquelle beaucoup de joueurs ont pris part.
Mais sans test, je ne peux pas vraiment dire si ce sera la cas.
D'ailleurs Sim, ça pourrait être une idée pour mettre à jour ton FS.

++
Syg

[S!m]

Salut,

j'utilise la première méthode.

En ce qui concerne la détermination de la position du joueur, je ne fait que calculer la distance du joueur et la comparer avec celle des autres coureurs un à un.
Toutefois, comme tu le dit, l'adaptation à Lalu demanderait pratiquement la réécriture du script.

En ce qui concerne ta suggestion, j'ai bien peur que la triangularisation ne soit pas vraiment plus efficace. Une variation dans un sens aurait un impact doublé je crois, enfin... il faudrait vérifier.

Par exemple, si un joueur franchi un CP et décide d'aller en direction inverse du CP suivant.
Avec la 2e méthode, il pourrait se retrouver devant un joueur qui est passé par le cp après lui et qui continue dans la bonne direction.
Bref, je ne crois pas que ce soit vraiment une très bonne méthode.
Par contre, avec la 1e méthode, on utilise la distance qu'il reste à franchir par le joueur pour passer par le prochain point obligatoire.
Donc, le joueur qui s'éloigne se retrouve derrière celui qui vient tout juste de franchir le CP.
Bien sur, si les joueurs doivent suivre un parcours tordu jusqu'au prochain CP, la donnée est faussée.

À noter, qu'une course devrait toujours permettre au joueur de savoir où il se dirige. Quand je crée une course je met un CP à tous les coins de plus de ~90°. On évite donc des problèmes...

De toute façon, je t'envoie le code et tu pourra en faire ce que tu veut.

++Sim++

[Ssk]

Je déconseille fortement d'ajouter cette suggestion, vu l'intensité de "lag" ( même si depuis le temps elle s'est amoindrie ) actuelle sur les courses, rajouter ce genre de calculs ne ferai que du mal pour presque rien, au pire ce qui serai une alternative à tous ces calculs ce serai de faire comme tu l'a suggéré Syg, de comparer les positions selon le CP que l'on passe.

[Syg]

C'est pas faux Ssk. Et avec les modifications importantes que j'ai fait dans la version à venir, ça risque d'être encore plus critique.
Mais la deuxième méthode que j'expose ne demandera pas beaucoup de calcul (puisqu'ils sont déjà fait).

Par exemple, si un joueur franchi un CP et décide d'aller en direction inverse du CP suivant.
Avec la 2e méthode, il pourrait se retrouver devant un joueur qui est passé par le cp après lui et qui continue dans la bonne direction.
Bref, je ne crois pas que ce soit vraiment une très bonne méthode.

C'est certainement le problème que l'on retrouve dans NFS mais il est très vite corrigé quand on passe par un CP.
La méthode 2 est plus précise car elle prend en compte le trajet réel du joueur (celui qu'il a parcouru) et non un trajet hypothétique (la ligne droite entre le joueur et le CP suivant).

Je persiste en pensant que c'est la meilleure méthode. Elle est très fiable dans le cas où les joueurs suivent à peu prêt le trajet prévu.
J'ai fait quelques dessins de cas particuliers pour simuler les deux méthodes et dans tous les cas, la deuxième méthode est plus fiable.

De plus, même si je n'en parle pas dans mon poste précédent car ça me paraissait évident, dans chacune des deux méthodes, la première comparaison a effectuée est celle portant sur le dernier CP passé par les joueurs. Si un joueur A est au CP 12 et un joueur B est au CP 8, ce n'est pas la peine de comparer les distances, le joueur A est forcément en tête. Il ne faut considérer que la zone entre deux CP et tous les joueurs qui y sont.

++
Syg