- Version du jeu : Xnova Legacies 2009.2
- Version de PHP: 5.3.0
- Version de Apache: 2.2.11
- Hébergeur(s) où le problème survient: Aucun (WampServer)
- Navigateur web utilisé: Firefox 3.6.8

Problème rencontré :
--------------------

Ce bug apparait lorsqu'on fait revenir une flotte en cours de route et qui devait stationner sur la planète de destination.

Si cette flotte met 2 heures pour aller sur la planète de destination et qu'on la fait revenir au bout de 10 minutes. Elle mettra pas 10 minutes pour revenir mais 2 heures.

Le problème vient de fleetback.php et notamment de ce bout de code :

if ($FleetRow['fleet_end_stay'] != 0)
{
// Faut calculer le temps reel de retour
if ($FleetRow['fleet_start_time'] < time())
{
// On a pas encore entamé le stationnement
// Il faut calculer la parcelle de temps ecoulée depuis le lancement de la flotte
$CurrentFlyingTime = time() - $FleetRow['start_time'];
}
else
{
// On est deja en stationnement
// Il faut donc directement calculer la durée d'un vol aller ou retour
$CurrentFlyingTime = $FleetRow['fleet_start_time'] - $FleetRow['start_time'];
}
}

fleet_start_time >>> corresponds à l'heure où la flotte arrive à destination.

Si fleet_start_time est plus petit que time() >>> çà veut dire que la flotte est arrivé à destination et qu'elle a entamé le stationnement, contrairement à ce qui est marqué dans les commentaires ;)

Solutions proposées :
---------------------

Remplacer

if ($FleetRow['fleet_start_time'] < time())

par

if ($FleetRow['fleet_start_time'] >= time())

Configuration :

- Version du jeu :Xnova Legacies 2009.2
- Version de PHP : 5.3.0
- Version de Apache : 2.2.11
- Hébergeur : Aucun (WampServer)
- Navigateur : Firefox 3.6.8

Problème rencontré :
--------------------

Un serveur >>>> 2 univers A et B

Un joueur X dispose d'un compte [Id n° 10] sur l'univers A.
Un joueur Y dispose d'un compte [Id n° 10] sur l'univers B.

Le joueur X [Univers A] pourra prendre le contrôle du compte du joueur Y [Univers B] en appelant directement frames.php de l'univers B.

Cela est possible car la session du joueur X sur l'univers A existe toujours.

if (isset($_SESSION['user_id']))
{
     $sql =<<<EOF
SELECT * FROM {{table}}
WHERE id={$_SESSION['user_id']}
LIMIT 1
EOF;

     $userData = doquery($sql, 'users', true);
}

Il y a aucun contrôle afin de vérifier si la session du joueur appartient bien à l'univers en question ou d'un autre univers.

Si le joueur Y est administrateur sur l'univers B (Aie !!! xD)

Solutions proposées :
---------------------

- Prévoir un identifiant associé à chaque univers lors de l'installation dans game_config.

- Lors de la connexion sur l'univers, on stocke l'identifiant de celui-ci dans une variable de session.

- A chaque changement de page, on vérifie si la valeur de l'identifiant dans la variable de session est la même que celle dans game_config.
> Si les deux identifiants ne sont pas les mêmes >>> on supprime la session, les cookies et goto login.php :D

-L'expédition bug, on ne reçois pas les bonus ni les malus tel que la disparition de la flotte par exemple.
-Page blanche quand on veut consulter la page infos.php, qui donne des informations détaillées de chaque élément de l'arbre technologique.
-Page blanche quand on veut aller sur la page du chat.

Module gestionnaire d'empire :

- Flottes
- Planètes
- Bâtiments
- Recherches

- Version du jeu: WARSTAGAME
- Version de PHP: ???
- Version de Apache: ???
- Hébergeur(s) où le problème survient: (précisez le nom ou s'il s'agit de tests en local)
- Navigateur web utilisé: mozzilla firefox

Problème rencontré: je jouer a warstagame quand tout a coup une page pleine de chifre et lettre souvrit je fit precedent et tout mon compte warstagame a etai remi a zero

Solutions proposées:jespere que vous trouverer une solution pour que je continu a jouer avec mon compte car je ne compte pa en crer un autre

Refonte de la gestion utilisateur, en se basant sur  FS#117 

Classe : Nova_User_Model_Session
Classe parente : Nova_Core_Model_SessionAbstract
Type : Modèle (singleton)
Méthodes nécessaires :
- getUser()
- getUserId()

Classe : Nova_User_Model_User
Classe parente : Nova_Core_Model_Database_EntityAbstract
Type : Modèle
Méthodes nécessaires :

- login(string $user, $string $password) : connexion de l'utilisateur
- logout() : déconnection
- register(string $username, string $password, array $userdata = array())

Classe : Nova_User_Model_Resource_Dal_Mysql4_User
Classe parente : Nova_Core_Model_Resource_Database_EntityAbstract
Type : Resource DAL Mysql4
Méthodes nécessaires :
- néant -

- Version du jeu: Legacies 2009.2
- Version de PHP: PHP 5.3.0
- Version de Apache: Apache 2.2.11
- Hébergeur(s) où le problème survient: tous les hébergeurs :p
- Navigateur web utilisé: Google Chrome

Problème rencontré: Pour chaque ami afficher dans la liste, le nom de l'alliance est ajouter.
Exemple
joueur1 , alliance : test
joueur2, alliance : test j2alliance
joueur3, alliance : test j2alliance

Dans l'exemple, le joueur3 n'as pas d'alliance, mais aura comme alliance dans la liste la dernière alliance afficher.

Le code qui pose ce problème est :

if ( $u["ally_id"] != 0 ) { // Alianza
// $allyrow = doquery("SELECT id,ally_tag FROM {{table}} WHERE id=".$u["ally_id"],"alliance",true);
// if($allyrow){
$UserAlly .= "<a href=alliance.php?mode=ainfo&a=" . $u["id"] . ">" . $u["ally_name"] . "</a>";
// }
}

Solutions proposées:

if ( $u["ally_id"] != 0 ) {
$UserAlly = "<a href=alliance.php?mode=ainfo&a=" . $u["id"] . ">" . $u["ally_name"] . "</a>";
} else {
$UserAlly = "";
}

- Version du jeu : 2009.2
- Version de PHP : Aucune importance
- Version de Apache : Aucune importance
- Hébergeur(s) où le problème survient : Test en local
- Navigateur web utilisé: Firefox mais çà ferait pareil avec un autre ;)

Problèmes rencontrés :

1°) Le code dans common.php affichant un message au joueur : << le serveur de jeu est clos >> ne fonctionne pas.
2°) Une fois réparé, le message apparait mais le skin n'est pas affiché.

Solutions proposées :

1°) Très léger changement dans le code pour afficher ce message si l'univers est fermé
2°) Déplacement du code qui déclare et initialise la variable $dpath pour le mettre plus tôt (avant l'appel de la fonction message)

Voir le patch ci-joint pour les modifications

Ajout du support des fichiers Pack

Tests unitaires de Lineage_Setup