Citizen

Et t'as bien raison ! Ceux qui devraient avoir honte sont ceux qui disent: "j'ai essayé mais j'ai pas réussi, je montre pas ce que j'ai fait peux-tu le faire à ma place ?". Souvent ils n'y ont passé que 10 minutes max, n'ont pas envie d'apprendre et veulent quand même sortir un serveur ! LOL J'apprécie que tu es testé toi-même de faire les corrections vu le temps que j'ai passé à tout détailler (pourquoi, comment) avec le raisonnement pour bien visualiser. Et tu vas être content, tu es vraiment pas loin !! C'est quasiment tout bon ! addEvent( "PlaySound", true ) -- Ok addEventHandler( "PlaySound", getRootElement(), sounds ) -- Ok Nickel, c'est ce qu'il fallait faire, créer un event qu'on peut trigger du côté serveur (true) et attaché la fonction sounds à cet event. Juste je changerai le nom de l'event pour éviter un conflit avec une autre ressource. Exemple: onLaserSaberSwing (Il faut se lever de bonne heure pour trouver une autre ressource qui utilise ce nom sur ton serveur haha) function jedi ( player ) -- bindKey envoi le joueur qui a appuyé en 1er paramètre, il faut le "receptionner" -- Ici tu avais oublié de ramener la fonction qui récupère l'arme actuelle du joueur: local weaponID = getPedWeapon ( player ) -- On récupère l'arme du joueur qui a "fire" if ( weaponID == 15 and isControlEnabled ( "fire" ) ) then -- Ok pour la cane triggerClientEvent ( "PlaySound", player ) -- Ici on met le joueur en source de l'event à la place car root = tout le monde (on le récupérera côté client pour jouer le son à la bonne position) end end bindKey ( "fire", "down", jedi ) -- Ok local JediSound = { "a.mp3", "b.mp3", "c.mp3" } function sounds ( ) local muzzleX, muzzleY, muzzleZ = getPedWeaponMuzzlePosition ( source ) -- remplacer par source car on veut pas le joueur local mais bien celui qui a tiré -- local px, py, pz = getElementPosition ( localPlayer ) -- Heuuu px, py, pz ne sont pas utilisé, un oubli de l'auteur. A supprimer ! -- local weaponID = getPedWeapon ( source ) -- plus besoin de weaponID ici, on n'en a besoin que du côté serveur maintenant. A supprimer ! local sound = playSound3D ( JediSound[ math.random( 1,#JediSound ) ], muzzleX, muzzleY, muzzleZ, false ) setSoundMaxDistance ( sound, 40 ) end addEvent( "PlaySound", true ) addEventHandler( "PlaySound", getRootElement(), sounds ) Et là on devrait retrouver le même fonctionnement d'origine mais qui marche également si d'autres joueurs donnent des coups avec le sabre laser. Mais le problème des sabres lasers des zombies qui ne font pas de bruits est toujours là (ouai j'ai oublié d'en parler dans mon post précédent, mais de toute façon il fallait faire ça avant). Une fois les corrections fonctionnelles, je ne vois pas d'autre solution que de faire le même triggerClientEvent mais dans la fonction attack de la ressource zombie en mettant le zombie en source de l'event (et c'est tout, ça marchera direct normalement). Pour la 2ème question: Ultra proche du bon résultat ! Juste il te manquait la "réception" des argument que t'envoie l'event onClientPedDamage et il ne faut pas faire de addEvent pour les events fournit par MTA. function killp ( attacker, weapon, bodypart ) -- on doit réceptionner ce que nous envoie l'event pour les utiliser dans la fonction (exception pour 'source') if weapon == 5 then -- Du coup comme je l'ai nommé weapon pour le killPed, je change le nom de la variable à tester if (getElementData (source, "zombie") == true) then -- C'est juste mais comme c'est un boolean et qu'il n'y a qu'un test, on peut raccourcir à: if getElementData(source, "zombie") then killPed(source, attacker, weapon, bodypart) end end end -- addEvent( "onClientPedDamage", true ) -- Event MTA. A supprimer ! addEventHandler ( "onClientPedDamage", getRootElement(), killp ) -- manquait le 2ème argument (= qui peut en être la source) Cordialement, Citizen

Wumbaloo qui répond plus vite que son ombre ... Un petit check rapide du code montre bien que c'est un playSound3D qui est utilisé et en plus tu n'as pas dû comprendre la question de LawrenceKnight, il a pas parlé d'un problème de position du son hein ! Alors ce script a visiblement été réalisé par un novice qui n'a pas pensé que son script ne marcherai pas avec d'autres joueurs sur son serveur. Voilà la traduction strict du code (la partie son seulement): * En tant que joueur, si je(1) tire avec une arme et que l'id de cette arme est égal à 8 (Katana), alors je joue pour moi(1) et en 3D un des 3 sons dispo à l'emplacement du bout de l'arme. (1) Parce que c'est un script côté client = le joueur local S'il avait eu une autre personne pour tester, il aurait remarqué que lorsqu'un 2ème joueur "tire" avec le katana, aucun son ait joué pour le 1er joueur. Ma première idée pour le corriger rapidement était d'appeler la fonction jedi avec l'event onClientPedWeaponFire et d'utiliser source au lieu de localPlayer: Mais en fait on peut pas parce que: oh Bon bah du coup plan B, il faut séparer la partie (A)détection d'un tire au katana de la partie (B)jouer un des 3 sons à l'embout de l'arme du joueur responsable avec (A) => côté serveur (B) => côté client Je te propose donc cet exercice car ça doit être dans tes cordes. Il te faudra la fonction triggerClientEvent pour que depuis le serveur tu puisses déclencher la fonction du son côté client (indice: ne renseigne pas l'option sendTo au début pour que ça le déclenche chez tous le monde. Pour ta 2ème question: Il suffit d'utiliser l'event onClientPedDamage, tester si l'argument weapon vaut 5 (Batte), et si c'est le cas, tu killPed(source, attacker, weapon, bodypart) et ça devrait faire le taff. En revanche un Player est considéré comme un Ped spécifique car contrôlé par un joueur donc ça va 1 shot les joueurs aussi (sauf s'ils sont dans la même team et que le friendly fire est désactivé). Donc en plus du check du weapon qui vaut 5, il faut rajouter un check pour vérifier si la source est un zombie, pour ça il faudra regarder dans la fonction qui spawn un zombie s'il y a un element data spécifique qu'on pourrait utiliser afin d'identifier de façon sûr que ça soit un zombie (genre si y a un setElementData(bidule, "isZombie", true) c'est bingo pour nous, il suffira de faire un if getElementData(source, "isZombie") then et la correction est torchée/terminée ^^) Bon courage en attendant ton retour Cordialement, Citizen

A noter que le gamemode OWL est un gamemode volé.

Oui sauf: Les métatables Les coroutines Les tables d'environnement

Nan upgrade modifie les fichiers, après c'est bon. Il faut la ressource "scoreboard" de lancée, tu dois avoir une autre ressource pour la scoreboard mais il faut celle là en particulier !

Super ! 1. Bah il dit que la ressource scoreboard n'est pas démarrée. Démarre là ? => start scoreboard dans la console serveur. Pour éviter de devoir le lancer à la main à chaque fois, ajoute le à la fin de ton mtaserver.conf 2. L'utf-8 est juste un warning, mais pour le régler, ouvre le fichier dans Notepad++ et dans le menu du haut: Encodage => Convertir en UTF-8 et tu sauvegardes. Pour les fonctions en "deprecated" tape la commande upgrade dans la console serveur (il va mettre un peu de temps car il va te le faire pour toutes les ressources). Sûrement une méthode "deprecated" qui a été supprimée. La commande upgrade devrait la corriger. Les erreurs suivantes sont potentiellement provoquées par les problèmes précédents. Donc ils devraient disparaître d'elles-même normalement. Reposte les si ce n'est pas le cas. J'attends ton retour.

Essaye dans la console serveur: delaccount vehicleManager addaccount vehicleManager ds4f9$ Et redémarre le tout.

Il fallait pas remplacer dans ce fichier là. Pour le problème du getAccountData, la procédure d'installation aurait du créer un compte vehiclemanager. Ton problème est qu'il n'existe pas.

Ce sont des avertissements plutôt et non des erreurs. Les avertissements n'interrompt pas l'exécution des instructions contrairement à une erreur. Ici les 3 avertissements ne sont pas graves et le script marche très bien. Du moins pour l'instant parce qu'une fonction "deprecated" a pour but d'être supprimée dans une version future de mta (potentiellement dans la 1.6) en faveur d'une autre fonction. Et dans ce cas là, le script ne marchera plus. Ici les messages sont clair et te disent de remplacer une fonction deprecated par une autre et te disent même à quel endroit le faire: - Dans survivorSystem_client.lua remplace tous les showPlayerHudComponent par setPlayerHudComponentVisible. - Dans survivorSystem_client.lua remplace tous les setControlState par setPedControlState. - Dans survivorSystem_client.lua remplace tous les getControlState par getPedControlState Tu peux utiliser le remplacement de masse de ton editeur.

C'était effectivement le paramètre texte qui n'est plus bon car c'est une variable qui était censé être rempli par la fonctionnalité d'auto-save des identifiants username - password mais que tu as cassé car tu as remplacé des textes qui n'étaient pas destinés à de l'affichage. Restaure tous les xmlNodeGetAttribute et xmlNodeSetAttribute concernant le "Pseudo": Si xmlNodeGetAttribute(toto, "Pseudo") remettre xmlNodeGetAttribute(toto, "username") Si xmlNodeSetAttribute(toto, "username", tata) remettre xmlNodeSetAttribute(toto, "username", tata) !! N'utilise plus la fonction de remplacement de masse de ton éditeur !!

Règle #1 pour traduire: Ne remplacer que les textes (Phrases entre guillemets) destinés à l'affichage et ne jamais toucher aux variables, fonctions ou events. Changer les variables ne sert à rien pour l'utilisateur et ne peut que créer des erreurs dans tes scripts. Pour aussi afficher les erreurs côté client, utilise la commande /debugscript 3 (il faut être logué avec un compte admin). Montre nous le code qui crée le panel. Le paramètre parent du guiCreateEdit ne doit plus être bon (ou le paramètre texte)

Bonjour, Pour compléter la réponse, dans ce dossier "[editor]" il doit y avoir un editor.zip qui correspond au Map Editor que tu peux démarrer via la commande start editor (a taper dans la console). Cordialement, Citizen

@xeniria As-tu pu régler ton problème ?

Je suis sûr que le problème (duplication des véhicules à chaque restart du mode) est résolu si tu n'as plus l'erreur du vehicles_init.lua:49: Access denied @ 'addAccount' Le problème maintenant que tu constates, c'est que les véhicules qui ont été dupliqués 40 fois sont toujours présents dans la BDD vehicles.db et sont toujours chargés au démarrage. Pour repartir sur une base propre (serveur éteint), supprimes vehicles.db et tu édites internal.db du dossier deathmatch (avec SQLiteBrowser par exemple) pour supprimer dans la table userdata la ligne qui a pour key 'serverhasloadvehicles' et qui a pour value 'true' et qui doit ressembler à ça: Tu supprimes la ligne, tu sauvegardes (Write Changes sur mon screenshot) et tu peux relancer ton serveur DayZ. Il recréera la BDD vehicles.db, puis fera spawn les véhicules initiaux puis remettra serverhasloadvehicles à true. Ce qui empêchera d'en refaire spawn à chaque prochain restart. (Désolé, je n'étais pas alerté par de nouvelles réponses, ça doit être bon maintenant)

J'ai inspecté le code pour comprendre le fonctionnement de la création, sauvegarde et chargement des véhicules. Et une théorie que j'en ai tiré pour expliquer ton problème est que la ressource DayZ n'a pas les droits nécessaires pour créer un compte vehicleManager pour ensuite y stocker l'information comme quoi il a déjà créé les véhicules. As-tu bien suivi les instructions d'installation ? Surtout cette partie: Cette opération doit se faire serveur éteint. Pour valider ma théorie, dans les logs du serveur, une erreur du style doit apparaître: Acces Denied @ addaccount pour le script vehicles_init.lua Sinon c'est qu'il doit y avoir une autre possibilité que je n'ai pas identifiée en listant le code. Une copie de ton server.log serait dans ce cas la bienvenue pour nous aider à identifier le problème.

You forgot to put the username and password for the connection: $mtaServer = new mta( $hostname, $port, $username, $password );

Is COL_ID a global string ? Are x and y valid everytime ? (during your creation loop) Copy that var_dump function and use it after the creation process to check the content of your table: var_dump("-v", pickupCollision)

Please provide any error coming from debugscript 3 and debugdb 2. Also make sure your script is loaded as a server script (check your meta.xml). I'm asking that because you are using executeSQLQuery (serverside only) alongside with onClientGUIClick (clientside only).

Je réponds pour éviter de donner l'impression que je n'ai pas vu ta question, mais malheureusement il y a encore des choses que je n'ai jamais essayé de faire sur MTA et l'utilisation/manipulation de shaders en fait parti. Désolé de t'avoir donné un faux espoir en recevant la notification de ma réponse Citizen.

Tu hardcodes la valeur depth à 999 puis tu utilises processLineOfSight entre la caméra x, y, z et le x, y, z de ce que t'a retourné getWorldFromScreenPosition. Les valeurs hitX, hitY, hitZ retourné par processLineOfSight représenteront le point d'impact avec le sol, objet ou autre (tu peux régler ce que tu dois prendre en compte pour le point d'impact. Par défaut: tout).

J'ai pas compris ton soucis. Qu'est-ce que depth, et a quoi doit il te servir dans ton script ?

Hmmm okay, bah si tu as des liens pour lui ça serai sympa si tu pouvais les mettre. (perso c'est sur le Wiki anglais que j'ai appris mais surtout avec la pratique) Je les regarderai et les garderai sous le coude pour une prochaine demande du même type. Cordialement, Citizen

Nan il te faut: https://wiki.multitheftauto.com/wiki/GetPlayerTeam Et https://wiki.multitheftauto.com/wiki/GetTeamFromName Si les 2 valeurs retournées sont égales, c'est qu'il est bien dans cette team. Cordialement, Citizen

No problemo

Effectivement, le setWeaponProperty ne change absolument rien quand j'ai testé. Du coup je te propose de contourner le problème en utilisant onPlayerDamage comme ceci: addEventHandler("onPlayerDamage", root, function ( attacker, weapon, bodypart, loss ) if weapon == 16 then -- Si touché par une grenade killPed(source, attacker, weapon, bodypart) -- mort immédiate end end) Il faut en revanche noter 2 choses: Si le joueur était suffisamment loin de l'explosion pour que normalement il ne devait perdre que 1HP, il sera tué instantanément. Si le joueur est en dehors de la portée maximum de l'explosion de la grenade (40.0 units par défaut) il ne perdra aucun HP. (Imagine il est juste à la limite, il perd pas d'HP, il fait 1 seul pas en avant pour rentrer dans la zone de portée, il meurt instantanément). A voir si c'est ce que tu voulais faire. Perso, la fonction n'a rien changé chez moi, je meurs si je suis trop près de l'explosion. Cordialement, Citizen