[Magic Cat]

Certaines fonctionnalités utilisées en script sont récurrentes comme les lecteurs de config de notecard, ou les dialog à plus de 12 boutons, etc...
Celles-ci alourdissent le script en lisibilité et en flexibilité.

L'objectif de ce projet est d'externaliser ces fonctions dans un ou des scripts esclaves.

Le principe est de crée une communication entre le script principal et son module via Link_message.
Ainsi en ajoutant simplement un script dans l'objet on pourrait utiliser une fonctionnalité un peu à la manière "objet" sans même forcément connaitre son contenu ni son fonctionnement interne.

L'objectif final étant de mutualiser ces fonctions ou bibliothèques de fonctions.

Cela permettra avec le temps d'écrire plus propre, plus puissant et performant.

Alors aujourd'hui, chers amis scripteurs j'aimerais votre avis, vos suggestion... Ou comment formaliser ca en terme de protocole, de méthodologie, de diffusion...
Qui ca tente de bâtir les premières pierres des script de demain?

...

[Iceman Arkin]

Projet intéressant

Etant plus à l'aise en algorithmique qu'en script LSL, je ne sais pas si je serais utile. Mais si je peux... c'est avec plaisir

[Magic Cat]

Criss, je croyais ru me connaissais depuis le temps...
Je suis contre l'élitisme pour et pour la vulgarisation et le communautaire
C'est la finalité de ce projet !

Mais pour lancer ce projet et participer bien sure il faut être un peu aguerris.
Par contre à terme tout le monde pourra en profiter !

Car à terme tu n'auras que à ajouter un script dans ton objet et une ligne dans ton script pour que ton script fasse quelque chose là ou ca aurait prit 80 lignes.
Donc ton script et plus clair, plus performant car pas embrouillé par du code inutile.

Mais une fois cette méthode de scriptage mise en place, des bibliothèque sur les particules pourraient être à envisager
Ca serait cool pour les personne qui connaissait rien au particule de pouvoir l'exécuter en ligne simplement rien que en ajoutant un script que tu as écris

[Maxwell37_Carter]

A tenir compte le projet de réguler la puissance des scripts by LL.
Si vous vous cassez la tête à créer pour être périmé dans qques mois, ça va faire remonter qques amydales.

Le systeme HouseControl de A.E. gere un pluging dans la boite de controle, + le script dans l'objet à gérer (lamp, fan, porte...)
C'est un systeme de ce type dont tu parles ?

[Nibb]

Il n'y a pas de "include" en LSL, il y a 2 possibilités:
- soit tu rajoutes un script pour chaque fonction, mais dans ce cas, tu dois orienter ton script principal autour d'evenements message_linked pour récupérer les résultats de chaque script, ce qui n'est pas forcément pratique
- soit tu te limites à une bibliothèque de fonctions perso que tu peux rajouter en tête de script

L'un n'exclue pas l'autre bien sûr.

On ne sait pas comment LL compte mettre en pratique sa politique de limitation des scripts, mais il est possible que la limite se fasse sur le nombre de scripts par personne ou par parcelle...

[Iceman Arkin]

...comme il est possible qu'ils ne fassent rien... ne sachant pas trop comment faire...

Puis, ils l'ont dit : Leur priorité 2009, c'est l'adult filtering.

[Magic Cat]

Non maxwell c'est pas de ça dont je parle.

Grosso modo je veux essayer de reproduire le principe des DLL, OCX et autres joyeuseries sous windows.

oui nibb, c'est de ca dont je parle mais orienté autour du link_message

Car tout scripteur sais quand il ecrit un truc qui sera réutilisable, ca demanderait juste un petit effort de structure et de générosité pour le partager.

Concernant les modifs de LL je les voit mal envisager de limiter les script à un script par objet
Ils sont cons mais y a des limites

[bestmomo]

L'idée est bien entendu excellente et tous ceux qui développent en parallèle avec des langages qui supportent la POO, c'est à dire tous les langage actuels, sont considérablement frustrés dans SL parce qu'ils ont du mal à se créer une bibliothèque de routines facilement réutilisables.

Personnellement j'essaie toujours dans mes scripts d'établir des structures génériques qui facilitent le réemploi. J'en ai donné un exemple ici :
https://forums.jeuxonline.info/showt...highlight=menu

Le problème est la lourdeur pour ne pas dire la balourdise des messages entre scripts qui oblige à intervenir quasi systématiquement au niveau du script appelant. On est loin de la création de classes avec toutes leurs subtilité syntaxique.

Donc je souscris à ton idée mais je suis un peu dubitatif sur sa formalisation. Mais comme d'habitude je veux bien participer à cette initiative si elle voit le jour.

[Elenia Boucher]

Vous me faites sortir de ma retraite là:

J'avais proposer une approche qui peut être utile pour formaliser ça : https://forums.jeuxonline.info/showthread.php?t=963614.

Mais pour avoir tester plusieurs scripts dans une prim ça fonctionne certes mais on a aucune garantie de synchronisation, sans compter que vu la pauvreté du dialogue déjà souligné par nibb il faut formater les données au départ et les extraire à l'arrivée, ce qui nuit à l'efficacité.
Donc a réserver à des cas avec peu de volume de données, et là où la synchronisation n'est pas critique. A des traitements paralléles aussi. Et indispensable quand on a besoin de gérer des permissions avec plusieurs avatars bien sur.

J'ai trouvé que l'écriture modulaire en utilisant les fonctions était beaucoup plus efficace, surtout depuis mono qui a fait sauter la limite des 16k. Et une fonction, ça peut se partager aussi. Seule différence cela oblige à donner le code source.

[Iceman Arkin]

L'idée de modulariser, de proposer des "briques logicielles" est une très bonne idée, je trouve. Récupérer un bout de code qui fait telle ou telle fonction (lecture de notecard, menu...), on le pratique déjà, mais faut avouer que c'est pas toujours facile d'intégrer dans son propre code le script créé par une autre personne...

L'idée de développer des "bibliothèques", avec passage de paramètre normalisé pourrait donc être une excellente chose, tant pour les "généreux" qui offrent leur scripts, que pour les "fainéants" qui ne l'écrivent pas eux-même...

[Freelance Gontineac]

Je veux bien répondre présent a l'appel également, le concept est intérèssant mais des détails supplémentaires seraient les bienvenus également. Créer des bibliothèques simplifiant certaines problematiques, la dessus ok, reste encore a determiner lesquelles exactement, pour qui, et sous quelles conditions aussi...

[Iko Aker]

Bonjour,

Je veux bien répondre présent aussi sachant qu'un autre aspect peut rentrer en ligne de mire: La quantité de mémoire.

J'ai commencé à créer une librairie de scripts et je l'ajoute en début de script pour lecture notecard, gestion de la langue et traduction des messages, fonction CGI.... mais au bout d'un moment, notamment pour la gestion de langue, le script seul est insuffisant, D'où la séparation et la gestion du chargement de messages pour une langue donnée dans un autre script. Mais alors comment utiliser les messages traduits ? Le script se retrouve donc à devoir gérer aussi l'affichage des messages ou la modification du texte au dessus des objets, il a donc une autre fonction que 'juste' charger les messages d'une langues donnée.... à rajouter à cela le besoin potentiel de fournir les paramètres pour le message et se pose alors d'autres questions....

Une autre utilité est aussi pour l'envoi d'email avec des scripts esclaves. Déléguer l'envoi de manière à ne pas souffrir de l'attente de 20 secondes... une fois de plus il faut faire passer une information sujet/adresse email/contenu à un script avec comme paramètre de message lié integer/string/key... d'où besoin d'un protocole spécifique....

Donc il y a un certain nombre de tips et de choses à réaliser pour faire une librairie de modules réutilisables..... je suis ok pour partager cela après définition du type de licences et d'utilisation (script full perm oui/non, utilisation pour projets commerciaux, ....)

[XanorK]

J'adore l'idée !!

si besoin d'aide, j'en suis.

[bestmomo]

Pour un peu avancer dans la réflexion, puisque le sujet semble intéresser étant donné les réactions récoltées de différentes manières, il me semble souhaitable dans un premier temps de définir la pertinence de chaque façon de gérer la réutilisation de code dans le cadre de LSL. Je vois en gros 3 approches :

1. les fonctions directement intégrées dans le script,
2. les fonctions se trouvant dans un script annexe avec liaison par linkMessage,
3. une surcouche logicielle du genre celle utilisée dans LSL Plus, plugin de Eclipse dont j'ai déjà parlé sur ce forum : https://forums.jeuxonline.info/showt...hlight=eclipse

Quels sont les avantages et inconvénient de ces approches ?

1. une fonction dans le script a le mérite de la simplicité des appels, mais elle alourdit le script et nécessite une procédure de copier/coller pour être intégrée,
2. une fonction dans un script annexe a pour mérite d'alléger le script principal et d'éviter le copier/coller. Mais le principe de communication basé sur des linkMessages est lourd à gérer au niveau du passage des valeurs et ne supporte pas des traitements synchronisés,
3. l'approche de LSL Plus possède les avantages de la fonction intégrée sans les inconvénients du copier/coller. Par contre elle rend dépendant d'un outil de développement.

On perçoit bien les limitations de LSL au travers de ces descriptions. La question est : quelle est la meilleure façon de procéder ? Chacun a pris ses habitudes selon son style personnel, la question de fond ici est celle de la mutualisation de certaines routines fréquentes et de la meilleure façon de les partager.

Il faut bien entendu tenir compte de la possible limitation des scripts prévue par LL que Nibb nous a signalé. Il serait évidemment ballot de se retrouver avec une multitudes de scripts dans un contexte où juste quelques uns nous seraient autorisés. Cette épée de Damocles est de nature à orienter nos choix pour éviter certaines frustrations futures. On peut d'ailleurs se demander sur ce sujet comment on va pouvoir gérer par exemple des produits de danse qui nécessitent un script pas danseur, mais c'est un autre sujet (quoi que...).

Au delà des contraintes techniques évoquées je trouve toujours sympathique le partage dans un cadre sociétal qui nous pousse à l'individualisme et l'élitisme. Je vais glisser hors sujet ? Ok je m'arrête

[Pierre (Pi78)]

C'est bien beau de rêver (SL est aussi fait pour ça), mais là je crois que l'on part complètement dans le décor avec cette idée de "programmation modulaire" appliquée à LSL...

Bon, je ne prétends pas être un génie du LSL mais j'ai pratiqué la programmation en tous genres pendant plusieurs dizaines d'années, d'abord sur les "mainframes" puis sur les microprocesseurs. Je pense donc avoir suffisamment de recul et d'expérience pour prétendre que cette idée est farfelue et s'avère être une pure perte de temps (désolé Magic Cat, rien de personnel bien sûr !), et cela pour les quelques raisons suivantes :

1. le LSL est beaucoup trop limité (j'allais dire trop "pauvre") pour lui appliquer cette méthodologie. En fait, il n'a pas été "fait" pour ça.

2. Comme plusieurs participants à ce fil l'ont fait remarqué, la procédure d'appel et de passage des paramètres est lourde, très LOURDE, sans compter les effets induits par notamment la désynchronisation difficile à maîtriser.

3. L'ampleur relativement faible des projets basés sur LSL ne justifie nullement l'application de cette méthodologie : quelques dizaines, voire quelques centaines de lignes, écrites dans la grande majorité des cas par la même personne -- et non par une équipe de développeurs -- et agissant dans un périmètre particulièrement restraint.

4. L'incertitude sur la pérennité et le support du LSL.

Bon, soyons pragmatiques : par rapport, d'une part, à un projet de développement comme par exemple Windows XP (au hasard) qui comprend plusieurs centaines de milliers de lignes de code et plusieurs dizaines (centaines ?) de développeurs et qui nécessite OBLIGATOIREMENT (et implicitement) des méthodologies appropriées comme celle dont il est question ici, et d'autre part un applicatif consistant, par simple appui sur un bouton, à déclencher, à une heure donnée et pendant un temps donné, le préchauffage d'une bouilloire électrique connectée à un port USB... il y a une montagne dont il faut être conscient ! Je n'irais pas jusqu'à dire que pour moi, le script LSL s'apparente plus à la bouilloire électrique... mais je n'en pense pas moins

Voilà, c'est mon avis. Je ne prétends pas qu'il soit le meilleur et je reste ouvert à toute alternative, du moment qu'elle est constructive et objective, et apporte des arguments incontournables .

[bestmomo]

Citation :

Publié par Pi78

C'est bien beau de rêver (SL est aussi fait pour ça), mais là je crois que l'on part complètement dans le décor avec cette idée de "programmation modulaire" appliquée à LSL...

....

Je pense que tout le monde est d'accord sur les points que tu soulèves (limitations de LSL, lourdeurs du passage de paramètres, rare coopération entre développeurs...). Il n'en reste pas moins vrai qu'on remarque des répétitions fréquentes de code dans nos scripts que nous gérons chacun à notre manière. Une réflexion sur le sujet me semble pertinente. Je suis d'accord avec toi qu'il est inutile de se lancer dans une usine à gaz aux horizons plus qu'incertains. Mais une discussion raisonnable sur le sujet est loin d'être inutile et un partage de procédures, sous quelque forme que ce soit, me paraît judicieux.

[Pierre (Pi78)]

Citation :

Publié par bestmomo

Je pense que tout le monde est d'accord sur les points que tu soulèves (limitations de LSL, lourdeurs du passage de paramètres, rare coopération entre développeurs...).

Pour ce qui concerne la "coopération entre développeurs", je pensais plutôt aux grands projets sur lesquels une équipe de développeurs est mise en place, et où il est alors nécessaire de bien définir l'interface avec les "boîtes noires" qui seront mises en commun pour toute l'équipe. Dans le cas des projets en LSL, je ne pense pas que ce soit le cas puisque la plupart du temps il n'y a qu'un développeur par projet...

Citation :

Publié par bestmomo

Mais une discussion raisonnable sur le sujet est loin d'être inutile et un partage de procédures, sous quelque forme que ce soit, me paraît judicieux.

Ok, mais compte tenu des contraintes évoquées, je ne vois pas trop de solutions satisfaisantes, à part l'utilisation des fonctions.

Mais en pratique, ce sera pour gagner quoi ? Quelques lignes de codes ou quelques millisecondes dans l'exécution ?

Ah, la lisibilité du programme ? Il faut quand même noter une composante qui me paraît essentielle : la maintenabilité du projet. Car tôt ou tard, le développeur devra remettre le nez dans ses scripts, soit pour corriger un bug, soit pour y apporter des améliorations. Si on utilise un code relativement linéaire, il faudra déjà un certain temps d'adaptation pour se remettre dans le bain quelques semaines ou mois après. Si en plus le code effectue sans arrêt des appels plus ou moins sophistiqués pour accéder à telle ou telle fonction, ce qui aurait pu se faire plus simplement par un copier/coller de 3 lignes, ça ne va pas arranger les choses !

Bon, on peut toujours continuer à discuter...

[Iko Aker]

Il est vrai que l'avenir du LSL est incertain mais pour le moment c'est le moyen d'avoir des comportements, limités diront certains, dans les objets et permettre une interaction relativement simple avec le monde.

Apres il est vrai qu'il existe bon nombre de freebes, cours et autre pour aller piocher des bouts de codes, faire un copier coller et basta.

Mais ce projet modulaire a deux vocations pour moi:
- Accélérer les temps de développement en réutilisant des choses validées, corrigées et déjà en exploitation
- Partager avec les autres une approche pour résoudre un besoin et échanger dessus pour la faire évoluer

Je développe quelques projets avec des composantes récurrentes:
- Gestion des zones de click sur une face
- Gestion des langues avec chargement de notecard
- Gestion de configuration par notecard
- Envoi d'email en parallèle
- Appel CGI
-...
un ensemble de choses à partager, faire cohabiter pour proposer UNE méthode de programmation (pas la seule bien évidement), qui convient ou pas, mais qui existe.