Yumi2004

Chaotic>Le plus étrange dans Marabounta, c'est qu'il y a pas assez de puissance pour matèrialiser des objets inertes, mais qu'il y en a suffisemment pour matèrialiser des IA et des humain à tous vas.

Il n'en a peut être PLUS assez après le transfert de la bande à basil. ^^

C'est surtout le programme de matérialisation et de multiplication de la Marabouta qui bouffe de la puissance, si a coté de cela on rajoute les programmes de matérailisation de la bande a Ulrich, ca commence a faire. Si en plus on rajoute le programmes pour les véhicules sachant qu'ils doivent lancer pleins d'autres sous programmes comme celui de calcul de trajectoire (cf "Nouvelle Donne", on arrive vite a saturation. Cela est encore plus vrai si on prend en compte que X.A.N.A soit le supercalculateur (j'en mettrai ma main a coupé), il y a deja tous les programmes des 5 territoires qui tournent, plus les programmes de création des monstres et ceux des tours.

Rentrons un peu dans les details.
Si vous ne connaissez pas grand chose a la programmation, et surtout la programmation orientée objet, sauter ces lignes

Alors si on imagine que le programme de création de Lyoko et ceux de gestions des perso et montres sont en programmation objet ( exemple C++) alors nos perso et les monstres peuvent etre representé comme une classe (sorte de struture avec plein de variables (champs) et de propriété (méthode) . Idem pour les tours...
Par exemple voici a quoi peut ressembler la classe caractérisant un personnage (celle d'un monstre serait analogue)

Class perso
{
//champs
entier point_de_vie = XXX;
véhicule nom_vehicule;
etc...

//methode
marcher(...)
courir(...)
sauter(...)
attaquer(...)
etc...
};

dans laquelle "véhicule" correspondant a une autre classe similaire a celle la. marcher(...), courir (...) correspondent a des fonctions plus ou moins complexe definie dans le programme.

Toutes ces classes sont stockées en memoire tantque les persos, monstres et véhicule sont matéralisés et entraine une multitude de calcul et de variables en memoire.Meme en considerant que les tours constituent des sortes d'index avec des pointeurs constituant d'autant de racourci pour effectuer ces calculs.Ils n'en restent pas moins complexes et gourmands en memoire et en processus.

Ce qui pourrait expliquer pourqoui Jeremie manque de puissance pour matérialiser les véhicules

J'espere que ma théorie n'etait pas trop soporique...

Oui, et étant donné le nombre de sphères qui composent la Marabounta, qui d'ailleurs grandit sans cesse lorsqu'elle est touchée, celà multiplie considérablement le nombre d'objets à gérer en même temps pour le supercalculateur, et chaque objet à ses propres propriétés. En plus, si on considère que le programme de Jérémie n'est pas parfait (même si on peut lui faire confiance de ce côté là), de la mémoire peut avoir été incorrectement allouée ou libérée. Multipliez une telle imperfection par millions, et vous avez un gros problème de mémoire à résoudre...

Oui, il faut bien apprendre a utiliser ces "malloc" et ses "free" pour attribué ou restituer de la memoire, comme a chaque devirtualisation, sinon la memoire est gardée et prend de la place pour rien. N'est pas ce que arrive a Aélita dans "D'un cheveu" où elle "disparait". c'est comme si son pointeur (son point s'acces dasn lyoko en quelque sorte) avait été supprimé sans restitué la memoire. c'est pour cela qu'avec "l'ADN numérique" (j'ai plus trop l'expression en tete) contenu dans le chéveux d'Aélita que Jeremie a reussi a mateliser, sert en quelque sorte a creer un nouveau pointeur sur la memoire d'Aelita en le matérialisant. Ce n'est qu'une hypothèse mains tres réaliste...

EDIT : Pour revenir sur la notion de classe que je pense réaliste pour definir perso et montres. Dans la notion de Classe, il y a le principe d 'héritage qui consiste a creer de nouvelles classes (appelees classes filles) qui contiennent au moins les meme champs et methodes que la classe mere ( = superclasse).Une instance de la classe fille est capable d'acceder aux memebres et methodes de la classe mere et peut redéfinir le traitement prévu d'une methode

Ce qui expliquer parfaitement que Odd soit obligé de detruire la premiere sphere que Jeremie a matérialiser ( car sans classe mere, plus de classe fille...) et que les spheres attaqué par Odd modifient le fait d'attaquer que des montres de X.A.N.A. pour attaquer Odd car les sphere attaquée par Odd redéfinissent le traitement de la méthode Attaquer en ajouter Odd a la liste de parametres d'attaque.

pour ses monstres, xana a peut être une partit de la memoire du super calculateur qui lui est reservé ? et jeremie doit faire avec le reste ?

Pourquoi pas, mais il s'agit alors d'un problème de mémoire, pas de puissance. Il y a d'ailleurs un épisode dans la saison 1 où il rencontre un tel problème (je ne sais plus lequel, j'ai moi aussi un problème de mémoire ), résolu grâce à la console d'Odd.

Très juste Olivier. mémoire != puissance... J'ai donc un peu dérapé en parlant des malloc/free, vu que ça a plus un rapport avec la mémoire et non avec l'activité, désolé. Ici, c'est bien un problème de puissance, non de mémoire.

Mais je maintiens le fait que la Marabounta et ses multiples sphères animées sont responsables de la faîblesse du supercalculateur. D'ailleurs, on ne peut pas vraiment dire que X.A.N.A. ait concentré toutes ses forces dans la bataille en virtualisant quelques petits monstres, comparé à l'épisode précédent et les 50taines de Krabes. Si même X.A.N.A. ne peut plus matérialiser un Kankrelat de plus, je vois mal comment Jérémie pourrait matérialiser des véhicules au fonctionnement relativement complexe. Ulrich s'est fait matérialiser, car Yumi et au moins deux Kankrelats ont été dévirtualisés avant.

Je vous rappelle que la Marabounta est inspirée des fourmilières et utilise donc une architecture de type SMA (système multi-agents) dans laquelle chaque agent est autonome et ne reçoit aucun ordre du PC de contrôle.

Très intéressants vos exposés en programmation.

Pour ma part... Je sais plus trop quoi penser. A part bien sûr qu'une incohérence reste une incohérence qui échappe aux scénaristes...

Si on suppose qu'il y a un espace alloué à Jérémie et un autre au supercalculateur-XANA, ça ne colle effectivement pas puisque les véhicules prennent moins de place que l'avatar de Yumi qui arrive après...
A moins que la Marabounta, quand elle devient autonome (dans le sens où elle n'est plus sous le contrôle de Jérémie) passe dans la mémoire du super-calculateur qui gère tout ce que Jérémie ne gère pas.
D'où, libération de place pour virtualiser Yumi.

La Marabounta est obligatoirement dans la mémoire du calculateur dés le départ (au plus tard, dés sa première éxécution sur Lyoko).

Il la virtualise, donc seulement son IA doit y etre !

Tu parles d'Aëlita ? Si c'est le cas, comme à chaques épisodes depuis Faux Départ, ce qui n'a jamais empéché de virtualisé les véhicules (ou alors, je comprend pas ce que tu veux dire).

Oui, mais avec le statut de "paquet expédié par Jérémie". Alors qu'Aëlita ne l'a pas.

Aëlita n'a pas le même statut que les autres Lyokons. Sa forme virtuelle est sa forme propre, et sa forme matérielle sa forme impropre, comme pour les monstres. Pour les autres c'est l'inverse. Donc il est normal pour Aëlita d'être effacée si elle est brutallement dévirtualisée. C'est le fait de matérialiser Aëlita qui réclame de bidouiller!

Ta théorie implique que Marabounta à le même statut que les véhicules. Donc si Marabounta arrive à se virtualiser, les véhicules ne devraient pas poser de problème.

Pour McIntosh: c'est précisément parce que Marabounta a le même statut que les véhicules que ça pose problême: le système refuse de consacrer trop de puissance aux objets de ce statut. Donc le supercalculateur dit "ah non, tu m'as déjà expédié la Marabounta, alors je vais pas accepter AUSSI les véhicules! L'espace mémoire qui reste il est pour XANA, Aëlita, les scanners et les monstres, c'est clair?"

Le degré 0 de l'argumentation scientifique... Mais au moins, tu vois où je veux en venir.

Pourquoi, dans ce cas, le système ne refuse pas d'allouer davantage de ressource à Marabounta ?

Euh… à quel moment? Je n'ai pas retenu ce truc-là.

Bah... au fur et à mesure que Marabounta se dévelloppe, il prend toujours plus de ressource. Donc si tous les programmes de Jérémie sont limité en ressource, la croissance de Marabounta devrait être limité dés que Jérémie ne dispose plus de ressource pour lancer ses programmes.

ça me donne l'idée d'une solution encore plus conne: il y a largement la puissance nécessaire disponible, mais le système refuse de l'utiliser au cas où Marabounta en réclamerait plus encore.

On n'est pas sûr non plus que la Marabounta pompe tant de ressources que ça. Les sphères sont nombreuses mais chacune d'entre elles fonctionne selon un programme simple, si j'ai bien compris. De plus, en se multipliant, les sphères détruisent des éléments de Lyoko (monstres, tours, éléments du décors...), libérant ainsi de la puissance de calcul.

Certe, mais dans ce cas, rien n'empèches la virtualisation des véhicules.

Et même en considèrant ça… c'était vraiment plus dûr de virtualiser les véhicules que le virus anti-Marabounta?

Bon, Marabounta avait dévirtualisé la moitié de la réserve de monstres de XANA et un lyokoguerrier, je crois, quand le virus a été envoyé. Mais dans l'hypothèse de l'isolement des ressources… ça devrait pas compter.

Hopper a peut être écrit la Marabounta sur Lyoko, après que XANA a échappé à son contrôle.
Ou alors Marabounta n'est autre que la forme primitive du programme XANA. Majin Hopper ne dit-il pas que XANA est un programme multi-agent ? Et Marabounta n'échappe-t-il pas au contrôle de Jérémie, tout comme XANA a échappé au contrôle de FH ?

à ce propos, il faut vraiment sortir des raisonnements tordus pour justifier que Marabounta attaque Aëlita… OK, Marabounta connaît chaque partie de XANA, dont celle qui appartient à Aëlita… D'où son agression contre la semi-elfe.