[Tuto] Lua scripting et Toribash

Voila le .exe que j'ai compiler avec la précieuse aide de powerfish(merci encore)=
http://forum.toribash.com/attachment.php?attachmentid=298128&d=1314735795
Bientôt je ferai en .lua avec plusieurs niveaux de difficulté

Ca a pas vraiment sa place ici, c'est pas un tuto "programmation", c'est un tuto "lua pour Toribash". On revient au sujet SVP. Si tu le fais en lua, je veux bien que tu le postes, je commenterai. ~Melmoth

Oui je ferai dès que j'ai du temps j'ai poster ça aussi parce que je suis fière d'avoir créé mon premier jeu quand même et c'est en rapport avec la page d'avant donc voila.

*=-Nokturnal44-=* a écrit:

J'ai essayer en .lua mais je me suis enbrouillé alors j'ai demander a un pote de me faire un petit cour(gratos) et
voila j'ai tapé le code en C mais comment le passer en .exe? il m'a pas expliquer il est parti en vacance...

Code:

/*

Plus ou Moins
-------------
Par matieu/Nokturnal44

*/


#include <stdio.h>
#include <stdlib.h>
#include <time.h>


int main ( int argc, char** argv )
{
    int nombreMystere = 0, nombreEntre = 0;
    const int MAX = 100, MIN = 1;

    // Programme choisi un nombre au hasard

    srand(time(NULL));
    nombreMystere = (rand() % (MAX - MIN + 1)) + MIN;

   

    do
    {
        // le joueur essaye un nombre
        printf("Quel est le nombre ? ");
        scanf("%d", &nombreEntre);

        // Le programme compare les 2 chiffres

        if (nombreMystere > nombreEntre)
            printf("C'est plus !\n\n");
        else if (nombreMystere < nombreEntre)
            printf("C'est moins !\n\n");
        else
            printf ("Bravo, vous avez trouve le nombre mystere !!!\n\n");
    } while (nombreEntre != nombreMystere);
    return 0;
}

Aussi il n'y a pas d'erreur?
C'est possible d'utiliser le même code pour le .lua?

Au fait, j'ai vu ça un peu tard, mais ta boucle While est placé après son contenu ! Mets là juste avant le Do, et ça devrait marcher.

Destork a écrit:

Au fait, j'ai vu ça un peu tard, mais ta boucle While est placé après son contenu ! Mets là juste avant le Do, et ça devrait marcher.

On peut mettre le while après un do et ça peut être très utile dans certains cas.
On appelle ça une boucle ... do-while.

Destork a écrit:

Au fait, j'ai vu ça un peu tard, mais ta boucle While est placé après son contenu ! Mets là juste avant le Do, et ça devrait marcher.

ça marche quand même tu as tester le .exe que j'ai donné?*

leverdier a écrit:

Destork a écrit:

Au fait, j'ai vu ça un peu tard, mais ta boucle While est placé après son contenu ! Mets là juste avant le Do, et ça devrait marcher.

On peut mettre le while après un do et ça peut être très utile dans certains cas.
On appelle ça une boucle ... do-while.

Bon à savoir °°'
Quelle est la différence entre une boucle While-do et une Do-while?

Aller je commence en .lua

Code:

-- les éléments de notre menu
local list_items_menu = {"Item 1","Item 2","Item 3","Item 4","Item 5"}
-- l'élément sélectionné
local selected_item = 1
--Menu des difficultés a faire + tard
--Initialisation
Int{nombreMystere = 0, nombreEntre = 0
Min=0 Max=100}
--Tb choisi un nombre au hasard
for nombreMystere= 0,100 do
nombreMystere = (rand() % (MAX - MIN + 1)) + MIN;

--Joueur choisi un nombre

run_cmd("echo " .. Quel est le nombre mystere?)

scanf("%d", &nombreEntre);

end

Destork a écrit:

leverdier a écrit:

Destork a écrit:

Au fait, j'ai vu ça un peu tard, mais ta boucle While est placé après son contenu ! Mets là juste avant le Do, et ça devrait marcher.

On peut mettre le while après un do et ça peut être très utile dans certains cas.
On appelle ça une boucle ... do-while.

Bon à savoir °°'
Quelle est la différence entre une boucle While-do et une Do-while?

Mettre un do avant le while permet d'être sûr que la boucle se fera au moins une fois.

En fait, en temps normal on a
while (condition)
{
code
}

Le code se fait tant que la condition est vraie. La condition est vérifiée avant chaque passage dans la boucle.
Si la condition est fausse des le départ, on rentrera jamais dans la boucle.


Alors que dans le cas
do
{
code
}
while (condition)

La condition est vérifiée après chaque passage dans la boucle, même si la condition est fausse au départ la boucle sera faite une fois.

Ca peut paraitre con mais parfois ça allège vraiment le code.
Dans son cas en tout cas ça n'est pas nécéssaire.
Sache quand même que le do-while est beaucoup moins utilisé, il faut donc pas se prendre la tête, parfois ça vient, on se dit que c'est plus pratique et que ça évite quelques lignes de code. L'informatique est faite pour les fainéants.

Ah ouais, je l'avais lu dans un tuto ça, y'a quelques années, mais j'avais oublié °°'

Merci!

Et Nokturnal, ton "--Joueur choisi un nombre" est inexact, il me semble. Ce serait plutôt "Console demande au joueur le nombre" pour le coup, non?

Si si c'est bon mais j'ai pas fini mais je c'est pas comment faire pour que le .lua reconnait ce que le joueur tape comme nombre

Ca fait partie des choses que je traiterai dans un prochain tuto... mais là, j'suis débordé, désolé.

Ok bah je vais attendre

Code:

-- les éléments de notre menu
local list_items_menu = {"Item 1","Item 2","Item 3","Item 4","Item 5"}

c'est bien ça pour faire un menu? j'ai vu ça dans la partie 2d

Je ne sais pas ce que tu entends par menu, mais pour faire un tableau, c'est bien ça.

Gros up du topic vu que je commence un peu à luater.

J'ai fait ma propre version du hax_detection de Melmoth. Voilà je trouvais que le script était une excellente idée.
MAIS j'ai sous-estimé Melmoth, je pensais qu'il avait fait une erreur quelque part (le script ne fonctionne pas réellement). Et je me retrouve avec les mêmes résultats.

https://www.box.com/s/c192b705a79c9f9468c1
(l'entier printé avant les résultats est la première frame pour laquelle il existe une différence entre le replay original et le replay créé)

Donc j'ai codé ça avec un gros tableau moi sans passer par un fichier .tmp
Je pense que tu as utilisé ça Melmoth pour vérifier le replay que ça donnait, parce qu'effectivement je n'arrive pas à récupérer le replay créé par le script.. Donc j'ai du mal à analyser les résultats.

Le replay qui est créé est exactement le même que celui créé par hax_detection.lua.

Sauf que moi il me dit à tous les coups (presque) que le replay est hacké. Parce que je vérifie les positions de chaque joint, et il y a quasiment à chaque fois des différences (au moindre contact en tout cas ...)

Avec un replay sans contact, ça marche (parfois). Exemple avec ce replay. Donc je pense pas avoir décalé le replay d'une frame ou bêtise de ce genre, qui aurait donné une erreur sur tous les replays.

Mon hypothèse pour l'instant c'est que hampa à coder ça avec ses pieds et que set_joint_state ne fonctionne pas comme lorsque nous cliquons nous-même sur les joints. Je pense qu'il modifie bien les bonnes articulations mais étrangement, cela ne donne pas les mêmes résultats. Est-ce possible ?
Je n'exclue pas une erreur de ma part bien sûr, surtout que j'ai pas passé beaucoup de temps encore sur le script, mais les différents tests que j'ai effectué me paraissent très étranges.

Qu'en penses tu Melmoth, avais-tu essayé à un moment de débeuguer ton script et quelles avaient été tes hypothèses/conclusions ?

Je me souviens plus de ce qui avait motivé mes choix à l'époque
Je forçais l'état des joints à chaque frame, même si il n'y avait aucun changement, et je me souviens que je pensais que ça impliquait une légère différence entre le replay original et le replay généré. Différence que je n'explique pas, donc on va se mettre d'accord et dire qu'effectivement, Hampa code avec les pieds.

Mon hypothèse (attention, si vous n'êtes pas familier avec le développement informatique, lire ce qui suit peut avoir des effets secondaires néfastes) :
- Le set_joint du jeu (celui qui intervient quand on change manuellement l'état d'un joint, in game) est un simple setter sur l'attribut "état" de l'instance du joint qu'on modifie. Il ne modifie pas les autres attributs (position, vitesse linéaire/angulaire notamment).
- Le set_joint du lua, au lieu d'appeler exactement cette méthode, est exécutée par l’interpréteur lua, et comme les dév de Nabi sont des feignasses, ça m'étonnerait bien qu'ils aient wrappé toutes les méthodes de l'objet "joint". Je penche pour une méthode du genre update_joint, qu'on appelle avec tous les attributs, ceux qu'on veut modifier (ici : l'état) et ceux qui ne bougent pas (position, vitesse angulaire, vitesse linéaire...). Problème : ces attributs sont des floats. Entre le moment où ils sont récupérés et le moment ils sont repassés en paramètre de la méthode d'update ils ont le temps d'être arrondis différemment. D'où les légères différences à chaque frame, qui entraînent à la fin une énorme différence entre les deux replays.

C'est en tout cas de côté que je chasserais le bug si j'avais le code source dans les mains et si j'avais un tantinet l'envie de rendre service à une équipe de dév qui se trouve être la moins disponible de toute la galaxie du jeu indé (un forum support géré par des gens qui n'ont pas accès au code, c'est quand même du jamais vu).

Merci de votre attention, je retourne dessaouler.

En conclusion, il est donc impossible de faire ce hax_detection.

En tout cas si set_joint_state ne marche pas comme il le faut c'est super chiant, car ça enlève énormément de possibilités de scripts (bot, etc ...)

Mais effectivement, j'ai pas envie d'en parler sur le forum officiel parce que je sais que je n'obtiendrai jamais de réponse.

Faut voir comment l'équipe a géré la perte de données de plusieurs clans (dont fr_death) : moins on en parle, mieux c'est.

Cela dit, j'ai trop bu aussi
Mais je compte pas déssaouler, il n'est que 19h

leverdier a écrit:

Faut voir comment l'équipe a géré la perte de données de plusieurs clans (dont fr_death) : moins on en parle, mieux c'est.

Je vais un peu faire l'avocat du diable mais :
- Les membres du staff n'ont le droit de diffuser aucune information interne, sous peine de perma-ban, y compris la provenance réelle du problème (malgré qu'ils auraient pu plus nous informer, je suis d'accord avec toi sur ce point là).
- J'ai parlé avec Uric, il a fait tout ce qu'il a pu mais n'a pas pu tout récupérer.

En gros, il y a juste un problème de communication. On ne sait pas ce qu'on a le droit de dire ou pas, du coup, on ne prend pas de risque. Mais oui, les infos que je sais aurait dû être publique plutôt que des dialogues irc sur des boards réservés au mods...
/hs

J'ai du mal à imaginer les raisons qui poussent une équipe de dév/modérateur à garder le secret sur un problème comme la perte de messages sur un forum, et je sais pas pour les autres, mais dans mon cas ça me pousse juste à penser que c'est entièrement de leur faute. Mais je me doute bien qu'en tant que GM tu ne peux pas changer le monde, personne ne te tiens responsable de quoi que ce soit, Flo

Mais dans le cas de lua et TB, c'est encore une autre histoire : j'ai fait remonter pléthore de bugs au forum support, à Blam qui se chargeait du dev de ce côté, et à Hampa. Aucun n'a été corrigé. C'était déjà un miracle quand j'avais une réponse.

Parfois, on m'a dit qu'il fallait que je choppe Hampa sur IRC. Faut qu'on m'explique l'intérêt d'un forum Support et d'une équipe support si ils ne font pas remonter les bugs eux mêmes. Perso, je n'avais pas accès à IRC au boulot, à chaque fois que je m'y suis connecté, Hampa ne s'y trouvait pas. Le jeu restera glitché car rien n'est fait pour rendre le report de bugs simple.

Si vous saviez le nombre de scripts que je n'ai pas pu finir à cause de ça, vous comprendrez que c'est une des raisons qui fait que je suis quasiment totalement inactif aujourd'hui. J'ai vraiment l'impression d'avoir perdu mon temps (une bonne cinquantaine d'heures sur Atmo 3, qui ne sortira probablement jamais, par exemple).

On peut parler de ça sur un autre thread si vous voulez, continuons donc à parler lua ici

Melmoth a écrit:

J'ai du mal à imaginer les raisons qui poussent une équipe de dév/modérateur à garder le secret sur un problème comme la perte de messages sur un forum, et je sais pas pour les autres, mais dans mon cas ça me pousse juste à penser que c'est entièrement de leur faute.

Tout à fait d'accord avec toi

Ça a déjà dû être proposé mais, il est possbile de faire un script lua permettant de revenir en arrière sur les replays ?

Je me suis déjà penché sur ce problème, je ne me souviens plus pourquoi j'ai arrêté de bosser là dessus... j'ai des idées qui peuvent marcher en tout cas, mais c'est un très gros travail.

EDIT : je m'en souviens : j'attendais de voir si la 4.0 n'allait pas le proposer par défaut

Flosax a écrit:

- Les membres du staff n'ont le droit de diffuser aucune information interne, sous peine de perma-ban, y compris la provenance réelle du problème.

C'est justement ça qui me choque.

La 4.0 c'était pas une blague ?