Oulà, y'a beaucoup de sujets là. On va éviter de trop s'étendre sur les points qui ne sont pas liés au problème qui nous occupe dans ce thread : les broadcasts.
1) pb. de repository
Comme tu le dit juste après, le problème est (visiblement) que tu ne lance pas l'exe "dans le répertoire par défaut". A quoi ressemble ta configuration sur ce point ? Ici le jeu cherche à utiliser un script qui est livré
avec les sources et donc pas présent sur le repository (mania_server_tracks.php).
Je pense qu'il faut ouvrir un nouveau thread sur ce sujet.
2) mania_server_tracks.txt
L'idée était de ne pas fournir de liste de circuits par défaut pour "forcer" l'administrateur du serveur à écrire sa propre liste, tout en connaissant du coup le fichier chargé de contenir cette liste.
Sachant qu'il était prévu un "éditeur de liste de circuits" dans ManiaDrive, cela tenait debout. Il est vrai que cette idée (l'éditeur) est laissée de coté pour l'instant, il parait logique de proposer une liste par défaut sur le repository. Je vais tacher d'y penser.
3) napleon (et les autres musiques)
Trop gros, pas tout à fait dans l'esprit du repository, liberté pour l'utilisateur de compléter ou remplacer les musiques par défaut, etc ...
Autant de raisons de ne pas placer les musiques du jeu là bas.
Soit l'utilisateur télécharge le pack de données du jeu (dispo sur le site web), soit il réalise l'installation depuis les sources et n'a pas de musique.
Peut-être qu'une solution intermédiaire serait de mettre en place un repository spécifique à ManiaDrive en complément de l'autre. En attendant , vu l'extrême minorité de gens qui vont lancer ManiaDrive depuis les sources la première fois, je ne vois pas d'urgence. Erreur de ma part ?
4) le serveur et le client sur la meme machine
Pour la partie broadcast, effectivement, ça ne peut pas marcher (le port étant le même). En fait je me demande même comment ça fait pour marcher pour le reste
5) timeout de 10 secondes
Trop peu pour laisser le temps de télécharger les données la première fois, pas assez lorsque qu'un joueur sort brutalement du jeu et se reconnecte très vite ... l'éternel problème des timeout
Cette valeur est empirique, et semble être la plus tolérable pour l'instant. Il était prévu de faire envoyer un paquet par le client lors de se déconnection pour avertir le serveur et donc éviter les "ghosts", ce qui peut ensuite nous permettre de pousser le timeout à 30 secondes, par exemple. En attendant ...
6) comportements voitures / ombres / lenteurs
Important mais HS sur ce thread. En ce qui concerne le comportement de la voiture, je me permet de sortir toujours la même histoire : pour l'instant, il n'est plus possible de toucher à la physique du jeu (temps, circuits, bloc, etc, tout ça est calibré pour la physique actuelle), mais en revanche, il est prévu d'offrir à termes d'autres "univers" (genre neige, ville, etc) avec des voitures différentes et donc d'autres physiques.
7) 2 réseaux et broadcasts
Parfait ! C'est la preuve que windows à un comportement logique sur ce point
Détail amusant : c'est la première fois dans le code source que je dois écrire un truc du genre "#ifdef linux" et non "#ifndef WIN32"
Je vais donc pouvoir continuer à avancer sur ce sujet ce soir.
sleep / usleep dans tests.c
Oui, effectivement, c'est logique. Je vais là aussi tâcher d'y penser.
9) jouer sans serveur
Le serveur fait plus que jouer le rôle de simple répéteur : il gère les temps, le circuit en cours, les congestions réseau de chaque client, etc.
Et en LAN, le gain de perf avec 100% de broadcast contre la méthode actuelle est loin d'être évident. Il faut savoir qu'il est écrit un peu partout qu'il faut éviter les broadcast (risque important de flood du segment réseau). Un paquet toutes les 5 secondes, passe encore, mais 2000 paquets/minute pour chaque client, c'est moins évident
Sans compter que c'est beaaaaucoup plus simple à programmer au niveau de l'application cliente
heu... c'est tout