Script ?

[Lonos]

Bonjour,
Avant tout je ne sais pas si j'ai le droit de faire une demande d'un script particulier contre de l'argent ! Je le fait dans l’espoir que mon post de soit pas supprimé !

Je cherche une personne qui sais dev lua !
Pour faire un script qui permettrais que lorsque l'on veut un job, on clique normal sur choisir avec le F4 mais sa donne une tenue ! Et par exemple (pour mon serveur ) Que la tenue ne spawn que pour certain job sinon c'est normal sa le met directement
Avec un système de hiérarchie par exemple certain job ne pourront être pris que si un supérieur lui donne ... Et qu'il est le métier de base dans l'armée donc la c'est recrue afin de passer Soldat SS ..
Je compte rémunéré si le script ne dépasse pas une certain somme mais on verra avec la personne en question !
Donc si quelqu'un est tenté !!
Cordialement
Maxence

[Lonos]

Ok Merci a toi encore !
Voici le code :

AddCSLuaFile()

ENT.Type = "anim"

ENT.Spawnable = true
ENT.AdminSpawnable = true

ENT.Model = "models/german/headgear/grenadier_helm.mdl"	

function ENT:Initialize() -- Regardez les arguments de ENT:Initialize(), à savoir qu'il n'y en a pas ici
	self:SetModel("models/german/headgear/grenadier_helm.mdl")
	
	self:PhysicsInit(SOLID_VPHYSICS) -- On gère la physique de l'entité (qui est ici solide)
	self:SetMoveType(MOVETYPE_VPHYSICS) -- Gère la façon dont il tombe
	self:SetSolid(SOLID_VPHYSICS) -- Gère la physique
	self:SetUseType(SIMPLE_USE) -- Le type d'utilisation de l'entité : Ici c'est un simple bouton d'utilisation préssée.
end

function ENT:Use( activator, caller ) -- Il est vrai que dans le cas présent, les deux derniers arguments sont optionnels mais vu que ce n'est pas tout le temps le cas, pour bien le montrer je les mets)
caller:changeTeam(TEAM_SSOBERSHUTZE, true) -- On force le joueur (deuxième argument important à préciser malgré le fait qu'il soit optionnel) à aller dans la TEAM rentré)
self:Remove() -- Ici, on demande au "self" (lui-même, l'entité donc) de se supprimer lui-même après une utilisation. [A VERIFIER] : Il est possible que certains gamemodes gèrent déjà cette suppression après une utilisation mais nous pouvons directement le faire "normalement".
end 

[Diablos]

Tu utilises bien la fonction comme demandée. Essaie donc de supprimer la ligne du "SetUseType", redémarre le serveur et fait moi savoir si une autre erreur intervient.
Pour les deux soucis que tu avais, voici les solutions :
Pour le premier problème, il va falloir modifier un fichier principal du DarkRP. Il faut se rendre dans

gamemodes/darkrp/gamemode/modules/sv_jobs.lua

A l'intérieur, tu verras normalement à la ligne 139 la ligne

if GAMEMODE.Config.norespawn and self:Alive() then

Cette ligne vérifie si norespawn est à true ou à false. Normalement, la tienne est à false donc c'est le else en dessous qui est pris en compte. Sauf que nous, nous voulons passer dans le if. On écrit donc simplement (j'écris MAYOR par simple exemple, bien évidemment tu changes par ce que tu veux) :

 if GAMEMODE.Config.norespawn and self:Alive() or self:Team() == TEAM_MAYOR then 

Le hook OnPlayerChangedTeam[wiki.darkrp.com] prend plusieurs paramètres. Ici, c'est assez particulier puisque nous demandons un "self:Team()" (self = ply sur la page du hook mais le code du DarkRP indique qu'il faut mettre self), ce qui pourrais faire croire à un Si GAMEMODE.Config.norespawn renvoie la valeur true ET le joueur est vivant OU le job du joueur est TEAM_MAYOR, mais en réalité c'est surtout ...... OU le joueur essaie d'aller dans la TEAM_MAYOR.
Et oui, car le hook c'est "OnPlayerChangedTeam", donc c'est au moment du changement dans la TEAM. Assez parlé, je pense que tu as compris.
Si tu veux mettre plusieurs jobs, il faudrait donc que tu mettes

 if GAMEMODE.Config.norespawn and self:Alive() or self:Team() == TEAM_MAYOR or self:Team() == TEAM_COPS or self:Team() == TEAM_BODYGUARD then 

Bref, quand tu auras 10 jobs à mettre, peut-être que ça t'énervera de toujours aller voir ce fichier. Je vais donc te trouver une méthode un peu plus facilitée pour éviter de modifier le fichier.
Tu peux mettre donc

 if GAMEMODE.Config.norespawn and self:Alive() or table.HasValue(TeamWhoNeedsToNoRespawn, team.GetName(self:Team())) then 

Nous allons expliquer la table.HasValue()[wiki.garrysmod.com]. On voit ici que la classe s'utilise côté client et serveur ,et qu'elle prend deux arguments : la première est le nom de la table dans laquelle la classe va aller chercher, et la seconde est la valeur à trouver. En mettant la ligne ci-dessus, alors si le nom de la team (team.GetName()) du joueur (self:Team()) est présent dans la table TeamWhoNeedsToNoRespawn (tu peux changer le nom si tu veux), alors nous n'aurons pas besoin de réapparaître. Reste donc à créer cette table.
Tu peux la créer dans lua->autorun dans un fichier, ou alors tout au début / fin du jobs.lua (car le fichier est exécuté au démarrage du serveur). Si tu ne le sais pas, une table se constitue comme ceci :

 TeamWhoNeedsToNoRespawn = { "Policier", "Commissaire", "Garde du corps" } 

Les accolades délimitent la table et tu rentres chaque valeur entre guillemets avec une virgule entre chaque valeur (pas de virgule à la fin). Tu pourras directement mettre tes noms de jobs (et non TEAM_MAYOR par exemple, sinon il faut faire un table.HasValue( TeamWhoNeedsToNoRespawn, self:Team()) simplement).
Bref, je pense que tu as compris. Dire que j'ai fait qu'une méthode pour tout ce pavé, je suis désolé mais je préfère expliquer pour que tu comprennes ce que tu fais.

Pour la deuxième méthode : c'est très simple à comprendre. Il faut simplement que tu mettes pour les métiers en conséquences, un customCheck inaccessible aux joueurs, comme par exemple

customCheck = function(ply) return ply:IsSuperAdmin() end,
customCheckFailMsg = "Vous devez etre accepte par un membre hierarchiquement superieur"

De ce fait, une personne non administrateur ne pourra pas accéder au job, et le texte du customCheckFailMsg sera retourné.
Si tu te poses la question de pourquoi dans l'entité ça marcherait alors qu'il y'a un customCheck, c'est car il faut que tu te souviennes de changeTeam[wiki.darkrp.com] qui a le deuxième paramètre optionnel que tu as bien mis en "true", qui est de "FORCER" le joueur à aller dans la TEAM. Même avec un customCheck, le joueur pourra donc accéder au job (c'est de toute façon expliqué dans la page de la fonction) !

Voilà, c'est terminé pour tout ce que tu m'as demandé ; j'attends d'autres questions si nécessaires.

[Lonos]

Comme dab des explications Si bonne !
Et une réponse Trop top qui m'a permis de faire fonctionné TOUS Sa !!

Ps : Toujours cette ptit erreur même après avoir suprime ce que tu m'as dit :

 
[ERROR] addons/tenue/lua/entities/offizer/shared.lua:16: attempt to call method 'SetUseType' (a nil value)
  1. unknown - addons/tenue/lua/entities/offizer/shared.lua:16 

MERCI mille fois

[Diablos]

Remplace

 self:SetUseType(SIMPLE_USE) 

par

 if SERVER then self:SetUseType(SIMPLE_USE) end 

L'explication de cette modification est simple : Entity:SetUseType()[wiki.garrysmod.com] accepte uniquement le côté serveur, il faut donc indiquer que la fonction doit être déclarée en côté serveur.

PS : Les côtés clients et serveurs n'étant pas gérés en solo, il faut se rendre en serveur dédié pour que ça fonctionne.

[Lonos]

Nickel Plus d'erreur !
Encore un ptit truc ! Je voudrais que le joueurs puissent prendre la tenue que s'il est un certain metier !
J'ai regardé sur le wiki dakrp pour trouvé genre un truc comme toi : OnPlayerChangedTeam
mais genre si le jouuers est un job ...
Mais je trouve pas c'est peut etre un autre nom

[Diablos]

Tout simplement, dans la fonction ENT:Use(), tu autorises à pouvoir prendre l'objet que si le joueur est dans une certaine team.
Quelque chose comme ça :

 function ENT:Use (activator, caller, useType, value)
if caller:Team() == TEAM_MAYOR then -- Autorise à utiliser l'entité si le joueur est dans la TEAM_MAYOR.
caller:changeTeam(TEAM_COPS, true)
end
end

Tu pourrais même rajouter en "else" un notify (voir la fonction sur le wiki du DarkRP) pour avertir le joueur qu'il ne peut pas utiliser l'entité.

De plus, dit toi aussi que ce sont des fonctions de base : Il faudrait donc plutôt aller dans le Wiki du Garry's Mod ; vérifier la team du joueur n'est pas spécifique au DarkRP.

Bonne chance!

[Lonos]

Ok merci !
Pour les notify par exemple :

function ENT:Use (activator, caller, useType, value)
if caller:Team() == TEAM_MAYOR then -- Autorise à utiliser l'entité si le joueur est dans la TEAM_MAYOR.
caller:changeTeam(TEAM_COPS, true)
self:Remove() else
if caller:Team() ~= TEAM_MAYOR then
DarkRP.notify(ply, 1, 6, "Tu n'as pas le bon grade")
return end
end
end

Espérant que c'est un bon début ...

[Diablos]

C'est un bon début oui. A vrai dire c'est presque bon! Il faut juste que tu ne fasses pas un elseif (d'ailleurs le retour à la ligne doit faire planter le code), mais un "else" :
En effet, ici nous voulons que si le joueur est dans telle équipe, il puisse utiliser l'entité. SINON (donc peu importe la team), ça va notifier le joueur.
Il faut donc transformer

if caller:Team() == TEAM_MAYOR then -- Autorise à utiliser l'entité si le joueur est dans la TEAM_MAYOR.
caller:changeTeam(TEAM_COPS, true)
self:Remove() else
if caller:Team() ~= TEAM_MAYOR then
DarkRP.notify(ply, 1, 6, "Tu n'as pas le bon grade")
return end
end
end

par

if caller:Team() == TEAM_MAYOR then
caller:changeTeam(TEAM_COPS, true)
self:Remove() 
else
DarkRP.notify(caller, 1, 6, "Tu n'as pas le bon grade")
end
end

Etant donné que nous n'avons rien besoin de retourner en règle général, on peut enlever le "return end" : dans le if, on ne retourne rien en valeur (pas de "return args" ou quelque chose du genre que nous avons vu dans un autre sujet) donc pas besoin de le préciser ici. De plus, mettre return end voudrait dire que nous retournons rien et que nous passons donc la suite de la fonction ; ici, dans tous les cas, il n'y a pas de suite.
A part cette remarque et l'enlèvement du elseif (expliqué au dessus), j'ai aussi modifié le ply du DarkRP.notify en caller, car ply n'est pas déclaré.

Voilà, maintenant, ça devrait marcher!
Bonne journée/soirée .

[Lonos]

Super Merci sa fonctionne !
Encore des questions si sa te dérange pas !
Je pense c'est trop compliqué !
Je voudrais que si une personne arrive a un certain grade (via les entities que l'on avait crée ) A chaque fois en gros on arrive a un grade mieux en mieux on a accès au grade directement via le F4 ! Comme sa plus besoin de refaire tout les testes !
Et aussi mettre plusieurs personne qui peuvent se mettre ce metier tu sais de cette ligne :

    customCheck = function(ply) return ply:IsSuperAdmin() end,
    customCheckFailMsg = "Vous devez etre accepte par un membre hierarchiquement superieur",

Merci !

[Diablos]

J'avoue que ça devient plus compliqué. C'est toujours possible de créer un type de tableau du joueur ply semblable à

 ply.CanHaveThisJob 

puis de mettre un

 customCheck = function(ply) return ply.CanHaveThisJob end,

mais après y'a certaines questions qui se posent : Faut que le joueur puisse aller dans les jobs de hiérarchie inférieure ? Qu'il puisse y aller uniquement durant sa session ou définitivement à partir du moment où il a utilisé l'entité (si c'est le cas, je pense qu'il va falloir utiliser dans ce cas des tables SQL) ?
Tu commences à approcher de quelque chose d'un peu plus sérieux et compliqué. En voilà du défi, je ne sais pas si je pourrais te le faire par manque de temps et peut-être aussi (même si je n'ai rien tenté) d'expérience, mais ça a l'air intéressant. Il faudrait juste que tu décrives un peu plus ce que tu veux faire exactement.

[Lonos]

En faite si t'arrive a un un grade ! Tu l'as accès définitivement puis si tu arrive encore a un autre au dessus tu y as accès et aussi a l'ancien

[Diablos]

Oui mais

ÐĪÂßĿØ$ původně napsal:

Qu'il puisse y aller uniquement durant sa session ou définitivement à partir du moment où il a utilisé l'entité (si c'est le cas, je pense qu'il va falloir utiliser dans ce cas des tables SQL) ?

[Lonos]

ÐĪÂßĿØ$ původně napsal:

définitivement à partir du moment où il a utilisé l'entité (si c'est le cas, je pense qu'il va falloir utiliser dans ce cas des tables SQL) ?

[/quote]
Et donc sql sa veut dire une base de donnée ?

[Diablos]

Oui ça veut dire qu'il faut sauvegarder dans une table des valeurs par "personne" qui diront si le joueur a déjà réalisé tous les tests ou non... Assez complexe en somme.

[Lonos]

Ah Trop dommage mais j'ai peut etre plus simple fin je pense !
Si on faisait genre des tu rejoins un grade sa te change ton group ulx
Et faudrait en faire plein mais sa peut fonctionner !