Themabewertung:
  • 0 Bewertung(en) - 0 im Durchschnitt
  • 1
  • 2
  • 3
  • 4
  • 5
güterverkehr mit speedbonus in pak64
#41
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)
Zitieren
#42
Trams und Monorail werden beim Bonus als Schiene behandel.
_______________________________

Ringlinien
Rentieren sich jetzt schon nicht immer, zumindest wenn diese größer sind und viele Stationen haben. Bestes Beispiel ist hier wieder die Tram.

Durch das Prinziep der Personenmitnahme sammeln sich Passagiere, die zur vorgelegenen Station (in der Linie) wollen. Diese fahren aber den ganzen Ring als Umweg.

Das dürfte mit ein Grund für unrentable Tramlinien sein.
Zitieren
#43
Warum ist ein mit der Zeit steigender Speedbonus eine schlechte Idee? (Man könnte natürlich ebenso gut das Einkommen pro ware senken.) Ersteres repräsentiert den Fortschritt schon eher.

Das die Durchschnittsgeschwindigkeit nicht die beste Lösung ist, gebe ich gerne zu. Ich wollte schon lange das auf vordefinierte Tabellen umstellen.
Zitieren
#44
@ ringlinie, die sollte man zumindest wenn sie mehr als ein paar stops enthält oder über einen größeren bereich geht, in 2 richtungen gestallten, ist nur bei tramlinien schwierig.

tramlinien sind eigentlich nicht unprofitabel, in pak.german habe ich einige gute laufen, allerdings verkehren dort inzwischen kurze normale züge, da sie mehr passagiere transportieren und besser beschleunigen.

in pak64 kann es sein das sie als schiene abgerechnet werden (hatte ich schon 2mal gefragt aber noch keine antwort bekommen) dann haben sie durch ihren geringen speed in spätem spielverlauf keinerlei chance mehr gewinn zu machen.
Zitieren
#45
Deshalb baue ich große Ringe (also nicht Trams) auch 2-gleisig. Soweit ich verstanden habe sind die Passagiere dann zwar immer noch nicht"intelligent" genug (oder doch?) nur in den Zug zu steigen der nur einen Halt weiterfahren braucht anstatt in den der erst einmal komplett rum muss - aber es besteht eben doch die 50/50 Chance das sie doch in den anderen, günstigeren Zug setzen.

Aber so was lohnt auch nur wenn man wirklich Passagiere in Massen transportieren muss. Hab ich bis jetzt erst einmal eingesetzt (ist auch schon ne Weile - und vor allem einige Versionen - her) bin aber schon am Planen der Neuauflage.

Aber jetzt wo Du's sagst... auf einer Bahn die nur hin und her pendelt - steigen da die Passagiere auch immer nur ein wenn der Zug in die "richtige" Richtung fährt? Oder kann es auch passieren das sie erstmal einsteigen und dann den Umweg bis zum verkehrten Ende der Linie und dann wieder zurück als Umweg zurücklegen?

Wie intelligent sind denn eigentlich die Simutaner bei der Wahl des Transportmittels?
Zitieren
#46
@speedbonus,prissi

entschuldige ich hatte mich etwas schwammig ausgedrückt:
ich meinte einen steigenden rev_speed wert der mit der jahreszahl steigt und damit den speedbonus bei gleichbleibender geschwindigkeit immer kleiner werden lässt.

ansonten ist einfach ein konstanter wert fuer jedes gut als speedbonus/konstante rev_speed in der jetztigen berechnug ok, schnelle züge bekommen dann eben höhere betriebskosten da sie durch die geschwindigkeit und speedbonus ja mehr einnahmen erzeugen als langsame.

liese sich dann einfach ausblanzieren.

ich wäre dennoch fuer meinen vorschlag wenn er das spiel nicht zu langsam macht

was anderes was mir und bown im chat aufgefallen ist:

folgende rechnung:
bei 20 bits_per_month ist ein spielmonat 2^20ms = 1048sekunden=17,6minuten lang.
dh eine spielstunde sind 2^20/720 ms in realtime (bei 30 tagen pro monat) das sind in etwa 1.456 sekunden.

ein feld in simutrans soll ja 1km lang sein

fährt ein zug unn 100kmh sollte er 100 felder in 1.456 sekunden realtime zuruecklegen, was er ja ganz offensichtlich nicht tut.
daher meine frage, wie funktioniert das mit der geschwindigkeitsdarstellung im spiel.
sprich wie werden aus 100kmh die in etwa 2-3 felder/s die man beobachten kann.
und wo wird es im sourcecode geregelt, ich finde es einfach nicht :/

und mal wieder ein edit:
nun habe ich es gefunden:
Code:
/*
* Global vehicle speed conversion factor between Simutrans speed
* and km/h
* @author Hj. Malthaner
*/
#define VEHICLE_SPEED_FACTOR  80


/**
* Converts speed value to km/h
* @author Hj. Matthaner
*/
#define speed_to_kmh(speed) (((speed)*VEHICLE_SPEED_FACTOR+511) >> 10)


/**
* Converts km/h value to speed
* @author Hj. Matthaner
*/
#define kmh_to_speed(speed) (((speed) << 10) / VEHICLE_SPEED_FACTOR)


beispiel: 100kmh = 100*1024/80 speed=100*12.8 speed =1280 speed
speed ist nun was? felder/1000 ticks oder noch anders?
Zitieren
#47
Zitat:Original von Kasei
...
in pak64 kann es sein das sie als schiene abgerechnet werden (hatte ich schon 2mal gefragt aber noch keine antwort bekommen) dann haben sie durch ihren geringen speed in spätem spielverlauf keinerlei chance mehr gewinn zu machen.

Zitat:Original von FrankP 21:13 Uhr
Trams und Monorail werden beim Bonus als Schiene behandel.
Zitieren
#48
danke frank, hatte nur ab ringlinie gelesen sry.

@DirrrtyDirk
nein, sie steigen nicht ein wenn das in die andere richtung liegt,

anders bei einer ringlinie. dort steigen sie ein, weil es nicht auf dem rueckweg sondern auf dem hinweg liegt Smile

insgesammt aber hast du bei einer 2gleisigen ringlinie mit guter auslastung das problem nicht da wenn in beide richtungen genügend züge fahren (btw das ist auch bei busringlinien sinnvoll sie in beide richtungen fahren zu lassen) und die haltestellen alle ähnlichles verkehrsaufkommen haben der zug mit dem kürzeren weg die passagiere transportieren wird.
Zitieren
#49
Trams: wie schiene (weil ja oft eh mit normalen Zügen betrieben)

Monorail: eigenen Kategorie

Zu den Geschwindigkeiten:
Original kannte Simutrans nur eine Monatslänge, glaube 17 oder 18. Die tatsächliche Geschwindigkeit hat somit nicht aber auch gar nichts mit der Realität zu tun (genauso wenig wie die Einwohnerzahlen). Ein Haus ist entweder 32 m oder 1km breit usw. Spiele müssen die Maßstäbe so ändern, dass sie spielbar sind.
Zitieren
#50
ok, meine frage zielte auch nicht auf den realismus ab, sondern mehr drauf herrauszufinden in welchem bereich bei meiner berechnung D und T bzw D/T liegen wird Smile

deshalb meine frage, wie wird ein speed in simutrans nun dargestellt? wie aus den kmh speed wird habe ich ja nun gefunden.
Zitieren


Gehe zu:


Benutzer, die gerade dieses Thema anschauen: 15 Gast/Gäste