01-08-2007, Wednesday-21:06:15
insofern hast du recht, dachte ware_t wäre größer. vll reicht fuer starttime und fuer dist jeweils auch ein 16 bit int aus. das wären dann nur 16Byte anstatt von 12 Byte.
wenn man ticks>>10 speichert anstatt ticks zb. die höchsten 6 bit wegläst, bekommt man immer noch 18h realtime im sekundenraster abgedeckt.
es wird doch ticks gespeichert und geladen, dazu letzter monat und letztes jahr.
wenn wie du sagst alle 5 jahre ticks auf 0 gesetzt wird, kann man damit arbeiten, muss nur beim setzen von starttime eben ein bitshift um 10 bits machen, und bei die berechnung von now-starttime anpassen und wenn das ergebnis negativ ist den tickswert von 5 jahren sprich 5*12*bits_per_month addieren.
die frage ist ob 16 bit als dist reichen, aber ich denke selbst auf einer 4096*4096 karte wird sich jemand schwer tun fracht ueber eine strecke die größer als 32768 felder ist zu verfahren.
wenn man wayfactor auf den raum 0 bis 1 beschränkt kann man fuer dist auch ein unsigned int verwenden sprich, eine strecke von 65536 feldern.
edit: ja und nach dem laden von ticks werden sie modulo ticks_per_tag gerechnet ?
irgendwie steig ich durch das zeitmanagement noch nicht durch.
edit2: ok, wenn 32 bit mehr in der class ware_t ok wären, und das spiel nicht zu langsam machen, dann habe ich eine lösung fuer das ticksproblem.
dist wird uint16 oder sint16
uint16 monthticks :11;
uint16 month:5;
in ticks monthticks werden die ticks seit monatsanfang >>10 gespeichert. also die sekunden seit monatsanfang.
in month werden die ersten 5 bits von current_month gespeichert.
daraus kann man dann die startzeit berechnen und kann immerhin einen zeitraum von 32 monaten erfassen, nur wenn waren länger unterwegs sind kommt es zu einem abrechnungsproblem.
problem gibt es nur wenn einer mit mehr als 21 bits_per_month spielen will :/
vll wäre es auch geschickter man hat uint16 monthticks und uint8 month? gibt aber wieder 8 bit mehr zu ware_t.
falls ihr doch am jetztigen system festhalten wollt. schafft dieses average_speed ab und ersetzt es durch etwas besseres. (und nein ein steigender wert über die zeit ist keine gute idee meiner meinung nach)
wenn man ticks>>10 speichert anstatt ticks zb. die höchsten 6 bit wegläst, bekommt man immer noch 18h realtime im sekundenraster abgedeckt.
es wird doch ticks gespeichert und geladen, dazu letzter monat und letztes jahr.
wenn wie du sagst alle 5 jahre ticks auf 0 gesetzt wird, kann man damit arbeiten, muss nur beim setzen von starttime eben ein bitshift um 10 bits machen, und bei die berechnung von now-starttime anpassen und wenn das ergebnis negativ ist den tickswert von 5 jahren sprich 5*12*bits_per_month addieren.
die frage ist ob 16 bit als dist reichen, aber ich denke selbst auf einer 4096*4096 karte wird sich jemand schwer tun fracht ueber eine strecke die größer als 32768 felder ist zu verfahren.
wenn man wayfactor auf den raum 0 bis 1 beschränkt kann man fuer dist auch ein unsigned int verwenden sprich, eine strecke von 65536 feldern.
edit: ja und nach dem laden von ticks werden sie modulo ticks_per_tag gerechnet ?
irgendwie steig ich durch das zeitmanagement noch nicht durch.
edit2: ok, wenn 32 bit mehr in der class ware_t ok wären, und das spiel nicht zu langsam machen, dann habe ich eine lösung fuer das ticksproblem.
dist wird uint16 oder sint16
uint16 monthticks :11;
uint16 month:5;
in ticks monthticks werden die ticks seit monatsanfang >>10 gespeichert. also die sekunden seit monatsanfang.
in month werden die ersten 5 bits von current_month gespeichert.
daraus kann man dann die startzeit berechnen und kann immerhin einen zeitraum von 32 monaten erfassen, nur wenn waren länger unterwegs sind kommt es zu einem abrechnungsproblem.
problem gibt es nur wenn einer mit mehr als 21 bits_per_month spielen will :/
vll wäre es auch geschickter man hat uint16 monthticks und uint8 month? gibt aber wieder 8 bit mehr zu ware_t.
falls ihr doch am jetztigen system festhalten wollt. schafft dieses average_speed ab und ersetzt es durch etwas besseres. (und nein ein steigender wert über die zeit ist keine gute idee meiner meinung nach)