Mieux comprendre le fonctionnement des rétros

[achrafmaziz 29]

Bonjour à tous,

Je vais donc vous expliquer ici en détails (selon ce que je sais) ce qu'est un rétro serveur, le fonctionnement d'un rétro serveur Habbo.

 

Un rétro serveur Habbo (Serveur Rétroviseur Habbo ou Serveur Retour) est une copie plus ou moins conforme du jeu de Sulake: Habbo, ce dernier tourne grâce à un émulateur qui permet de transformer les données de la base de données en récupérant des données de Habbo.com (du moins les SWF utilisent les données de Habbo.com). Les données émulées sont propulsées via une interface dynamique qu'on appelle le CMS.

 

L'émulateur

 

Vous l'avez surement remarqué, mais les émulateurs actuels sont bien plus performants que les anciens émulateurs. Bien que le code soit bien plus performant ils faut aussi remarquer le changement de fonctionnement de l'émulateur. Avant, si vous l'avez déjà constaté, les émulateurs étaient (plus ou moins) stables, mais en regardant de plus près, ils étaient totalement indépendant. Avec l'arrivée de la R28 (j'insiste bien, c'est le début d'une longue zone d'instabilité au niveau des émulateurs), les émulateurs restent indépendants. Cependant, la R36 représente un gros changement avec l'apparition (pour la version flash) d'un nouveau problème. Les packages. Personne n'a réussi à être indépendant de ceux ci. Si vous vous souvenez de quelques projets sur ces versions là, il y avait pas mal de problème avec la Mod Tool, et différentes fonctionnalités. Il faut donc récupérer les packages de Sulake. Mais cela ouvre des possibilités inimaginables. D'ailleurs, il y a quelques temps de cela, il y avait une psychose générale dans la communauté des rétros lorsque Sulake annonce changer la sécurité qui protège ses packages. En revenant au sujet, peu d’émulateurs réussissent à maîtriser ce système de packages. Peu? Un certain Meth0d travaillait sur un projet très ambitieux nommé Uber Emu. Il est le premier à maîtriser en partie ce système de packets. Il est suivi également par Marteen (je ne sais pas si ils ont travaillé ensemble) qui met en vente un émulateur stable (plusieurs versions selon votre utilisation) pour R42 (CokeDev ont été les premiers à l'utiliser).

Sachez également qu'il faut une base de données qui fonctionne (quel qu’en soit la forme, il faut stocker et récupérer les données quelque part). Tous les émulateurs en utilisent une et elle n'est pas forcement sous la forme que vous pensez (je pense par exemple aux émulateurs OldSchool qui utilisent une base de données "à même l'ému")

Bref, vous l'aurez compris, l'émulateur récupère des données à Sulake pour faire fonctionner des SWF crackés justement pour l'émulateur. Apprenez d'ailleurs par simple culture générale que Phoenix Emu est un développement basé sur Uber Emu.

 

Les SWF

 

Beaucoup diront que les SWF ne sont que des images. Ceci est tout simplement faux. Derrière les images il y a aussi des scripts. En voici un exemple (pris tout à fait au hasard)

<layout name="purchase_confirmation" width="20" height="20" version="0.0">
<window>
    <frame x="51" y="38" width="320" height="200" params="33025" style="0" caption="%24%7Bcatalog.club.buy.confirm%7D" color="0x418db0">
     <children>
        <border x="0" y="0" width="308" height="168" params="2192" style="0" caption="%24%7Bcatalog.club.buy.confirm%7D">
         <children>
            <icon x="12" y="12" width="85" height="40" params="16" style="17" name="icon" caption="%24%7Bcatalog.club.buy.confirm%7D"/>
            <text x="100" y="12" width="200" height="110" params="16" style="0" name="description" caption="">
             <variables>
                <var key="font_face" value="Volter" type="String"/>
                <var key="font_size" value="9" type="uint"/>
                <var key="text_color" value="0x0" type="hex"/>
                <var key="embed_fonts" value="true" type="Boolean"/>
                <var key="word_wrap" value="true" type="Boolean"/>
             </variables>
            </text>
            <button x="9" y="135" width="120" height="25" params="132113" style="0" name="select_button" caption="%24%7Bcatalog.club.buy.subscribe%7D" width_min="120" width_max="120"/>
            <button x="180" y="135" width="120" height="25" params="132113" style="0" name="cancel_button" caption="%24%7Bcancel%7D" width_min="120" width_max="120"/>
         </children>
        </border>
     </children>
    </frame>
</window>
</layout>

Ce code définit la confirmation d'un achat.
Ces codes également ont une image qui leur est attribuée et qui est ce que vous voyez en jeu.
D'ailleurs, pourquoi n'utilisons nous pas les SWF de Habbo.com? Tout simplement parce qu'ils ne sont pas crackés pour fonctionner avec tel ou tel émulateur.

 

La Base de données

 

La Base de données est le centre de divergence de l'émulateur. Les données de la base de données sont émulées via l'émulateur et transformés en image via les SWF,  à part que sans base de données l'émulateur ne tournera jamais.

 

Le CMS

 

Le CMS est l'interface qui permet de propulser le jeu. Quelque soit l'émulateur il y a une interface qui permet la connexion à l’hôtel (du loader au très complet Uber CMS). En quittant les versions OldSchool (avec l'apparition de CMS très complets), les bases de données type MySQL apparaissent pour propulser le CMS. De Naked CMS à System CMS, il n'y a pas de grand changement par rapport à la connexion en jeu (bien que le client ait changé) on retrouve toujours une interface dynamique modifiable via la Base de données ou l'administration. Notez qu'on peut différencier les rétros OldSchool à ceux actuels avec le système de SSO Login apparut en V23 avec la première version de Holograph Emu utilisant un CMS, un database MySQL. Je considère ce système comme un grand trait de partage entre OldSchool et rétros actuels et comme seul point commun entre versions Old et versions Flash. Ce système permet l'authentification unique, et ayant commencé les rétros avec l'apparition du SSO Login, je pense que c'est un fait marquant.

 

Ce sujet a été déjà publier par BlackHole sur iBuild (eeeh oui, mdr) en 2012.

[Seigneur Vador 165]

Le sujet remonte effectivement mais c'est sympa de l'avoir remis ici, Merci!

 

Valentin.