Eintragsdetails ansehen
ID | Projekt | Kategorie | Sichtbarkeit | Meldungsdatum | Zuletzt aktualisiert |
---|---|---|---|---|---|
0000247 | Magellan | Allgemein | öffentlich | 2008-05-13 13:16 | 2008-05-20 15:02 |
Reporter | thewhitewolf5123 | Bearbeitung durch | Fiete | ||
Priorität | normal | Schweregrad | Feature-Wunsch | Reproduzierbar | nicht getestet |
Status | erledigt | Lösung | erledigt | ||
Produktversion | 2.0.1 | ||||
Behoben in Version | 2.0.2 | ||||
Zusammenfassung | 0000247: Anzeige der Region-id | ||||
Beschreibung | Ich hätte gerne, dass die neue Regions-id überall dort angezeigt wird, wo man auch die Koordinaten einer Region sieht. Als base36 zum Beispiel. Der Vorteil darin liegt, dass man sich so mit anderen Spielern leichter koordinieren kann, ohne erst prüfen zu müssen ob man eh die gleiche Region meint, da die Region-id garantiert eindeutig ist. Auf die Koordinaten könnte man theoretisch in Zukunft verzichten, doch das alte System wird sicherlich noch länger bestehen. | ||||
Zusätzliche Informationen | Beispiel: Rirocepes (4, -25 / 7xzuce) welche region meine ich? anhand von namen und koordinaten nicht eindeutig feststellbar, da sich der name ändern kann (BENNENE) und die koordinaten bei jedem spieler anders sein können. Die Regions-ID ist aber eindeutig, daher würde diese kurze Information ausreichen. | ||||
Tags | Keine Tags zugeordnet. | ||||
Project | Magellan 2 | ||||
|
Achtung! Für Eressea ist die regionid von Enno als int aktiviert worden. Und ist wohl nun auch als int im CR (erst war es text). Allerdings kann es denke ich gut sein, dass andere Spiele eine String-id liefern. Die Umwandlung in base36 ist dann natürlich nicht möglich. Davon abgesehen gehört zur Anfrage eine regionid auszugeben natürlich auch die Suchmöglichkeit danach :-) |
|
ich habe keinen report vom server erhalten, wo die region-id etwas anderes als ein int im CR war. zu den anderen spielen: sobald in zwei spielen ein attribut exakt gleich heißt, aber unterschiedliche bedeutung hat, muss man jedenfalls eine spiel-spzifische weiche einbauen. wenn ein feature aufgrund so eines Unterschiedes für garkein Spiel implementiert werden würde, fände ich das sehr schade. |
|
Die Id hat Enno ja auch in Bezug auf die XML Diskussion eingeführt. Der Gedanke dabei war, das diese Id eben ein regionselement eindeutig referenziert. Diese anzuzeigen ist natürlich sinnvoll. Lediglich die Umwandlung in base36 habe ich in Frage gestellt, um nicht in Probleme mit andersartigen IDs zu kommen. Die ID ist m.E. schon dafür gedacht, das sie auch in anderen Eressea-ähnlichen Spielen existieren kann und Regionen im Report eindeutig identifiziert. Dabei den Datentyp int vorauszusetzen, empfinde ich als Einschränkung. |
|
ok, nun hab ich dich verstanden. dann lass mich deine kritik auf diese, andersartige, weise hinterfragen: Pudod (7, -26 / 55319745) ohne copy&paste ist die fehlerrate beim lesen genauso groß, als würde man gleich bei regionssname+koordinaten bleiben. Die Zahl ist eindach zu lange, um sie als mensch schnell zu verarbeiten. Wenn schon als Zahl, dann zumindest Tausendertrennpunkt: Pudod (7, -26 / 55.319.745) base36 bot sich aus meiner sicht aufgrund der ähnlichkeit zu einheiten-nummern an. die zahl an sich ist irgendwie schwer zu fassen, da das hirn hier nichts zusammenfassen kann: die zahl ist ja "zufällig" (naja, hashwert) vergeben. copy&paste steht nicht immer zur verfügung. |
|
Lange zahlen sind immer ein weniger schwerer zu lesen als ihre Base36 Pendants - klar, umsonst wird das ja nicht verwendet. Ich versuche mir nur zu überlegen wie man das sinnig in clients handhabt. Vielleicht folgendes: Die Behandlung der regionid erfolgt in Abhänigkeit vom CR-Datentyp. int = base vom Report wird verwendt, die umwandlung in reportbase ist auch die gültige string-id string = ohne konvertierung XML Reporte enthalten hingegen nur string-ids. Das müsste dann aber auch bei den Serverreports so sein. Beispiel: Eressea-CR: REGION 1 1 ... 12;id ... -> int, wert 12 -> stringid = "C" Anderes Atlantispbem - CR: REGION 1 1 ... "12";id -> string -> stringid = "12" ("12" != "C") Hingegen im XML Report (alle Spiele): ... <region id="12"> <coordinate x="1" y="1"/> ... </region> -> string/nmdata -> stringid = "12" tendentiell würde im XML Report noch der Elementtyp mit in die ID wandern, da sonst die Eindeutigkeit im Report über verschiedene Elemente sichergestellt werden muss. Daher würde es dort wohl wie folgt aussehen: <region id="region_12"> ... Süeichern wir nun den als erstes erwähnten Eressea-CR in einem XML-Report um, dann wird aus: REGION 1 1 ... 12;id dann: <region id="region_c"> <coordinate x="1" y="1"/> ... </region> Allerdings könnte dann der Eressea-Server auch gleich string-ids im base36 Format in den Report schreiben. Ich glaube wir müssen Enno mal auf diesen FR aufmerksam machen. |
|
Es ist absicht, dass die IDs base10 sind. Sie sind 32 bit lang, und wuerden damit ohnehin 6 zeichen lang in base36. Und sie stehen im CR als Zahl, nicht als String gespeichert. Es ist natuerlich Magellan ueberlassen, ob es die trotztdem in base36 oder rigendwas anderes umwandeln moechte (andere variante: 256 eissorten ausdenken, und dann als 4-Frucht becher anzeigen (Banane-Kiwi-Erdnuss-Straziatella). Solange diese Info nicht an den Server zurueckgehen muss, ist das ja alles egal. |
|
Ab build 199: Base36 wird mit (ID:uvwxyz) angezeigt und ist Copy&Paste-fähig. Suchfunktion erweitert: Wenn bei Objekt-Suchbereich Regionen und bei Attribut-Suchbereich IDs aktiviert sind, werden die IDs als base10 und base36 gesucht und gefunden. Eventuelles ToDo: Auswahlen als Liste von IDs anstelle von Koordinaten speichern/laden können. Fiete |
|
Oh, sehe gerade, Du wolltest das *überall* haben, ich habe es jetzt lediglich in RegionDetails anzeigen lassen. Ich werde zusätzlich das Contextmenu bei Rechtsclick auf Region entsprechend anpassen.Soon.... |
|
Done. Rechtsklick im Overview-Fenster liefert jetzt sehr detailierte Copy&Paste - Möglichkeiten. Rechtsclick auf Map erzeugt bei Copy und Paste nun Name + Koords + RegionUID. Die RegionUID generell bei den Koordinaten zu ergänzen (bei region.toString) möchte ich nicht, weil dass so häufig benutzt wird, dass es garantiert irgendwo nicht passt. Lieber trage ich noch 2 Stellen nach, die irgendwo gewünscht werden... |
Änderungsdatum | Benutzername | Feld | Änderung |
---|---|---|---|
2008-05-13 13:16 | thewhitewolf5123 | Neuer Eintrag | |
2008-05-20 14:15 | Fiete | Status | neu => zugewiesen |
2008-05-20 14:15 | Fiete | Bearbeitung durch | => Fiete |
2008-05-20 14:19 | Fiete | Status | zugewiesen => erledigt |
2008-05-20 14:19 | Fiete | Behoben in Version | => 2.0.2 (Planung) |
2008-05-20 14:19 | Fiete | Lösung | offen => erledigt |