Informatique en cycle 3/4: découvrons Scratch (récapitulatif tenu à jour de mes essais page 8)

Franck059 a écrit:

Mrs Hobie a écrit:l'IPR a été formel : ce serait dommage de se priver d'un outil si puissant, et que les élèves connaissent déjà, et il est si simple de changer le "lutin" si on trouve le chat trop puéril
Graoumpfff

J'ai la charge de 130 élèves (4ème et 3ème).
J'ai mené mon enquête auprès d'eux.
Résultat : aucun ne connaît Scratch, ni d'ailleurs aucun autre outil de programmation.
AUCUN
Sont vraiment de plus en plus à côté de la plaque ces ipr...

Tu fais un peu de mauvaise foi là ou pas ?   (d'habitude c'est moi qui ait du mal avec les implicites/sous-entendus ...)
Plus sérieusement, la question posée à l'IPR était lors de la liaison collège-lycée, dans le contexte de la réforme du collège, et donc des retombées de cette réforme au lycée, dans les années à venir, pour les aménagements de programme, particulièrement pour l'algorithmique ... Donc théoriquement, tous les élèves auront vu Scratch, puisque les nouveaux programmes de collège incitent fortement à utiliser Scratch ...

Mrs Hobie a écrit:

Franck059 a écrit:

Mrs Hobie a écrit:l'IPR a été formel : ce serait dommage de se priver d'un outil si puissant, et que les élèves connaissent déjà, et il est si simple de changer le "lutin" si on trouve le chat trop puéril
Graoumpfff

J'ai la charge de 130 élèves (4ème et 3ème).
J'ai mené mon enquête auprès d'eux.
Résultat : aucun ne connaît Scratch, ni d'ailleurs aucun autre outil de programmation.
AUCUN
Sont vraiment de plus en plus à côté de la plaque ces ipr...

Tu fais un peu de mauvaise foi là ou pas ?   (d'habitude c'est moi qui ait du mal avec les implicites/sous-entendus ...)
Plus sérieusement, la question posée à l'IPR était lors de la liaison collège-lycée, dans le contexte de la réforme du collège, et donc des retombées de cette réforme au lycée, dans les années à venir, pour les aménagements de programme, particulièrement pour l'algorithmique ... Donc théoriquement, tous les élèves auront vu Scratch, puisque les nouveaux programmes de collège incitent fortement à utiliser Scratch ...

Sauf si un bon nombre de collègues fait de la résistance passive, considérant que le temps manque et qu'il y a d'autres priorités que Scratch.

Mrs Hobie a bien employé le "théoriquement".
Le même "théoriquement" qu'on retrouve dans "Théoriquement, les élèves arrivent en 6° en connaissant leurs tables de multiplication" .

Je suppose que l'IPR aura voulu dire quelque chose comme :
"Bien sûr que tous les élèves ne le connaîtront pas en arrivant en 2nde et qu'il faudra tout reprendre avec eux... Mais il faut déjà partir de rien avec algobox... Et quitte à reprendre, autant reprendre un truc que certains auront peut-être déjà vu."

Mais l'argument "ce serait dommage de se priver d'un outil si puissant, et que les élèves connaissent déjà" est grandiose, puisqu'il aurait permis au boulier de perdurer jusqu'à présent dans nos salles :lol:
J'imagine bien les élèves :
- Monsieur, on aura droit au boulier au contrôle de fractions ?
- Oui.
- Ouf...

William Foster a écrit:Mrs Hobie a bien employé le "théoriquement".
Le même "théoriquement" qu'on retrouve dans "Théoriquement, les élèves arrivent en 6° en connaissant leurs tables de multiplication"   .

Tout à fait.
Et même que ça me fait penser à cette citation, attribuée à Einstein :
“La théorie, c'est quand on sait tout et que rien ne fonctionne. La pratique, c'est quand tout fonctionne et que personne ne sait pourquoi. Ici, nous avons réuni théorie et pratique : Rien ne fonctionne... et personne ne sait pourquoi !”
Et si j'avais le courage, j'irai chercher une image de Shadock pour ponctuer l'ensemble du propos  
J'ai de plus en plus l'impression d'être une Shadock

William Foster a écrit:Je suppose que l'IPR aura voulu dire quelque chose comme :
"Bien sûr que tous les élèves ne le connaîtront pas en arrivant en 2nde et qu'il faudra tout reprendre avec eux... Mais il faut déjà partir de rien avec algobox... Et quitte à reprendre, autant reprendre un truc que certains auront peut-être déjà vu."

Oui, on peut imaginer ça ... Mais je pense qu'il était vraiment convaincu que les collègues de collège vont le faire (c'est beau, quelque part, la naïveté d'un IPR, ou les dons de comédien, j'en sais rien ...)

William Foster a écrit:Mais l'argument "ce serait dommage de se priver d'un outil si puissant, et que les élèves connaissent déjà" est grandiose, puisqu'il aurait permis au boulier de perdurer jusqu'à présent dans nos salles :lol:
J'imagine bien les élèves :
- Monsieur, on aura droit au boulier au contrôle de fractions ?
- Oui.
- Ouf...

J'avoue avoir fait la même réponse qu'au pédiatre la dernière fois que je l'ai vu ou à n'importe qui dont l'opinion semble gravée dans le roc, et donc une tentative d'argumentation vouée à l'échec et une perte de temps certaine : "oui, je comprends"  en hochant la tête pensivement ...

Ceci dit, je l'ai déjà dit, mais mon cher et tendre, a confirmé le côté puissant du bouzin (et le côté puéril aussi ... mais puissant. Purée, mon cher et tendre aurait pu être IPR s'il avait été prof !!! )

Bref, va falloir la jouer "subtil" ...

CSP a écrit:Le Conseil supérieur des programmes souhaite faire part de son interrogation sur la cohérence de l'offre de formation en informatique proposée aux élèves de la série scientifique qui n'auront accès à l'enseignement facultatif qu'en classe de première et ne pourront pas le poursuivre en classe terminale même s'ils n'ont pas choisi la spécialité ISN.
Il souligne le fait que les nouveaux programmes du collège ainsi que ce nouvel enseignement d'ICN invitent à revoir le programme de l'enseignement de spécialité ISN en terminale S.
Enfin, il insiste sur la nécessité d'une formation des enseignants qui voudraient prendre en charge ce nouvel enseignement, quelle que soit leur discipline.

source

J'ai graissé les morceaux que je trouve bizarres...

Je n'ai lu que le début du papier, vais finir en m'endormant... Bonne lecture

William Foster a écrit:

CSP a écrit:Le Conseil supérieur des programmes souhaite faire part de son interrogation sur la cohérence de l'offre de formation en informatique proposée aux élèves de la série scientifique qui n'auront accès à l'enseignement facultatif qu'en classe de première et ne pourront pas le poursuivre en classe terminale même s'ils n'ont pas choisi la spécialité ISN.
Il souligne le fait que les nouveaux programmes du collège ainsi que ce nouvel enseignement d'ICN invitent à revoir le programme de l'enseignement de spécialité ISN en terminale S.
Enfin, il insiste sur la nécessité d'une formation des enseignants qui voudraient prendre en charge ce nouvel enseignement, quelle que soit leur discipline.

source

J'ai graissé les morceaux que je trouve bizarres...

Je n'ai lu que le début du papier, vais finir en m'endormant... Bonne lecture

Le côté sympa de ce programme, c'est sa vacuité prescriptive : "on tente quelques idées plus ou moins réalisables, maintenant démerdez-vous".
Par contre j'ai trouvé une faute de conjugaison ; j'ai arrêté de lire, j'attendrai une version corrigée.
Je n'ai pas vu d'indication horaire. Bon c'est cohérent avec la présentation générale : beaucoup de baratin (même si j'avoue avoir glané deux ou trois idées pas inintéressantes).

William, "revoir le programme d'ISN" c'est parce que les thèmes sont grosso modo les mêmes qu'en ISN ; un élève ayant fait ICN en seconde et en 1S commencera ISN avec un peu d'avance sur un débutant complet ; de plus ICN existait déjà en seconde et est désormais proposé en 1L et TL, 1ES et TES, 1S et pas TS. "Quelle que soit leur discipline" : les enseignants d'ISN actuels sont des professeurs de Mathématique, de SPC, de SVT, de SI ; mais on peut supposer que seront formés des géographes, des collègues de SES, de Lettres, de LV, dans la mesure où l'option ICN s'ouvre aux L et ES.

Ok pour les disciplines. Merci pour l'explication

Par contre, notre IPR qui recommande 3h de Scratch dans l'année, je trouve que ça fait court pour influencer l'enseignement au lycée jusqu'en Tale. C'est prêter de grands pouvoir à un chat orange :lol:

William Foster a écrit:Ok pour les disciplines. Merci pour l'explication

Par contre, notre IPR qui recommande 3h de Scratch dans l'année, je trouve que ça fait court pour influencer l'enseignement au lycée jusqu'en Tale. C'est prêter de grands pouvoir à un chat orange :lol:

Mais trois heures de Scratch par an de la cinquième à la troisième, ça fait déjà plus que le temps qu'on consacre au Python pendant l'année d'ISN !

En tout cas tu as un IPR raisonnable, c'est cool.

ben2510 a écrit:

William Foster a écrit:Ok pour les disciplines. Merci pour l'explication

Par contre, notre IPR qui recommande 3h de Scratch dans l'année, je trouve que ça fait court pour influencer l'enseignement au lycée jusqu'en Tale. C'est prêter de grands pouvoir à un chat orange :lol:

Mais trois heures de Scratch par an de la cinquième à la troisième, ça fait déjà plus que le temps qu'on consacre au Python pendant l'année d'ISN !

En tout cas tu as un IPR raisonnable, c'est cool.

Houla ! Tu as mal comprendu les propos de l'Inspecteur Pédagogique Raisonnable : 3 h, c'est en tout. Juste 3 h, en troisième. Rien avant.
Au final, à peine plus que ce qu'on faisait sur l'angle inscrit

Mais on en fera sans doute plus : pour un autre IPR, décaler un lutin vers la droite de 50, c'est largement suffisant comme explication sur les translations

Un extrait du sujet 0 du DNB 2017 en maths :


Programmer dans le cadre du DNB, c'est donc bien faire des dessins à motifs répétitifs.

Je crains que la "figure à main levée" obtenue ne soit particulièrement moche dans la majorité des copies .... ah, faire une chouette figure, à la règle, au compas, au rapporteur, on faisait ça, au XXème siècle !
Quant à dire "combien mesure l'espace entre deux motifs", je suppose qu'un bon tas d'élèves va mesurer sur le dessin (oui, mais on leur dit "mesure", alors ils mesurent ; et puis l'énoncé ne précise pas "dans l'unité Scratch"). Et on fait quoi, si un élève mesure à la règle en se plaçant perpendiculairement aux parallèles ? On lui dit : mathématiquement, c'est plus juste, mais on ne te demande pas de faire des maths dans cet exercice ?
Ce sujet 0 annonce la couleur : l'algorithmique n'a pas pour but de faire des programmes mathématiques. La partie "math" de cet exercice, c'est de programmer le tracé du losange. Cela suppose de connaître les propriétés des angles. Mais comme c'est trop dur, on le donne directement. Du coup, que ce soit un losange ou un chat orange, finalement ...
C'est déprimant ...

Une série de tutoriels SCRATCH proposée par l'APMEP :
http://www.apmep.fr/Programmer-avec-Scratch

ycombe a écrit:Le but, c'est qu'ils programment les mouvements de la fourmi. Je vais lui programmer des blocs capteurs droite/devant/gauche qui donneront la distance du mur dans ces directions, et ils se débrouilleront avec ces infos pour que la fourmi trouve son chemin.

Une version scratch de laby, quoi!

Voilà ce que j'avais en tête:

Simulation robotique
- Le labyrinthe et la fourmi (non programmé): https://scratch.mit.edu/projects/105742748/
préparé pour être complété dans l'esprit de Laby. La fourmi représente un robot équipé d'un capteur lui permettant de savoir si un mur ou la sortie se trouve devant, à droite où à gauche. On doit la programmer avec les blocs Capteur, TourneDroite, TourneGauche et Avance (et les structures de contrôle, bien sûr) pour qu'elle trouve la sortie.
- La labyrinthe et la fourmi: https://scratch.mit.edu/projects/104158753/
Version fonctionnelle: la fourmi parcourt le labyrinthe (algorithme main droite) pour trouver la sortie.

ycombe a écrit:

ycombe a écrit:Le but, c'est qu'ils programment les mouvements de la fourmi. Je vais lui programmer des blocs capteurs droite/devant/gauche qui donneront la distance du mur dans ces directions, et ils se débrouilleront avec ces infos pour que la fourmi trouve son chemin.

Une version scratch de laby, quoi!

Voilà ce que j'avais en tête:

Simulation robotique
- Le labyrinthe et la fourmi (non programmé): https://scratch.mit.edu/projects/105742748/
préparé pour être complété dans l'esprit de Laby. La fourmi représente un robot équipé d'un capteur lui permettant de savoir si un mur ou la sortie se trouve devant, à droite où à gauche. On doit la programmer avec les blocs Capteur, TourneDroite, TourneGauche et Avance (et les structures de contrôle, bien sûr) pour qu'elle trouve la sortie.
- La labyrinthe et la fourmi: https://scratch.mit.edu/projects/104158753/
Version fonctionnelle: la fourmi parcourt le labyrinthe (algorithme main droite) pour trouver la sortie.

Bon, c'est peut-être un peu chaud pour des collégiens, quand même.

Ça m'a rappelé un article sur l'algorithme de Pledge : https://interstices.info/jcms/c_46065/l-algorithme-de-pledge
et comme j'ai d'abord cherché sur Images des Maths, j'ai aussi trouvé ça :
http://images.math.cnrs.fr/Labyrinthes-et-fil-d-Ariane.html
et http://images.math.cnrs.fr/Pavages-arbres-et-labyrinthes

Bon, je suppose que tu les as déjà vus, mais sait-on jamais.

Sur la lisibilité du code, j'avoue que j'ai lâché l'affaire assez vite ; je crois que tu atteins les limites de Scratch.
Je réessaierai pendant les grandes vacances (et en imprimant tout, puis en le traduisant en Python ou js).
Par curiosité, tu utilises quoi comme algorithme de génération de labyrinthe ?

ben2510 a écrit:
 Bon, c'est peut-être un peu chaud pour des collégiens, quand même.

En codant en dur les chemins à coups de avance, tourneDroite/Gauche, c'est faisable. Je vais faire une version avec des labyrinthes en dur pour pouvoir faire ça.

Ça m'a rappelé un article sur l'algorithme de Pledge : https://interstices.info/jcms/c_46065/l-algorithme-de-pledge
et comme j'ai d'abord cherché sur Images des Maths, j'ai aussi trouvé ça :
http://images.math.cnrs.fr/Labyrinthes-et-fil-d-Ariane.html
et http://images.math.cnrs.fr/Pavages-arbres-et-labyrinthes

Bon, je suppose que tu les as déjà vus, mais sait-on jamais.

Sur la lisibilité du code, j'avoue que j'ai lâché l'affaire assez vite ; je crois que tu atteins les limites de Scratch.
Je réessaierai pendant les grandes vacances (et en imprimant tout, puis en le traduisant en Python ou js).
Par curiosité, tu utilises quoi comme algorithme de génération de labyrinthe ?

Je ne connaissais pas, merci.

L'algorithme de génération est la fusion aléatoire de chemins: https://fr.wikipedia.org/wiki/Mod%C3%A9lisation_math%C3%A9matique_d%27un_labyrinthe#Fusion_al.C3.A9atoire_de_chemins
détaillé ici: http://www.ilay.org/yann/articles/maze/

OK merci !
(Je proposerai ça en isn comme projet l'année prochaine).

Pour l'utilisation avec des collégiens, on peut peut-être séparer en deux parties :
* générer des arrières-plans labyrinthiques
* utiliser ces arrières plans sous Scratch, et demander aux élèves de résoudre les labyrinthes

Cela permettrait de cacher la complexité de la génération des labyrinthes, non ?

Tiens, je suis tombé sur ça aussi : http://www.astrolog.org/labyrnth/algrithm.htm#perfect

Après avoir testé tout ce qui est dans la citation suivante, je m'autorise un avis sur Scratch:

Scratch mélange un environnement de programmation de dessin à la LOGO et un environnement de programmation de petits jeux.

La partie dessin ne présente rigoureusement aucun intérêt, l'expérience a déjà été faite à coups de tortue par le passé, pendant le temps à y consacrer on ne peut approfondir ni l'algèbre ni la géométrie. Comme pour la géométrie dynamique, les élèves qui accrocheront sont ceux qui seront déjà à l'aise en mathématiques.
La partie programmation événementielle offre une certaine puissance mais quelques limitations très ennuyeuses. Au mieux les élèves risquent de prendre de mauvaises habitudes, au pire cela va les gaver et ils vont renoncer, s'arrêter à des programmation simplistes voire ridicules.

Parmi les difficultés à prévoir:
* Les essais successifs dans lesquels il faudra commencer à réinitialiser le dessin (ce qui signifie au total: lever le crayon, remettre la couleur et la taille du stylo, aller au point de départ, reprendre la direction de départ, effacer tout). Il suffit d'en oublier un pour que le deuxième essai parte de travers, ça nous promet une belle perte de temps.

* L'orientation. Pour faire un triangle équilatéral, on doit faire ceci:
  - descendre le stylo, choisir son épaisseur et sa couleur
  - Répéter 3 fois:
     -- avancer de la longueur du côté
     -- tourner de 120°
Pourquoi 120° et pas 60° ? Parce que l'angle de 60° est entre le trait déjà tracé qui se trouve derrière et le trait qui va être tracé vers l'avant. Il faut se mettre à la place du stylo, ce qui risque de poser quelques problèmes.
Dans ce même problème d'orientation, on peut aussi parler des instructions "tourne à droite" et "tourne à gauche". Si on tourne à gauche au départ (orientation à 90°) on trace un trait vers le haut, si le lutin est vers le bas on trace un trait à droite. Les marins utilisent "bâbord" et "tribord", ce qui n'est franchement pas idiot. Ça nous promets des petits problèmes avec les dys. Les  labyrinthes de GCompris  proposent plusieurs modes: guidage absolu (la flèche droite envoie Tux à droite) et relatif (la flèche droite envoie tux vers sa droite, autrement dit à tribord), vous pouvez les proposer en remédiation sur la question.

* les listes servent de tableau à une dimension dont l'adressage commence à 1. Dans tous les langages que je connais, les tableaux commencent à 0.  Pour la simulation de tableau à deux dimensions, on va transformer le numéro en ligne/colonne avec modulo et division. C'est classique, mais ici il faudra à chaque fois ajouter 1, ça va être lourd. Et cela va rendre plus difficile le passage à d'autres langages.

* l'absence de fonction va rendre difficile la montée en complexité des programmes. On va rester à de petits dessins et de petits jeux sans grand intérêt.

* l'absence du compteur de boucle for semble assez curieux. Cela oblige souvent à le mettre soi-même, ce qui augmente la lourdeur.

* La direction est comptée dans Scratch à partir du haut dans le sens des aiguilles d'une montre. En mathématiques, on compte à partir de la droite dans le sens inverse. Pour moi il vaudrait mieux apprendre la règle générale, puis la règle particulière de ce logiciel. Là les élèves auront le temps de généraliser eux-même la règle de scratch avant de devoir la désapprendre au lycée, ce qui va être plus difficile. Heureusement que cela ne concerne que ceux qui iront en première S.

Au final je maintiens ma première impression: si on s'arrête aux exigences du DNB (c.f. les sujets 0) c'est une perte de temps. Et on n'aura pas le temps nécessaire pour faire des choses qui iraient suffisamment loin pour que cela puisse être profitable.

ycombe a écrit:Je récapitule mes essais:

Utilisation des costumes:
- Simulation d'un lancer de deux dés: https://scratch.mit.edu/projects/103315319/
- Pétales autour de la rose: https://scratch.mit.edu/projects/103133102/
- Lights (je ne sais pas comment l'appeler): https://scratch.mit.edu/projects/103079582/
Il y en une variante avec des pièces dans les documents d'accompagnement mais elle est sans intérêt (position fixe au départ).

Utilisation des déplacements
- Basket: https://scratch.mit.edu/projects/103283652/

Utilisation des costumes et des déplacements:
- Pile ou face (un peu difficile niveau déplacement): https://scratch.mit.edu/projects/103185275/
- Pile ou face (bis): https://scratch.mit.edu/projects/103337433/
avec un déplacement plus réaliste et peut être plus simple à expliquer (ce dernier point n'est pas sûr).

Dessin comme en logo
- Flocon de Koch: https://scratch.mit.edu/projects/103392742/
- Fonction de Bolzano: https://scratch.mit.edu/projects/103532170/
- Courbe du dragon: https://scratch.mit.edu/projects/103576043/

Récursivité
Pas de retour de valeur sur les blocs. On peut faire comme en récursivité terminale:
- Factorielle: https://scratch.mit.edu/projects/103926140/
- Flocon de Koch avec un tracé calculé récursivement: https://scratch.mit.edu/projects/103927942/

Algorithmes spéciaux:
- Labyrinthe (générateur de labyrinthe): https://scratch.mit.edu/projects/104043448/
(Ceci est la seconde version. La première a un code beaucoup plus abscon: https://scratch.mit.edu/projects/103949340/ )

Simulation robotique
- Le labyrinthe et la fourmi (non programmé): https://scratch.mit.edu/projects/105742748/
préparé pour être complété dans l'esprit de Laby. La fourmi représente un robot équipé d'un capteur lui permettant de savoir si un mur ou la sortie se trouve devant, à droite où à gauche. On doit la programmer avec les blocs Capteur, TourneDroite, TourneGauche et Avance pour qu'elle trouve la sortie.
- La labyrinthe et la fourmi: https://scratch.mit.edu/projects/104158753/
Version fonctionnelle: la fourmi parcourt le labyrinthe (algorithme main droite) pour trouver la sortie.

Pour programmer il ne suffit pas de savoir faire des choses évidentes:
https://scratch.mit.edu/projects/106274482/

(À essayer avec un côté maximal de plus de 2000).

Petit jeu: écrivez un programme en scratch qui trouve la liste des nombres amicaux inférieurs à 100000.

Rappel: deux nombres sont dits amicaux si la somme des parties aliquotes (les diviseurs stricts, quoi)  de l'un est égal à l'autre.
Par exemple 220 et 284 sont amicaux.

Edit: le mien est fini. Score à battre: 9,872 (mode Turbo) pour la liste des 13 paires de nombres amicaux inférieurs tous deux à 100000. Non je ne le montre pas. Essayez de faire mieux. (Avec Scratch).

Merci pour ce travail sur lequel je vais m'appuyer (pour faire le minimum).

Y'a pas de quoi.

Petit truc: sauver des scripts pour s'en resservir dans d'autres programmes: il est possible de sauver un lutin avec ses scripts et de l'importer dans un autre programme: donc on peut créer un lutin, glisser les scripts dedans et les rappeler comme cela.

ycombe a écrit:Petit jeu: écrivez un programme en scratch qui trouve la liste des nombres amicaux inférieurs à 100000.

Rappel: deux nombres sont dits amicaux si la somme des parties aliquotes (les diviseurs stricts, quoi)  de l'un est égal à l'autre.
Par exemple 220 et 284 sont amicaux.

Edit: le mien est fini. Score à battre: 9,872 (mode Turbo) pour la liste des 13 paires de nombres amicaux inférieurs tous deux à 100000. Non je ne le montre pas. Essayez de faire mieux. (Avec Scratch).

Pas de joueurs ? Dommage...

ycombe a écrit:

ycombe a écrit:Petit jeu: écrivez un programme en scratch qui trouve la liste des nombres amicaux inférieurs à 100000.

Rappel: deux nombres sont dits amicaux si la somme des parties aliquotes (les diviseurs stricts, quoi)  de l'un est égal à l'autre.
Par exemple 220 et 284 sont amicaux.

Edit: le mien est fini. Score à battre: 9,872 (mode Turbo) pour la liste des 13 paires de nombres amicaux inférieurs tous deux à 100000. Non je ne le montre pas. Essayez de faire mieux. (Avec Scratch).

Pas de joueurs ? Dommage...

9,872, c'est 9872 secondes ? millisecondes ?

William Foster a écrit:

ycombe a écrit:

ycombe a écrit:Petit jeu: écrivez un programme en scratch qui trouve la liste des nombres amicaux inférieurs à 100000.

Rappel: deux nombres sont dits amicaux si la somme des parties aliquotes (les diviseurs stricts, quoi)  de l'un est égal à l'autre.
Par exemple 220 et 284 sont amicaux.

Edit: le mien est fini. Score à battre: 9,872 (mode Turbo) pour la liste des 13 paires de nombres amicaux inférieurs tous deux à 100000. Non je ne le montre pas. Essayez de faire mieux. (Avec Scratch).

Pas de joueurs ? Dommage...

9,872, c'est 9872 secondes ? millisecondes ?

C'est l'unité du chronomètre interne, je pense que ce sont des secondes, vu la durée réelle. Mais en vrai je ne suis sûr de rien.

Mais c'est 9,872 ou 9 872 ? moi je n'ai que deux décimales avec le chrono de scratch...

dami1kd a écrit:Mais c'est 9,872 ou 9 872 ? moi je n'ai que deux décimales avec le chrono de scratch...

Moi j'ai trois décimales, en faisant comme ça:



https://scratch.mit.edu/projects/106438347/