Hidiho mal wieder

Ich habe mit Freude festgestellt, dass man einen Köcher mit z.B. 20 Pfeilen "bestücken" kann und dass diese Pfeile dann nicht mehr einzeln das Inventar "vollmüllen".
Geht das auch irgendwann mit Rucksäcken und Taschen?

Ja, irgendwann™.

Darauf freue ich mich schon heute!

Das die Pfeile in einen Köcher abgelegt werden können, ist ja eine feine Sache...
Aber wenn ich das bei einer anderen Diskussion richtig mitbekommen habe, sind diese Pfeile dann für das System auch verschwunden und können nicht mehr als vorhanden abgefragt werden... Oder irre ich mich da?

Nein, die Pfeile sind noch da. Den Köcher kann man auch wieder leeren, wenn man sie nochmal sehen will.
Das Problem waren wohl Abfragefehler durch vergessene Befehle beim Questerstellen.

Sie können nicht mehr einfach so gefunden werden, aber auf Umwegen über die entsprechenden Variablen. Ist halt ein Provisorium.

Wäre ein klassischer Fall für diese Liste: Globale_Variablen

Und da ich gerade daran denke. Die Füllmenge Wasserschlauch vielleicht auch.

cvk hat geschrieben:Wäre ein klassischer Fall für diese Liste: Globale_Variablen

Hmm, ist das nicht nur die Übergangslösung? Irgendwann wollen wir den Stand doch eben nicht global speichern oder? Damit jeder Köcher seinen eigenen Füllstand hat.

Hierfür (zu den Behältnissen) soll es eine andere technische Lösung geben als AOQML. Weil man keinem AOQML-Schreiber zumuten kann jedesmal diese globalen Variablen abzufragen.

@Gaddezwerch

Ach menno, jetzt hätte ich mir die Antwort auch sparen können. Aber da sie schon geschrieben ist ...

@Theoran

Schon, aber bis dahin erschwert es die Erstellung von ZB und Questen nicht unerheblich, wenn man darauf nicht zurückgreifen kann. Im Augenblick heißt das zum Beispiel, dass man nichts mit Fernkampfwaffen schreiben kann, weil sonst jedesmal das Problem auftritt, dass der Charakter angeblich keine Bolzen/Pfeile dabei hat. Ein Problem, das zum Beispiel bei meiner Jagdqueste auftauchen wird, da die Köcher dort nicht eingebaut sind. Und ich sie nicht einbauen kann, weil ich die zuständige Variable und ihre Funktionsweise nicht kenne.

Aber gut, Problem erkannt und in Arbeit, kann ich temporär mit Leben.

Köcher auffüllen find ich auch ne super Sache. Leider ist es doch etwas umständlich, da man den Held zur hälfte ausziehen muss bis man den angelegten Köcher ablegen kann um ihn im Inventar neu bestücken zu können.
Ist es denn programmierbar die Items Pfeile/Bolzen in den angelegten Köcher zu legen? Also mit einem 'Benutzen'-Feld im Inventar?

Dante hat geschrieben:Ist es denn programmierbar die Items Pfeile/Bolzen in den angelegten Köcher zu legen? Also mit einem 'Benutzen'-Feld im Inventar?

Hmmh... Aber ist gerade da nicht das Problem?
Wenn der Köcher angelegt ist, taucht er ja nicht mehr in der Ausrüstungsliste auf und kann dementsprechend auch kein "Benutzen"-Feld haben...
Das müsste man dann entweder in den Kampf-Schirm für Gerüstete Ausrüstung legen, wo es aber doch unübersichtlich werden würde...
Oder man müsste es bei der Liste der Gerüsteten Ausrüstung in der Heldeninfo einbauen. Wär zwar etwas gewöhnungsbedürftig, Gegenstände in der Heldeninfo zu "benutzen", aber wär vom bisherigen Aufbau der Oberflächen wohl da sinnvollste.
Die Frage ist halt wirklich: Lässt sich sowas überhaupt programmieren?
Aber wenn ja, dann wird es wohl ein ziemlicher Aufwand werden... oder?

Merlinius hat geschrieben:Das müsste man dann entweder in den Kampf-Schirm für Gerüstete Ausrüstung legen, wo es aber doch unübersichtlich werden würde...

Es wäre auch eine Idee, die angelegte Ausrüstung im Kampfbildschirm direkt klickbar zu machen, je nachdem, was an den Items direkt möglich sein soll, wäre das sogar notwendig. Es würde sich dann ein neuer Bildschirm öffen.

Oder man verwaltet alles in einer "Behälter" Übersicht, die nicht nach ungelegt und nicht angelegt unterscheidet.

Theoran hat geschrieben:Es wäre auch eine Idee, die angelegte Ausrüstung im Kampfbildschirm direkt klickbar zu machen, je nachdem, was an den Items direkt möglich sein soll, wäre das sogar notwendig. Es würde sich dann ein neuer Bildschirm öffen.

Naja... Dazu müsste man dann aber jeden Gegenstand anzeigen lassen, was im Moment ja nicht direkt möglich ist, da nur alles an einer Position angezeigt wird, wenn Du drübergehst...
Aber das ist ja ohnehin ein wenig problematisch, da man so ja auch immer schlecht einen bestimmten Gegenstand ablegen kann...

Theoran hat geschrieben:Oder man verwaltet alles in einer "Behälter" Übersicht, die nicht nach ungelegt und nicht angelegt unterscheidet.

Das wär natürlich auch eine nette Idee. Ich würde mir das vorstellen wie eine zweite Ausrüstungsliste, in der nur die Behälter aufgeführt sind. Und bei Klicken auf einen Behälter klappt die dazugehörige Liste an Gegenständen auf...

Aber irgendwie befürchte ich, ist das eine Baustelle, die auch noch in ferner Zukunft liegt...

Aber irgendwie befürchte ich, ist das eine Baustelle, die auch noch in ferner Zukunft liegt...

Das ist bei jedem System, das eingeführt wird, zu befürchten, denn sonst wäre es schon implementiert (Magie/Kampf-Einzelrunden etc.)
Liegt wahrscheinlich daran, dass zu wenige Leute hier tiefergehende Programmierkenntnisse besitzen.

Ich zum Beispiel dachte nicht, dass ich mich je an AOQML ranwagen dürfte, bis ich's einfach mal probiert habe.
Jetzt habe ich gemerkt, das das durchaus mit HTML zu vergleichen ist, auch wenn ich noch nicht weiß, welche HTML-Tags alles nach AOQML umgewandelt sind und welche gar nicht funzen.

Aber... festzulegen, welcher Tag nun für AOQML umgeschrieben wird und wie das geht... davon hab' ich immer noch keine Ahnung. Und genau diese Ahnung muss man haben, um solche grundlegenden Mechanismen zu bauen. Wenn man nur AOQML bräuchte und einem alle "Tags" und alle "Tag-Variablen" vorliegen würden, die möglich sind (parallel zu SelfHTML und CSS3- eine Idee für das A-Team ), dann würde ich mir sogar zutrauen, nach einer entsprechenden Einarbeitungszeit solche Systeme selbst zu programmieren. Aber so, wie ich das einschätze, fehlen mir einfach wirkliche Programmierkenntnisse... und das dürfte vielen Anderen ebenso gehen. Aber selbst "Wirkungs-Mechanismen", die ja vor dem Programmieren ausgearbeitet werden müssen, würde ich mir zutrauen. Nur bräuchte ich dann einen Programmierer mit Zeit.