Eintragsdetails ansehen
| ID | Projekt | Kategorie | Sichtbarkeit | Meldungsdatum | Zuletzt aktualisiert |
|---|---|---|---|---|---|
| 0000156 | Magellan | Funktionen | öffentlich | 2008-03-20 04:48 | 2008-05-23 17:17 |
| Reporter | Askarloth | Bearbeitung durch | darcduck | ||
| Priorität | normal | Schweregrad | kleinerer Fehler | Reproduzierbar | immer |
| Status | erledigt | Lösung | erledigt | ||
| Zielversion | 2.0.2 | Behoben in Version | 2.0.2 | ||
| Zusammenfassung | 0000156: CR-Merging bei gefällten Bäumen | ||||
| Beschreibung | Fehler tritt in Regionen auf, deren Bäume oder Schößlinge vollständig gefällt wurden: Beispiel: Region mit 240 Schößlingen in der Vorwoche, die komplett gefällt wurden 1. Der neue Orginal-CR enthält keine Tags für Bäume. 2. Der alte Orginal-CR wird hinzugefügt. (andersrum tritt der Fehler auch auf) 3. Der erstellte CR enthält unter anderem folgende Tags für die entsprechende Region, die sich auf Bäume beziehen: 0;letztebaeume 240;letzteSchoesslinge RESOURCE 1355696724 "Schößlinge";type 240;number Einen Tag "240;Schößlinge" gibt es nicht. Der Block "RESOURCE" ist irgendwie falsch... | ||||
| Tags | Keine Tags zugeordnet. | ||||
| Project | Magellan 2 | ||||
|
|
Ja, ist mir auch schon aufgefallen. Es kommt dann durchaus zu Diskrepanzen in der Detail-Ansicht. Die ATR Meldung scheint richtig, die Baumansicht (im Sinne von JTree) nicht. Das ist ein Folgefehler des fehlerhaften Mergen. |
|
|
Das ganze hat Fiete doch schon mal überarbeitet? Genau wegen dieser Problematik. Deshalb sind die Resourcen jetzt nach "Sichtbar" oder "Talentabhängig sichtbar" eingeteilt. In MagellanFactory.java -> mergeRegion() 1238: // Fiete: check here if we have skillIrrelevantResources // if curRes == null AND we have units in curReg -> these // resources are realy not there anymore: Baeume, Mallorn if (sameTurn){ if (skillIrrelavntTypes.contains(newRes.getType())){ // we have "our" Type // do we have units in newRegion i guess the sameTurn check here is wrong, because when we add a report of a newer turn, then this would mean skipping this part of coding. I think we could also change RegionResource.merge() throwing out much of the coding to determine which resources need to be deleted. An old regionResource having getSkillLevel == -1 means this is a resource without a skilllevel required to see it - horses, wood or mallorn. RegionResource.merge() should now allow adding a newResouce == null. Then we have 3 cases: 1. level dependent & (curResource.skillLevel != -1) && 1.1. seen & (higher level | less amount): (newResource != null) && ( (newLevel > oldLevel) || ((newLevel == oldLevel) && (newAmount < oldAmount)) ) => newResource = newResource (no change) 1.2. else: => newResource = curResource 2. not level dependent: (curResource.skillLevel == -1) => newResource = newResource (no change) This might work ... haven't tested it ;-) |
|
|
he? Bäume sind nicht Talent-abhängig sichtbar (oder verstecken die sich neuerdings). Das betrifft also allein die IF Bedingung 2. Aber ich denke, das ist eher nur ein Darstellungsproblem zwischen den Regionsdetails und dem ATR Renderer (der graue Kasten). Einer von beiden (ich vermute unterer) greift auf falsche Daten zu. Ich glaube mittlerweile nicht mehr, dass es ein Merge-Problem ist. |
|
|
Im gemergeten CR steht drin, dass es Bäume in der Region gibt, obwohl da keine sind. Muss das dann nicht ein Merge-Problem sein? Selbst wenn auf die falschen Daten zugegriffen wird - immerhin steht im grauen Kasten oben der richtige Wert und nur unten im weißen Kasten der falsche - der Eintrag im CR macht keinen Sinn. |
|
|
Ja, stimmt. Das hatte ich überlesen. |
|
|
Der ATR greift wohl auf die Tags von Region zu, die sind richtig - auch nach dem Mergen. Aber eigentlich sind die Tags "deprecated". Richtig wäre nur noch die RESOURCE Blöcke zu verwenden. Leider werden diese noch falsch gemergt. Der sameTurn check in Zeile 1241 darf m.E. nicht sein. Falls ich Einheiten dort habe, es sich um eine nicht stufenabhängige Resource handelt und diese nicht aufgeführt ist, dann ist auch nichts davon vorhanden. Ob ich nun zu einem alten einen neuen hinzufüge oder mehrere aus der gleichen runde ist dabei egal. |
|
|
Richtigerweise müsste man die Visibility prüfen. Bei 1 (contains own units) und 2 (travel) sieht man meines Wissens nach Bäume, Schösslinge und Pferde, also alle nicht talentabhängigen Resourcen. Blöderweise wird die Visibility schon verändert bevor die Resourcen ausgewertet werden. sonst könnte man bei newRegion.getVisibility()>2 bereits abbrechen und die Resourcen von curRegion verwenden. |
|
|
Hm ... nein das geht auch nicht. Nämlich dann nicht wenn zwei gemergte Reports gemergt werden. (a1+a3) + (b2+b3) Immer bezogen auf eine Region: Reporte a1 und b2 enhalten Resourcen - b2 ist also aktueller. Die Reporte aus Runde 3 enthalten nur visibility 4 (nachbar). Die gemergten b reporte werden nun den a reporten zugefügt. a ist also current und b new. da b aber von b3 den visibility status erbt haben die b reporte zusammen status 4. Damit würde automatisch a genommen werden. => das ist ein detailproblem und kann ohne Zusatzinfo auch nicht behoben werden. => ich könnte daher mit der vorher genannten variante leben => langfristig würde ich aber die Resourcen-Blöcke mit runde tags versehen wollen. |
|
|
ich glaube, wir kommen um diesen Runde-Tag langsam nicht mehr herum. Ich hab ein sehr ähnliches Problem mit den Talentwerten von Einheiten, die ich nicht mehr "sehe". Es ist dann sehr schwierig, herauszufinden, welche Resource/Einheit/Region jetzt besser passt. Ich denke, dass sollten wir aber gemeinsam auf der Mailingliste diskutieren, da dass wieder ein Eingriff in das Format des CRs ist. |
|
|
So repariert. Das löschen war ja gut gedacht. Leider griff das nur auf die Collection durch, nicht auf die HashMap in der die Daten primär gespeichert sind. Ich habe das jetzt korrigiert, und damit niemand wieder auf die Idee kommt die collection, die von resources() zurückgeliefert wird, zu modifizieren, ist das jetzt eine UnmodifyableCollection. Die Logik habe ich soweit angepasst, dass nun die visibility geprüft wird. Ist sie 3 oder 4 sollten Resourcen sichtbar sein. Der Units.size>0 check hat zwar auch meist funktioniert, aber nur, weil in fast jeder Region besetzte Gebäude sind. Deren Einheiten sieht man ja auch beim durchreisen. Checke es heute Abend ein. |
| Änderungsdatum | Benutzername | Feld | Änderung |
|---|---|---|---|
| 2008-03-20 04:48 | Askarloth | Neuer Eintrag | |
| 2008-03-25 09:33 | trickert | Status | neu => bestätigt |
| 2008-04-07 23:33 | trickert | Zielversion | => 2.0.1 (Planning) |
| 2008-04-08 23:28 | trickert | Zielversion | 2.1.0 => 2.0.1 (Planung) |
| 2008-05-04 08:07 | trickert | Zielversion | 2.0.1 => 2.0.2 (Planung) |
| 2008-05-23 17:16 | darcduck | Status | bestätigt => zugewiesen |
| 2008-05-23 17:16 | darcduck | Bearbeitung durch | => darcduck |
| 2008-05-23 17:17 | darcduck | Status | zugewiesen => erledigt |
| 2008-05-23 17:17 | darcduck | Behoben in Version | => 2.0.2 (Planung) |
| 2008-05-23 17:17 | darcduck | Lösung | offen => erledigt |
