C’est officiel : j’en ai marre.
5 jours que je me prends la tête à faire un fichier de sauvegarde de profil crypté. Et ça fait n’importe quoi.
Objectif :
J’ai un fichier “profiles” dans lequel je stocke les session de jeu de x joueurs.
Contraintes :
Je dois mettre à jour la session d’un joueur en particulier lors d’un autosave, sans altérer les sessions des autres.
Je dois crypter le fichier pour empêcher les cheats.
Procédure :
Charger le fichier “profiles” en mémoire
Décrypter le fichier “profiles” vers “profiles.decrypt”
Charger le fichier “profiles.decrypt” en mémoire
Mise à jour des éléments que je veux
Crypter le fichier “profiles.decrypt” vers “profiles”
Fermer le fichier “profiles.decrypt”
Supprimer le fichier “profiles.decrypt”
Fermer le fichier “profiles”
Et au mieux, j’ai un fichier “profiles.decrypt” qui se met bien à jour avec tous les profiles d’avant, mais pas “profiles” !
J’ai vérifié en ne supprimant pas le fichier “profiles.decrypt”. Il recoit bien les nouvelles valeurs et les nouveaux profiles, et les recrypte bien dans “profiles” (changement de taille du fichier).
Mais impossible de relire ensuite le fichier “profiles”, qui me génère systématiquement un fichier “profiles.decrypt” vide.
J’ai la désagréable impression que la commande “décrypter fichier vers fichier.temp” ne marche pas.
Soit il ne trouve pas le fichier à décrypter à cause d’une histoire de chemin, soit il génère un fichier nul.
En tout cas, les infos cryptées sont inexploitables puisque non lisibles à postériori.
Ma méthode est-elle mauvaise ?
Pourquoi n’y-a-t-il aucun détail dans la doc sur comment procéder pour une fonction “de base” de tout jeu vidéo qui se respecte depuis presque 30 ans ?
“Charger” et “Fermer” sont-ils utiles ou deprecated ?
Il n’y a pas besoin de charger en mémoire un fichier qui va être decrypté ou crypté. Le chargement en mémoire n’est utile que quand on procède ensuite à des actions/conditions qui concernent la structure XML du fichier. Dans ton cas, c’est peut être la cause du soucis, vu que GD va charger le fichier en mémoire, puis le sauver quand tu va le décharger. Sauf que vu qu’il n’a rien compris au fichier quand tu l’a chargé ( le fichier était crypté ), il va sauver un fichier vide quand tu va le décharger de la mémoire.
Voilà un exemple de comment procéder, j’ai testé ça marche sans soucis :EncryptionExample.gdg (11.1 KB)
J’avais pensé à ça aussi. J’avais donc essayé sans charger/fermer. Mais le résultat n’était toujours pas bon.
Le pire, c’est que pendant un moment, ça marchait bien.
Mais j’ai changé une ligne à un moment, et depuis, c’est la bérézina.
GD plante à l’ouverture. Erreur C++
On ne doit pas avoir la même version de GD.
Je l’ai ouvert en xml, mais c’est pas évident de suivre les instructions en full text …
Ah oui mince, j’ai supprimé dans la nouvelle version de GD l’enregistrement d’une donnée qui ne sert plus à rien depuis longtemps, mais ça fait crasher les anciennes versions qui tentent d’y accéder lors de l’ouverture du fichier sans prendre de précautions. Ça devrait être bon maintenant :EncryptionExample.gdg (11.3 KB)
Donc le problème venait de là : mon mot de passe ne faisait pas 24 caractères exactement.
J’imagine que lors du cryptage, GD remplissait les caractères manquants avec du vide. Et bien sûr, lors du décryptage, ces caractères manquants n’étaient pas remplacés. D’où un fichier decrypt ignoré lors du chargement en mémoire, puisqu’illisible.
Mon algo était donc bon, c’était le mot de passe qui était mauvais.
Ca avait dû fonctionner avant, car le mot de passe était à vide.
Petite question subsidiaire : l’association d’objet est-elle affectée par le mouvement de la caméra ?
J’ai une suite d’objets texte qui représentent mes sauvegardes. Je peux faire défiler cette liste de haut en bas en bougeant la caméra. Bien sûr, cette liste est créée dynamiquement. Il y a donc x association d’objets texte-zoneInteractive simultanément.
Mais quand je sélectionne une des sauvegardes, après avoir bougé la caméra vers le bas de l’écran, c’est une des premières associations qui réagit.
Tant que la caméra est à son origine, l’association texte-zoneInteractive est bonne (premiere = premiere, derniere = derniere).
Dès que la caméra bouge, l’association se décale d’un écran vers le haut, sur les premières zoneInteractive (derniere = derniere “moins un écran” ).
Ce qui est sûr, c’est que l’association d’objets est quelque chose d’uniquement virtuel et que ça n’a rien à voir avec la partie graphique.
Montre peut être les évènements qui gère l’association des objets ?
Ces évènements ont lieu au lancement de la scène. Ils sont donc bien exécutés une seule et unique fois.
Tant que j’ai encore un profil dans mon fichier de profils, je reste dans la boucle et je crée l’objet profilZoneInteractive.
Ensuite, en reprécisant sa position, je l’oblige à prendre la profilZoneInteractive juste créée et à l’associer au reste des objets.
Mais quand je bouge ma caméra (Y+10 de la camera du calque ListeSauvegardes où sont créés les objets texte des profils), le changement d’opacité a lieu de manière décalée.
Quand je remets la caméra à son origine (Y-10 jusqu’à arriver à Y==0), les associations se font correctement.
Comme si GD se repérait sur les coordonnées de l’écran pour déterminer quels objets sont associés …
La caméra ayant modifié sa zone de rendu, ces coordonnées de fenêtre sont évidemment fausses. Mais pourquoi GD se baserait-il là dessus ?
Masque de collision entre deux objets (profilZoneInterractive, les rectangles blancs transparents, et petitCarre, le petit carré blanc qui suit la position de la souris à l’écran).
Ah ouais …
Le problème vient peut être de là alors ?
Les rectangles blancs sont sur leur propre calque (ListeSauvegardes) et le curseur de souris sur le sien (ViseurSouris).
Si je bouge le calque ListeSauvegardes seulement, on a deux coordonnées différentes : celle des objets et celle de la souris, même si à l’oeil nu ils sont au même niveau.
C’est assez dangereux de mélanger les conditions de collisions entre objets de calques différents, car leur position qu’on aperçoit ne correspond pas à leur position X/Y réelles… Utilise plutôt une condition comme “le curseur est sur l’objet” qui prend en compte les calques.
