Eintragsdetails ansehen

IDProjektKategorieSichtbarkeitZuletzt aktualisiert
0002670EresseaATTACKIEREöffentlich2020-06-07 12:28
ReporterEON Bearbeitung durchEnno  
PrioritätnormalSchweregradkleinerer FehlerReproduzierbarnicht getestet
Status erledigtLösungerledigt 
Produktversion3.23.3 
Zielversion3.25Behoben in Version3.25 
Zusammenfassung0002670: Fehlermeldung bei attackiere, Attacke wird trotzdem durchgeführt
Beschreibung

Die Einheit Alrik (ty0m) hatte in Runde 1170 die Befehle

"LERNE Hiebwaffen
// cript IfNotEnemy script lernen Hiebwaffen 20
// aus Safesnal
ATTACKIERE 8jj3 ;Xarx'zishlll"
bekommen.

In Runde 1171 erscheint folgende Fehlermeldung:
"Alrik (ty0m): 'ATTACKIERE  8jj3 ' - Dieser Befehl ist unbekannt."

Die Einheit hat aber dennoch angegriffen und den Gegner getötet. Nur die Fehlermeldung ist verwirrend.

Zusätzliche Informationen

Die Region wurde von einer meiner Einheiten mit Status kämpfe defensiv bewacht.

Durch einen menschlichen Fehler standen drei weitere Einheiten die ebenfalls angreifen wollten auf kämpfe fliehe. Diese bekamen je zwei Fehlermeldungen:

Konbarth (mkqk): 'ATTACKIERE  8jj3 ' - Dieser Befehl ist unbekannt.
Konbarth (mkqk) in Dusven (-8, -4): 'ATTACKIERE 8jj3 ' - Einheiten in den hinteren Reihen können nicht angreifen.

für die Einheiten Konbarth (mkqk), Arnie (vkrh) und Zwalrik (4cr9), Die zweite Fehlermeldung ist natürlich korrekt, könnte aber evtl. eine störende Wirkung entfaltet haben?

ParteigLod
SpielE2
Report1171

Notizen / Dateien

Enno

Enno

2020-06-03 20:32

Administrator   ~0008816

Hinter dem ATTACKIERE folgt ein c2a0, das wird wahrscheinlich nicht als whitespace erkannt: https://en.wikipedia.org/wiki/Non-breaking_space - ich dachte, die werden entfernt, und falls Du wirklich zu attackieren versucht hast (zweite Meldung), scheint das ja zumindest teilweise zu funktionieren. Gucke ich mir also gelegentlich mal an.

Einfachste Lösung: Keine seltsamen unsichtbaren Zeichen verwenden.

EON

EON

2020-06-03 20:57

Reporter   ~0008817

Das ist seltsam - ich nutze die Autovervollständigung von Magellan, keine Ahnung warum das mit einem mal Probleme machen sollte.

Enno

Enno

2020-06-05 18:07

Administrator   ~0008818

Nutzt Du denn auch den Versand aus Magellan, oder irgendwelchen Webmail-Mist?

EON

EON

2020-06-05 19:47

Reporter   ~0008819

Ich habe den Versand aus Magellan eingestellt wegen der Spam Klassifizierung. Aber über Webmail gehe ich auch nicht, ich kopiere direkt nach Thunderbird. Das habe ich aber auch schon früher gemacht, ohne Probleme. Keine Ahnung wie sich das Zeichen jetzt eingeschlichen hat. Halte ich aber auch nicht weiter für wichtig solange es nicht wieder passiert, und der Agriff wurde ja auch durchgeführt. => Forensische IT kann beendet werden ;-)

Enno

Enno

2020-06-05 19:57

Administrator   ~0008820

Ich kann mir immer noch nicht vorstellen, dass das mit der Spam-Klassifizierung an Magellan liegt, aber Spamfiltern ist ja eher eine Pseudowissenschaft, da soll man nicht zu viel vermuten.
Wenn der Versand aus Thunderbird den Text ändert, dann versuch es doch mal mit den Befehlen als Attachment an der Mail. Das sollte der Befehlsempfang kapieren.

Enno

Enno

2020-06-06 11:13

Administrator   ~0008821

In einer Neuauswertung mit aktuellem Code auf meinem Rechner (Windows) tritt das Problem nicht auf. Auf dem Originalrechner (Linux) aber schon. Sicher ein Unterschied in der C standard library, in sowas wie isspace() oder isctrl()?

Enno

Enno

2020-06-06 11:34

Administrator   ~0008822

Für das Zeichen sind iswspace und iswcntrl auf Linux beide 0. Das Problem scheint in unicode_utf8_trim zu sein, aber auch in der parse_token Schleife könnte man das schon überspringen?

Enno

Enno

2020-06-06 11:36

Administrator   ~0008823

char_trimmed(160) ist true in Windows, false in Linux.

Enno

Enno

2020-06-06 13:11

Administrator   ~0008824

https://stackoverflow.com/questions/50952142/why-are-no-break-space-and-others-ispunct-in-glibc

EON

EON

2020-06-06 15:43

Reporter   ~0008825

Na, da habe ich ja was losgetreten ;-)

Enno

Enno

2020-06-07 12:25

Administrator   ~0008826

Ich habe eine Lösung gewählt, die ohne die unzuverlässige iswspace Funktion auskommt, und die drei fehlenden Zeichen in char_trimmed() hart kodiert. Das Problem ist, dass iswspace entscheidet, ob ein Zeichen eine Trennung zwischen zwei Worten erlaubt (also z.b. einen Zeilenumbruch im Report), was nicht das Gegenteil der Frage ist, ob es Teil eines Wortes ist. Da es keinen Sinn macht, diese Zeichen an Anfang oder Ende eines Wortes zu setzen, kann ich sie aber getrost löschen, wenn sie das erste oder letzte Zeichen sind (wozu char_trimmed benutzt wird). Testreport zeigt jetzt, dass der Befehl nicht mehr abgelehnt wird!

Eintrags-Historie

Änderungsdatum Benutzername Feld Änderung
2020-06-02 22:27 EON Neuer Eintrag
2020-06-03 20:32 Enno Notiz hinzugefügt: 0008816
2020-06-03 20:32 Enno Bearbeitung durch => Enno
2020-06-03 20:32 Enno Status neu => zugewiesen
2020-06-03 20:57 EON Notiz hinzugefügt: 0008817
2020-06-05 18:07 Enno Notiz hinzugefügt: 0008818
2020-06-05 19:47 EON Notiz hinzugefügt: 0008819
2020-06-05 19:57 Enno Notiz hinzugefügt: 0008820
2020-06-06 11:13 Enno Notiz hinzugefügt: 0008821
2020-06-06 11:34 Enno Notiz hinzugefügt: 0008822
2020-06-06 11:36 Enno Notiz hinzugefügt: 0008823
2020-06-06 13:11 Enno Notiz hinzugefügt: 0008824
2020-06-06 15:43 EON Notiz hinzugefügt: 0008825
2020-06-07 12:25 Enno Notiz hinzugefügt: 0008826
2020-06-07 12:28 Enno Produktversion 3.23 => 3.23.3
2020-06-07 12:28 Enno Behoben in Version => 3.25
2020-06-07 12:28 Enno Zielversion => 3.25
2020-06-07 12:28 Enno Status zugewiesen => erledigt
2020-06-07 12:28 Enno Lösung offen => erledigt