Argh, jetzt sehe ich, dass sie Steine rückübergeben werden...

Trotzdem sind die Fehlermeldungen falsch.

Wann haben wir denn eine "neue" Reservierungsregel eingeführt? Bin mir keiner Änderung bewusst, aber mein Gedächtnis ist bekanntermaßen nicht das beste.

Nach meiner Erinnerung war das 2014. Wir haben verändert, dass reservierte Gegenstände niemals übergeben werden. Und alle mit GIB übergebenen Gegenstände sind reserviert.

Mit anderen Worten bedeutet dass, dass jeder Gegenstand nur einmal übergeben werden kann. Sowas wie "A gibt B, B gibt an C weiter" funktioniert nicht.

Wenn ich folgende Annahmen mache, kann ich den "Bug" nachvollziehen:

• Lif1 und L6iv haben genau 280 bzw. 240 Steine
• 2b37 ist in der Einheitenreihenfolge vor den beiden anderen (z. B. als Regionsbesitzer)

Dann passiert folgendes:

EINHEIT 2b37; Steinmetze, 0 Steine @GIB Lif1 480 stein ; Übergibt Lif1 480 Steine, und zwar Lif1's eigene aus dem Materialpool! ; Das ist natürlich Quatsch, aber was erwartest du? @GIB L6iv 240 stein ; übergibt L6iv seine eigenen Steine ; jetzt wurden alle Steine der Region übergeben und sind damit alle reserviert @GIB tra5 381 stein ; Erzeugt die erste Fehlermeldung ; Die Einheit hat keine Steine und kann sich auch keine aus dem Pool holen @GIB koxr 74 stein ; Erzeugt die zweite Fehlermeldung (keine Steine mehr frei)

EINHEIT Lif1; hat am Anfang 480 Steine @GIB 2b37 480 stein ; Erzeugt die vorletzte Fehlermeldung ; "Die Einheit hat diesen Gegenstand zwar, aber sämtliche 480 Steine sind reserviert." ; Nämlich durch das GIB weiter oben

EINHEIT L6iv; hat am Anfang 240 Steine @GIB 2b37 240 stein ; erzeugt die letzte Fehlermeldung

Einen Bug kann ich hier nicht erkennen. Aber:

Welche Fehlermeldungen sind hier falsch bzw., welche wären hilfreicher?

Welche Regelseiten sind veraltet?

Welche findest du irreführend und hast du eine Idee, wie man sie klarer formulieren könnte?

Die Wirkung von RESERVIERE wurde vor wenigen Wochen (maximal 12 Wochen?) geändert, seitem gibt es reichlich unerwartete Überladungen, da @GIB und RESERVIERE sich ins Gehege kommen, was eigentlich nur dann Probleme macht, wenn diese Befehle gemischt werden, so z.B. regelmäßig bei Handelsschiffen, die für andere Völker arbeiten, also keinen Kontor/Einheit im Hafen haben und folglich keine Silberreserve dort und von der Versorgung durch ein anderes Volk abhängig sind. Problematisch dann, wenn sie zurück pendeln und dort Silber per RESERVIERE zuladen. Mittlerweile habe ich aber da wohl alle Fehler gefunden und angepasst, nur das Entladen von Silber funktioniert nicht per GIB x y SILBER, sofern auch noch ein RESERVIERE parallel läuft, da halt bis auf den Sockelbetrag von RESERVIERE kein Silber abgegeben wird und ein @GIB x y SILBER eines Allierten dann automatisch zu Überladung führt, zumindest wenn auf maximale Schiffsauslastung beladen wird abseits des Silbers.

Was Fehlermeldungen angeht, so fällt mir auch nichts besseres ein, ich finde die Logik nach wie vor irritierend, kann aber damit leben, da damit endlich das RESERVIERE x SILBER von sich kreuzenden Handelsschiffen in dem Sinne behoben wurde, dass sie sich nicht mehr gegenseitig Silber abnehmen und regelmäßige Havarieren provozierten. Dann lieber wunderliche Fehlermeldungen, das ist weniger Mikromanagement.

Regeln, online sind nur diese hier, denke ich? --> https://wiki.eressea.de/index.php/RESERVIERE#Fehlerquellen Eine herunterladbare wäre natürlich hübsch, meine .chm-Datei ist von 2001.

Egal, wie man es macht, es wird immer Fälle geben, wo das Verhalten unerwünscht ist. Die gegenwärtige Regelung ist recht robust, dafür etwas zu kompliziert.

Ich habe mal die Regeln, die den Materialpool, GIB und RESERVIERE betreffen, an einer Stelle zusammengefasst:

https://wiki.eressea.de/index.php/Materialpool

Soweit ich mich entsinne wurde ein gib sich selbst x dinge früher immer mit einen "Das ist sinnlos" kommentiert und NICHT ausgeführt. Warum das jetzt anders ist, weiß ich nicht. Auch wurde das Reserviere vor einigen Monaten angepasst, aber nur in so weit das es nicht mehr möglich ist einer Einheit Dinge mit Reserviere wegzunehmen welche sie selber reserviert. Da Steine in dem hier geschilderten Problem gar nicht Reserviert werden, kann es nicht daran liegen. Das GIB die dinge bei der Zieleinheit reserviert war schon sehr lange so, denn sonst könnte eine späteres GIB die ja wieder wegnehmen und es wäre nicht mehr vorherzusagen wo etwas landet.

Ich denke der Fehler ist das aus irgend einem Grund der "Gibt sich selbst Check" weggefallen ist , und es keine "Das ist sinnlos" Meldung mehr gibt sonder es einfach stur ausgeführt wird.

Das sollte aber recht schnell zu fixen sein.

Hier hat niemand sich selbst etwas gegeben.

EINHEIT 2b37 hat Steine an EINHEIT Lif1 übergeben. Diese wurden aus dem Materialpool genommen, und zufällig waren dort als erstes die Steine von EINHEIT Lif1 drin. Ein Versuch, das zu verhindern oder irgendwie anders zu regeln, würde meiner Meinung nach nur neue Probleme schaffen. Das einzige, was man tun könnte, wäre eine Meldung zu erzeugen wie "Einheit 2b37 übergibt Einheit Lif1 ihre eigenen Steine". Das könnte allerdings zu viel "Logspam" führen.

Statt "Die Einheit hat diesen Gegenstand nicht" könnte man sagen "Von diesem Gegenstand ist nichts mehr/nicht mehr genug in der Region verfügbar." Oder "Alle Steine in der Region sind bereits reserviert."

Und wenn man dabei wäre, sollte man gleich noch Meldung einführen für "Einheit x übergibt/reserviert 5 von 10 Silber", falls beim Geben/Reservieren nicht genug Silber im Pool ist. Ich bin aber nicht sicher, ob man so viele neue Meldungen überhaupt haben will.

Ah ja. Die Einheit bekommt schon ihre eigenen Steine aber nicht weil sie die sich selbst gibt, sondern weil eine andere Eineheit die aus dem Pool an sie zurück gibt. Alles klar. Da kann ich nur sagen Gib alles übergibt nur Sachen welche die Einheit auch selbst hat und die nicht reserviert sind. Ich verwende für die Transporter immer @Gib Alles wenn sie "abkippen" sollen, das klappt prima.

Und: EINHEIT 2b37; Steinmetze, 0 Steine @GIB Lif1 480 stein

EINHEIT Lif1; hat am Anfang 480 Steine @GIB 2b37 480 stein

Ist doch irgendwie totaler Qwatsch. Entweder die Steine sollen zu Lif1 oder zu 2b37. Beides kann nicht klappen. Wenn genug Steine in der Region wären würde der Transporter auch nie was abgeben. Da ist irgendwas mit den Befehlen nicht richtig.

PS: Reserviere hatte schon immer Vorrang vor GIB. Das ist ja der Trick an Reserviere. Daher kann ich dein Schiffsproblem auch nicht ganz nachvollziehen.

Ich bin auch der Meinung, der Titel dieses Bugreports ist mindestens irreführend, denn Steintransporte sind ja weiterhin möglich (z.B. wenn man nicht RESERVIERE benutzt). Ich glaube auch eher, dass hier kein Bug vorliegt, sondern einfach eine komplexe Situation schwer zu verstehen ist, und in dem Fall würde ich zu einfacheren Befehlsmustern raten, besonders wenn man sowieso mit Skripten arbeitet. Es hat jedenfalls noch niemand anderes einen Bug gemeldet.

Jau, hab ich ja gesagt, es ist kein Bug, jetzt verstehe ich die Abläufe.

Und habe auch erst den Bugreport geschrieben und dann beim Sammeln der Informationen wurde mir klar, dass die Steine hin und her gegeben wurden, jetzt sind zwei alte @GIB-Befehle entsprechend gelöscht.

Nur haben mich die Fehlermeldungen irritiert.

Was die Schiffstransporte angeht. Das kann nur passieren, wenn zwei Parteien interagieren. Partei A hat das Schiff und noch Restsilber. Bekommt im Hafen von Partei B per @GIB bei jedem Anlanden Silber für die weitere Reise. Jetzt aber wird einmal überladen, wegen 10 Silber ist eine Überladung von 0,1 GE entstanden. In der Folgewoche laufen die automatisierten Befehle von Partei B weiter, also noch mehr Überladung. Um dem entgegen zu wirken, gibt Partei A Silber zurück. Da Partei A allerdings im anderen Pendelhafen per RESERVIERE Silber abgreift (weil eigener Hafen), kann nicht mehr als bis zur RESERVIERE-Grenze an Partei B abgegeben werden und es kommt laufend zur Überladung.

Ich brauchte dann eine Anpassung des @Gib Silber von Partei B bzw. ein Aussetzen des Befehls, um überhaupt ablegen zu können. Habe allerdings ein GIB 0 nicht erwogen, das hätte das Problem wohl auch gelöst. Im jeweiligen Report stand immer nur die Fehlermeldung des nicht möglichen Ablegens wegen Überladung, im Regionsreport waren die Schiffe genau mit 3000 GE beladen, also nicht überladen. Die 20 bzw. 30 Silber zuviel waren eigentlich durch Rückübergabe weg, aber irgendwie dann doch nicht.

Nein, die wurden nicht "zurückübergeben" sondern einfach nach dem NACH am Ende der Runde von deiner Besatzung aufgegessen. Ein Schiff das Silber an board hat und genau zu 100% beladen ist (im Report) war zum Zeitpunkt des Segeln (NACH Befehl) überladen, denn du musst immer noch das Silber draufrechnen was deine Leute auf dem Schiff jede Runde an Unterhalt verbrauchen. Arbeite ist da auch noch so ein Fallstrick, da ja erst Verdient wird, dann bei NACH das Gewicht überprüft, und dann Gegessen. Und im Report sieht alles gut aus.

Übrigens, wenn du das RESERVIERE kurzzeitig anpassen willst, es gilt immer nur der letzte Reserviere Befehl den die Einheit für einen Gegenstand hat.

@Reservier 1500 Silber Reserviere 800 Silber GIB xyz ALLES Silber

Die Einheit behält genau 800 Silber und nächste Runde steht immer noch der richtige Reserviere Befehl bei der Einheit (@RESERVIERE 1500 SILBER).

Das Verhalten das du dinge welche mit Reserviere "Festgehlaten" werden nicht übergeben kannst ist aber auch nicht angefasst worden, das ist auch schon so lange ich mich zurückentsinnen kann so.

Wichtig (weil nicht Intuitiv)ist nur das GIB auch gleichzeitig Reserviert. Wenn man das weiß passt auch die Fehlermeldung.

Ich denke das kann zu?

PS: Gib 0 dürfte genau so nicht gehen, Reserviert ist Reserviert.

Ich denke wir waren uns einig das es hier keinen Bug gibt.