Bonjour me voila encore avec une question qui me taraude l'esprit. Est ce que l'on peut accéder aux script des commandes DM ?
J'ai trouvé les référence aux noms des commandes dans le dialog.tlk (6582, 6573 etc etc) et j'ai fait un peu le bourrin en cherchant ces numéro de nom dans tous les 2da du jeu => résultat rien trouver ...

Peut-on y accéder ou bien est ce coder en dur ?

Le pourquoi de ma demande. Pour un module j'ai besoin d'un système anti-deco paf je suis plus mort. Je pensais utiliser en premier lieu un système d'objet. Apparemment ça se fait sur plein de module. Mais que se passe t'il quand l'inventaire est plein, l'objet est créé ou pas ?
Je sais qu'il faut modifier les sort de rez et rappel a la vie pour détruire cet objet, pas de soucis de ce coté la, mais...
Il m'arrive parfois d'user du Repos md pour ramener des joueurs a la vie alors qu'il n'aurait pas du mourir et que je suis a distance (a préparer un terrain d'animation), en fait un genre de rez a distance. Le soin s'effectue, mais l'objet en théorie reste sur le pj, non ? Il suffit qu'il déco reco et paf mort.
Donc est il possible d'accéder au script dm ? de les modifier ?

Ou bien dans le onExit il est préférable de faire un test sur le nombre de point de vie et regarder si la présence de l'objet ? Genre si 0 pv et objet => mort et si 15 pv et objet => pas mort alors destruction objet.

Comme le mode mort MD l'objet ne devrait pas se créer, meme test sur le onexit sur la présence de l'objet et le nombre de pv ?

(espère avoir été assez clair )

edit : ce ne sont que des questions conceptuelles, je ne demande pas que l'on me scripte la chose, ca je pense savoir pouvoir le faire.
_________________
Premier DM a avoir inauguré la chute d'auberge sur Joueur rebel

Preuve => http:

premièrement, si tu dois machiner un plan contre le fait que les pjs se tiennent un inventaire plein a 100% pour éviter d'avoir l'objet de mort, je te plains car je vois mal leur esprits RP dans tout ca....

ensuite, tous les serveurs ou presque ont connus ce problème, oui en effet l'option *soigner* n'enlève pas cet item. Parcontre, pour éviter que le pj deco et reco mort meme s'il ne le devrait pas, nous nous assurions tout simplement que la dernière fois qu'il avait été rez était par le sort rez. Donc il arrive parfois que je butte le pj et le rez aussitot juste pour enlever l'item OU, enlever l'item *mort* de son inventaire via intervention md tout simplement.^^



Citation :c'est une idée intéressante, tu as essayé sans objets?
_________________
L'imagination est plus importante que le savoir. (Albert Einstein)

Pour le moment je n'ai rien essayé, je fais une étude de concept. Je préfère coder et créer les objets en une seule fois et pas rajouter des bout de code par ci par la lors de la phase debuggage. Parfois ça a des effets de bords, non attendue. Je prefere en fait envisager toutes les possibilités.
Concernant le fait de l'inventaire plein, je vais partir du postulat qu'un joueur qui veut gagner de l'xp veut aussi gagner des po donc il a de la place dans son inventaire pour stocker des objets qu'il ramassera.

Et puis s'il ne peut pas créer l'item, inscription log signalement DM et règlement de compte par la suite mais bon a vrai dire vu le nombre de joueur cerné, je pense que le cas de l'inventaire 100% ou le cas deco/reco pour tricher ne se produira pas. Apres tout je fais confiance au joueur, quite a rétablir le tir par la suite.

Les seuls test que j'ai fait c'est qu'a la reco un pj regagne intégralement ses pv plus tard je pense que je tenterais de mettre en place un système a base de nwnx/ff pour sauver les pv du joueur a et les restituer entre une entrée et une sortie du serveur, ou bien au même moment que la sauvegarde la position du joueur. Enfin ca se sont des projets dans le futur
_________________
Premier DM a avoir inauguré la chute d'auberge sur Joueur rebel

Preuve => http:

J'me demande si les items, quand on leur ajoute des VARIABLEs local ça s'enleve ... ça métonne je crois, ce que tu peux faire :

Tu crées une peau, que tu mettras sur le joueur (à tous les joueurs qui entrent). Cette peau peut te servire à de multiple chose pour leur affecter des propriétées, des locals, etc... (ça peut etre le base de donnée a eu si tu preferes).

A chaque fois que le joueur meurt > Variable "Mort" sur la peau à 1
Si cette variable est a 1 quand il rentre, on le tue.
Il faut enlever la variable à chaque fois qu'il se passe quelque chose qui peut le ressucité.

Ensuite pour le soin a distance, moi j'ai fait mon système MD pour moi (que je risque de mettre sur le vault). J'utilise enfaite un dialogue, qui repertorie 5 joueurs par page du module, et on peut leur faire plein d'action via ce dialogue, à distance.

Il suffirait donc que dès que tu utilises le script de soin, tu detruises en même temps l'objet ou la variable du joueur.

Voila, si j'ai le temps et que tu veux un exemple de mon script, je le mettrais =)
_________________
[http]

Par contre si je me trompe pas les peaux, étant des items dans un des slots Creature, donc elles ne se sauvegardent pas avec l'inventaire du joueur, et donc les variables locales ne sont donc pas enregistrées non plus (sauf si il y a eu MaJ de ce coté).

Le plus simple est d'utiliser un item que tous tes joueurs ont dès le début de module (et impossible de le poser, ni de le vendre), genre livre des quêtes ou autres, et la dessus tu applique la même idée que Black Knight pour les variables.
_________________
Scripts, systèmes, fonctions,... c'est par ici...
Pyjama pour castor, une vocation, un avenir sûr

Bon je peux pas détruire l'objet a la déconnection, ce qui est parfaitement logique, car l'objet référencé par GetExitingObject() n'existe plus. Donc on ne peut travailler que sur une référence. Aucune possibilité de bosser sur un inventaire ou autre; bah oui le joueur n'est plus la . Ou bien j'ai rien compris

Ma parade, j'ai rendu l'objet destructible par le joueur. Comme ça si soin MD le joueur n'a qu'a activé la carte de son vivant et il n'en n'a plus. Enfin c'est précisé dans la description de l'objet.
_________________
Premier DM a avoir inauguré la chute d'auberge sur Joueur rebel

Preuve => http:

Flumby> Il y a une autre solution , mémoriser " en dur " grace au ohb module le nombre de points de vie de chaque joueur toutes les 6 secondes.

Et quand il revient sur le module , tu fixe le nombre de ses points de vie selon ce qui à été mémorisé précédement.

C'est redoutablement efficace !

Du coup , les deco/reco deviennent inutiles , et celui qui tente de tricher le fait une fois , puis il cesse de lui même.
_________________
" La ruse doit être employée pour faire croire que l'on est où l'on est pas, que l'on veut ce qu'on ne veut pas. " CdG
" La véritable école du Commandement est la culture générale. " CdG
" Une société prête à sacrifier un peu de liberté contre un peu de sécurité ne mérite ni l'une ni l'autre et finit par perdre les deux. " B.F
" La gloire se donne seulement à ceux qui l'ont toujours rêvée. " CdG
" La fin de l'espoir est le commencement de la mort. " CdG

Je veux bien tenter sur les 6 secondes, mais le seul soucis qui m'ennuie c'est la génération du traffic, nombre de joueur par six secondes, j'ai peur que le serveur ait du mal a suivre. Et surtout actuellement je n'ai pas dB derrière je ne veux pas tenter.

Pour la sauvegardes des points de vie, je verrais en même temps que la sauvegarde de positions du joueur. Pour le moment je préfère laisser le serveur se roder un peu avant de lancer une modification aussi lourde qu'une base de donnée SQL
_________________
Premier DM a avoir inauguré la chute d'auberge sur Joueur rebel

Preuve => http:

Flumby> Je peux te confirmer que ça fonctionne parfaitement et le serveur suit sans soucis pour peu que tu crée tes scripts de maniére inteligente pour bouffer un minimum de ressources.

Quand a la position des joueurs , elle est mémorisée par le serveur et tu n'a rien a faire.
Et si jamais ton soucis c'est de garder la position des joueurs aprés un reboot , il te suffit de faire réguliérement des " auto-save " de ton module en ligne pour relancer la derniére " auto-save " aprés un reboot , et les positions de tous les joueurs seront mémorisées.

Il n'y a qu'aprés une modification de module que ça ne fonctionne pas !

Sinon tu peux faire des tests sur un module " test " et tu n'a pas besoin d'aller toucher a ton module de travail !

Par contre je ne comprends pas pourquoi tu parles d'une base de donnée SQL, il existe déja des variables " en dur " utilisable sur NWN1 et NWN2.
Et même si une variable en dur prends dans l'absolu plus de temps a mémoriser ou a lire qu'une variable locale , les ralentissements sont invisibles a l'oeil nu ( va t'en faire la différence pendant le jeu entre 0,1 et 1 miliseconde de lag ) .
_________________
" La ruse doit être employée pour faire croire que l'on est où l'on est pas, que l'on veut ce qu'on ne veut pas. " CdG
" La véritable école du Commandement est la culture générale. " CdG
" Une société prête à sacrifier un peu de liberté contre un peu de sécurité ne mérite ni l'une ni l'autre et finit par perdre les deux. " B.F
" La gloire se donne seulement à ceux qui l'ont toujours rêvée. " CdG
" La fin de l'espoir est le commencement de la mort. " CdG