Ich bin's mal wieder mit neuen Wünschen

setting: Böse Orkbegegnungs-ZB im Orklandgebirge, Held verliert und wird dann verschleppt...
Jetzt: sofort Queststart: quests/orkhoehlen
Held wacht in Verlies in Orkhoehlen auf und muss sich rausschleichen/-kämpfen

Problem --> Aufruf der Quest und Stopp der Reise... evtl. noch folgende ZB der ursprünglichen Reise müssten gelöscht werden

Frage: Da man einen Kampf verloren hat, ist man körperlich am Ende. Würde man durch einfaches Warten in der Quest langsam wieder regenerieren, um gewappnet zu sein für Kämpfe in der Quest?

wenn Held raus ist muss er natürlich irgendwo weiterreisen können:

Problem --> Held in einen Ort versetzen, der nah an ursprünglichem Ziel liegt

Frage: evtl. noch ein paar passende ZB vorschalten, damit es nicht nach Teleport aussieht?

Athuran hat geschrieben:Ich bin's mal wieder mit neuen Wünschen

setting: Böse Orkbegegnungs-ZB im Orklandgebirge, Held verliert und wird dann verschleppt...
Jetzt: sofort Queststart: quests/orkhoehlen
Held wacht in Verlies in Orkhoehlen auf und muss sich rausschleichen/-kämpfen

Problem --> Aufruf der Quest und Stopp der Reise... evtl. noch folgende ZB der ursprünglichen Reise müssten gelöscht werden

Ich würde es erstmal so machen, dass es für den Rest der Zeit spezielle Gefangenen ZB gibt. Es müsste also einen Heldenstatus "gefangen" geben, ähnlich wie "arbeitend". Und analog zu "arbeitend als Nachtwächter in Anderstein" gäbe es folgedessen ein "gefangen von Orks in der Nähe von Anderstein". Könnte jemand vom Kern-A-Team diesen Teil implementieren und mir eine API dafür bereistellen? Derzeit lässt sich so ein "in der Nähe von Anderstein" ja nicht einmal in der Datenbank darstellen, was Voraussetzung wäre. Idee: Spezielle Orte in die Datenbank, die man nicht einfach so betreten/verlassen kann. Das hatten wir ja schon für den Silberberg, Burgen, Xorlosch etc. andiskutiert.

Dann könnten wir uns noch zusätzlich überlegen, wie die Gefangenschaft für andere Helden evtl. ein Trigger ist (z.B. sie bekommen die Entführung mit und können sich entscheiden, Retter zu spielen).

Athuran hat geschrieben:Frage: Da man einen Kampf verloren hat, ist man körperlich am Ende. Würde man durch einfaches Warten in der Quest langsam wieder regenerieren, um gewappnet zu sein für Kämpfe in der Quest?

Hier gäbe es grundsätzlich zwei Möglichkeiten:

Quest in in-game-Zeit)
- Normale Regeneration nach 4min (oder wie lang der Tag gerade ist)
- Quest-Seiten würden ein Auto-Reload bekommen so dass auch zeitgesteuert etwas passieren kann

Quests außerhalb der in-game-Zeit)
- Eigentlich dauern so Quests wie bisher eher eine Stunde, man braucht aber als Spieler einen ganze in-game-Tag
- also müsste die Regeneration abgeschaltet sein, damit man nicht einfach auf einer Verfolgung warten kann, um zu regenerieren

Meist braucht man die Unterscheidung wohl je nach Szene.

Athuran hat geschrieben:wenn Held raus ist muss er natürlich irgendwo weiterreisen können:

Problem --> Held in einen Ort versetzen, der nah an ursprünglichem Ziel liegt

Frage: evtl. noch ein paar passende ZB vorschalten, damit es nicht nach Teleport aussieht?

Man könnte sicherlich recht einfach implementieren, den Helden in eine normale Reiseposition versetzen. Also ihn in dem Beispiel irgendwo zwischen Orkenhort und Anderstein auf die Reise setzen. Die ZB kommen dann schon von alleine.

Insgesamt machst du da aber ein Riesen-Fass auf, von dem wir vermutlich noch so weit weg sind wie von Gruppenreisen. Folgendes würde uns z.B. zum Ziel führen:

1. spezielle Orte einführen, die nicht per normaler Reise erreichbar sind (könnte auch ein Ortsteil von Khezzara etc. sein)
2. evtl. einen Heldenstatus "gefangen" analog zu "arbeitend"
3. evtl. Gefangenentransport-ZBs
4. Anreise/Abreise zu diesen Orten "schützen" - geht also nur über eine ZB (Gefangennahme) oder ein ein Quest (Rettungsaktion, Flucht)
5. Suspendieren der Regeneration
6. Zeitgesteuerte Aktionen in Quests

dann gibts noch Erweiterungen:
7. Gefangene Helden als Trigger für Retter-Quests

Ich schlage vor, erst einmal die Punkte 1., 5. und 6. anzugehen. Das macht schon einige weitere Quest-Situationen möglich (z.B. Xorlosch den Zwergen) und ist noch relativ einfach. Dann die anderen. Wir könnten die Todos ja ins Mantis aufnehmen. Für mich wären initial 6. und 7., evtl. 4. - wobei wir da erst einmal eine Idee bräuchten, wie man das implementiert und ich dabei vermutlich aber wieder Hilfe vom Kern-A-Team brauche. Bei den anderen müsste definitiv erstmal Vorleistung vom Kern-A-Team geleistet werden, bevor ich aktiv werden könnte. Denn in die Tiefen des Antamar Codes wollte ich nicht eindringen, das ginge über meine verfügbare Zeit.

Aber wenn wir dahin kommen, was du hier angeregt hast, dann wären das schon fantastisch spannende Möglichkeiten.

Na so riesig ist das Fass nun auch nicht, so viele Möglichkeiten hatte ich heute Nacht gar nicht im Sinn, wie du daraus gemacht hast

Die Quest selbst habe ich schon fast zur Hälfte fertig, das Verzeichnis existiert schon und der grundlegende Aufbau ist auch schon drin. Sind jetzt etwa 55 Dateien. Auch der Ort ist überhaupt kein Problem, ich kann ja selbst einen erstellen, zu dem einfach kein Weg führt (weil man den Ort ja auch nicht betreten muss) wo keiner lebt und es sonst nichts gibt, von dem aus aber Wege weg führen.

Damit wäre das Folgeproblem auch schon gelöst mit dem Wiederfinden der Zivilisation. Das ist mir gestern abend aber nicht mehr aufgegangen. Darüber hinaus bräuchte es auch keinen Status "gefangen oder so", es müßte nur eingestellt sein, dass jeder in dem Ort sofort die Quest vorgesetzt bekommt. Dass der Held verschleppt wurde, erfährt er dann in der Quest.

Bei diesem Konzept bräuchte es nun eigentlich nur noch eine function, die den Helden sofort in einen (oder einen von dreien?) festgelegten Ort (id = w3+10005) zu versetzt und die restlichen Reisebegegnungen zu löschen und die Regeneration sollte durch einfaches Abwarten innerhalb der Quest möglich sein, also die tägliche Regeneration.

ps: Das mit dem gemeinschaftlichen Befreien ist eine sehr gute Idee, da ist dann aber der Ansatz der Dungeons dafür vorbehalten, weil diese konkret auf sowas auch ausgelegt sind.

Athuran hat geschrieben:Na so riesig ist das Fass nun auch nicht, so viele Möglichkeiten hatte ich heute Nacht gar nicht im Sinn, wie du daraus gemacht hast

Die Quest selbst habe ich schon fast zur Hälfte fertig, das Verzeichnis existiert schon und der grundlegende Aufbau ist auch schon drin. Sind jetzt etwa 55 Dateien. Auch der Ort ist überhaupt kein Problem, ich kann ja selbst einen erstellen, zu dem einfach kein Weg führt (weil man den Ort ja auch nicht betreten muss) wo keiner lebt und es sonst nichts gibt, von dem aus aber Wege weg führen.

Wow 55 Dateien! Und ja, stimmt, eigentlich. Wenn erstmal solche Orte existieren, dann kommt man ja da eh nicht raus, bevor man das Quest beendet hat, weil weiterreisen während eines Quests nicht geht. Quest abbrechen darf dann natürlich auch nicht gehen

Athuran hat geschrieben:Bei diesem Konzept bräuchte es nun eigentlich nur noch eine function, die den Helden sofort in einen (oder einen von dreien?) festgelegten Ort (id = w3+10005) zu versetzt und die restlichen Reisebegegnungen zu löschen und die Regeneration sollte durch einfaches Abwarten innerhalb der Quest möglich sein, also die tägliche Regeneration.

Das mit dem "an einen Ort versetzen" implementiere ich noch. Für das ZB löschen wäre mir ein Tipp vom jemandem recht, der sich damit auskennt (also SQL-Anweisung oder Hilfsfunktion), denn für sowas rauszufinden geht immer viel Zeit drauf.

Athuran hat geschrieben:ps: Das mit dem gemeinschaftlichen Befreien ist eine sehr gute Idee, da ist dann aber der Ansatz der Dungeons dafür vorbehalten, weil diese konkret auf sowas auch ausgelegt sind.

Ich meinte eigentlich eine Einzelbefreiungs-Aktion, da es eh noch keine Gruppen-Quests gibt. Aber die eben ggf. mehreren angeboten wird, solange der Held gefangen ist.

Bevor man da groß neue Zustände erfindet:

Eine Funktion die die bisherigen ZB-namen in der DB gegen neue austauscht (kann ja zufällig aus einem Array gewählt werden) ist sicher schneller geschrieben.
In der ZB muss dann ebenfalls lediglich die Zielort-ID manipuliert werden.

Das ist mit zwei Funktionen und eventuell einer neuen Tabelle (um ZB-Namen vorzuhalten) erledigt. Die Tabelle kann man sich sogar sparen da die ZBs bei uns eh zusammengefasst sind, da kann Athuran einen seiner Random-Arrays recyceln.


grüße

Worauf willst du hinaus?

Lowlander hat geschrieben:

Athuran hat geschrieben:Frage: Da man einen Kampf verloren hat, ist man körperlich am Ende. Würde man durch einfaches Warten in der Quest langsam wieder regenerieren, um gewappnet zu sein für Kämpfe in der Quest?

Quest in in-game-Zeit)
- Quest-Seiten würden ein Auto-Reload bekommen so dass auch zeitgesteuert etwas passieren kann

Wenn ich grade an der Queste sitze und der Postbote klingelt, oder das Telefon bimmelt, brauche ich sicher länger als nur 4 Minuten um die Szene zu Ende zu bringen. Wenn mir dann die Queste zeitlich davonläuft, fände ich das sehr unschön.

Quests außerhalb der in-game-Zeit)
- Eigentlich dauern so Quests wie bisher eher eine Stunde, man braucht aber als Spieler einen ganze in-game-Tag
- also müsste die Regeneration abgeschaltet sein, damit man nicht einfach auf einer Verfolgung warten kann, um zu regenerieren

Meist braucht man die Unterscheidung wohl je nach Szene.

Die starre 4-Minuten-Einteilung für die Tage ist in den Questen sehr hinderlich, wie die Beispiele oben zeigen.
Was haltet ihr davon, die Regeneration in Questen vom Programmierer/Autor anzustoßen? Z. B. in AOQML mit einem neuen Tag á la <regeneration/> oder so (bzw mit dem Aufruf einer entsprechenden Funktion in PHP, oder einer entsprechenden Bibliothek, die die Regeneration in AOQML nachbildet). Tages(zeiten)wechsel sind dann irrelevant, die muss der Autor selbst festlegen und berücksichtigen.
Dann könnte man dem Spieler auch die Möglichkeit an die Hand geben, selbst zu entscheiden, während der Queste eine zweite Ruhephase zur Regeneration einzulegen, bzw zu rasten. Dann muss man beim Anlegen der Quest die Folgen eben schon mit berücksichtigen. Oder eben festlegen, dass die Queste so hektisch ist, dass keine Regeneration möglich ist. Dann enthält man dem Spieler die nötigen Links eben vor.

Zeitgesteuerte Aktionen in Quests halte ich für problematisch, weil der Zeitablauf innerhalb der Quest ja auch vom Fortschreiten durch die Quest abhängt. Siehe oben.
Ich meine, Ereignisse sollten nur auftreten, wenn der Held die entsprechende Szene erreicht hat.
Ich hoffe, ich hab dich nicht völlig missverstanden, ist schon spät.

Nur mal so zwischendurch, ich habe derzeit schon mehr abzuarbeiten, als ich voraussichtlich (je nach Auftragslage beim Geldverdienen) im ganzen Juni schaffen kann.

Bitte nutzt, was geht, und stellt alles andere erstmal zurück.

Lowlander hat geschrieben:Für das ZB löschen wäre mir ein Tipp vom jemandem recht, der sich damit auskennt (also SQL-Anweisung oder Hilfsfunktion)

Dafür gibt es bereits die Funktion delete_zufallsbegegnung($held_id, $zeit) in functions_reise.inc.php

handborons hat geschrieben:Wenn ich grade an der Queste sitze und der Postbote klingelt, oder das Telefon bimmelt, brauche ich sicher länger als nur 4 Minuten um die Szene zu Ende zu bringen. Wenn mir dann die Queste zeitlich davonläuft, fände ich das sehr unschön.

Guter Punkt.

handborons hat geschrieben:Was haltet ihr davon, die Regeneration in Questen vom Programmierer/Autor anzustoßen? Z. B. in AOQML mit einem neuen Tag á la <regeneration/> oder so

Sowas in der Art werden wir wohl brauchen.

Die Regeneration kann mit einem timestamp aufgerufen werden. Dabei muss man dann beachten bei verlassen eines Dungeons wieder einen vernünftigen timestamp in der DB zu haben damit die normale Regeneration weiterhin funktioniert.

ab r 1795:
<set attrib="site" val="Khezzara"/> bzw. <set attrib="site" val="#360"/>
löschen alle ZB (TODO: Zeitangabe muss noch berücksichtigt werden, sobald ich die durchgeschleift habe)
und verlegen den Helden an den angegebenen Ort

Lowlander hat geschrieben:ab r 1795:
<set attrib="site" val="Khezzara"/> bzw. <set attrib="site" val="#360"/>
löschen alle ZB (TODO: Zeitangabe muss noch berücksichtigt werden, sobald ich die durchgeschleift habe)
und verlegen den Helden an den angegebenen Ort

Nur zum Verständnis: wenn eine Quest z. B. an Reisetag 3 aufgerufen wird, bleiben in dem Fall die ZBs von Reisetag 1 und 2 erhalten?

handborons hat geschrieben:

Lowlander hat geschrieben:ab r 1795:
<set attrib="site" val="Khezzara"/> bzw. <set attrib="site" val="#360"/>
löschen alle ZB (TODO: Zeitangabe muss noch berücksichtigt werden, sobald ich die durchgeschleift habe)
und verlegen den Helden an den angegebenen Ort

Nur zum Verständnis: wenn eine Quest z. B. an Reisetag 3 aufgerufen wird, bleiben in dem Fall die ZBs von Reisetag 1 und 2 erhalten?

So sollte es sein. Ich verwende nur die Antamar-Funktion delete_zufallsbegegnung($held_id, $zeit) in functions_reise.inc.php implementiert. Nur übergebe ich derzeit noch keinen Zeitpunkt, so dass es sicherlich noch nicht richtig funktioniert. Bisher ist es also eher ein Zwischenstand, damit solche ZB/Quest-Kombinationen entwickelt werden können. Freigeschaltet werden können sie erst, wenn ich die Zeit durchschleife. Was die o.g. Funktion macht, wenn keine Zeit angegeben ist: Keine Ahnung.

@Athuran: ok, ab r1808 sollte das mit dem Zeitpunkt funktionieren. Neuer Parameter in play_aoqml_zb für den Zeitpunkt, also:

Code: Alles auswählen

play_aoqml_zb( 'zb/gefangennahme-durch-orks', $zeit );