Themabewertung:
  • 0 Bewertung(en) - 0 im Durchschnitt
  • 1
  • 2
  • 3
  • 4
  • 5
güterverkehr mit speedbonus in pak64
#51
Ich weiss nicht ob's hilft, aber ich meine Hajo hätte letztens irgendwo gesagt er hätte einfach irgendwann irgendwo nach Gefühl mal festgelegt das so und soviel km/h (weiss die Zahl nimmer) sich so und so schnell auf dem Monitor bewegt (also auch wieviel reale Zeit vergeht für das Abfahren von x Kacheln... richtig?). Oder ist das der Teil den Du im Code gefunden hast?
Zitieren
#52
coivoi_t:Confusedync_step() case DRIVING:

Pro tile macht ein Convoi 16 Schritte. Damit sollte sich das ausrechnen lassen. Bin aber zu müde, um das jetzt ncoh selbst zu machen.
Zitieren
#53
Zitat:Original von prissi
...
Monorail: eigenen Kategorie
...

nur wurde die nirgens ausgewiesen, weshalbs wohl keiner wusste
Zitieren
#54
Ok, Fehler meinerseits. Kann man aber diskutieren, da in sich geschlossen.
Zitieren
#55
Persönliche Meinung von mir:

Ich würde ware_t so klein als möglich lassen und Tabellen für die Referenzgeschwindigkeit nehmen. Gründe: Simutrans braucht schon genug Rechenzeit, der Vorteil eines komplizierten Bezahlsystems erschliesst sich mir nicht, und komplizierter Programmcode is schwerer verständlich und schlechter wartbar. Ich habe das Gefühl, dass das neue System eine ganze Menge Fehlerquellen erzeugt, die nicht notwendig sind.

Eines meiner Projekte ist gestorben weil es einfach zu komplex war, und am Ende der Aufwand das Ergebnis in keiner Weise rechtfertigte. Im Moment steht am Anfang jeder Designentscheidung bei mir die Frage: Was ist die einfachste Lösung für das Problem? Wie nahe kommst die einfachste Lösung einer perfekten Löung? Oft ist die Antwort "nahe genug" und der Unterschied im Kodieraufwand beträchtlich.

Aber vielleicht bin ich nur von einem extrem ins andere geschwankt.

PS: Mit "einfach" sind keine Lösungen gemeint bei denen schon abzusehen ist dass sie in drei Wochen ersetzt werden müssen weil sie nicht tragfähig sind.

PPS: Erfahrungsgemäss bin ich einer der Bremser was Änderungen angeht, vor allem wenn die existierende Löung ausreicht, und die Änderung Risiken mit sich bringt. Ich sehe ein dass die Referenzgeschwindigkeit nicht gut ermitelt wird, im Moment. Ich denke aber, dass das eine so großen Umbau nicht rechtfertigt. Das jetzige System ist fehlerarm und gut genug. Mit einer besseren Refernzgeschwindigkeit ist es sicher ziemlich brauchbar.
Blogger blog blog
Zitieren
#56
das jetzige Modell ist brauchbar (mit einem konstanten rev_speed, da dies fuer die pakentwickler die planung leichter macht und sich mir nicht erschliest warum der revspeed mit der zeit steigen sollte?)

Allerdings wird noch immer die min_top_speed des zuges verwendet. ist das wie aus dem comment zu entnehmen noch immer die mögliche maximalgeschwindigkeit des zuges? prissi hat glaub ich mal erwähnt das die auf dem weg erreichete höchstgeschwindigkeit genommen wird, was eine verbesserung wäre.

zur größe von ware_t, habe 2 dummyvariablen eingefügt und so die größe geändert, allerdings beim spielen noch keinen unterschied feststellen können, simloobs blieb bei um die 5 in meinem aktuellen spiel.
Zitieren
#57
Zitat:Original von Kasei
das jetzige Modell ist brauchbar (mit einem konstanten rev_speed, da dies fuer die pakentwickler die planung leichter macht und sich mir nicht erschliest warum der revspeed mit der zeit steigen sollte?)
....

Ganz einfach, es soll erreicht werden, das in modernere Fahrzeuge investiert wird. Im Zuge dessen muss dann auch die Infrastruktur ausgebaut werden.

Deshalb ist es mir recht unverständlich, das die langsamen Straßen und Schienen nicht ausgeführt werden.
_____________________

Statt der Startzeit des Fahrzeuges die Einladezeit der Waren zu nehmen, sollte auch nicht so große Schwierigkeiten machen. Dadurch würden aber die Wartezeiten bei der Ladestation mit berücksichtigt, die meiner Meinung nach mit zur Beförderungszeit gehöhren.
_____________________

Zitat:Original von prissi
Trams: wie schiene (weil ja oft eh mit normalen Zügen betrieben)

Und ich dachte, der Bonus ist ans Fahrzeug gebunden. Eine Tram bleibt immer eine Tram und ein Zug immer ein Zug.
Durch den verschiedenen Einsatzzweck unterscheiden sich Trams und Züge doch um einiges.

Zugegebenermassen verwischt die Grenze in jüngster Zeit allmählich.

Hier wäre wider die Traglast des Verkehrsweges interessant. Zu schwere Fahrzeuge dürfen einen Verkehrsweg mit geringerer Traglast nicht befahren.
Zitieren
#58
Zitat:Original von FrankP
Statt der Startzeit des Fahrzeuges die Einladezeit der Waren zu nehmen, sollte auch nicht so große Schwierigkeiten machen. Dadurch würden aber die Wartezeiten bei der Ladestation mit berücksichtigt, die meiner Meinung nach mit zur Beförderungszeit gehöhren.

die wäre eine alternative zum speichern in ware_t, und würde das benutzen von min_top_speed nicht mehr benötigen. (diese zeit kann im convoi gespeichert werden)

grundlegendere frage die wir vll vorher mal klären sollten:
Soll simutrans schon durch den programmcode spielern ein gewisses verhalten vorschreiben, oder ist es pak-entwicklern überlasen dieses durch parameter im pak zu machen?
Sprich, soll in einem Timelinespiel schon vom Programm her dafuer gesorgt werden das man immer schnellere/neuer Fahrzeuge benutzen muss, oder nicht?

Denn je nachdem wie man die Abrechnung gestaltet, kann ein Spielverhalten vorgeschrieben werden.
Zitieren
#59
Persönliche Meinung:

Ich mag Spiele die dem Spieler viele Freiheiten lassen, wie er spielen möchte. Auch Freiheiten um Dinge auf ungewöhnlich weise zu lösen. Oder einfach mal was Neues zu probieren. Ich finde es blöd wenn mir ein Programm vorschreibt was ich zu tun habe, und dann auch noch wie.

Für mich war Simutrans meine Transport-Bastelbox. Der Speed-Bonus war als "Bonus" also etwas extra für gute Leistungen gemeint und nicht als Zwang oder einzige Möglichkeit zu Geld zu kommen. M.E. sollte das ein Bonus bleiben, und nicht der treibende Faktor von Simutrans sein.

Wenn das nicht klappt dann stimme ich Frank zu, besser den Bonus komplett zu streichen.

Die Timeline hat ursprünglich nur neue Fahrzeuge hinzugefügt, aber keine "ausgemustert". Da war kein Zwang zum Upgrade.
Blogger blog blog
Zitieren
#60
Zitat:Original von Hajo
...
Die Timeline hat ursprünglich nur neue Fahrzeuge hinzugefügt, aber keine "ausgemustert". Da war kein Zwang zum Upgrade.

Tut sie jetzt auch nicht. Die Fahrzeuge werden nur im Depot ausgeblendet. Über den Knopf 'veraltete anzeigen' können diese wieder eingeblendet werden.

Durch die Menge der heute verfügbaren Fahrzeuge halte ich diese Lösung für ganz gut.

Bei den Menüs lässt sich da wieder streiten.
Zitieren


Gehe zu:


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