[Diskussion] Neue Wiki QSB Version

[Old McDonald]

Absturzbugs sind uns bisher nicht bekannt - eher dieses Designproblem von Reward_InitObjectCosts.
Ich glaube auch nicht, dass der Absturz von Reward_ReplaceEntity ausgelöst wird. Die einzige Möglichkeit, wie es dazu bei einigen wenigen, bestimmten Entitytypen kommen könnte, wäre, dass die Einheit, die ersetzt werden soll, tot ist. Dann würden nämlich die neue Einheit auf der Karte bei (0/0) erstellt, und das könnte Probleme verursachen. Da das bei Dir offensichtlich nicht der Fall ist, können wir auch diese Belohnung wahrscheinlich ausschließen.

Ich glaube, dass das Problem eher im Wasserabsenken und Bodenerhöhen liegt - das war schon immer problematisch.

1. Quest mal posten.
2. Alle Befehle bezüglich dieser Aktion rausnehmen und nach und nach wieder einfügen (mit mehrmaligen Testen). Beginnen die Abstürze, ist der Übeltäter gefunden.

@Britta: Ich habe mal Reward_CreateEntity, Reward_CreateBattalionOmd, Reward_ReplaceEntity und Reward_ReplaceEntityByBattalion einem Sicherheitsupdate unterzogen. Du kannst diese aus dem Wiki in die neue QSB kopieren. Danke!
Und möglicherweise sollten wir uns überlegen, Debugmeldungen in die Questverhalten einzubauen falls eine Belohnung nicht ausgeführt werden kann, ein IO nicht initialisiert wurde und ähnliches. Das würde wahrscheinlich das Testen erleichtern und dem Mapper deutlicher vor Augen führen, was das Problem ist. Aktivieren könnte es der Mapper dann entweder im Skript oder per Belohnung.

@Saladin: Die IO-Funktionalität wird, denke ich, gründlich von uns überarbeitet bald verfügbar sein. Britta arbeitet an der neuen QSB, sie wird Dir am ehesten sagen können, was Sache ist (denn ich habe die neue bisher nicht gesehen, sondern nur das grundsätzliche neue IO-Design beigesteuert). Es wird dann eine Reihe neuer Befehle geben:
Reward_ObjectInit
Reward_ObjectSetupCarts
Reward_ObjectAddReward
Reward_ObjectClearRewards
Reward_ObjectSetupCosts
Die alten werden noch vorhanden sein, denke ich mal, aber im Beschreibungstext wird ausdrücklich stehen, dass diese Befehle unerwünscht (bzw. englisch "deprecated") sind und in einer späteren QSB-Version entfernt werden.

[saladin]

Alle Befehle bezüglich dieser Aktion rausnehmen und nach und nach wieder einfügen (mit mehrmaligen Testen). Beginnen die Abstürze, ist der Übeltäter gefunden.

Klassisch! Das ist unser täglich Brot in den letzten 12 Jahren gewesen, da die viele Fehler sonst nicht zu finden sind. War hier aber nicht bzw. es war nur in zwei Fällen eine Terrainveränderung in dem Stile vorhanden, wobei Abstürze auch ohne diese Veränderungen stattfanden - wobei Abstürze "leider" auch nicht immer vorkommen. Die andere Karten sind sehr einfache, skriptlose Maps gewesen.

Die alten werden noch vorhanden sein, denke ich mal, aber im Beschreibungstext wird ausdrücklich stehen, dass diese Befehle unerwünscht (bzw. englisch "deprecated") sind und in einer späteren QSB-Version entfernt werden.

Ich votiere für gleich raus. Soll denn die QSB nicht das Arbeitsmittel für den Mapper werden, der eben nicht skripten kann oder will? Einfache, klare Strukturen sind angesagt, nenne es meinetwegen skripten für Doofe.

saladin

[Old McDonald]

Ich votiere für gleich raus. Soll denn die QSB nicht das Arbeitsmittel für den Mapper werden, der eben nicht skripten kann oder will? Einfache, klare Strukturen sind angesagt, nenne es meinetwegen skripten für Doofe.

Das Problem ist dann aber, dass die neue QSB kaum in den Maps, die gerade entwickelt werden, eingesetzt wird und dass viele Mapper sich dann beschweren, dass ihre interaktiven Objekte nicht mehr funktionieren. Mir wär's also lieber, erst einmal diese Befehle drin zu lassen - aber deutlich zu kennzeichnen, dass diese nicht mehr verwendet werden sollten und auch bald entfernt werden (schon mal jemand versucht, Farbe in den Beschreibungstext reinzubringen?).

[Netsurfer]

Das Problem ist dann aber, dass die neue QSB kaum in den Maps, die gerade entwickelt werden, eingesetzt wird und dass viele Mapper sich dann beschweren, dass ihre interaktiven Objekte nicht mehr funktionieren.

Ich bin da eher Saladins Meinung.

1. Für bereits fertige Maps eh kein Thema
2. Für in Arbeit befindliche Maps ist es Sache des Mappers, ob er weiter mit der QSB arbeitet, mit der er begonnen hat, oder ob er sich die ggf. Mehrarbeit antun möchte und auf die neue Version wechselt
3. Für zukünftige Maps, und die bilden ja den Hauptaspekt, sollten aber a) nicht haufenweise fast identische Geschichten in der QSB vorhanden sein und b) wenn diese eh rausfliegen sollen, dann lieber sofort.

Ich sehe es wie Saladin: Immer die Haupt-Zielgruppe für die QSB im Auge behalten!

Allerdings ist es imho eh auch problematisch, wenn Mapper einerseits "die tollsten Sachen" in ihren Maps machen wollen, andererseits nicht bereit sind, sich mal näher mit der Scripterei zu beschäftigen und das dann alles per QSB machbar sein soll!

Ich stehe ganz klar auf dem Standpunkt, dass man da auch mal eine Grenze ziehen sollte!

Gruß
Gunther

[Old McDonald]

Okay, wie wäre es mit einem Kompromiss:
Eine Standard-QSB, die die Mapper für alle neuen Maps verwenden sollen, und eine "Update-QSB", die nur für aktuell laufende Projekte verwendet werden soll und nach ca. drei Wochen aus dem Wiki entfernt wird?

[Netsurfer]

Okay, wie wäre es mit einem Kompromiss:
Eine Standard-QSB, die die Mapper für alle neuen Maps verwenden sollen, und eine "Update-QSB", die nur für aktuell laufende Projekte verwendet werden soll und nach ca. drei Wochen aus dem Wiki entfernt wird?

Mir egal.

Was die in Arbeit befindlichen Maps angeht, stehe ich mehr auf dem Standpunkt, dass man die entweder mit der QSB Version fertigstellt, mit der man auch angefangen hat (ging ja bis jetzt auch), oder man nimmt die neue Version und muss ggf. ein paar kleine Anpassungen vornehmen.

Persönlich sah ich bis jetzt was die QSB angeht immer den entscheidenden Vorteil darin, dass man sich sicher sein konnte, im Bezug auf die Funktionen, wenn jemand Probleme mit irgendetwas hatte.
Das ist auch der Hauptgrund, warum es imho nicht alle paar Tage eine geänderte Version davon geben sollte. Denn wenn es nachher 5 oder noch mehr unterschiedliche Versionen gibt, dann wird es richtig spaßig bei der Fehlersuche, Bugfixes, Neuerungen, etc.!

Gruß
Gunther

[saladin]

Nehmen wir mal eine Karte der aktuellen Generation mit ca. 72 Quests. Auf der Karte befinden sich 4 IO's, dazu gehören 12 Quests.
Jeder der sich die QSB vom Wiki holt muss wissen und wird wissen (so Gott will) ob bzw. was geändert wurde, denn das schreiben die anwesenden Skriptkünstler ja dazu.
Dann muss man also auf der Karte an 12 Quests etwas ändern oder ggf. 4-6 dazu setzen. Was ist daran jetzt dramatisch bei dem sonstigen Aufwand?

Und wenn die Neuerungen der alten QSB dem Mapper nicht so wichtig sind, nimmt einfach seine alte QSB, die er gerade am Wickel hatte. Die Karte die bereits fertig sind nachzurüsten ist sein Bier.
Fehlersuche! Ich erinnere mich finster an die MapShitFunction, die im Original so und im Wiki so heißt oder hieß - 3 Tage habe ich damit rumgealbert - es war nirgendwo erwähnt worden.

Jedenfalls halte ich einen stringenten Kurs mit einer neuen QSB und Schluss für sinnvoller als die Arie mit Update von gestern auf übermorgen, bis dann 3 -12 QSB's rumfliegen. Nonsens.

Im übrigen möchte ich nochmals eindringlich auf die Zielgruppe hinweisen. Diese neue QSB einige sehr nette neue Elemente, die nunmehr denen nutzbar gemacht werden, die eben nicht skripten können.

Also : eine komplett neue, einheitliche und getestet QSB ohne Reste von gestern.

saladin

P.S. Und wer die neuesten Wunder der Siedlerwelt produzieren will soll bitte skripten lernen.

[Netsurfer]

@Saladin: Ganz meine Meinung ... !

P.S. Und wer die neuesten Wunder der Siedlerwelt produzieren will soll bitte skripten lernen.

Genau! Und wenn er sich nur mit dem Questsystem und der QSB beschäftigt, um diese nach seinen Wünschen zu ergänzen/ abzuändern.

Man kann ja durchaus gewisse Dinge ins Wiki stellen. Wer kann und will, der möge sie dann verwenden (auf eigenes Risiko ).

Gruß
Gunther

[Old McDonald]

Was die in Arbeit befindlichen Maps angeht, stehe ich mehr auf dem Standpunkt, dass man die entweder mit der QSB Version fertigstellt, mit der man auch angefangen hat (ging ja bis jetzt auch), oder man nimmt die neue Version und muss ggf. ein paar kleine Anpassungen vornehmen.

Ein sehr komisches Verständnis von Kundenfreundlichkeit. Stell' Dir vor, MS würde das genauso handhaben mit Betriebssystemupdates - keiner würde es mehr machen.

Das ist auch der Hauptgrund, warum es imho nicht alle paar Tage eine geänderte Version davon geben sollte. Denn wenn es nachher 5 oder noch mehr unterschiedliche Versionen gibt, dann wird es richtig spaßig bei der Fehlersuche, Bugfixes, Neuerungen, etc.!

Ja, da stimme ich Dir zu, dass es nicht zu viele Versionen geben sollte. Aber normalerweise wird für eine Übergangszeit gewährleistet, dass die alten Funktionen bestehen bleiben, einfach um Kompatibilität für kurze Zeit zu erhalten. Es geht auch nur darum, dass auch die Mapper, die schon mit einer Karte angefangen haben, auf die neue QSB relativ problemlos umsteigen können - und wenn es eine speziell ausgewiesene "Upgrade-QSB" ist, die nur für ein paar Wochen verfügbar ist. Schließlich sollen auch diese Mapper von den Bugfixes profitieren, oder?

Jeder der sich die QSB vom Wiki holt muss wissen und wird wissen (so Gott will) ob bzw. was geändert wurde, denn das schreiben die anwesenden Skriptkünstler ja dazu.

Liest Du Dir jedes Mal das Changelog eines Programmes durch, wenn Du Dir ein Update besorgst? Ich nicht, ich gehe normalerweise davon aus, dass es vollständig funktioniert

Dann muss man also auf der Karte an 12 Quests etwas ändern oder ggf. 4-6 dazu setzen. Was ist daran jetzt dramatisch bei dem sonstigen Aufwand?

Hm, ich wüsste nach dem Import nicht mehr sicher, wo ich was eingefügt habe. Wenn ich nur vergesse, ein Verhalten zu ersetzen, geht möglicherweise schon jede Menge Zeit drauf, um herauszufinden, dass es fehlt.

Und wenn die Neuerungen der alten QSB dem Mapper nicht so wichtig sind, nimmt einfach seine alte QSB, die er gerade am Wickel hatte. Die Karte die bereits fertig sind nachzurüsten ist sein Bier.

Gerade Du solltest doch interessiert sein, dass auch Fehler in diesen Maps durch eine neue QSB behoben werden.

Fehlersuche! Ich erinnere mich finster an die MapShitFunction, die im Original so und im Wiki so heißt oder hieß - 3 Tage habe ich damit rumgealbert - es war nirgendwo erwähnt worden.

Ich wäre auf jeden Fall dafür, in die nächste oder übernächste QSB ein ausgeprägtes Fehlertool einzubauen, dass darauf hinweist, dass bestimmte Verhalten nicht ausgeführt werden können (weil Einheit tot oder ähnliches), sowohl im Log als auch auf dem Bildschirm. Den Modus (Bildschirm/Log, detailliert/nur schwerwiegende Fehler) könnte dann der Mapper einstellen - dann könnten Fehler auch noch mit der fertigen Karte ins Log geschrieben werden

Also : eine komplett neue, einheitliche und getestet QSB ohne Reste von gestern.

Ja, aber für 2, 3 Wochen auf jeden Fall eine Übergangs-QSB neben der neuen, bereinigten - ansonsten wird es auch Mapper geben, die sich eine von Hand zusammenbauen, und das würde zu noch mehr QSBs führen

[Netsurfer]

Ein sehr komisches Verständnis von Kundenfreundlichkeit. Stell' Dir vor, MS würde das genauso handhaben mit Betriebssystemupdates - keiner würde es mehr machen.

Der Vergleich hinkt ... (schon klar: sonst wär's ja auch keiner)
Aber: Im Gegensatz zu einem OS oder sonstigen Anwendungsprogrammen ist die QSB eine "einmal" Variante! Will heißen, sie wird in der Form nur für die jeweilige Map gebraucht. Das ist imho auch einer der riesen Vorteile, da man nicht auf Abwärtskompatibilität achten muss!

Ja, da stimme ich Dir zu, dass es nicht zu viele Versionen geben sollte. Aber normalerweise wird für eine Übergangszeit gewährleistet, dass die alten Funktionen bestehen bleiben, einfach um Kompatibilität für kurze Zeit zu erhalten. Es geht auch nur darum, dass auch die Mapper, die schon mit einer Karte angefangen haben, auf die neue QSB relativ problemlos umsteigen können - und wenn es eine speziell ausgewiesene "Upgrade-QSB" ist, die nur für ein paar Wochen verfügbar ist. Schließlich sollen auch diese Mapper von den Bugfixes profitieren, oder?

Ich verstehe deinen Standpunkt, bzw. deine Ansicht und kann diese durchaus nachvollziehen. Es läuft halt auf die Frage raus, ob das wirklich (wieviele Mapper werden das sein, die davon überhaupt betroffen wären?) notwendig ist, oder ob ein klarer Schnitt nicht für alle Beteiligten besser ist?

Liest Du Dir jedes Mal das Changelog eines Programmes durch, wenn Du Dir ein Update besorgst? Ich nicht, ich gehe normalerweise davon aus, dass es vollständig funktioniert

Oh - aber natürlich mache ich das, und zwar bevor ich update! Manchmal lasse ich es dann nämlich lieber.

Ich wäre auf jeden Fall dafür, in die nächste oder übernächste QSB ein ausgeprägtes Fehlertool einzubauen, dass darauf hinweist, dass bestimmte Verhalten nicht ausgeführt werden können (weil Einheit tot oder ähnliches), sowohl im Log als auch auf dem Bildschirm. Den Modus (Bildschirm/Log, detailliert/nur schwerwiegende Fehler) könnte dann der Mapper einstellen - dann könnten Fehler auch noch mit der fertigen Karte ins Log geschrieben werden

Ja, die Idee finde ich auch "extremst" gut !

Ja, aber für 2, 3 Wochen auf jeden Fall eine Übergangs-QSB neben der neuen, bereinigten - ansonsten wird es auch Mapper geben, die sich eine von Hand zusammenbauen, und das würde zu noch mehr QSBs führen

Das Problem daran ist u.a. folgendes: Du kannst nicht sicherstellen, dass etwas auch wirklich verschwindet und nicht mehr verwendet wird, wenn du es vorher für einige Wochen ins Netz gestellt hast!
Aus diesem und anderen Gründen wäre ich nachwievor für einen strikten Versionssprung.

Gruß
Gunther

[trabbi]

Es läuft halt auf die Frage raus, ob das wirklich (wieviele Mapper werden das sein, die davon überhaupt betroffen wären?) notwendig ist, oder ob ein klarer Schnitt nicht für alle Beteiligten besser ist?

Das Problem daran ist u.a. folgendes: Du kannst nicht sicherstellen, dass etwas auch wirklich verschwindet und nicht mehr verwendet wird, wenn du es vorher für einige Wochen ins Netz gestellt hast!
Aus diesem und anderen Gründen wäre ich nachwievor für einen strikten Versionssprung.

Hat nicht sowieso jeder Mapper dieverse QSB auf seinem Rechner abgespeichert ??

[Netsurfer]

Hat nicht sowieso jeder Mapper dieverse QSB auf seinem Rechner abgespeichert ??

Keine Ahnung.
Fakt ist aber aktuell, dass es nur eine "offizielle" Version gibt (nämlich die vom 30.03.08). Wer selber "daran rumschraubt" verliert also quasi die "Garantie".

[LordFWD]

Wer selber "daran rumschraubt" verliert also quasi die "Garantie".

das hättest du aber auch mal vorher erwähnen können

[saladin]

Also ich glaube kaum das jemand, der die QSB richtig ändern kann, das nicht lieber gleich im Skript macht. Dann darf ich daran erinnern das die Anzahl der Mapper, die relativ stetig Karten produzieren, bei 18 liegt.

Den 18 People's ist sicher mehr als recht wenn ein Schnitt mit glatter Kante gemacht wird als das wieder ein rumgeiere stattfindet weil 2 People sonst 10 Minuten länger ihre Fehler suchen müssen.

Ich habe übrigens nur ein aktuelle Version auf dem Rechner.

Oh, und Fehlersuche: Es hat sich mittlerweile eine Kultur des Maptesting entwickelt. Jeder Mapper hat so seine Kumpel die sich mit seinen Kunstwerken auseinandersetzen. Bei unerklärlichen Fehlern wird hier gefragt - und meistens ist die Sache dann geregelt.

saladin

[trabbi]

Den 18 People's ist sicher mehr als recht wenn ein Schnitt mit glatter Kante gemacht wird als das wieder ein rumgeiere stattfindet weil 2 People sonst 10 Minuten länger ihre Fehler suchen müssen.

Außerdem werden evtl. Neumapper gleich mit dem richtigen Werkzeug arbeiten

[Fidelio1958]

Absturzbugs sind uns bisher nicht bekannt -

Dann lebst du allerdings am Mond, glaube ich.

Es gibt einige Absturz Maps, die bei Saladin und auch schon bei BB sind.

Abstreiten hilft da nichts, eine Lösung suchen und verbessern wäre der bessere Weg

Grüsse Wolfi

[BVernheim]

@ Fidelio1958
Ich habe gerade mal ein wenig QSB Luft geschnuppert. Es war ein (1) echter Bug (Trigger_OnAtLeastXOfYQuestsuccess) drin. Der sollte sich aber eigentlich nur in nicht funktionieren äussern. Drei andere waren im besten Fall Schönheitsfehler/Designfehler/Anwendungsfehler.

Das schlimmste waren wohl noch die Entities in den Replace Behaviors. Damit war ein Absturz provozierbar, was aber zum einen schon von BB so geliefert wurde, zum anderen nicht am System "QSB" liegt. Ein im normalen Script produziertes ReplaceEntity mit denselben Entitäten liefert den selben Absturz.

Hast Du noch andere Bugs die durch Verwendung der QSB zum Absturz führen? Ich denke dann wird die neue besser noch zurückgehalten.

Britta

[Old McDonald]

@Britta: Die Entities waren doch schon immer in den Replace-Belohnungen deaktiviert (Bauplätze und ähnliches). Das einzige, was ich hinzugefügt habe, war ein Check darauf, ob die Einheit, die den Ort angibt, tot ist

Direkte, offene, immer von einer Belohnung in der QSB erzeugte Absturzbugs sind uns nicht bekannt - das bedeutet aber nicht, dass überall zum Beispiel überprüft wird, ob eine Einheit tot ist. Das kann durchaus zu unerwarteten Ereignissen führen, inklusive eines Absturzes - aber das gleiche würde auch im Skript passieren (ehrlich: wer überprüft jedes Mal, ob eine Einheit tot ist?)

Außerdem werden evtl. Neumapper gleich mit dem richtigen Werkzeug arbeiten

Da würde ja ein Hinweis ausreichen, dass davon abgeraten wird, diese QSB zu verwenden, sie aber für aktuell schon begonnene Projekte für kurze Zeit zur Verfügung gestellt wird.

[saladin]

Die von Fidelio angemerkten Fehler sind von BB vorläufig als Probleme von Interaktionen zwischen Skript- und QSB Abläufen bezeichnet worden.

Kann ich nicht recht was mit anfangen, aber bitte. Jedenfalls sind die Fehler belast- und belegbar nicht eindeutig der QSB zuzuordnen, da ist wohl eher die Spielprogrammierung verantwortlich.

Merkwürdigkeiten gibt es immer wieder. DestroyEntity im Skript für ein Dekoobjekt fünktioniert, mit DestroySettler in der QSB nicht. Bezieht sich mittlerweile auf 7 Elemente. Ist vielleicht auch nicht so sensationell. Soweit ich das verstehe sind ja wohl alle Entitäten mit ihrem eigenen Eigenschaftspaket unterwegs. Egal, zur Zeit schmoren 5 Karten bei BB und harren der Erlösung.

Ich würde die QSB so wie sie momentan vorliegt und wie wir sie auch noch testen dann rauhauen. Irgendwelchen Ärger gibt's wohl immer.

saladin

[BVernheim]

@OldMcDonald
Asche auf mein Haupt, so genau hatte ich es gar nicht angesehen. Ich meinte es so aus deinem Post in Erinnerung zu haben in dem du auf die korrigierten Versionen hingewiesen hast.

@Saladin

Ich warte da nur auf euer Okay, momentan ist nichts Neues mehr in Arbeit.

Britta