Allgemein
News
News-Archiv
Partner
Netzwerk
Banner
Header
Media
Downloads
Impressum

The Elder Scrolls
Arena
Daggerfall
Spin-offs
Romane
Jubiläum
Reviews
Welt von TES
Lore-Bibliothek
Namens-
generator

FRPGs

Elder Scrolls Online
Allgemein
Fraktionen
Charakter
Kargstein
Technik
Tamriel-
Manuskript

Media

Skyrim
Allgemein
Lösungen
Tipps & Tricks
Steam-Kniffe
Review
Media
Plugins & Mods

Oblivion
Allgemein
Lösungen
Tipps & Tricks
Technik
Charakter
Media
Plugins & Mods
Kompendium

Morrowind
Allgemein
Lösungen
Tipps & Tricks
Media
Plugins & Mods

Foren
The Elder Scrolls Online
Hilfe & Diskussion

Skyrim
Hilfe & Diskussion
Plugins & Mods

Ältere TES-Spiele
TES-Diskussion
Oblivion-Plugins
Morrowind-Plugins

Community
Taverne zum Shalk
Adventures of Vvardenfell
Tales of Tamriel
Ergebnis 1 bis 20 von 27

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

Hybrid-Darstellung

Vorheriger Beitrag Vorheriger Beitrag   Nächster Beitrag Nächster Beitrag
  1. #1
    @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

  2. #2
    @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.
    Geändert von Scanner (30.06.2007 um 23:43 Uhr) Grund: Korrektur

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

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

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

    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 - oder ?

  6. #6
    Wenn ich mich hier auch mal dazwischendrängen dürfte.
    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.

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

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

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

  10. #10
    @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 )

    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)

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

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

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •