ZB in AOQML

[Athuran]

Wie weit ist die Einbindung?

Werden die ZB genau gleich ausgegeben wie die in php?

Wie erfolgt der Aufruf?

Was muss noch umgesetzt werden?

Wie weit sind Abfragen der Wegart, Vegetation, Region und Handelszone möglich?


Ich würde wie schon geschrieben die bisherige Struktur (DB und Zufallsweichen) unbedingt weiternutzen wollen, weil die Entscheidungsbaum und Zufallsauswahl an sich bisher super bewährt hat. Also ab dann in den zufalls.inc-Dateien lediglich den Aufruf der jeweiligen .xml schreiben.

ps: Ich bin im übrigen sehr dafür, das schreiben in xml voranzutreiben, also nicht falsch verstehen

[Lowlander]

Wie weit ist die Einbindung?

Es müsste vermutlich noch in der ZB-Datenkbank ein Feld für den Pfad zur XML-Datei rein und wenn es diese Spalte gibt, dann ein Funktionsaufruf, dem eben dieser Feldinhalt übergeben wird.

Werden die ZB genau gleich ausgegeben wie die in php?

Nein, logischerweise genauso wie in den Quests, ist ja derselbe Code wie bei den Quests. Ja, das soll angepasst werden. Hat für mich aber nicht so hohe Priorität, wie z.B. Kampf - der ja auch noch nicht integriert ist.

Wie erfolgt der Aufruf?

soll soll es aussehen:

Code:

play_aoqml_zb( 'zb/hose-zu-viel.xml' ); // so hieß eine ZB, die hier im Forum gepostet wurde


ich baue gerade für ZB noch ein paar Sachen rein, wird wohl noch heute im SVN landen

Was muss noch umgesetzt werden?

- diverse Umgebungs-Wertabfragen (siehe z.B. unten) und Helden-Eigenschaften
- Kampf
- Angleichung der Proben-Ausgaben

Wie weit sind Abfragen der Wegart, Vegetation, Region und Handelszone möglich?

Abfragen noch nicht, ließe sich aber schnell einbauen. Aber über die ZB-Tabelle wird das doch eh vorausgewählt, oder?

Ich würde wie schon geschrieben die bisherige Struktur (DB und Zufallsweichen) unbedingt weiternutzen wollen, weil die Entscheidungsbaum und Zufallsauswahl an sich bisher super bewährt hat. Also ab dann in den zufalls.inc-Dateien lediglich den Aufruf der jeweiligen .xml schreiben.

genau so war's geplant
ps: Ich bin im übrigen sehr dafür, das schreiben in xml voranzutreiben, also nicht falsch verstehen [/quote]

[Spacewolf]

ps: Ich bin im übrigen sehr dafür, das schreiben in xml voranzutreiben, also nicht falsch verstehen

Da gab es doch mal die Idee (von Gerrit??) zum Erstellen von solchen XML-Dateien ein Web-Frontend zu basteln.
Sollten wir unbedingt im Auge behalten.
Das wäre in meinen Augen ein echter Quantensprung, da damit kreativ begabte Schreiber direkt einsatzfähige ZBs erstellen könnten.
Irgendwie ist das Erstellen einer XML-Datei von Hand doch ebenso ein Gepfriemel wie das Codieren einer ZB in PHP.

[Lowlander]

Da gab es doch mal die Idee (von Gerrit??) zum Erstellen von solchen XML-Dateien ein Web-Frontend zu basteln.
Sollten wir unbedingt im Auge behalten.
Das wäre in meinen Augen ein echter Quantensprung, da damit kreativ begabte Schreiber direkt einsatzfähige ZBs erstellen könnten.

ja, wäre es!

Irgendwie ist das Erstellen einer XML-Datei von Hand doch ebenso ein Gepfriemel wie das Codieren einer ZB in PHP.

ZBs kann man eigentlich in AOQML so runtercoden, erst Quests sind komplexer, weil man sich Szenenübergreifend so viele Daten merken muss und dann dafür sorgen muss, dass alle Zweige alle Daten haben etc. Klar, es braucht ein wenig Übung, aber bei ZBs liegt dabei die Betonung auf "wenig"

[Athuran]

Wie sind die Einstellungen zum Charverhalten (aggressiv/defensiv, phexisch/gesetzestreu, etc.) abfragbar?

Wie weit sind Abfragen der Wegart, Vegetation, Region und Handelszone möglich?

Abfragen noch nicht, ließe sich aber schnell einbauen. Aber über die ZB-Tabelle wird das doch eh vorausgewählt, oder?

Jein, eigentlichschon, aber manche Begegnungen müssen noch feiner eingestellt sein, weil sie bspw. universell verwendet werden und je nach Region unterschiedliche Zweige entwickeln oder Teil einer umfassenden Weiche sind, die keine große Vorauswahl zulässt.

[Lowlander]

Wie sind die Einstellungen zum Charverhalten (aggressiv/defensiv, phexisch/gesetzestreu, etc.) abfragbar?

Gerade implementiert (in r1762) mit den Namen und Werten exakt wie in der Datenbank (also auch deutsch). Z.B.

Code:

<switch attribute="vorgehen">
    <case val="offen">Zweig für offenes Vorgehen</case>
    <else>Zweig für sonstiges Vorgehen (bleibt ja nur "schleichen")</else>
</switch>


Grundsätzlich würde ich das aber nur in ZB, in Quests nur in gut begründbaren Ausnahmefällen verwenden, und sonst dem Spieler die Entscheidung lassen.

Wie weit sind Abfragen der Wegart, Vegetation, Region und Handelszone möglich?

Abfragen noch nicht, ließe sich aber schnell einbauen. Aber über die ZB-Tabelle wird das doch eh vorausgewählt, oder?

Jein, eigentlich schon, aber manche Begegnungen müssen noch feiner eingestellt sein, weil sie bspw. universell verwendet werden und je nach Region unterschiedliche Zweige entwickeln oder Teil einer umfassenden Weiche sind, die keine große Vorauswahl zulässt.[/quote]

Ok, ich baue dann sowas ein:

Code:

<switch attribute="site.staatenbund">
    <case val="Fürstkomturei Maraskan|Gloriana|Schwarztobrien">
        <!-- Achtung: das mit dem "|" funktioniert auch bei case noch nicht! -->
    </case>
    <else> ...< /else>
</switch>


Und zwar für "staat", "staatenbund", "handelszone", "vegetation", "vegetation_wasser" (?), "einwohner", "markt" (true/false), "belebt" (true/false, ist das nicht bei Einwohner > 0 immer so?), "hafen" (true/false). Achtung: In ZB auf Reisen würde ich fast sagen, dass das Attribut "site" am besten NICHT definiert ist! Das hat schon im PHP-Code von Antamar immer wieder zu Problemen geführt, uns sollte hier sauberer gelöst werden.

Dafür dann auf Reisen "ex_ort", "zielort" und "weg.klasse" (Feste Wege", ""Lose Wege", "Wald", "Gebirge", ...), "weg.vegetation", "weg.handelszone" und "weg.art" ("Reichsstraße", "Reichslandstraße", ...). Da dabei mehrere neue Tabellen involviert sind, werde ich dafür aber etwas Zeit brauchen.

(Nicht wegen Englisch/Deutsch wundern, ich werde alles außer den Tags wohl ins Deutsche ändern und mache die neuen daher schon in Deutsch.)

Eine weitere Möglichkeit wäre, dafür ein initcode Feld in der ZB-Datenbank-Tabelle zu spendieren, wie auch bei den Quests. Damit kann man z.B. Variable je nach Region vorbelegen, dann aber dieselbe AOQML Datei aufrufen, welche die Variablen dann auswertet. Dazu schreibt man einfach AOQML-Code (den Teil innerhalb des scene-Tags). Für ZB würde das allerdings noch nicht funktionieren, ist also erstmal nur als Möglichkeit einer extrem flexible Parametrisierung zur Info.

[Lowlander]

In r1766 implementiert: site_einwohner, site_markt, site_hafen, site_belebt. Mit _ statt ., war so einfacher.

Alles für <get attribute="..."/> und <switch attribute="..."/> - eigentlich alle attribute="...", aber mehr fallen mir gerade nicht ein.

Die Einwohnerzahl bezieht sich außerdem immer auf die ganze Stadt, nicht nur den Stadtteil. Und die Stadtzentren sind i.d.R. als "nicht belebt" markiert. Daher ist es auch separat.

[Lowlander]

Ab r1809 geht sowas:

Code:

<p>Du befindest dich im Staate <get attribute="site_staat"/> (#<get attribute="site_staat_id"/>)
im Staatenbund <get attribute="site_staatenbund"/> (#<get attribute="site_staatenbund_id"/>)
und der Handelszone <get attribute="site_handelszone"/> (#<get attribute="site_handelszone_id"/>/<get attribute="site_handelszone_kuerzel"/>),
die Umgebung besteht aus <get attribute="site_vegetation"/> (#<get attribute="site_vegetation_id"/>).</p>


Das ergibt z.B.:

Du befindest dich im Staate Mittelreich (Kgr. Almada) (#62) im Staatenbund Heiliges Neues Kaiserreich vom Greifenthron zu Gareth (#24) und der Handelszone Almada (#3/ALM), die Umgebung besteht aus Grasland und Wiese (#6).

Natürlich auch per <switch> abfragbar.

Mit anderen Worten, die folgenden (read-only) Attribute wurden implementiert:

site_staat, site_staat_id, site_staatenbund, site_staatenbund_id,
site_handelszone, site_handelszone_id, site_handelszone_kuerzel,
site_vegetation, site_vegetation_id

Als nächstes kommen Reiseinformationen ...

[Lowlander]

Als nächstes kommen Reiseinformationen ...

Ok, es gibt ab r1810 haufenweise neue Reiseinformations-Attribute für ZB:

unterwegs (auf Reisen 'true', sonst 'false')

Der Rest ist nur auf Reisen definiert:

Code:

weg_ankunft
weg_art
weg_art_id
weg_klasse
weg_klasse_id
weg_vegetation
weg_vegetation_id
weg_handelszone
weg_handelszone_kuerzel
weg_handelszone_id

weg_von
weg_von_einwohner
weg_von_markt
weg_von_belebt
weg_von_hafen
weg_von_staat
weg_von_staat_id
weg_von_staatenbund
weg_von_staatenbund_id
weg_von_vegetation
weg_von_vegetation_id
weg_von_handelszone
weg_von_handelszone_id
weg_von_handelszone_kuerzel

weg_nach
weg_nach_einwohner
weg_nach_markt
weg_nach_belebt
weg_nach_hafen
weg_nach_staat
weg_nach_staat_id
weg_nach_staatenbund
weg_nach_staatenbund_id
weg_nach_vegetation
weg_nach_vegetation_id
weg_nach_handelszone
weg_nach_handelszone_id
weg_nach_handelszone_kuerzel


Jetzt überlege ich noch, wie man in AOQML eine Reise starten könnte. <set attribute="site" val="Madasee"/> wäre ja eher wie ein Teleport. Brainstorming:

<travel to="Madasee"/> -- wäre ein Stilbruch, weil andere Tag-Verwendung als bisher

<set attribute="weg_nach" val="Madasee"/> -- dann sollte aber weg_nach wohl auch vor Ort definiert sein, statt nur auf Reisen

Ich tendiere zur zweiten Variante.

Das Heraussuchen der weg_id etc. würde in jedem Fall die AOQML-Antamar-Anbindung machen, d.h. darum braucht sich der AOQML-Entwickler nicht zu kümmern. Alternativ ginge auch in beiden Fällen val="#927".

Auch in jedem Fall: Sowohl ein Teleport als auch ein Reisestart sollte ganz am Ende einer Szene sein, denn jede Szene kann prinzipbedingt nur an einem Ort spielen!