Ich wünsche mir einen Befehl <select-inverted/>, der folgendes bewirkt:
- Alle vormals selektierten Helden sind nicht länger selektiert
- Alle vormals nicht selektierten Helden sind selektiert

Das hätte ich bestimmt schon 10 mal brauchen können und würde aufwendige, auf Variablen basierende Konstruktionen ersparen.

Ginge das bitte, Zwerch?

Hagen vH hat geschrieben:Ich wünsche mir einen Befehl <select-inverted/>, der folgendes bewirkt:
- Alle vormals selektierten Helden sind nicht länger selektiert
- Alle vormals nicht selektierten Helden sind selektiert

Das hätte ich bestimmt schon 10 mal brauchen können und würde aufwendige, auf Variablen basierende Konstruktionen ersparen.

Ginge das bitte, Zwerch?

Das unterschreibe ich voll und ganz!

(Kohärenter wäre aber wohl <select inverted="true"/>.)

Was soll passieren, wenn vorher alle selektiert sind. Dann nur der Gruppenführer.

Man sollte natürlich drauf achten, dass nicht alle selektiert sind. Wären aber alle selektiert und anschließend demnach keiner, dann den Anführer. Das ist ja jetzt auch schon so bei den anderen Funktionen von Select, dass wenn niemand selektiert würde, der Anführer herhalten muss.

select inverted="true" ist jetzt verfügbar, habs auch ins Wiki eingetragen.

Vielen Dank!

Mal gucken, ob ich die Funktion morgen schon irgendwo einsetzen kann.

Super! Danke!!

Wäre es möglich, dass man bei Var-dump auch Variablen mit dem scope dungeon anzeigen lassen könnte?

Ist jetzt drin.

Gaddezwerch hat geschrieben:select inverted="true" ist jetzt verfügbar, habs auch ins Wiki eingetragen.

Woah! Super! Ein Krampf weniger bei den Gruppenklamotten.

Es ist zwar schon länger/lange her, dass ich wirklich im Editor selbst Szenen sortiert habe, weil ich zumeist ja doch eher Korrekturlese. Da ich mich nun allerdings endlich mal wieder an zwei meiner Questprojekte setzen will bin ich wieder mit Anordnung von Szenen im Editor in Kontakt gekommen.

Als hoffentlich einfachsten Wunsch habe ich, dass die .aoqml-editor zukünftig logische Zeilenumbrüche enthält. Wie ich sie mal für ein Beispiel nach einem realen Beispiel gesetzt habe.

Code: Alles auswählen

<?xml version="1.0" encoding="UTF-8"?>
<aoqml-editor-config>
  <scene-node-positions>
    <position name='Nachsehen' x='424.89381909531375' y='67.20327067092848'/>
    <position name='oeffnen' x='658.3138640658003' y='162.39702246533392'/>
    <position name='Ziehen' x='559.1980966054206' y='90.71309513017792'/>
    <position name='Beutel' x='481.9865233833241' y='165.17753013526385'/>
    <position name='Schauen' x='503.6067358282156' y='20.80758695928462'/>
    <position name='start' x='248.0' y='198.0'/>
    <position name='umschauen' x='308.16848118579895' y='121.90307842940871'/>
    <position name='Ziehen1' x='660.0365354642563' y='85.58554631854042'/>
    <position name='Mitnehmen' x='542.433335598688' y='326.96242436761344'/>
    <position name='Mitnehmen1' x='308.9782672911396' y='464.972229560709'/>
    <position name='Haken' x='582.1749899922196' y='25.651658451719072'/>
    <position name='ende1' x='184.35279639512942' y='52.40296959649356'/>
  </scene-node-positions>
  <questnotes><![CDATA[]]>
</questnotes></aoqml-editor-config>

Ein weiterer, frommer Wunsch ist es, dass man zukünftig verbesserte Möglichkeiten zur automatischen Anordnung hätte, ODER dass man ein Format aus dem AOQML-Editor erhält, welches man zum Beispiel mit dem yEditor verarbeiten kann (präferiert, weil man dann "nur" die Schnittstelle braucht).
Ich will mir das bei Zeiten selbst auch mal anschauen, dass ich eine .xls versuche zu erstellen. Dabei fehlt mir allerdings die Information über die Beziehung der Knoten untereinander. In der jetzigen Form sind lediglich die Koordinaten der Szenen gespeichert, den Rest erarbeitet der Editor noch anhand der Szeneninhalte.
Gerade bei großen Questen mit zig unzähligen Szenen wäre ich echt so manches Mal froh, die Quest einfach im yEditor zu laden, um dann dort die gewünschten Pfade mir herausarbeiten zu können.

Ein weiterer, kleiner Zwischenschritt wäre es, würde man die Präzision der Positionierung senken. 14 Nachkommastellen sind zwar für's Programm uninteressant, aber sollten doch Zwei, maximal Vier doch auch eine eindeutige Positionierung ermöglichen.

Soweit erst einmal von mir an dieser Stelle. Vielleicht findet sich ja ein Weg, um die Möglichkeiten in der Hinsicht deutlich zu verbessern, ohne den Editor vollkommen neuerfinden zu müssen.

Enno hatte bisher den Editor gemacht. Wie gut ist dein Java? ^^

Ich kann bestimmt Bomben programmieren. Also irgendwie Pseudocode, der wenn, er überhaupt etwas macht, sicherlich nur Alles kaputt, womit er arbeitet.

Java ist so überhaupt nicht meins! Danke der Nachfrage ^^

Der Todschlagwunsch schlechthin natürlich: Schnipsel für alle vorhandenen Befehle.

Weil es mir gerade aufgefallen ist: Neuladen der Quest per Button

Der Editor dürfte bezüglich der Groß-/Kleinschreibung bei den Szenen nachlässiger sein: start = Start = sTart wäre etwas was ich persönlich sehr angenehm fände.
Immerhin sollte eh niemand auf die Idee kommen seine Szenen nach dem Schema Kampf #1 = Kampf, Kampf #2 = kAmpf, Kampf #3 = kaMpf zu bennen. Ich zumindest schreibe dem Anschauenden gefällig Szenennamen groß und stehe so gar nicht auf alles in Kleinbuchstaben, obwohl ich die Konsequenzen ahnen kann.

Es ist zwar nur Optik, aber ich mag es eben anders und wünsche mir daher: Neue Szenen enden bisher immer mit </scene> /nl und wenn man die Szene dann öffnet startet man mit dem Tippen in der falschen Zeile Sieben. Zum Einen bitte entsprechend die neue Zeile entfernen und den Cursor in Zeile Vier beginnen lassen.

EDIT: Neue Szenen werden "irgendwo" im Editor eingefügt - könnte man dies auf immer mit Abstand X rechts daneben und bei mehreren Szenen gleichzeitig diese dann auch noch übereinander gestapelt oder eben immer weiter rechts daneben dressiert werden?
Meine Wünsche zur Positionierung und Ausrichtung der Szenen habe ich ja schon mal publiziert

Bezugnehmend auf den Beitrag von Proser im Spoiler möchte ich an dieser Stelle die angesprochene Erweiterung des "useBE"-Flags hier aufgreifen.



An dieser Stelle wäre es dann sogar noch schön, würde der Editor irgendwann™ bei einer Probe direkt den BE-Einfluß mitangeben, sodass man talentabhängig weiß, ob 0*/1*/2*BE die Probe grundsätzlich erschwert. Wie so oft jedoch pures Gimmick und Nice to have