Raydium 3D Game Engine

En fait, j'avais pas du tout recompiler...Effectivement ya probleme

De mon coté, j'ai ceci


... ce qui dans l'idée reste normal puisque nous devons maintenant utiliser le support SOAP natif de PHP5 et non NuSOAP.

Normalement, PHP5 reste compatible avec PHP4 et nusoap devrait continuer à marcher...Le problème ressemble à une collision de namespace. Je pense qu'il faut enlever --enable-soap (que j'ai du rajouter a la fin sans trop tester) du configure (ou utiliser le soap natif)

Désolé, ca m'apprendra a ne pas faire un test complet avant de commiter

_________________
Phyce

Ah bhen nan ! On va pas virer l'un des ajouts intéressants de PHP5 ! Il faut migrer de nusoap vers le soapclient natif de PHP5 (et supprimer le rep. NuSOAP), sinon je ne vois pas l'intérêt

Je suis en ce moment en train d'essayer de porter tout ça sous windows ... eh bien c'est loin d'être gagné ...

C'etait la méthode "Quick n' dirty"

OK, je regarde le passage de nusoap a soap natif juste en ce moment.

_________________
Phyce

Ca marche, je commite mes changements a mania_score.php et mania_score_get.php + suppression de nusoap

Petite question : c'est normal qu'il y ait un $result++ avant d'afficher le classement ?

Petite question annexe : Pourquoi lorsqu'on clique sur "internet tracks" ca fige pendant plusieurs secondes ? (ca fait ca chez moi depuis toujours) Ya-t-il un accès réseau a ce moment la ?

_________________
Phyce

result++ est présent pour passer d'un rang (0..n) à une place (1..n). Le clic sur "Internet Tracks" va effectivement télécharger la liste des circuits dispos sur le net pour ManiaDrive (mania_track_list.php ou un truc comme ça de mémoire), et le garde en cache.

en fait le probleme vient de

apellé au début de mania_tracklist.php

Il a l'air de tester une connexion a internet en testant le port 53 d'un DNS racine, ce qui non seulement ne marche pas derrière un firewall, et de plus c'est mal d'utiliser des ressources que l'on ne controle pas dans ses programmes réseau...cf le scandale D-Link sur les serveurs NTP.

A ma connaissance, le réseau est utilisé pour 2 choses distinctes dans Raydium :

-- Télécharger des fichiers depuis les repository, en envoyer, utiliser soap pour les scores, et récuperer cette tracklist, qui sont toutes des opérations liées à HTTP (proxies) et vraiment liées à l'accès a Internet

-- Jouer en réseau (local), avec des datagrammes UDP qui ne quitteront de toute facon pas le réseau local

Je trouve que cette fonction s'intègre mal au schéma qui se dessine, avec :
-- Les services HTTP gérés par PHP d'une part
-- Et le moteur réseau du jeu proprement dit d'autre part, qui doit rester en C.

Je propose de gérer le test internet en PHP, dans rayphp ; et de ne plus utiliser cette fonction.

_________________
Phyce

Cette fonction à un avantage : elle est fiable (au ""détail"" du proxy près). Détecter une connexion internet à la fois sous Linux et win32, dans différents cas de figure (c'est à dire avec des interfaces down [mais un loopback] mais aussi avec des interfaces up mais déconnectées physiquement) s'est avéré assez complexe.
S'il est possible de reproduire ce comportement en PHP, c'est bien sûr une solution idéale.

- Et pendant ce temps là, je galère avec PHP5/MinGW/win32 ... -

C'est ok pour windows, on peut avancer

Cool pour les windoziens !

L'idée est que le mode "internet tracks" ne marchera pas sans un accès web (pas de scores, mais aussi pas de possibilité de downloader des fichiers), on doit commencer par le tester en allant chercher le fichier tracklist.txt sur le serveur.
-- Si ca marche, on met a jour la liste et on peut jouer,
-- Si ca marche pas, on fait un dialogue du genre "please check your connection to the internet, and the proxy settings in the option menu"

Et dans les deux cas, la liste stockée sous forme de fichier n'est pas utile.

OK, si on a déja le fichier circuit, on doit pouvoir jouer quand meme, mais avec des ralentissements (du genre 20 secondes d'attente pour (ne pas) avoir les temps records), et c'est pas garanti.

Et je persiste, le test de fonctionnalités web ne se fait pas en testant le DNS : tout le monde n'est pas a la maison derrière son routeur perso...

_________________
Phyce

Il ne faut pas interdire à un utilisateur sans connexion de jouer à des circuits qu'il a déjà probablement en local. Il faut tester la connexion (encore une fois d'une manière différente du ping sur les roots DNS si il y a mieux, je suis tout à fait d'accord) et garder cet état pour éviter l'attente des timeout pour les scores.
Ca n'empêche pas l'apparition d'un éventuel message d'avertissement si le net n'est pas dispo.

La modification semble mineure une fois que l'on disposera d'une nouvelle version de raydium_network_internet_test() qui passe les proxies

J'ai ajouté une fonction http_test qui cherche a télécharger le (petit) fichier de tracklist :


Si pas de réponse en 3 secondes, c'est que pas de connexion ou que les paramètres sont mauvais. Je pense qu'on peut ainsi se passer de raydium_network_internet_test() qui n'est de plus utilisé que dans mania_tracklist.php.

On peut faire en sorte que mania_tracklist rende une nouvelle variable boléenne, qui permettrait l'affichage d'un message et la désactivation du SOAP.

_________________
Phyce

Je pense au contraire qu'il ne faut pas se passer de raydium_network_internet_test() mais la ré-écrire (sans doute sous un nom différent) selon ta première idée, dans RayPHP, et l'utiliser juste avant de récupérer (ou non, du coup) la liste des circuits.

Ce passage par Curl règle bien des détails, sachant que le point négatif dans cette affaire reste le fait que Raydium devient dépendant de raydium.org et de sa qualité de connexion pour la détection de l'accès au net. Mais c'est peut être le prix à payer
Au cas ou : http://raydium.org/ping.php (ok, c'est [très] minimaliste, mais ça fait l'affaire )

Désolé, j'ai manqué de clarté dans le post précédent :
-- Le bout de code est bien dans RayPHP, est est appelé avant de récupérer (ou pas) la liste des circuits. Exemple d'utilisation :

-- quand je parlais de se passer de raydium_network_internet_test(), j'entendais "de la fonction C dans network.c, et de son enregistrement dans RegAPI"

Le coup de la variable supplémentaire, c'est effectivement pas forcément le plus propre : idéalement, il faudrait tester 1 fois dès le démarrage de Raydium et s'en souvenir, ou tester à chaque utilisation du réseau (plus simple, mais c'est pas top pour la bande passante). Mais ca me paraissait le plus facile à court terme.

_________________
Phyce

C'est moi qui ai mal lu ton extrait de code

C'est OK pour moi, mais je vois venir à nouveau un un autre problème (connu) : RayPHP ne supporte pas la récursivité. En clair, du PHP ne peut faire appel à une fonction C si cette dernière fait elle même appel à du PHP. Ce cas peut sembler rare, mais c'est ce qui se passe lorsque qu'un script PHP (comme la console ingame, par exemple) cherche à afficher un objet ou une texture alors que cette donnée n'est pas encore dispo en local, ce qui va engendrer un téléchargement par "R3S" (qui est écrit en PHP).

Si on souhaite faire bien les choses, il serait logique de placer ton code dans un fichier rayphp/httptest.php (par exemple) et d'encapsuler son appel dans une fonction de rayphp.c, à l'image des autres fonctions du genre. Dans cette situation, il devient impossible de se servir de cette fonction depuis mania_tracklist.php (PHP->C->PHP) ...
Faire à la place un appel "direct" à une fonction PHP qui encapsule le script httptest.php semble résoudre le problème, mais uniquement pour le cas qui nous intéresse.

Je me doute que mon explication n'est pas limpide, donc voilà une petite aide pour comprendre ce qui me semble être la seule solution "simple" qui me vient à l'esprit :
rayphp/httptest.php (ton code)
rayphp/direct.php (nouveau fichier chargé d'encapsuler toutes les scripts rayphp/ qui doivent pouvoir être appelées directement depuis PHP, tel httptest.php)
mania_tracklist.php (avec un require_once de rayphp/direct.php)
raydium/rayphp.c (qui encapsule lui aussi httptest.php mais à destination du C uniquement [pas de ref dans RegAPI, donc])

Je ne sais pas si je suis clair, mais je pense que nos idées se rejoignent
A terme, il faudrait plutôt être capable de trouver une astuce pour permettre des appels récursif du Zend Engine.

Pourquoi pas la disposition suivante :

-- rayphp/libfile.php contient la fonction http_test()

-- on crée un fichier httptest.php,

qui est utilisé par rayphp.c pour permettre l'appel depuis le C.

-- mania_tracklist.php reste inchangé par rapport a mon post précédent (avec require_once("libfile.php") au début pour importer la fonction http_test())

Je vois pas bien ce qu'apporte direct.php, puisque la majorité des scripts (comme getfile.php) utilise déja la librairie libfile.php. Autant rajouter cette nouvelle fonction dedans, quitte a renommer "libfile" en "rayphp" si le nom un peu restrictif dérange.Ou d'envisager son éclatement en blocs fonctionnels, sauf pour le moment toutes les fonctions servent de près ou de loin au transfert de fichier.

_________________
Phyce