Betriebskosten?

[Hajo]

Ich bin etwas verwirrt, was die Betriebskosten für Fahrzeuge angeht.

Im pak.Hajo habe ich heute ein Schiff überarbeitet, das hatte Betriebskosten von "RunningCost=62"

Ich habe im pak.64 ein vergleichbares Schiff gesucht, war eigentlich auf der Suche nach besseren Grafiken, und habe auch eines gefunden, gleiche Geschwindigkeit, etwas mehr Nutzlast, geringere Motorleistung und "RunningCost=8800"

Nun, das ist ein gewaltiger Unterschied. Ist im pak.Hajo da eine Änderung übersehen worden - etwa, die Kosten werden heute in % angegeben, somit Factor 100? Das würde die Größenordnung des Unterschieds erklären. Ansonsten bin ich ratlos.

[prissi]

Die Kosten im Original pak64 waren sehr niedrig. Irgendwann 2006 oder so habe ich mal ein Excelsheet entworfen, dass Schiffe nur bei 48% Auslastung Gewinn machen und dementsprechend die Kosten angepasst. Schiffe (und andere Verkehrsmittel) waren immer sehr sher billig. Auch lokomotiven hatten selten mehr als 3ct Kosten pro km.

Aber mittlerweile muss ich das für den Passagierverkehr nochmal wiederholen. Für Schiffe und Lastwagen stimmt die Formel immer noch. Müsste im pak64 als cars.xls enthalten sein.

[Hajo]

Ok, danke Dann ist 8800 also der heutige "richtige" wert, und die 56 ist historisch bedingt, aber in Ihrere weise auch richtig. Ich bleibe dann zunächst bei den 56 biss ich ein besseres Gefühl dafür habe wie sich einkommen und Ausgaben entwickeln. Ausserdem soll pak.Hajo leicht zu spielen sein.

[Gotthardlok]

pak64 ist gegnüber pak.hajo teilweise einfach inflationär...einige Güter, die in pak64 preislich nicht angepasst worden sind, fahren in späten Jahren bei vernünftigen Anhängelasten (vollbeladen 900t für die BR185) nur Verlust ein.

Und bei Gelegenheit meine uralte Bitte: Umsatzdivision aus dem Code entfernen, bevor neue Preislisten geschrieben werden! Es gibt mittlerweile genügend Einstellungen in Simutrans, um Umsätze (z.B. beginner_price_factor) und alles mögliche zu manipulieren, einmal davon abgesehen, dass sich Güter-dats mit höheren Umsätzen sehr einfach herstellen lassen (braucht keine Grafik). Wenn Spieler alte pak-Dateien für höhere Umsätze verwenden wollen - stört uns das?

Ebenso erneuere ich mein Angebot, dat-Dateien für den verbesserten, CPU-schonenderen Code umzuschreiben.

[Hajo]

Vielleicht bin ich zu lange weg gewesen, was ist "Code für Umsatzdivisionen"? Ich bin stark daran interessiert ein gut balanciertes Set zu entwickeln, auch wenn ich es tendenziell einfach zu spielen, von der Kosten- und Einkommensstruktur, halten möchte.

[DirrrtyDirk]

Irgendein Wert (bin nicht mehr sicher welcher) wird nicht wie in der dat angegeben verwendet sondern programm-intern durch 3 geteilt (oder so) - ich glaube das ist was Gotthardlok meint.

[Gotthardlok]

Sämtliche in die Güter-dats geschriebenen Erlöse pro km tauchen in der Warenliste nur mit einem Drittel auf, d.h. wenn man einen Erlös pro km rechnerisch ermittelt, muss er in der dat-Datei dreimal grösser eingetragen werden (umständlicher als nötig bzw. kann vergessen werden und dann gibts nur Verluste...).

Die Division ist allerdings schon uralt und dürfte, wie ich vermute, schon von der allerersten Ausbalancierung von Kosten und Einnahmen stammen, Leider hat man dann einfach die codeseitige Anpassung stehen lassen, anstatt die Güter-dats umzuschreiben, was mittlerweile bei den vielen paksets zur Hypothek geworden ist - und diese Hypothekaramortisation ist meines Erachtens (über)fällig.

[Hajo]

Viele paks haben intern eine Versionsnummer. Man könnte vermutlich für alte paks die Division drin lassen um kompatibel zu bleiben, und für mit einem neuen MakeObj erstellte die Division weglassen. Ich weiss alerding nicht ob Güter-Paks eine Versionsnummer haben - Volker hatte das vergessen als er das pak System entwarf, und ich habe nachträglich für einige pak Sorten Versionsnummern eingeführt, aber ich erinnere mich dass es für manche paks aus kompatibilitätsgründen nicht möglich schien eine Versionsnummer dazuzumogeln ohne die bestehenden paks inkompatibel zu machen.

[prissi]

goods habe eine Version. Wenn es als wirklich dringend gesehen wird, kann man das ändern. Nur stehe ich auf dem Standpunkt, möglichst nichts anzufassen, was funktioniert. Insbesondere im Vergelich zu dem, was sonst in den pak-Dateien noch alles falsch gemacht werden kann und wieviele überhaupt sich eigene pak-Dateien erstellen. Aber wenn die liebe Seele Ruhe hat, kann ich auch die Version hochsteppen und dann das gnaze bei Laden mit drei MUltiplizieren.

[Gotthardlok]

Leider kann ich auf meinem System kein eigenes Simutrans kompilieren; könnte mir bitte jemand eine Linux-Version der ausführbaren Datei einfach ohne diese Division bauen, damit getestet werden kann, wieviel wirklich nicht mehr funktionieren würde? Rein theoretisch müsste das ja klappen, ausser die Programmierung an der Stelle wäre wirklich komplizierter, als ich mir das vorstelle (oder es sein müsste).