View Issue Details

IDProjectCategoryView StatusLast Update
0000721EresseaGeneralpublic2006-04-16 23:43
Reporterdefaitist Assigned ToEnno  
PrioritynormalSeverityminorReproducibilityalways
Status closedResolutionfixed 
Summary0000721: nicht im Kampf beteiligte Person kann keine langen Befehle ausfuehren
Description

Die Wahrnehmerin einer Gletscherexpedition ist nach 2fachem Hungern verhungert. Sie hat den Befehl ARBEITE erhalten und den Status "kaempfe nicht" gehabt, wurde allerings von 7 Juju-Zombies angegriffen. Diese konnten allerdings von den in der ersten Reihe stehenden 42 Personen abgewehrt werden.

Also ist kein Treffer gegen die Einheit erfolgt und folglich sollte auch ein ganz normaler langer Befehl moeglich sein. War aber nicht und sie ist verhungert, da ich nicht damit gerechnet haette, sonst haette sie wahrscheinlich mit einem reserviere-befehl gerettet werden koennen.

--> Milena Muschelkalk (ntij) verliert in Lesotho (-17,-19) 1 von 1 Personen durch Unterernährung.

TagsNo tags attached.
Factionstyx
Game
Report443

Relationships

related to 0000708 closedEnno Umsetzung announce vom 13.9. offenbar noch nicht erfolgt 

Activities

Enno

Enno

2005-10-16 21:46

administrator   ~0001531

Einheiten, die im Kampfreport auftauchen, verhalten sich bzgl. ihrere langen Befhle alle gleich - wenn deine erste Reihe es nicht schafft, die Feinde in einer Kampfrunde abzuwehren, dann gilt der Verlust des langen Befehls auch für die zweite bis letzte Reihe.

Lange Befhle trotz Kampf ausführen zu können ist eine Ausnahme, die nur gelten soll, wenn es sich um unbedeutende Scharmützel handelt, und das war's hier nicht.

Enno

Enno

2006-01-15 11:24

administrator   ~0001645

Mein Kommentar da sieht falsch aus, insbesondere mit Blick auf das Beispiel in http://eressea.upb.de/pipermail/announce/2005-September/000591.html

Lange Befehle (nicht NACH) sollten möglich sein, wenn man an einem Kampf unbeteiligt war. Oder die Regel muss geändert werden, wenn das nicht geht. Aber Verahlten und Regel passen nicht zusammen. Falls das wirklich sich so verhält (Tiuri sagte, bei ihm hat's geklappt).

Enno

Enno

2006-01-15 17:48

administrator   ~0001649

Fehler ist gefunden und behoben. Vond em alten Gruppen-Code war noch ein Überrest dabei, der das verursaht hat.

Issue History

Date Modified Username Field Change
2005-10-10 11:51 defaitist New Issue
2005-10-10 11:51 defaitist Partei/Faction => styx
2005-10-10 11:51 defaitist Report No. => 443
2005-10-11 22:31 Enno Status new => assigned
2005-10-11 22:31 Enno Assigned To => Enno
2005-10-16 21:46 Enno Status assigned => resolved
2005-10-16 21:46 Enno Resolution open => no change required
2005-10-16 21:46 Enno Note Added: 0001531
2006-01-15 11:24 Enno Note Added: 0001645
2006-01-15 11:24 Enno Status resolved => confirmed
2006-01-15 11:27 Enno Relationship added related to 0000708
2006-01-15 17:48 Enno Status confirmed => resolved
2006-01-15 17:48 Enno Resolution no change required => fixed
2006-01-15 17:48 Enno Note Added: 0001649
2006-04-16 23:43 Enno Status resolved => closed