Préserver l'héritage
Rester compatible avec eD2K et Kad, conserver les mécanismes fondamentaux d'eMule et documenter les choix des développeurs historiques avant de les modifier.
La philosophie CODEX
Moderniser eMule.
Sans effacer son ADN.
CODEX n'est pas un nouveau réseau et ne cherche pas à rendre eMule incompatible avec son propre héritage. Le projet conserve le moteur eD2K/Kad, reconstruit l'expérience utilisateur, automatise certaines tâches devenues inutilement manuelles et remet en lumière vingt ans d'idées issues de la communauté.
Base de travail eMule 0.72a x64
Réseaux eD2K + Kad
État documentaire 30 août 2026
Le point de départ
Préserver. Comprendre. Construire.
CODEX part d'une idée simple : eMule n'a pas besoin d'être réinventé pour être modernisé. Son protocole, son moteur de transfert, Kad, les crédits, les hashes et les mécanismes de partage forment un socle éprouvé. C'est autour de ce socle que le projet travaille.
Moderniser l'expérience
Remplacer l'ancienne présentation par une interface sombre, cohérente, lisible sur les écrans modernes et organisée autour de tableaux de bord plutôt que d'une accumulation de fenêtres historiques.
Réutiliser les bonnes idées
Étudier les Mods, outils et branches qui ont expérimenté pendant vingt ans, puis reprendre seulement les idées encore utiles — en citant leur provenance.
Automatiser intelligemment
Les PC de 2026 disposent de ressources très différentes de ceux de 2002. CODEX veut utiliser cette marge pour automatiser la recherche, la gestion des serveurs, la pression disque ou l'entretien des sources sans modifier le protocole partagé avec les autres clients.
Architecture
Une nouvelle façade.
Le moteur eMule reste au cœur.
La stratégie CODEX consiste à séparer autant que possible l'interface moderne du moteur historique. Le backend continue d'assurer le réseau, les transferts, les sources, les crédits, l'intégrité des fichiers et les échanges eD2K/Kad. CODEX ajoute une couche de commandes, de télémétrie et de modules spécialisés, puis présente ces données dans sa propre interface.
CODEX n'est pas un nouveau protocole fermé.
CODEX n'est pas une rupture avec les clients eMule existants.
CODEX n'est pas seulement un thème graphique posé sur l'ancienne interface.
CODEX ne revendique pas comme nouvelles des idées qui viennent des Mods historiques.
03
Interface CODEXDashboard · Recherche · Transferts · Réseau · Partage · Statistiques · Préférences
↕ commandes & télémétrie
02
Modules CODEXDiskGuard · MaX Research · MultiServer · AutoClean · stratégies spécialisées
↕ intégration minimale
01
Moteur eMuleeD2K · Kad · uploads/downloads · sources · crédits · hashes · AICH · fichiers partiels
CODEX UI
L'interface n'est pas un habillage.
C'est une autre manière de lire eMule.
Le travail d'interface a été conçu comme un projet à part entière : navigation verticale, cartes thématiques, dashboards, données synthétiques, réglages contextuels et suppression progressive de l'ancienne interface visible.
⌂
Dashboard
Une vue de synthèse sans réglages superflus : activité du client, état du réseau, transferts, pression disque et indicateurs utiles en un coup d'œil.
⌕
Recherche
Une page moderne où la recherche, les filtres, les résultats et les statistiques vivent dans la même composition au lieu de dépendre de dialogues séparés.
⇅
Transferts
Présentation dense mais lisible des téléchargements et uploads, complétée par des indicateurs visuels de charge et d'activité.
◎
Réseau
eD2K, Kad, liste des serveurs, journal et qualité de connexion réunis dans un tableau de bord réseau cohérent.
◫
Partage
Bibliothèque partagée et informations de diffusion présentées avec les mêmes règles visuelles que le reste de CODEX.
◔
Statistiques
Les statistiques historiques d'eMule sont conservées comme richesse du logiciel, mais réorganisées avec résumés, graphiques et vues de performance plus accessibles.
⚙
Préférences
Les réglages gardent leur profondeur, avec une zone dédiée aux « Special Features by Akshaan » pour les fonctions propres à CODEX.
◌
Démarrage utile
Le splash screen et les états d'initialisation ont vocation à refléter de vraies opérations — connexion, chargement ou récupération de données — plutôt qu'une animation décorative.
Sous le capot
Huit fonctions majeures pour mieux exploiter eMule.
La page Concept distingue clairement les fonctions conçues par Akshaan, les briques natives d’eMule et les inspirations historiques documentées. Lorsqu’une filiation extérieure est connue, elle reste visible.
Signatures CODEX
Smart MultiServerMaX ResearchAdaptive Disk Guard v2Endgame
01Intégré
MaX Research by Akshaan
Une seule recherche déclenche plusieurs chemins de découverte : serveur principal eD2K, serveurs secondaires Smart MultiServer, Kad et Auto More. CODEX fusionne ensuite les réponses et supprime les doublons par hash ED2K.
by Akshaan · orchestration des mécanismes natifs eMule02Intégré
Smart MultiServer by Akshaan
Un serveur principal stable assure la session eD2K ; quelques serveurs secondaires complètent la découverte de sources. Le moteur mesure leur rendement, mémorise l'historique et remplace progressivement les serveurs improductifs.
by Akshaan · scoring, apprentissage, rotation et garde-fous03Intégré
AutoClean Extended by Akshaan
Exploite les noms alternatifs déjà observés sur le réseau afin de proposer ou appliquer des noms de fichiers plus propres : casse, présentation, tags inutiles et variantes incohérentes. Une assistance externe peut aider, mais elle reste optionnelle.
by Akshaan · les informations réseau restent le cœur du module04Validé
Adaptive Disk Guard v2 by Akshaan
Observe les écritures en attente, les données bufferisées, les fichiers actifs et l'évolution de la pression disque. Lorsque le stockage devient réellement le goulot d'étranglement, CODEX adapte la réception plutôt que de laisser les buffers grossir sans limite.
by Akshaan · pipeline disque eMule05Validé
Source Control + Adaptive Reask
Réunit A4AF, Source Exchange, reask serveur et Kad dans une couche de décision commune. Des cooldowns, temporisations et garde-fous empêchent cette orchestration de devenir agressive.
Mécanismes natifs eMule · orchestration CODEX06Validé
Performance Engine by Akshaan
Cooperative Hashing, Adaptive GUI, IntelliFlush, limite globale de sources et travail avec DiskGuard visent à préserver la réactivité CPU/RAM/disque sur des machines modernes sans modifier le protocole.
Référence actuelle : plafond global de 2500 sources07Intégré
Smart Upload Strategy by Akshaan
Concentre mieux l'upload disponible sans réduire la limite globale configurée, changer les crédits ni modifier l'ordre de la queue. Les profils étudiés agissent surtout sur l'ouverture de nouveaux slots : Équilibré ≈ 6 slots, Focus ≈ 3.
by Akshaan · inspiration conceptuelle SUC Lovelace, pas un port direct08VALIDÉ
Endgame by Akshaan
Traite la longue traîne des derniers blocs : récupération des réservations bloquées, réveil de sources, mesure du risque de dispersion et, lorsque nécessaire, réservation spéculative contrôlée du même bloc auprès de plusieurs bonnes sources.
NetF WARP · Spike2 · Silversurfer · réécriture CODEX mesuréeDiskGuard Visual Pressure by AkshaanVert → ambre → orange → rouge : la couleur expose la pression disque tandis que la hauteur continue de représenter le débit.
Interface CODEXLe cadre commun qui rend les fonctions lisibles : dashboards, cartes, tableaux modernes, DPI propre et réduction du recours visible aux anciennes fenêtres MFC.
Signature CODEX · Réseau eD2K
Smart MultiServer : plus de couverture, pas plus de bruit.
Smart MultiServer ne transforme pas eMule en client connecté sans discernement à une foule de serveurs. CODEX conserve un serveur principal pour la session eD2K et n'utilise qu'un petit ensemble de serveurs secondaires lorsque ceux-ci apportent réellement quelque chose : nouvelles sources, sources rares ou résultats complémentaires.
1 + quelques
Un principal stable, quelques secondaires utiles.
Le principal porte l'identité de session, le High ID et la stabilité. Les secondaires sont des éclaireurs : ils sont évalués, mémorisés et rétrogradés s'ils ne rapportent rien. Le but n'est jamais de maximiser le nombre de connexions, mais de maximiser l'utilité de chacune.
Rôle principal préservé
CODEX ne remplace pas le fonctionnement central d'eMule : un serveur reste la référence de la session eD2K. MultiServer ajoute une couche de découverte, pas une collection de « principaux » concurrents.
Secondaires sélectionnés
Les serveurs secondaires sont choisis pour leur rendement réel : stabilité, capacité à fournir des sources utiles, présence de sources rares et disponibilité dans le temps.
Scoring et apprentissage
Le moteur attribue des scores distincts selon le rôle, conserve l'historique des sessions et apprend quels serveurs méritent d'être sollicités à nouveau.
Rotation sans agitation
Un serveur improductif est progressivement remplacé. Les reconnexions frénétiques n'ont aucun intérêt : elles chargent le réseau sans augmenter la qualité des sources.
Fusion et déduplication
Une même source peut être vue par plusieurs chemins. CODEX fusionne les réponses au lieu de compter plusieurs fois la même information ou de relancer inutilement des demandes déjà satisfaites.
Complément de MaX Research
Les serveurs secondaires peuvent aussi enrichir la recherche, mais les requêtes restent ordonnancées et temporisées. MultiServer et MaX Research partagent la même philosophie : plusieurs chemins, une seule orchestration.
« Plusieurs serveurs = abus du réseau » ? Non, pas par principe.
Les garde-fous d'eD2K et d'eMule ont été conçus à la naissance et dans les premières années d'un réseau où les serveurs centraux, les débits, les disques et les machines n'avaient rien de comparable avec l'environnement actuel. Cela ne rend pas ces garde-fous inutiles : leur objectif — éviter la surcharge — reste essentiel, d'autant plus que le réseau est aujourd'hui plus petit. CODEX ne les supprime donc pas aveuglément. Il revoit la décision locale en conservant les formats eD2K, les temporisations, les cooldowns, la déduplication et une sélection restreinte de serveurs. Un secondaire inutile est moins sollicité, pas davantage.
Exemple emblématique
MaX Research : une recherche, plusieurs chemins.
Dans eMule classique, l'utilisateur choisit souvent où chercher. CODEX inverse la logique : l'utilisateur exprime ce qu'il cherche ; le moteur se charge d'interroger intelligemment les sources de découverte disponibles.
1Votre rechercheUne seule requête
→
2AServeur principaleD2K
2BSecondairesSmart MultiServer
2CKadRéseau distribué
2DAuto MoreCompléments utiles
→
3Fusion CODEXSearchID · file d'attente · temporisation · déduplication par hash ED2K
→
4Résultats uniquesProgressifs et regroupés
Pourquoi ? Parce qu'en 2026 le logiciel peut faire lui-même une partie du travail d'orchestration qui reposait autrefois sur l'utilisateur, sans modifier la manière dont les autres clients du réseau communiquent.
Fonction de confort
AutoClean Extended : faire parler les noms déjà vus sur le réseau.
Un même hash ED2K peut circuler sous de nombreux noms. AutoClean Extended exploite cette information déjà disponible pour rendre la bibliothèque plus propre sans toucher au contenu du fichier ni à son identité ED2K.
Comparer les variantes
Le module rassemble les noms alternatifs connus par les sources et recherche les éléments qui reviennent de manière cohérente.
Nettoyer sans dénaturer
Casse, séparateurs, tags inutiles, présentations incohérentes et variantes incomplètes peuvent être normalisés tout en conservant les informations réellement utiles.
Le hash ne bouge pas
AutoClean agit sur le nom local présenté à l'utilisateur. Il ne modifie ni le contenu, ni le hash ED2K, ni le fonctionnement du partage.
Assistance externe facultative
Une aide externe peut proposer un meilleur nom dans les cas difficiles, mais elle n'est pas le moteur du système. Sans service externe, AutoClean continue à exploiter les informations eMule disponibles.
Une petite fonction, mais typiquement CODEX : automatiser ce que l'utilisateur faisait à la main en réutilisant d'abord les données que le réseau fournit déjà.
Signature CODEX · Stockage
Adaptive Disk Guard v2 : le réseau ne doit pas dépasser ce que le disque peut absorber.
Un débit réseau élevé n'est utile que si les données peuvent être écrites proprement. Sur une machine moderne, le goulot d'étranglement peut se déplacer : ce n'est plus forcément la connexion qui limite eMule, mais le pipeline d'écriture, les buffers ou la latence du stockage.
Réseau → RAM → Disque
Le débit utile est celui que toute la chaîne peut soutenir.
DiskGuard ne cherche donc pas à « gagner » quelques KiB/s artificiels. Il observe le système et accepte au contraire de réguler lorsque continuer à remplir les buffers ne ferait que déplacer le problème en mémoire ou rendre l'application instable.
Écritures en attente
Le nombre et l'évolution des écritures en attente indiquent si le stockage commence à accumuler du retard.
Données bufferisées
La quantité de données conservée en mémoire permet de distinguer une pointe momentanée d'une pression qui s'installe réellement.
Fichiers actifs
La pression n'est pas interprétée de la même manière lorsque plusieurs partfiles écrivent simultanément. Le contexte compte autant que la valeur brute.
Régulation adaptative
Lorsque le disque devient le vrai goulot, CODEX adapte la réception au lieu de laisser la file et les buffers croître sans limite. Lorsque la pression retombe, le système récupère progressivement.
Visual Pressure
Vert, ambre, orange, rouge : la télémétrie de DiskGuard devient visible dans les dashboards. La couleur représente la pression tandis que la hauteur d'une barre peut continuer à représenter le débit.
Mesurer avant d'agir
La visualisation reste séparée de la régulation : l'interface montre ce que le moteur calcule déjà, elle ne change pas ses décisions. Cela rend la fonction explicable et testable.
Une optimisation qui sait ralentir.
C'est aussi une façon de respecter le réseau : demander et recevoir plus vite n'a aucun intérêt si le client ne peut pas traiter proprement les données reçues. DiskGuard préfère un débit soutenable à une pointe suivie de saturation.
Gestion des sources
Source Control : orchestrer avant de redemander.
eMule possède déjà A4AF, Source Exchange, les reasks serveur et Kad. Source Control ne crée pas un nouveau moyen de récolter des sources : il décide quand et dans quel ordre utiliser les mécanismes existants.
Réutiliser ce que l'on connaît
Avant de repartir chercher ailleurs, une source connue sur un autre fichier peut parfois être réaffectée intelligemment.
Source Exchange
Les échanges de sources restent ceux d'eMule. CODEX choisit leur moment d'utilisation, il n'invente pas un canal parallèle.
Reasks ciblés
Serveur et Kad sont relancés lorsque l'état du fichier le justifie, pas en boucle simplement parce qu'une fonction existe.
Adaptive Source Request Cooldown
Le garde-fou essentiel : temporisations, nombre de sources, état du fichier et activité récente déterminent quand il faut attendre plutôt que solliciter à nouveau le réseau.
Respect réseau : une orchestration intelligente peut demander moins inutilement. Réutiliser A4AF ou une source déjà connue est souvent préférable à multiplier aveuglément les nouvelles recherches.
Moteur local
Performance Engine : moderniser la machine sans modifier le protocole.
Le cœur d'eMule a été pensé pour des PC, des disques et des interfaces d'une autre époque. Performance Engine regroupe des améliorations locales destinées à mieux utiliser les ressources actuelles sans demander quoi que ce soit de nouveau aux autres clients.
Cooperative Hashing / Finalization
Le hachage et la finalisation doivent avancer sans monopoliser l'application pendant de longues périodes.
Adaptive GUI
Lorsque beaucoup d'activité est présente, rafraîchir l'écran à la même cadence n'apporte rien au réseau. CODEX réduit le travail d'affichage inutile pour laisser les ressources au moteur.
IntelliFlush
Réduire les flushs inutiles tout en préservant l'intégrité évite de transformer le stockage en source de micro-blocages permanents.
Global Source Limit
CODEX conserve un plafond global de référence de 2500 sources. Plus de mémoire disponible ne signifie pas qu'il faut accumuler sans limite des milliers de sources et leur coût de gestion.
Le principe : utiliser davantage l'intelligence locale, pas davantage le réseau. Une machine de 2026 peut mieux trier, mesurer, fusionner et planifier sans changer un seul paquet eD2K.
Upload & communauté
Smart Upload Strategy : optimiser le partage, pas l'éviter.
Le mot « stratégie » peut faire penser à une réduction de l'upload, voire à du leeching. Ce n'est pas le fonctionnement de la version publique de CODEX. Le budget d'upload configuré reste disponible pour le réseau ; CODEX agit principalement sur la manière d'ouvrir de nouveaux slots afin d'éviter de fragmenter inutilement ce débit.
Équilibré≈ 6 slots × 12 KiB/s
Davantage de destinataires simultanés, avec un débit utile visé par slot.
= même budget d'upload =
Focus≈ 3 slots × 24 KiB/s
Moins de nouveaux slots, mais des transferts plus consistants.
La limite globale ne baisse pas
Smart Upload Strategy ne réduit pas la limite d'upload choisie par l'utilisateur. Il répartit autrement le même débit disponible.
Les crédits restent intacts
CODEX ne triche pas avec le système de crédits et ne cherche pas à obtenir un avantage en falsifiant la contribution passée.
La queue reste la queue
L'ordre de la file d'attente n'est pas réécrit pour favoriser arbitrairement certains clients. La stratégie agit surtout sur l'ouverture des nouveaux slots.
Les fichiers restent partagés
La publication et le partage ne sont pas masqués. Les sources et fichiers partagés restent disponibles au réseau comme auparavant.
Pas d'expulsion brutale
Les slots déjà actifs ne sont pas jetés simplement pour atteindre instantanément un profil Focus. La transition doit rester propre.
Filiation historique assumée
Le Smart Upload Control de Lovelace fait partie de l'histoire des stratégies adaptatives. CODEX en retient l'idée générale d'un upload mieux piloté, mais Smart Upload Strategy n'en est pas un port direct.
Pourquoi ce n'est pas du leeching.
Le leeching consiste à profiter du réseau en réduisant ou en contournant sa propre contribution. Ici, la contribution n'est pas supprimée : même limite globale, mêmes fichiers partagés, mêmes crédits, même queue. CODEX cherche seulement à faire en sorte que le débit offert soit réellement utile à ceux qui le reçoivent. Trois slots alimentés correctement peuvent être plus efficaces que six slots affamés, sans qu'un seul octet d'upload configuré ne disparaisse.
Fin de téléchargement
Endgame by Akshaan : attaquer le syndrome des 99 %.
Les essais CODEX ont montré qu'une fin lente n'est pas toujours un manque de sources. Le problème peut venir de la manière dont les derniers blocs sont réservés : une source lente conserve un bloc alors que de meilleures alternatives sont déjà présentes.
10 ≠ 10
Le pourcentage restant ne suffit pas.
Dix blocs dans dix parties sont plus risqués que dix blocs concentrés dans une seule partie. CODEX regarde le nombre de blocs, leur dispersion, leurs propriétaires, les sources actives, le débit et l'âge des réservations.
Locked Block Recovery
Une réservation immobilisée trop longtemps sur une source lente peut être libérée afin qu'une autre source la récupère. Inspiration : Drop Stalled Sources de NetF WARP / Silversurfer, avec cooldowns CODEX.
Tail Source Wakeup
Lorsque la fin manque de sources réellement actives, CODEX peut réveiller A4AF et Source Exchange. L'idée dialogue avec Delayed NNP et la conservation de sources étudiées dans WARP et Silversurfer.
Adaptive Risk Manager
La fin est classée selon la quantité et surtout la dispersion des blocs : fragmentation large, goulot concentré ou fin minuscule mais répartie sur de nombreuses parties.
Speculative Block Racing
Si une bonne source est bloquée uniquement parce qu'un dernier bloc est déjà réservé ailleurs, CODEX peut autoriser une seconde réservation contrôlée. Les deux sources font la course ; la première livraison utile gagne.
Racing Cleanup
Après la victoire d'un challenger, les copies devenues inutiles sont nettoyées avec prudence. Une source reste conservée si elle possède encore d'autres blocs intéressants.
Adaptive Rate Collapse
Le moteur apprend le débit sain du fichier puis détecte son effondrement. Les seuils de travail 50 %, 25 %, 10 % et 5 % rendent progressivement la stratégie plus réactive.
Stale Pipeline Bypass
Les anciennes réservations déjà gagnées peuvent rester dans le pipeline pour accepter des paquets retardataires, mais E6 ne les laisse plus bloquer la capacité logique nécessaire au véritable dernier bloc.
Partial Final-Tail Rescue
En consultant la vraie gap list, CODEX peut demander à une autre source uniquement la zone encore absente d'un bloc partiellement reçu, sans redemander le préfixe déjà acquis.
Mesures P18De plusieurs minutes à quelques secondes
Sur un cas particulièrement pathologique, le dernier bloc mesuré autour de 30 secondes en E5 est tombé sous la seconde lors d'un test E6 disposant de nombreuses bonnes sources.
Stabilisation E6bisHystérésis + mode source-limited
Les seuils de sortie sont plus larges que les seuils d'entrée afin d'éviter le yoyo. Si seules quelques sources médiocres existent réellement, CODEX cesse d'intensifier inutilement les courses.
Principe : CODEX peut mieux utiliser les sources disponibles ; il ne peut pas créer une bonne source qui n'existe pas.
Principe réseau
Respecter eD2K.
Ce n'est pas figer eMule en 2002.
Beaucoup de garde-fous, temporisations et habitudes du client ont été posés à la naissance ou dans les premières années d'eD2K/eMule. Ils répondaient à une infrastructure, des serveurs, des débits, des CPU, des quantités de RAM et des disques très différents. Leur intention reste juste : protéger un réseau partagé. CODEX ne remet pas cette intention en cause ; il remet en question l'idée qu'une décision locale vieille de vingt ans serait intouchable par principe.
Le réseau actuel est plus petit et mérite même davantage de prudence. C'est pourquoi les optimisations CODEX sont construites autour de limites, cooldowns, déduplication, mesures et mécanismes de repli. L'objectif n'est pas « demander plus », mais demander mieux et seulement quand c'est utile.
ConserveLes formats de requête eD2K et les hashes existants
ConserveLes clients eMule classiques, serveurs eD2K et Kad comme interlocuteurs normaux
RéutiliseA4AF et Source Exchange au lieu de créer des chemins propriétaires
EncadreReasks, recherches et serveurs secondaires par temporisations et cooldowns
DédupliqueRésultats et sources pour ne pas transformer plusieurs chemins en plusieurs fois la même demande
MesureAvant d'intensifier ; et se calme lorsque les bonnes sources n'existent tout simplement pas
Pas de fork du protocole, pas de « Zero Upload » public, pas de contournement des crédits, pas de reask infini, pas de nombre illimité de serveurs, pas de source inventée.
Utiliser la puissance d'une machine moderne pour mieux mesurer, trier, planifier et décider localement. Le respect d'un réseau se juge à la charge réellement créée et aux règles observées, pas au fait qu'un chemin de code de 2003 soit resté inchangé.
Si un serveur ou un client distant refuse, temporise ou ne fournit rien, CODEX doit l'accepter. Une optimisation correcte sait aussi s'arrêter.
La ligne rouge CODEX : moderniser le client sans faire payer cette modernisation au reste du réseau.
Détails & confort
Des améliorations moins spectaculaires,
mais utiles tous les jours.
Search Result Status Markers
Reconnaît le hash ED2K d'un résultat afin d'indiquer immédiatement s'il est déjà en téléchargement ou s'il a déjà été téléchargé.
Tri moderne des Transferts
Les principales colonnes sont triables par clic avec inversion croissant/décroissant, tout en gardant la sélection liée au fichier par hash.
Fichiers terminés
CODEX conserve correctement les téléchargements finalisés dans la vue, évite les calculs réservés aux partfiles incomplets et affiche clairement l'état « Terminé ».
DiskGuard Visual Pressure by Akshaan
Les dashboards et donuts peuvent réutiliser la télémétrie de pression disque sans modifier l'algorithme de régulation lui-même.
Même atelier, deux projets
CODEX & Nonoï : deux projets, un même maître d’œuvre.
CODEX et Nonoï sont deux projets eMule conçus par Akshaan. Nonoï n’est donc pas présenté comme l’origine des fonctions CODEX : lorsqu’une fonction apparaît dans l’un ou l’autre projet, son attribution reste Akshaan sauf inspiration ou reprise extérieure explicitement documentée.
Les deux projets peuvent partager des idées, du code et des méthodes, tout en conservant leur identité propre.
1Fonction by AkshaanDéfinir le comportement et son objectif
↓
2AuditDépendances · code · risques
↓
3Implémentation cibléeModifier seulement ce qui est nécessaire
↓
4API & télémétrieMesurer et rendre la fonction lisible
↓
5Compilation & testValider avant le module suivant
Inspirations & crédits
Une filiation doit être précise, pas décorative.
Le site ne doit pas attribuer une fonction à un Mod simplement parce qu’il a travaillé dans le même domaine. Par défaut, les fonctions CODEX sont attribuées à Akshaan ; une origine extérieure n’est citée que lorsqu’une inspiration, une adaptation ou une reprise est documentée.
eD2K, Kad, A4AF, Source Exchange, hashes ED2K, pipeline des partfiles et mécanismes réseau restent les briques fondamentales utilisées par CODEX.
Maître d’œuvre des fonctions développées dans les deux projets. Nonoï est une autre identité eMule d’Akshaan, pas une source d’attribution distincte.
Dynamic Block Requests, Delayed NNP et Drop Stalled Sources ont nourri l'étude historique qui a précédé Endgame by Akshaan.
PartCompletionSpeedUp et l'historique de Faster Endgame ont aidé à comprendre ce qui avait déjà été tenté — et pourquoi CODEX ne devait pas simplement ressusciter une ancienne recette.
Récupération de sources bloquées, Delayed NNP et PartCompletionSpeedUp font partie du corpus directement audité pour le chantier Endgame.
Le Smart Upload Control illustre l'idée ancienne d'un upload adaptatif. Smart Upload Strategy CODEX n'en est pas un port direct et conserve sa propre logique.
Ce que CODEX retient des Mods
Le rapport historique Endgame a conduit à une règle simple : ne pas copier une fonction parce qu'elle est célèbre. Auditer, instrumenter la base moderne, comprendre le problème réel, puis réécrire seulement ce qui reste pertinent.
Explorer eMule Mods Atlas →Méthode de développement
Une amélioration à la fois.
Et toujours réversible.
CODEX avance par petits paquets autonomes. Une fonction est portée ou créée, compilée, testée et validée avant que la suivante ne soit ajoutée. Cette discipline est volontaire : le moteur eMule est ancien, vaste et très interconnecté ; multiplier les modifications simultanées rendrait les régressions impossibles à isoler.
- 01Auditer
Comprendre le code existant et identifier précisément le point d'intégration.
- 02Modifier au minimum
Éviter les refontes inutiles du moteur lorsque la fonction peut être ajoutée proprement.
- 03Compiler
Chaque paquet doit compiler seul dans l'environnement de référence avant de devenir une base de travail.
- 04Tester
Vérifier le comportement réel, pas seulement l'absence d'erreur de compilation.
- 05Journaliser
Conserver des logs distincts pour les scripts et la compilation afin de pouvoir retrouver une régression.
- 06Valider puis avancer
La version validée devient le point de départ du module suivant. Pas de pile de changements non testés.
« Je ne suis personne face aux Pères Fondateurs. »
Akshaan ne cherche pas à réécrire l'histoire d'eMule à son nom. CODEX part du travail accumulé par eMule et par les Mods historiques, documente les idées qui l'ont inspiré, puis tente de les adapter à une base moderne en restant compatible avec le réseau.