[Rel] Global Settings Interface (GSI) - für Spieler und Modder

Da der Grundgedanke dieses PlugIns in dieser Community entstanden ist, soll es auch diese Community sein, die das Ergebnis zuerst zu sehen bekommt. Spieler, die nach einem tollen R0xx0r-Item suchen, verlassen jetzt besser bitte gleich wieder diesen Thread. Modder von Questmods, großen Dungeons, Hausmods und vielen anderen Modarten sowie wirklich interessierte Spieler, die auch wenigstens ein wenig Interesse für die Dinge "hinter den Kulissen" haben, möchte ich bitten, diesen Text hier - auch wenn er verflucht lang ist - zu lesen. Bei diesem PlugIn ist nämlich der folgende Text deutlich wichtiger (und inhaltsreicher ;) ) als die eigentliche ESM-Datei.

Achtung, nun kommt viel Text...

Zitat:

---

Zitat von der Readme

Global Settings Interface (GSI)
Eine Schnittstelle für die Kommunikation zwischen PlugIns.
Eine Modifikation für The Elder Scrolls IV: Oblivion
Version 1.0: Teleport

1. Inhalt

(wird hier nicht zitiert, weil nur ein Inhaltsverzeichnis)

Hinweis: Wenn in dieser Datei von Mod oder PlugIn die Rede ist, ist ein und das selbe gemeint. Wenn von Dungeon die Rede ist, so ist damit in erster Linie ein Dungeon gemeint, weil es eben wohl das Haupteinsatzgebiet ist, das jeweils dort beschriebene gilt aber genauso gut für jeden anderen Ort, an dem der Spieler vom außerplanmäßigen Verlassen abgehalten werden soll.


2. Beschreibung

Dies ist das erste inhaltslose und trotzdem praktische PlugIn der Welt. Es tut selbst nichts - es ist dazu geschaffen, anderen PlugIns bzw. den Spielern, die sie spielen, zu helfen, indem es inhaltliche Probleme, die in der Kombination verschiedener PlugIns auftreten könnnen, aus der Welt zu schaffen versucht.

Das Grundproblem: Viele Modder verwirklichen in ihren PlugIns auch natürlich viele Ideen. Da kommt es mitunter vor, das eine für das eine PlugIn wichtige Komponente durch ein anderes PlugIn beeinträchtigt wird. In diesem Fall gehen wir einmal konkret vom Teleportieren aus. Weitere Einsatzmöglichkeiten sind natürlich möglich, aber momentan noch nicht implementiert. Also: Ein Questmodder erschafft einen wunderschönen, riesigen Dungeon und versperrt die Eingangstür, so das der Spieler diesen Dungeon erst verlassen kann, wenn er eine bestimmte Aktion durchgeführt hat. Sei es nun den Dungeon durchspielen und den Endgegner besiegen, einen Schalter betätigen oder auch nur eine bestimmte Zeit darin verbringen. Nun setzen aber die meisten Spieler mehrere PlugIns ein. Ein weiteres PlugIn ermöglicht dem Spieler, beispielsweise mittels Zaubersprüche Orte zu markieren und zu diesen jederzeit zurück zu kehren oder es wird ermöglicht, sich durch die Benutzung eines Items jederzeit zu einem bestimmten Ort - beispielsweise dem Eigenheim - zu teleportieren. Der Modder, der den Dungeon erschaffen hat, hat nun das Problem, das er aus technischen Gründen keinerlei Möglichkeit hat, Einfluss darauf zu nehmen, was die anderen PlugIns dem Spieler ermöglichen. Er kann also nicht sagen: hier in diesem Dungeon funktioniert dein Item oder der Rückkehr-Zauber nicht. Bestenfalls zerstört es nur die Atmosphäre, wenn der Spieler sich dennoch teleportiert, obwohl es nicht vorgesehen war. Schlimmstenfalls hingegen hat der Modder Bedingungen geschaffen, die es erfordern, das der Spieler an diesem Ort bleibt und ihn erst wieder verlassen kann, wenn er das dort getan hat, was der Modder vorgesehen hat. In diesem Fall kann es sogar zu schweren Bugs bis zu unspielbaren Questabschnitten kommen. Und hier kommt GSI ins Spiel. Die GlobalSettingsInterface.esm fungiert als eine Art Vermittler zwischen beiden PlugIns. Das QuestplugIn sagt der GlobalSettingsInterface.esm, das teleportieren hier nicht erwünscht ist, das PlugIn mit der Teleportationsmöglichkeit fragt, bevor es das Teleportieren ermöglicht, bei der GlobalSettingsInterface.esm an, ob teleportieren erlaubt sein soll.

Die GlobalSettingsInterface.esm enthält dabei eigentlich nichts weiter als eine globale Variable, die von dem jeweilen PlugIn gesetzt und vom anderen ausgewertet wird. Das führt dazu, das alles sehr übersichtlich bleibt und das auch Spielern, die überhaupt kein PlugIn mit Teleport-Funktion einsetzen, diese Masterdatei ohne Probleme aktiviert haben können. Und das hat letztlich wieder den Vorteil, das jeder Modder seinem PlugIn die GlobalSettingsInterface.esm beilegen kann/soll, wodurch dieses ganze Funktionsweise erst ermöglicht wird. Das Ganze ist natürlich ebenfalls völlig sprachneutral.

Praxis: Die Grundidee entstand, als sich ein Spieler im Forum meldete, den es störte, das er sich mit den Markieren & Rückkehr-Sprüchen aus Oblivion Improved aus einem Dungeon von Rungs Verbesserter Magiergilde teleportieren konnte. Zwar war uns das Problem generell bekannt, aber nie hat sich jemand daran versucht es zu lösen. Leider kann weder Oblivion Improved auf irgendetwas zugreifen, das sich nur in der Verbesserten Magiergilde befindet, noch umgekehrt. Also musste ich ein wenig umdenken und "brainstormte" ein wenig mit dem User, der das Problem auf den Tisch brachte. Da die Sache kein spezifisches Problem von Oblivion Improved oder der Verbesserten Magiergilde ist, sondern eines, das sehr viele PlugIns betrifft, war klar, das eine etwas globalere Lösung her musste. Nun liegt es an euch, den Moddern, dieses System, welches euch und euren Usern keinerlei Nachteile bringt, weitläufig zu unterstützen und den Spielern eurer PlugIns mit einem sehr geringen Maß an Mehraufwand genau das Spielgefühl zu geben, das ihr mit eurer Arbeit für sie vorgesehen hattet.


3. GSI für Spieler

Spieler spielen die Inhalte, die von Moddern erstellt werden jetzt so, wie die Modder sie auch geplant haben. Keine Ungereimtheiten mehr, weil man den eigentlich nicht verlassbaren Dungeon jetzt doch verlassen hat. Das mag für die einen erstmal ein Nachteil sein, für die anderen ist es ein Vorteil, weil die ursprünglich geplante Atmosphäre erhalten wird. Zu einem wirklichen Vorteil wird es aber für alle spätestens dann, wenn man plötzlich mal einen solchen Dungeon verlassen hat, man aber - weil der Modder eben das nicht eingeplant hat - nicht wieder hinein kommt oder gar ein NPC draußen auf einen wartet, der sich dafür bedankt, wie gut man seine Aufgabe in Dungeon xyz gelöst hat - dabei war man dort noch garnicht fertig... mit dieser Komponente gehören solche Dinge der Vergangenheit an, sofern die Modder bereit sind, die paar minimalen Änderungen, die erforderlich sind, umzusetzen. Fragt doch einfach den Autor eines Mods, den ihr mögt und der genau dieses Problem hat, ob er nicht bereit wäre, sich - ohne viel Aufwand - mal die 5 Minuten Zeit zu nehmen und seinen Mod auf diese Art "abzusichern". Es sollte auch in seinem Interesse sein, denn jeder Modder will, das man seine Inhalte so erlebt, wie er sie sich vorgestellt hat. Und wenn ihr einen Mod einsetzt, der euch das Teleportieren auf irgendeine Art ermöglicht? Schreibt den Autor an und sagt ihm, das es nun eine sehr einfache Möglichkeit gibt, dafür zu sorgen, das sein Mod die Mods der anderen in dieser Hinsicht nicht mehr negativ beeinflusst. Weder für den Spieler noch den Modder entstehen irgendwelche Nachteile. Wird vom Spieler keine andere Mod eingesetzt, bei dem die GlobalSettingsInterface.esm irgendetwas vermitteln müsste, tut sie auch einach garnichts. Wenn alles läuft wie geplant, werden viele Mods diese Datei zukünftig mitliefern. Der Spieler kann die dann jeweils überschreiben oder auch nicht, was keine Rolle spielt, da jede Datei gleich sein wird und die GlobalSettingsInterface.esm natürlich nur einmal für eine quasi unbegrenzte Anzahl Mods benötigt wird. Ihr solltet als Spieler einfach nur darauf achten, die Datei GlobalSettingsInterface.esm - egal woher ihr sie bezogen habt, unter Zusatzdateien aktiviert zu haben. Dann läuft alles wie es soll - der Rest ist Aufgabe der Modder. Für euch heißt es: aktivieren -> vergessen -> die Vorteile genießen.


4. GSI für Questmodder, Dungeonmodder u.s.w.

Für die Modder von Quests ist die Verwendung von GSI eigentlich sehr einfach. Zuerst muss die GlobalSettingsInterface.esm zusammen mit eurer ESP-Datei im Construction-Set geladen werden. Euer PlugIn muss dabei auf "Active File" gesetzt werden. Danach noch abspeichern und der erste von zwei Schritten ist getan: eure ESP hat die Abhängigkeit zu GlobalSettingsInterface.esm-Masterdatei und kann somit auf ihre globalen Variablen zugreifen. Davon gibt es momentan genau eine - eben die, die für den Teleport zuständig ist. Diese globale Variable heißt GSITeleport und sie kann drei mögliche Werte haben:

• 0 - Teleportieren komplett verboten
• 1 - Teleportieren komplett erlaubt (Standardeinstellung)
• 2 - Teleportieren nur innerhalb des selben Interiors erlaubt *

* Bei Wert 2 ist noch zu beachten, das nur die allerwenigsten PlugIns davon Gebrauch machen. Im Regelfall werden die meisten "Teleport-PlugIns" dann also das Teleportieren komplett verbieten, auch wenn es eingeschränkt erlaubt wäre.

Nun überlegt einmal, wie ihr den Spieler daran hindert, euren Dungeon zu verlassen. In 99% der Fälle nutzt ihr dafür ein Script. Erweitert einfach die Bedingung, in der festgelegt ist, das der Spieler den Dungeon nicht verlassen kann um folgende Zeile:

Set GSITeleport to 0

Damit schaltet ihre die Teleportfunktion von allen GSI-unterstützenden PlugIns aus. Der Spieler muss nun genau das tun, was ihr für ihn geplant hattet.
Ganz wichtig: vergesst bitte keinesfalls am Ende eures Dungeons, wenn der Spieler ihn also verlässt/verlassen kann, die Variable mit

Set GSITeleport to 1

wieder zurückzusetzen. Andernfalls ist das Teleportieren dauerhaft - auch außerhalb des Einflussbereichs eures PlugIns - deaktiviert. Für einen Modder sollte das setzen dieser zwei Variablen nun aber keinerlei Problem darstellen und mehr ist für euch nicht zu tun. Also nochmal kurz zusammengefasst:

• Abhängigkeit zur GlobalSettingsInterface.esm herstellen, indem diese zusammen mit eurem PlugIn geladen und dann gespeichert wird. Euer PlugIn muss hierzu als "Active File" geladen werden.
• GSITeleport-Variable zur Situation passend mittels einem eurer Scripte auf einen der drei möglichen Werte stellen

Nun packt ihr die GlobalSettingsInterface.esm noch mit in das Download-Archiv eures Mods und erwähnt in der Readme, das der Spieler sie, falls er sie noch nicht von einem anderen Mod bezogen hat, unter Spieldateien im Launcher genauso aktivieren muss wie euer eigentliches PlugIn. Fertig! Mehr gibt es für euch nicht zu tun. War doch einfach, oder?


5. GSI für Modder, die Reise- oder Teleportmöglichkeiten jeder Art bereitstellen

Für Modder von PlugIns mit Reise- und Teleportmöglichkeiten ist der Einbau ebenfalls sehr einfach und ohne größeren Aufwand. Dabei ist es völlig egal, ob man in eurem PlugIn - wie beispielsweise mit Mark & Recall (Markieren und Rückkehr) an verschiedene Orte reisen kann oder ob ihr beispielsweise nur für eure "HausplugIn" einen Gegenstand oder Zauber erstellt habt, der den Spieler bei Benutzung schnell nach Hause bringt. Alles ganz einfach, allerdings gibt es hier für euch - je nachdem, wie euer Script aufgebaut ist - ein paar mehr Möglichkeiten, die Sache umzusetzen als für die Quest-/Dungeon-Modder. Der erste Punkt allerdings unterscheidet sich nicht von obriger Anleitung für die "Dungeon-Bauer". Ladet euer PlugIn als "Active File" zusammen mit der GlobalSettingsInterface.esm ins Construction Set und speichert das ganze einmal ab, um die Abhängigkeit zur ESM herzustellen, damit ihr Zugriff auf die globale Variable GSITeleport bekommt. Ist das erledigt, müsst ihr in eurem Teleport-Script eine Abfrage einbauen, die auswertet, ob das Teleportieren möglich sein soll oder nicht. Der einfachste aller möglichen Wege wäre beispielsweise der folgende Dreizeiler:

If GSITeleport == 0
return
endif

oder, falls euer PlugIn keine Funktion bietet, innerhalb einer Zelle hin- und herzuteleportieren (was wohl für 99% aller solchen PlugIns gelten dürfte)

If GSITeleport == 0 || GSITeleport == 2
return
endif

Das baut ihr am besten direkt am Anfang eures Scriptes ein. Natürlich steht euch jeder andere Art der Implementierung frei. Dieses Beispiel verdeutlicht nur den einfachsten, aber nicht unbedingt den besten Weg. Aber ich denke, wer in der Lage ist, ein funktionierendes Teleport-Script zu schreiben, sollte es auch mit Leichtigkeit schaffen, diese kleine Bedingungsabfrage zu integrieren. Wichtig ist nur, folgende Regeln in seinem Teleportscript korrekt umzusetzen.

• GSITeleport=0 - Teleportieren komplett verboten
• GSITeleport=1 - Teleportieren komplett erlaubt (Standardeinstellung)
• GSITeleport=2 - Teleportieren nur innerhalb des selben Interiors erlaubt *

Ist das erledigt, könnt ihr euch entspannt zurücklehnen, denn das war es schon. Kurz zusammengefasst:

• Abhängigkeit zur GlobalSettingsInterface.esm herstellen, indem diese zusammen mit eurem PlugIn geladen und dann gespeichert wird. Euer PlugIn muss hierzu als "Active File" geladen werden.
• GSITeleport-Variable auslesen und je nach gesetztem Wert euer Teleportscript entweder ablaufen lassen oder unterbinden.

Nun packt ihr die GlobalSettingsInterface.esm noch mit in das Download-Archiv eures Mods und erwähnt in der Readme, das der Spieler sie, falls er sie noch nicht von einem anderen Mod bezogen hat, unter Spieldateien im Launcher genauso aktivieren muss wie euer eigentliches PlugIn. Fertig!


6. Zukunft

Nun, in der Theorie ist die Sache, die hier bisher nur für den Teleport umgesetzt wurde, für jede Situation denkbar, in der sich zwei PlugIns wegen ihrer unterschiedlichen Funktionen negativ beeinflussen, solange diese Funktionen in irgendeiner Weise gescriptet sind oder sich zumindest mittels Scriptbefehlen beeinflussen lassen. In der Praxis wird schlicht das eingebaut, was von den jeweiligen Moddern gewünscht wird. Sollte es Erweiterungen/Aktualisierungen der GlobalSettingsInterface.esm geben, so wird auf jeden Fall eine 100%ige Abwärtskompatibilität sichergestellt sein. Der Name an sich suggeriert natürlich, das es nicht bei dieser einen Funktion bleiben muss - deshalb wurde er so allgemeingültig gewählt. Ein Versionsabgleich - sollten Funktionen hinzukommen - wird natürlich implementiert.


7. Verbreitung & Modifikation von GSI

Jeder Modder darf/kann/soll die "GlobalSettingsInterface.esm"-Datei mit seinem PlugIn ausliefern - ansonsten wäre sein PlugIn durch die hinzugefügte Abhängigkeit auch nicht mehr oder nur noch teilweise funktionsfähig. In diesem Fall müssen keinerlei Credits in irgendeiner Form gegeben werden und die Dokumentation (sprich: diese Datei) kann, muss aber ebenfalls nicht, beigelegt werden. Macht das ganz wie ihr möchtet. Der Dateiname der ESM sollte allerdings unter keinen Umständen geändert werden (sonst hat ein User vielleicht irgendwann 20 dieser Dateien im Data-Ordner, was absolut unnötig wäre). Die ESM-Datei als auch die hier vorliegenden Dokumentation ist mit ihrer Veröffentlichung Community-Eigentum, was ihre Verbreitung betrifft. Eigene Modifikationen/Erweiterungen sind allerdings - da es sich ja um eine generelle Schnittstelle handeln soll - nicht erwünscht. Würde jeder Modder die Datei erweitern, wie es ihm gerade gefällt, hätten wir bald unzählige davon und der eigentliche Sinn des Projektes wäre dahin. Deswegen schlage ich vor, Erweiterungen/Änderungen - sofern gewünscht - gemeinsam zu diskutieren und umzusetzen. Die richtige Adresse dafür ist meist das Forum, in dem ihr von diesem Projekt erfahren habt. Desweiteren ist es ausdrücklich erlaubt, die Datei GlobalSettingsInterface.esm und diese Readme-Datei auf jeder Webseite zum Downlaod bereitzustellen. Sofern sie aber nicht mit einem PlugIn zusammen ausgeliefert wird, das Gebrauch von ihrer "Funktion" macht, sondern eben nur GSI "Stand-Alone" ist dringend anzuraten, diese Readme-/Dokumentationsdatei mitzuliefern. Was sollte ein User auch mit der reinen ESM ohne eine Ahnung, welchen Sinn sie hat?!

---

Links zum Thema:

• Wie die Idee entstand...
• Download (6,25 KB)
• Readme in Originaldarstellung

Ich biete jedem Modder, der den Einbau trotz der Anleitung nicht hinbekommt, meine Hilfe an, obwohl ich dieses Projekt eindeutig nicht als "mein Projekt" ansehe, sondern als Geschenk an die Community. Desweiteren wird Oblivion Improved natürlich ebenfalls dieses System unterstützen und ich hoffe, das viele weitere Autoren ebenfalls darüber nachdenken, denn bis auf 5 Minuten eurer freien Zeit kostet das niemanden etwas und die Vorteile des - eigentlich sensationell primitiven Systems - sollten für Modder, gerade wenn sie mit ihren Mods Atmosphäre schaffen wollen, auf der Hand liegen. Anzumerken ist noch, das die GlobalSettingsInterface.esm gerade einmal 343 Byte groß ist und somit den Download eures Mods quasi garnicht vergößert. Für sämtliches Feedback und neue Ideen zur Erweiterung ist hier der richtige Platz :)

(Und falls sich nun jemand fragt, ob das wirklich hier her gehört... wie ich es auch tat und mir deshalb vorher die Auskunft/den Segen bei einem Moderator abgeholt habe: Es ist nunmal in der Tat ein fertiges PlugIn - auch wenn das nicht der wichtigste Part dieses Projektes ist... deshalb ein Release-Thread und nicht ein irgendwas in der Schmiede, zumal es für Spieler auch ab dem Moment interessant ist, wo die ersten PlugIns es nutzen :) )

Find ich ist echt toll, die Idee: Werde das auf jeden Fall in meine Mod(s) einbauen und habs auch schonmal hochgeladen. Hier! Danke NewRaven für dieses wirklich schöne Geschenk. :)
Ich appeliere an alle Modder diese Möglichkeit zu nutzen und uns allen den Moddingalltag zu erleichtern.

Sehr feine Sache. Vielleicht könnte man den Thread pinnen damit das auch zukünftige Modder schnell finden die womöglich nicht auf die Idee kommen sowas zu suchen.

GSI Cyrodiil :D

Wäre das möglicherweise eine Sache, die in das COBL Projekt integriert werden könnte/sollte?

Übrigens wären noch weitere Möglichkeiten denkbar:
Beispielsweise könnte man auch eine "Steuerung" für Companions einbauen, so das ein Modder Einfluss darauf hat, ob sein "Content" mit Begleiter betreten werden kann oder ob der Begleiter draußen warten muss. Es ist etwas sonderbar, wenn einem ein Mod in eine andere Dimension versetzt, weil man "der/die Auserwählte" ist, und plötzlich seine drei Companions hinter einem stehen... :rolleyes:

Selbst wirkliche Konflikte könnte man lösen: Nehmen wir mal an, der Spieler hat zwei Vampirmods aktiv, die technisch unterschiedlich sind und an sich nichts miteinander zu tun haben, sich aber in einem kleinen Teilbereich überlappen:

Sagen wir: Mod 1 lässt Vampire fliegen, aber das kostet 25 Ausdauerpunkte pro Sekunde.
Mod 2 macht das auch, allerdings kostet Mod 2 beim fliegen nur Ausdauer, wenns dazu noch regnet - sagen wir mal 30 Punkte. In beiden wird das ganze über ein jeweils eigene globales Script gesteuert.

Was passiert nun, wenn der Spieler beide Mods einsetzt und bei Regen draußen rumfliegt? Richtig, er ist 55 Ausdauerpunkte los. Mit einer kleinen Erweiterung in GSI kann man aber dafür sorgen, das die Mods prüfen können, ob ein anderer Mod aktiv ist, der diesen Bereich modifiziert. Und dann kann man schlicht eine Abfrage einbauen, in der man das Problem umgeht - selbst ohne den anderen Mod selbst überhaupt zu kennen. Ich wette, 80% aller inhaltlichen Konflikte von PlugIns könnte man so beseitigen. Ihr seht, die Möglichkeiten sind schier unbegrenzt. Nur müsste das Ganze dazu eben auch genutzt werden.

@kenet_korva: Danke, ich editiere gleich mal den Download-Link im Startposting :)

@DWS: Nein, Wrye sieht COBL als eine Art Ressource. Das heißt, da kommen schlicht Inhalte rein, die vom Originalspiel völlig unabhängig sind, aber dennoch als Resourcen von vielen Mods genutzt werden. Neue Bücher, Pflanzen, Scripte u.s.w. Während COBL eher sowas wie eine DLL unter Windows ist, wäre GSI eher sowas wie die Registry oder besser sogar eher sowas wie eine Ini-Datei. Leider hat Wyre sogar abgelehnt, MOBS in COBL zu integrieren, was meiner Meinung nach wirklich ungemein praktisch gewesen wäre.

Zitat:

---

Zitat von NewRaven

Es ist etwas sonderbar, wenn einem ein Mod in eine andere Dimension versetzt, weil man "der/die Auserwählte" ist, und plötzlich seine drei Companions hinter einem stehen... :rolleyes:

---

Ach was, das sind eben die Auserwählten des Auserwählten. :D

Spaß beiseite:
NewRaven, genial! ^_^
Vielen Dank für dieses Geschenk an die Community! Eine ganz feine Sache!

Zitat:

---

Zitat von GreyWolf

Ach was, das sind eben die Auserwählten des Auserwählten. :D

---

Das ist genauso eine Paradoxon wie ein "böser Paladin" ;) Es kann natürlich immer nur einen Auserwählten geben, sonst nennt man das nämlich "ein Lucky-Looser Hobbit und seine Gefährten auf dem Weg die Welt zu retten" :D

Übrigens: Wenn ihr in einem anderen Forum oder auf einer anderen Seite über GSI berichtet - was ich im übrigen nett fände ;) - so schickt mir doch bitte eine PN mit dem Link. Ich möchte gern dazu eine kleine Linkliste erstellen, genauso wie eine Auflistung der Projekte kommen wird, die GSI nutzen :) Danke :)

Hallo Rabe,

eine großartige Idee ist das. Die einfachsten Ideen sind eh immer die besten. Ich werd mich gleich mal dran setzen und ein paar GSI-Änderungen vornehmen.

Tolle Sache das.
Mein Gott, bin ich froh, daß ich nur Klamotten baue. ;) Das Scriptgefrickel fehlte mir noch. :D

Leider befürchte ich, daß viele Mods davon nicht profitieren werden, teils weil sie fertig released sind und der Modder von der Bildfläche verschwunden (haz mark & recall), teils weil ein erneutes Release mit den geänderten Dateien das Publikum nicht mehr erreicht (Realms of Ruun) oder weil das Publikum die geänderte Mod einfach nicht mehr wahrnimmt (weil sie bei TESsource inzwischen auf Seite 687 auftaucht).

Trotzdem hoffe ich, daß solche globalen Settings verstärkt Einzug in die Mods halten.

Zitat:

---

Zitat von NewRaven

Während COBL eher sowas wie eine DLL unter Windows ist, wäre GSI eher sowas wie die Registry oder besser sogar eher sowas wie eine Ini-Datei.

---

Die Registry oder Ini-Datei wird aber normalerweise nicht während der Laufzeit geändert, wie beim GSI. Die Global Settings dienen doch der Kommunikation 2er Mods (Teleport-Mod mit Quest-Mod) während der Quest.


Koordinaten-Übergabe-Vorschlag :

Eine weitere Möglichkeit der Parameterübergabe wäre die Einführung eines TeleportMarkers zur Zwischenspeicherung von Marker-Koordinaten. Damit kann 1 Mod dem anderen Mod 'seine' Markerkoordinaten übergeben und muß keine spez. Zugriffe auf die RefID eines anderen Mods machen.

So könnte z.B. ein Kvatch Mod eine Teleportverbindung mit einem Magiergilden-Teleport-Mod initialisieren indem in der Magiergilde des KvatchMods ein Script den GSIMarker auf 'seinen' Kvatch-Magiergilden-Teleportmarker setzt und danach ein Aufruf eines Scripts des Magiergilden-Mods den GSIMarker nutzt um 'seinen' Magiegilden-Teleport-Zielmarker-für-Kvatch darauf einstellt.

Einfachstes Protokoll :

1) Spieler reist zur Magiergilde im neuen Kvatch und aktiviert dort ein 'Koordinaten-Geber'-Skript.

2) Spieler reist zurück zu einem Teleportaktivator aus dem 'Magiergilden-Teleport-Mod' und aktiviert dort das 'Koordinaten-Empfänger'-Skript.

Danach kann der 'Magiergilden-Teleport-Mod' (ich denke da an Rungs VM) die Verbindung Magiergildenhallen->KvatchMagiergilde nutzen.

Mit diesem Prinzip kann man sich schrittweise ein Teleportnetz zwischen völlig unterschiedlichen Gebiets-Mods aufbauen, die sich nicht einmal kennen müssen. Vorraussetzung ist nur, daß jedes Mod die entsprechenden 'Koordinaten-Geber' und 'Koordinaten-Empfänger' Skripts verwendet und genügend Teleport-Marker intern reserviert hat (VM müßte also eine Teleportoption für Kvatch reservieren, während das Kvatch-Mod nur dorthin teleportieren kann, wo es ebenfalls Ziele dafür reserviert hat - bei nur einem Ziel wäre das dann whrscheinlich die magische Uni).

Der Spieler muß die entsprechenden Orte in der exakten Reihenfolge aufsuchen (sonst kann er z.B. ein Kvatch-Portal mit einem Dunkelwasser-Portal falsch verbinden). Da Globals keine Strings enthalten läßt sich sowas kaum durch If-Abfragen verhindern.

EDIT :
Ach ja, das einzige was also GSI bräuchte wäre der Marker : GSIMarker

Die Skripte sind Mod-spezifisch

Du zielst am Ziel eindeutig vorbei. Und nebenbei bemerkt ändert sich die Registry und auch früher die Ini-Dateien natürlich zur Laufzeit des Programms. Dafür sind sie da... ^^

GSI stellt eine nicht gesetzte Variable bereit, auf die die Mods, aufgrund ihrer Abhängigkeit zu ein und der selben ESM alle Zugriff haben. Was nun wann mit dieser Variable geschieht, obliegt den Moddern, die sie verwenden. Das kann und soll nicht die Aufgabe dieses Projektes sein. Die Änderungen erfolgen durch die Mods, die davon Gebrauch machen und werden zur Laufzeit eben im Speicher und danach im Savegame gehalten. Das Prinzip, das du erklärt hat, ist schön und gut und GSI ist für diesen Zweck ebenso sicher eine große Hilfe, aber es obliegt nicht GSI das so umzusetzen, sondern dem Modder, der eben dieses Transportplugin erschafft. GSI macht nichts weiter, als Zahlen speichern (eben die Werte) und diese anderen PlugIns zugänglich zu machen. Eben Kommunikation zwischen den PlugIns. GSI ist keine Ressource für irgendwas - und genau das ist auch der Punkt, der es neben dem Inhalt, deutlich von COBL unterscheidet.

Edit: Das mit der Marker-Variable lässt sich problemlos einrichten und entspricht auch durchaus der "Zielgruppe" - nur muss sich erstmal ein Modder finden, der es braucht. Was niemand nutzen will, wird auch nicht eingebaut :)

Hallo,

ich glaube, dass Einfachste ist es im Falle des Kvatchdings, eine zweite *.esp-Datei des eigenen Plugin (in meinem Fall die VM) beizulegen, die der Spieler aktivieren kann, wenn er Kvatch Tomorrow laufen hat.
Hm, vielleicht sollte ich mit solchen Sachen das nächste Mal warten, bis das betreffende Plugin erschienen ist.^^

@NewRaven :

Das GSI soll ja gar nichts machen, außer einzig und allein den GSIMarker bereitstellen. Nur damit lassen sich doch sinnvoll Marker-Postionen/Koordinaten übergeben. Normale Globals helfen da nicht.

Die ganze Sache mit der Übergabe erledigen die jeweiligen Mods. Ich wollte nur einen Weg aufzeigen, wie die Modder mithilfe eines einzigen Markers ein völlig Mod-unabhängiges Teleportnetz aufbauen können.

Eine Idee wäre es auch, Mods zu erlauben, Informationen gegenseitig auszutauschen, so dass man dann z.B. in einem Hausmod abfragen kann, ob der Spieler Blood & Mod fertig hat, um dann ein paar NPCs Kommentare dazu abgeben zu lassen. Oder in Item als "Trophäe" zu markieren, dass dann automatisch in die Erinnerungshalle kommt, etc..

Man könnte eben im GSI ein paar hundert (o.O) ungesetzte Variablen belassen, die dann auf Nachfrage einer Mod zugeteilt werden.

Und welcher Mod wäre so 'erlesen' seine eigene(n) Globale(n) im GSI zu bekommen ? Da bräuchte man 100e oder 1000e um keinen exquisiten Club draus zu machen. :eek:

Vielleicht geht es aber in einem seperaten QSI (QuestStatusInterface) ? Wo nichts weiter enthält als Globale zu allen denkbaren wichtigeren Quests von allen größeren Mods. Und du bräuchtest jemand, der sich die Arbeit macht das alles aktuell zu halten. Aber wer weiß ?

@NewRaven:
Wo liegt denn eigentlich die Variablengrenze für die Engine - Weißt du da was ? (Oder irgendjemand sonst). Vielleicht sind ja 100e weitere Globals bereits schon zuviel.

@Xartas_Nobody: Nun, wenn sich zwei Mods finden, die sich auf ihre Existenz gegenseitig überprüfen wollen ist das sicher Problemlos möglich, ja :) Was Blood & Mud angeht hatte ich ja eh gehofft, das Ryan sich GSI mal ansieht, denn da gäbe es einige Stellen, wo GSI schon allein wegen dem Teleport Sinn machen würde.

@Scanner: Keine Ahnung... aber genau deshalb wird ja auch nur das eingebaut, was wirklich gebraucht wird

@Xartas_Nobody & NewRaven :

Ich habe gerade überlegt, ob man nicht eine Faction für diesen Zweck mißbrauchen kann.

Factions lassen über 255 Ranks zu und man kann jedem Rank einen Namen geben. Damit läßt sich ideal eine Tabelle von erledigten Quests bauen. Und es ist nur eine einzige Faction dafür nötig.

EDIT :
Geht aber doch nicht wie gedacht. Man könnte höchstens noch jeder Quest einen Quest-NPC geben, dem man per Faction den Rang ändert. Ich nehme aber an, daß ein NPC, selbst wenn er nie auftritt, das System mehr belastet, als eine Global.

Sieht so aus als müßt ich für meine Idee alles selber machen. :rolleyes: Ich habe jetzt mal provisorisch meine Idee durch Modifizierung von Rungs VM-Teleportskripte ausgetestet (es hat funktioniert :D ) und mir ist folgendes aufgefallen :

1) Statische Marker zum variablen Teleportieren sind eine gaaanz schlechte Idee. Sie lassen sich nämlich nicht über Zellgrenzen hinweg bewegen. Ich habe dafür die Aktivatoren von NewRaven nach dieser Mark&Recall-Methode verwendet. Damit geht es problemlos. Für feste Teleporterziele läßt sich auch weiterhin die normalen Marker verwenden, nur kann ja die Ersetzung der stupiden Marker durch Aktivatoren nicht schaden. Ich würde jedem Teleportersteller zusätzlich die Aktivatoren empfehlen - es erlaubt nachträgliche Rekonfiguration und intermod-operable Netzdynamik.

2) Alles was ich als Zwischenspeicher in einem GSI oder COBL oder was auch immer benötige um Teleportziele umzulenken und ein intermod-operables Teleportnetz aufzubauen, ist ein Teleport-Aktivator zur Übernahme von Zielen eines Mods von einem arnderen Mod. NewRaven könnte allerdings sagen ob er es als Schnittstelle haben will oder eher als gemeinsame Resource a la COBL sieht. Immerhin benötigt der Aktivator eine Existenz in einer 'Heimatzelle'.

3) Die nachträgliche Veränderung im Skript ist minimal. Bei Rung mußte ich für jedes der Stadt-Teleport-Skripte nur wenige Zeilen ändern :

a) Ist das justierte Ziel auch wirklich entfernt ? :
Zuerst wird die Distanz des GSI-Aktivators zum örtlichen festen Marker in 1-2 Anweisungen festgestellt.

b) Justierung des dynamscihen Zielpunktes auf entweder auf ein unbekanntes Neuziel oder dem fixen Zielmarker + Sprung bzw. der Ablehnung :
Bei echter Distanz und einmaligem Vorgang bzw. nach einem Rekonfigurationsreset (durch Variable kontrollieren) wird ein vom Mod bereitgestellter Ziel-Aktivator auf den GSI-Aktivator bewegt (nach Aktivierung der Zieleingabe im Menü). Der Spieler springt anschließend zum GSI-Aktivator. (für jedes Ziel also eine extra if-condition statt dem Sprung)

c) Das eigene Feld als neuen Zielpunkt markieren :
Anstelle des nicht-teleportieren Menüpunktes erfolgt ein "neuen Zielpunkt festlegen" Prozess, d.h. einfach den GSI-Aktivator auf den örtlich festen Marker justieren. Da auch hier nicht gesprungen wird, braucht man auch keinen neuen Menüpunkt. Das ganze sind die für einen Aktivator übliche 2 Anweisungen (set active & moveto).

Daher mein Angebot an Rung :

Ich übernehme dir gerne die Arbeit der Anpassung deines statischen Teleportnetzes an ein intermod-dynamisches und rekonfigurierbares Teleportnetz. Für deine VM wird in einem ersten Schritt benötigt :

- Einen dynamischen Kvatch-Teleport-Aktivator (Skript siehe NewRavens Mark&Recall nicht vergessen)
- einen GSITeleport-Activator im GSI (das müßte allerdings von NewRaven kommen)
- das Umschreiben der Stadt-Teleport-Skripte (kann ich übernehmen)

Für den Kvatch-Mod wird benötigt :

- eines deiner modifizierten Stadtskripte für die Kvatch-Magiergilde (kann ich auch schreiben), lieferbar an Bulle (wenn du mit ihm Kontakt hast).

In einem späteren Schritt, kann man ja noch mehr Stadt- bzw. Gildenziele aufnehmen oder zu jedem Gildenmarker einen bewegbaren Teleport-Aktivator hinzufügen um das Netz rekonfigurierbar zu machen.

So das wars. :) Bin dankbar für jede Resonanz.

Hallo Scanner,

ich bin wirklich begeistert, wieviel Herzblut Du in diese Idee legst und mit was für Lösungen Du auftrumpfst, aber (ja, es gibt immer ein Aber) im Moment sieht es so aus, dass ich von dem Bullen (Autor der Kvatchmod) seit einer Woche nichts mehr gehört habe und ich bis jetzt überhaupt nicht weiß, ob es überhaupt eine Magiergilde in Kvatch geben wird. Das obliegt immer noch ihm selbst. Ich kann nur sagen, dass es mich freuen würde, wenn er mitmachte.

Ich möchte das lieber erstmal mit dem Bullen abklären, bevor wir uns hier extra Arbeit machen. ;) Außerdem habe ich erwähnt, dass mir eine direkt abhängige *.esp-Datei, die die User dann nutzen können, wenn sie auch die Kvatchmod installiert haben, im Moment besser gefällt.
Was ja nicht hieße, dass Deine Arbeit umsonst gewesen wäre. :) Wenn ich die Zeit finde, werde ich Deine Erkenntnisse dankend in die Mod aufnehmen. Meine Entscheidung zu der endgültigen Lösung des "Problems" ist noch nicht gefallen.
Fakt ist aber, dass ich im Moment am Drachenorden arbeite und nur ungern andere an mein Plugin lasse, ungeachtet Deiner Fähigkeiten, die ich damit keinesfalls in Frage stellen will. :)

Jetzt hab ich noch einen anderen Punkt (@NewRaven):

Eine alternative Variante zu den Teleport-Rechte-Globals wäre eine Teleport-Rechte-Faction mit den 3 Rängen, welche den Rechten entsprechen. Die Beschreibung der Rechte kommt dann auch noch gleich lesbar im CS selbst mit.

Ich hoffe NewRaven du siehst das nicht als Querschuß. Aber solange das Projekt noch jung und unbenutzt bzw. kaum benutzt wird, läßt sich vielleicht noch eher Weichen stellen. http://www.multimediaxis.de/images/s.../1/gruebel.gif

Im Grunde genommen ist es egal, ob man den Player eine Teleportrechte-Faction gibt und die Rechte über das Abprüfen der Ränge bewältigt, oder über Globals. Globals sind schneller in der Anwendung, aber die Factionhandhabung ist nicht zu langsam für den Zweck und erlaubt zusätzlich eine Rechtevergabe an etwaige geskriptete NPCs mit Teleportfähigkeiten. Ich seh zwar niemand, der es derzeit nützen könnte, aber wenn erst mal jeder Globals verwendet und hinterher jemand einen Nutzen findet ist es aus und vorbei mit einer nachträglichen Umstellung.

Also was ist - :A oder :B ?

Wenn ich mich hier auch mal dazwischendrängen dürfte. :D
Die Globals können genauso viel wie die Factions (soweit ich das überschauen kann). Die Globals kann man zudem leichter in Dialogen oder Tagebucheinträgen unterbringen, außerdem sind sie leichter zu handhaben, da Factions auch immer einen Actor brauchen. Die Spieler selbst hierfür zu missbrauchen, fände ich keine sehr gute Lösung.
Just my 2c.

Den Punkt mit der Unterbringung in Dialogen und Tagebucheinträgen habe ich nicht bedacht und spricht stark für die Globals (Vorrausgesetzt es geht mit den Factions nicht).

Der einzige Actor der derzeit in Anspruch genommen würde wer der Spieler, dem man eine Faction (geht doch Unsichtbar, oder ?) mit Rang verpasst. Was genau ist hier der Nachteil ?



Natürlich gibt es die Alternative Mischung : Der Player wird per Globals gesteuert und die anderen NPCs per Faction. Da noch niemand die NPC-Lösung braucht bliebe alles beim alten.

Nur wegen der später schwer machbaren Umstellbarkeit des Systems, wenn es bereits von mehreren Mods verwendet würde, sollte man schon früh Klarheit für die Player-Lösung haben.

Wenn sich die fehlende Machbarkeit mit den Dialogen und Tagebucheinträgen bei Factionranks bestätigt, sag ich selbst zur Player-Faction-Lösung :B

Mir kam gestern eine Idee, die man eventuell in einer späteren Version einbauen könnte.
Folgendes: Es gibt inzwischen ja diverse Mods, die Bedüfnisse und Ähnliches ins Spiel einfügen.
Andererseits gibt es aber auch Mods, die neue Welten einfügen in denen dieses System aber nicht inkludiert ist. Was macht also Character 1 mit Durst in Welt A ohne passendem Brunnen? Er geht ein.
Daher wäre eine Variable für solche Bedürfnisse sicherlich nüzlich

Der Gedanke ist gut - ich hab da auch noch ein paar Dutzend ;) Sehr nützlich, aber wie bei allem anderen gilt: eingebaut wird nur, was auch wirklich benutzt wird. Solange also kein Modder eines solchen Mods eine derartige Funktion anfragt, die dann auch garantiert umgesetzt wird, kommt dafür auch keine Variable rein. Sinnvoll wäre die von dir genannte Abfrage in jedem Fall. Bastel ich da jetzt auf gut Glück jede "Idee" rein, die dann aber nie verwendet wird, hab ich am Ende 200 Globals verschwendet... das möchte ich gern vermeiden, ich hoffe, du verstehst das :)

@Scanner: Daumen runter ;) Es macht einfach schlicht keinen praktischen Sinn (auch wenn man Factions auch per Script u.s.w. abfragen kann). Erstens ändert es den Player selbst, wogegen ich schonmal strikt bin, zweitens Beamen NPCs ja für gewöhnlich nicht lustig einfach so durch die Gegend, sondern tun das immer in irgendeinem bestimmten Verhältnis zum Player. Und für den haben wir eine Variable. Der Rest liegt am (hoffentlich schlauen) Scripter ;)

@NewRaven :

Ich hab noch mal über Aktivatoren und ihre mögliche Verwendung im GSI nachgedacht.

Theoretisch sollte das GSI nur Globals haben. Das wäre die sauberste Lösung und andere Objekte wie Activators (die zudem mind. eine Zelle benötigen) würden eigentlich nur stören.

Dummerweise hat Bethesda durch seine Restriktionen auf Zahlen (short,long,float) und den Verzicht auf Strings oder noch besser IDs die Funktionalität einer Mod-Kommunikation drastisch eingeschränkt.

Aktivatoren hingegen passen zwar nicht ganz ins reine Konzept, aber ich habe bis jetzt 2 Vorteile gefunden, welche mit den Globals nicht gehen :
- Der Koordinatentransfer (nicht nur die Achsen, sondern gerade die unbekannten, nicht per Globals transferierbaren Zell-IDs - natürlich indirekt)
- Die Möglichkeit einen WorldSpace zu bereichern, ohne damit in Konflikt bereits existierender Zellen zu geraten. Ob das Überdecken von Modellen damit möglich ist, weiß ich allerdings noch nicht.

Jetzt die Grundsatzfrage. Würdest du die Aktivatoren reinnehmen, wenn sich der Verwendungszweck rechtfertigt, auch wenn der Grundgedanke zum GSI nicht paßt ? Brauch die Antwort, weil ich an Aktivator-Kommunikationsaspekten rumbastle.

Experiment 1 : Transfer von Teleportkoordinaten zum Aufbau eines Inter-Mod-Teleporternetzes
Experiment 2 : Modifikation eines Worldspaces durch Skripte, welche Aktivatoren reinpositionieren.
Experiment 3 : Ausnutzen von Aktivatoren zur Übergabe von Questzuständen zwischen Mods (haarig http://www.multimediaxis.de/images/s.../1/gruebel.gif )

zu Experiment 2 bräuchte ich unter Umständen ein paar Variablen, da vielleicht ein Mod gerne wissen würde, welche Worldspaces vorhanden sind. Ist ein Worldspace vorhanden, kann man nämlich mit PositionWorld arbeiten.

Vorausgesetzt die Worldspaces - nicht notwendigerweise der volle Inhalt - sind zentrale Resourcen a la COBL oder ähnlich. Und ebenfalls vorausgesetzt man kann Worldspaces die schon existieren durch Zellen anreichern, ohne damit gleich - wie bei der Zellersetzung - den kompletten Worldspace zu ersetzen. Und genau das ist bei Experiment 2 die Frage. Geht das mit den Worldspaces so ? (Über die Variablen muß ich noch nachdenken)

Und jetzt zu etwas völlig anderem :

GSIRevivalPossible ?

Die Funktion ist ja ruiniert und klaut einem die Eigenschaften (hab ich gehört). Wenn aber ein Quest-Mod mit Eigenschaften arbeitet und ein Revival-Mod existiert, könnte die Quest schiefgehen, da vielleicht die entscheidende Eigenschaft nicht mehr da ist. Also will man vielleicht Revivals verbieten.

GSILevitationPossible ?

Bei YouTube habe ich ein Levitation Mod gesehen. Wenns wahr ist, will das aber in mancher Quest deaktiviert sein.

Tja das wars mal wieder
Gruß von Scanner 8)

Es kann problemlos wirklich ALLES in GSI eingebaut werden, wenn es auch Sinn macht... wir haben das ja hier schonmal ein wenig weiter gesponnen. Nur was per Variable zu Steuern ist, eben weil nur ein kleiner Wertbereich zu übergebene ist, kann und soll eben auch Variablen nutzen. Ist am einfachsten mit zu arbeiten und kann absolut rückstandsfrei entfernt werden.

Für die Levitaton gilt das gleichte... sobald es jemand braucht... bisher braucht aber noch niemand irgendwas... bisher ist nichtmal die eine bisher vorhandene Möglichkeit ausgenutzt. Es gibt derzeit genau einen Mod, der GSI unterstützt und das ist Rungs Vampirquest. Mit OI 0.95, das wohl irgendwann in den nächsten 7 Tagen erscheinen wird, wird es erstmals eine kleine sinnvolle Kombi geben. Dann werden wir ja sehen, ob Modder auf den Zug aufspringen, oder dem Spieler diesbezüglich weiter im Regen stehen lassen...

Ich hab noch ne Frage :

Zu den EVs gibts ja DVs, könnte man sowas nicht auch bei GSI machen (also GSI-Versionen zu bereits ex. PIs) ? Immerhin gehts vorerst nur um Teleportkonflikte und da dürfte nicht viel Arbeit anfallen.

Irgendjemand hat ja schonmal erwähnt, daß viele Mods bereits final sind und manche Entwickler gar nicht mehr daran arbeiten oder einfach verschwunden sind.