Eintragsdetails ansehen
| ID | Projekt | Kategorie | Sichtbarkeit | Meldungsdatum | Zuletzt aktualisiert |
|---|---|---|---|---|---|
| 0000008 | Magellan | CR-Support | öffentlich | 2007-03-14 01:04 | 2008-06-12 08:07 |
| Reporter | Fiete | Bearbeitung durch | trickert | ||
| Priorität | normal | Schweregrad | Feature-Wunsch | Reproduzierbar | immer |
| Status | erledigt | Lösung | erledigt | ||
| Zielversion | 2.1.0 | Behoben in Version | 2.0.2 | ||
| Zusammenfassung | 0000008: Runde tag in REGION Blöcken | ||||
| Beschreibung | von Ralf: Beim mergen von Karten Reports gibt es fast immer die Probleme, dass nie alle Regionsnamen stimmen, weil beim Mergen ein Report als jünger gilt und alle Namen von dort dann vorgezogen werden. Realität ist aber, dass zwei Völker unterschiedliche Gebiet unterschieldich aktuell haben. Jeder halt seine Insel. Mein Request hier wäre in Magellan zumindest für REGION Blöcke die Rundeninformation (tag runde) in die Regionsblöcke zu schreiben sofern nicht der aktuellen Runde des CRs entsprechend. Beim mergen eines Reports der Vorrunde mit dem aktuellen, muss also die Rundeninfo für alle nicht gesehenen Regionen auf der alten Runde bleiben. Die Einleselogik müsste dann natürlich auch entsprechend angepasst werden. Wie man aber mit unterschiedlicher Detailinformation aus unterschiedlicehn Runden umgeht ist eine andere Frage die wir sicher nicht so schnell klären. Darum geht es mir auch nicht, nur um aktuelle Namen und die hat man immer. Grüsse Ralf | ||||
| Tags | Keine Tags zugeordnet. | ||||
| Project | Magellan 2 | ||||
|
|
Es wird tatsächlich beim Mergen im Wesentlichen unterschieden, ob die Reports aus der gleichen Runde kommen oder aus verschiedenen. Das wird interessant, wenn mittels Runde tag die Aktualität der Informationen verglichen werden kann. Spannende Frage ist, wann setze ich das Runde Tag auf die aktuelle Runde eines Reportes? Wenn eine Einheit in der Region ist? Das kann auch bei alten -ungesäuberten- Reports der Fall sein. Fiete |
|
|
Ich hab beobachtet, dass das Mergen von Reports aus unterschiedlichen Runden selten bis gar nicht funktioniert. Setze ich bei beiden Reports das Datum auf die gleiche Woche /z.B. 545), dann funktioniert es problemlos. Das hat jetzt nicht direkt etwas mit dem Bug hier zu tun, beschreibt aber wieder das ursprüngliche Problem - wenn Magellan nicht weiß, dass zwei Regionen identisch sind, dann patzt es relativ häufig bei dessen Zuordnung. |
|
|
irgendwer hatte sich für das Rundenproblem schon interessiert und wohl angefangen zu implementieren. Ich würde hier trotzdem kurz die Fälle durchgehen: Welche Regionsinfos können wir haben so im generellen: "Map-Report" (MR) ;Name ;Terrain ;Beschr "Detail-Map-Report" (DMR) ;Name ;Terrain ;Beschr ;Bauern ;Rekruten ... Resourcen Und in Spielerreports nach visibility: ohne = "all" ~ DMR "travel" ~ DMR "lighthouse" ~ MR "neighbour" ~ MR Wobei es Unterschiede bei den Resourcen gibt. Da kommt es auch auf's Talent an, ausserdem sind manche beim Durchreisen nicht zu entdecken. Nicht zu vergessen sind ja die alten gemergten Reporte in denen keine Region eine Rundeninfo hat - kann man das überhaupt erkennen? Momentan würde ich so tun, also wären die ok, über die Zeit werden die Fehler in solchen Reporten verschwinden. Weitestgehend unproblematisch sind dann folgende Vergleiche: MR(X-1) : MR (x) DMR(X-1) : DMR (x) MR(X-1) : DMR (x) Problematisch ist aber: DMR(X-1) : MR (X) wobei es nur dann problematisch ist, wenn in dem neuen MR der Name, Terrain oder die Beschreibung geändert wurde. Wir wollen weder Name/Beschreibung/Terrain noch die alten Details verlieren stehen wir vor Wahl die alte oder neue Runde anzugeben. Unproblematisch sind die Resourcen, die können extra Rundeninfos bekommen und somit ihre alte Runde behalten. Eventuell führt der Weg hier wieder über die "letzte"-Tags. Das sind sowieso keine orginalen Tags, insofern kann Magellan da relativ frei mit umgehen. Ich würde also die detailsdaten die im neuen Report nicht drin sind in die "letzteBauern" usw. Schreiben, das tag "Bauern" gar nicht setzen das Runde Tag auf die neue Runde und ein "letzteRunde" auf die Runde aus der die "letzte"-Tags stammen. Damit kann man zumindest Infos aus 2 Runden in einem REGIONs-Block halten. Es bleiben aber Fälle in denen man nur teilweise Details erhält z.b. bei "travel" (dann fehlt Bauernsilber). Aber nur in seltenen Fällen hat das Auswirkungen und dann auch nur auf die 1-2 fehlenden Tags. Diese würde ich dann einfach etwas neuer datiere. Damit gibt es leichte Inkonsistenzen, aber nichts im Vergleich zur aktuellen Situation. Nachtrag zu den Resourcen: Die Resourcen brauchen dann auf jeden Fall auch Rundeninfo. Bei Nichtfunden würde ich ggf. für "versteckte Resourcen" (Eisen, Stein, Laen) eine 0-Resource mit Talentlevel der besten Einheit anlegen. Da erleichtert später die Übersicht wo mit welchem Level bereits gesucht wurde. Ausserdem führ ein ggf. älterer Report mit ggf. noch vorkommen auf dem angegebenen Level nicht dazu, das die Resourcen wieder sichtbar werden, obwohl bereits abgebaut. |
|
|
Nachtrag zum mergen von alten vollständigen mit neuen nur teilweisen infos: Die alten Infos mit den neuen vorhandenen ergänzen. Die Datierung und visibility aber auf dem alten Stand lassen. => lieber eine Region mit neuen Infos alt datieren als andersrum. Das dürfte meines Erachtens zu den bestmöglichen Mergeergbnissen führen (wenn man zu jedem Objekt nur einen Status speichert). (A1 + a3) + (B2) A1+B2 = vollständig aus runde 1 bzw. 2 a3 = nur Name, Terrain, Beschreibung ist nun in a3 ein anderer neuer Name drin, dann wird ist zwar der merge der A-Reporte korrekt, aber wenn man das Ergebnis mit B2 mergt verliert man die Namensänderung. Alle anderen mergereihenfolgen hingegen führen zu keinen problemen: (A1 + B2) + a3 -> korrekt A1 + (B2 + a3) -> korrekt Wenn Magellan es sich aussuchen kann (beim hinzufügen mehrerer Reporte), dann sollte dies in zeitlicher Abfolge geschehen. Kurzgefasst man sagen der Ansatz ist: Vollständige Infos haben Vorrang vor aktuellen, werden aber mit diesen ergänzt. D.h. Eigene Infos die man sammelt stehen i.A. über Kartenreports. |
|
|
Vielleicht noch zur Ergänzung: Was passiert nun also wenn zwei Völker auf unterschiedlichen Inseln hin und wieder Reporte tauschen? Sie tauschen ohne Details (aus Sicht von Volk 1): -> Die Insel 1 von Volk 1 hat vollständige und aktuellere Infos als die Karte von Volk 2 zur Insel 1. Die Daten von Volk 1 werden richtigerweise bevorzugt. -> Die Insel 2 von Volk 2 hat teils vollständige aber eher alte Infos. Die Karte von Volk 2 zur Insel 2 hat hingegen die aktuellen Namen drin wenn auch ohne weitere Details. Die Daten von Volk 1 werden mit den neuen Namen der Karte ergänzt aber das alte Datum bleibt, da keine Details verfügbar sind. => Beide Inseln haben die bestmöglichen Daten. Problematisch wird es erst wenn Volk 1 nun mit einem 3. Volk auch Karten tauscht. Die Daten die Volk 3 über die Insel 2 besitzt sind von den Details her vielleicht aktueller aber von den Namen nicht ganz so aktuell wie unsere Infos. Nun exportiert Volk 3 eine Karte und diese biete nun wieder die alten Namen an, jedoch mit einem jüngeren Datum als unsere Details. d.h. die Namen sind nun auf dem Stand der Karte von Volk 3. Insel 2: | 1 2 3 4 5 6 1 |-V------k2-k3--- 2 |--------------V- 3 |---V-k2--------- V = letzte vollständige Daten vorhanden kx = einfache Kartendaten von Spieler x erhalten und gemergt solange man also keine neuen vollständigen Daten erhält wird jeder aktuellere Report die alten Infos überschreiben - ganz ideal ist das nicht - muss ich zugeben. Hat man natürlich nie vollständige Infos gehabt, dann sind alle Namen aktuell. |
|
|
Das Problem wurde im Zuge der CR Problematik als Hotfix von Fiete gelöst. |
| Änderungsdatum | Benutzername | Feld | Änderung |
|---|---|---|---|
| 2007-03-14 01:04 | Fiete | Neuer Eintrag | |
| 2007-03-14 01:04 | Fiete | Notiz hinzugefügt: 0000018 | |
| 2007-05-03 03:34 | Fiete | Schweregrad | kleinerer Fehler => Feature-Wunsch |
| 2007-08-26 03:27 | trickert | Projekt | @3@ => @4@ |
| 2007-11-08 22:42 | trickert | Notiz hinzugefügt: 0000265 | |
| 2008-04-04 05:18 | stm | Projektion | keine => größere Änderung |
| 2008-04-04 05:18 | stm | Aufwand | keine => > 1 Monat |
| 2008-04-07 23:33 | trickert | Zielversion | => 2.0.1 (Planning) |
| 2008-06-12 08:07 | trickert | Status | neu => erledigt |
| 2008-06-12 08:07 | trickert | Behoben in Version | => 2.0.2 |
| 2008-06-12 08:07 | trickert | Lösung | offen => erledigt |
| 2008-06-12 08:07 | trickert | Bearbeitung durch | => trickert |
