Overextended a publié la version 3.42.0 d'ox_lib le 1er novembre 2026, peu avant midi (heure de Paris). Si vous faites tourner un serveur basé sur ox, Qbox ou n'importe quel script qui dépend d'ox_lib, cette mise à jour ne s'installe pas à l'aveugle : elle impose une version minimale de la ressource require.
ox_lib est présent sur une grosse partie des serveurs FiveM francophones, souvent sans que les admins s'en rendent compte, parce que des dizaines de scripts l'exigent. On fait le point sur ce qui change et sur l'ordre dans lequel mettre à jour.
Ce qui change : require doit être en 1.0.2
Depuis la 3.41.0 du 25 octobre, ox_lib ne contient plus son propre système require : il est livré à part, dans une ressource nommée require, issue du dépôt cfxlua-require. La 3.42.0 va plus loin et exige au minimum la version 1.0.2 de cette ressource.
Cette contrainte est écrite dans le fichier fxmanifest.lua d'ox_lib, et c'est le nouveau module SemVer de la bibliothèque qui la vérifie. En pratique, un serveur qui a installé require 1.0.0 en même temps que la 3.41 aura une ressource trop ancienne. La 1.0.2 de require est sortie le 29 octobre 2026 et corrige un bug qui touchait la version Enhanced de FiveM.
Le reste des prérequis ne bouge pas : il faut toujours un serveur FXServer en build 7290 ou plus et OneSync activé.
Dans quel ordre mettre à jour
La règle tient en une phrase : require d'abord, ox_lib ensuite. Remplacez le dossier de la ressource require par la 1.0.2, puis celui d'ox_lib par le contenu du fichier ox_lib.zip de la release (pas le code source brut, qui demande une compilation de l'interface web).
Vérifiez aussi votre server.cfg : require doit démarrer avant ox_lib, lui-même avant tous les scripts qui en dépendent. Si vous gérez votre serveur avec txAdmin, faites une sauvegarde de vos ressources avant le redémarrage. C'est un réflexe que l'on retrouve dans nos outils d'admin préférés pour FiveM, et il évite une soirée de panique.
Notre conseil : passez par un serveur de test si vous en avez un. Démarrez, regardez la console, et ne poussez en production que si aucune erreur de dépendance n'apparaît.
Un module de logs enfin standardisé
La nouveauté la plus intéressante pour les admins est le module logger, attendu depuis longtemps selon son auteur. Il gère des niveaux de log, attache automatiquement les données du joueur concerné et uniformise la façon de brancher un service externe.
Limite importante : pour l'instant, seul Fivemanage est pris en charge. Le développeur annonce DataDog et Loki comme prévus, et s'attend à voir arriver VictoriaLogs. Si vous centralisez déjà vos logs ailleurs, il n'y a donc pas encore de raison de changer vos habitudes.
Pour les développeurs : GameEntity et Player
Les classes GameEntity passent de l'ancien système d'imports à des modules, avec de petits changements d'API. Un nouvel outil permet aussi d'écouter facilement les changements de statebags d'un joueur, via Player.on côté client.
Attention : la documentation n'est pas encore à jour. La note de version le dit franchement, la doc viendra plus tard. Si vos scripts maison utilisent GameEntity, relisez-les avant de mettre à jour, et regardez les exemples donnés dans la note de version ox_lib 3.42.0.
Les correctifs qui comptent
- Les callbacks nettoient désormais leur clé quand ils expirent, ce qui évite d'accumuler des entrées fantômes sur un serveur qui tourne longtemps.
- Les options des boîtes de saisie (input dialog) deviennent facultatives dans les définitions de types fournies, ce qui calme les avertissements de l'éditeur pour les développeurs.
- Plusieurs corrections au chargement de require et à l'initialisation de la ressource.
Et les scripts que vous utilisez déjà ?
Pour l'immense majorité des ressources publiques, rien ne casse : elles appellent ox_lib comme avant. Le risque vient surtout de l'installation, avec une ressource require oubliée ou trop vieille. Si vous avez monté votre base avec les scripts gratuits les plus répandus, il y a de fortes chances qu'ox_lib soit déjà dans votre dossier resources : ox_inventory et ox_target, par exemple, ne démarrent pas sans lui.
Les serveurs RedM sont aussi concernés : ox_lib déclare les deux jeux dans son manifeste, la procédure est la même.
Et pour les joueurs ?
Rien de visible. Si votre serveur préféré redémarre un peu plus longtemps que d'habitude ce lundi, c'est peut-être cette mise à jour qui passe. Côté staff des communautés GTA RP, le module de logs pourrait à terme simplifier le suivi des sanctions et des litiges, une fois les autres services pris en charge.
Notre avis
Une mise à jour plutôt saine : la contrainte de version est un peu pénible sur le moment, mais elle évite les plantages incompréhensibles quand une dépendance est trop ancienne. Mettez à jour cette semaine, à froid, sur un créneau calme, et gardez l'ancienne version sous la main au cas où.
