Gedanken zur Vorgehensweise bei Aktualisierungen

[Kebap]

Wenn wir (offiziell oder nicht) Skripte verteilen, die Benutzer diese bei sich anpassen, und wir dann eine aktualisierte Version unserer Skripte veröffentlichen, wie können wir mögliche Komplikationen verhindern?

Empfehlung scheint zu sein, Skripte so bereitzustellen, dass sie von außen aufgerufen werden können. Auch untereinander sollen sie lose gekoppelt sein. Also viel in Funktionen auslagern, Events erzeugen und darauf lauschen. Durchaus können die Skripte in Mudlet editierbar bleiben, um eine geringe Einstiegshöhe zu behalten. Dennoch die Empfehlung an die Spieler, ihre eigenen Erweiterungen und Anpassungen nicht im gleichen Ordner abzuspeichern. Dieser Ordner wird per Mudlet-Modul aktuell gehalten und kann so auch von Spielserver bereitgestellt und (automatisch) aktualisiert werden (außer die Spieler deaktivieren diese automatischen Updates, dann per Hand)

[Kebap]

Wie läuft es bspw. bei TinyMacros für TinyFudge, das seit den 90ern von vielen gemeinsam erweitert wurde?

Zaphob: Gibt es manchmal neue Versionen von tf-Scripten, die irgendwo publiziert
 werden? Falls ja, wie verhalten sie sich gegenueber lokalen Aenderungen, die
 Spieler inzwischen gemacht haben? 

Bugfix: also die aktuellste version duerfte die aus chagalls finger sein
 wenn du standardfiles der tinymacros angefasst hast vertraegt sich das
 natuerlich nicht. 
 ich hab deshalb mal vor ein paar jahren alle aenderungen die ich gemacht hab
 aus dem standard-files der tinymacros rausgefummelt und in separate files
 verlegt, die ich durch eine aenderung von einer zeile in nem standard-file
 laden kann, so dass ein update nicht viel arbeit macht. 

Zaphob: OK letzte Aenderung vor ueber 5 Jahren, da kann man natuerlich lokal fleissig
 herumaendern ohne jemals Probleme zu haben, aber wie lief es als noch
 regelmaessiger Aenderungen publiziert wurden? Irgendwie muessen die ja dann
 wieder zusammengefuehrt werden? Oder ist jeder selbst fuer verantworlich, das
 einigermassen getrennt zu halten? 
 Genau so was zum Beispiel. 

Bugfix: keine ahnung, so lange spiel ich noch nicht, dass ich das erlebt haette :-)
 aber ich schaetze mal schon. 

Gulahr: na wenn man seine aenderungen nicht wieder hochlaedt muss man halt mit der
 konsequenz leben. wenn man es sauber trennt geht es ja. ansonsten kann man
 natuerlich glueck haben, dass sich die aenderungen dann nicht gegenseitig
 stoeren, andernfalls muss man es halt selbst reparieren. oder man holt sich
 nur bestimmte neuerungen, an denen man eben interessiert ist 

Zaphob: Das klingt schon so, als wuerde niemand wirklich auf die Idee kommen, in den
 Tinymacros herumzufummeln ohne das zu publizieren. Man kann vermutlich seine
 Aenderungen auch einfach gut daneben schreiben und laden, wenn sie
 einigermassen unabhaengig sind. 

Gulahr: ja, wenn man neue sachen schreibt kann man das gut auslagern. ansonsten ist
 es halt praeferenz. ich hab da soviel geaendert, dass ich einfach nicht auf
 die idee kommen wuerde, mir da neuerungen runter zu laden. oder halt nur sehr
 selektiv ;) 

[Kebap]

Welche Empfehlungen hat die Mudlet-Community für ähnlich gelagerte Fälle?

Leris: So how do your games cope with updating public Mudlet scripts? Are
scripts made publicly available at all, either by the game developers or by
other players maybe? If so, what happens when you use their scripts and modify
some, then they publish a new version? How do those two marry?

Vadi: The only games I've seen that officially provide Mudlet scripts install
them into Mudlet directly via atcp/gmcp extensions... the rest are player-made

jor'mox: Mine has all its public scripts stored as text files, and when a new
version of that file is made, the old version is overwritten. So it works by
ignoring what was done locally. ;)

Leris: I heard other players talking about "never touch the official files, only
put your extensions in sepeate files, included into the official code with a
single line, which can be added after update" - I feel this may be the most sane
solution, just not sure how that would fly in Mudlet context and/or scripts
provided directly from the game

Vadi: The better way is to have the official code raise Mudlet events for things
that players can hook into. That way, nobody has to mess with any code after
upgrading the official module. Looser coupling that way!

jor'mox: Well, yeah, I don't generally encourage people to mess with those
files, and I do have a number of ways they can hook into and leverage them to
accomplish what they want.

Leris: When I say files, this would also include Mudlet triggers, etc. displayed
in the GUI if they are provided / created as such by updating the script 

Vadi: Triggers - make your own triggers and have them call the functions from the
official script. Still no need to re-add anything It's totally workable as far
as I can see w/o the need to redo anything on upgrade, only if the official
script is setup in a way that allows for this

Leris: I just wonder how to best put the infrastructure down if a game wants to
start providing code and be both set up for future updates as well as giving
players room to add their own code in or next to the official code. Did not find
any documentation on that, yet, so asking around for experience

jor'mox: I do everything with temptriggers and aliases and such... so they can't
mess them up. Because of people changing the perm ones I had and then asking for
debugging help and forgetting about the changes...

Leris: I can totally see that point, on the other hand I hear people really dig
the created triggers and aliases as a starting base to read and write lua in the
first place

Vadi: Yeah, we don't have anything written with this. I'd say for triggers and
alises: provide functions people can call. For expanding functions: raise Mudlet
events. For GUI: use Geyser or simple window manager, and people can always add
to the containers in those frameworks.

jor'mox: If things are loaded as a module, and you replace the file the module
is loaded from, will that update properly in Mudlet? Or will it not be seen as
the same file?

Vadi: Rephase?

jor'mox: Okay, so Leris is asking about official code and such, with triggers
and whatever in the GUI. I hide them so people can't break things. But if the
official code was loaded via a module, and someone messed up one of their
triggers, it is going to change the code in the file that module is loaded from.
But if they replace that xml file with a backup version (or download a new
version from a server), will doing that fix the trigger they messed up?

Vadi: correct

jor'mox: That seems like it might be a decent middle ground.

Leris: So where can I watch this "updating of code from game via gmcp" in
effect? I wonder how it happens, is there a popup asking "Game has a new version
of code X, would you like to install?" If the user did not in fact mess up but
instead enhance the trigger in long hours of work, that status before update can
always be grabbed from profile history, right?

Vadi: midmud, luminari, midnight sun 2, a whole bunch of games do it if there is
an update, mudlet auto-updates without asking. the user has the option to turn
off auto-install / update in the profile

jor'mox: I would think the best suggestion to the players would be to move the
things that they have modified out of the module folder, so they aren't
overwritten. Then just remove the new copies in the folder after an update.