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

[MacGyver8472]

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.

[DWS]

GSI Cyrodiil

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

[NewRaven]

Ü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...

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.

[GreyWolf]

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...

...

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

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

[NewRaven]

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

...

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"

Ü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

[Rung]

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.

[Growlf]

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

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.

[Scanner]

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

[NewRaven]

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

[Rung]

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.^^

[Scanner]

@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.

[Xartas_Nobody]

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.

[Scanner]

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.

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.

[NewRaven]

@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

[Scanner]

@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.

[Scanner]

Sieht so aus als müßt ich für meine Idee alles selber machen. Ich habe jetzt mal provisorisch meine Idee durch Modifizierung von Rungs VM-Teleportskripte ausgetestet (es hat funktioniert ) 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.