fixed_cost = feste Betriebskosten

[Leartin]

Für die statistische Anzeige eines laufenden Monats wäre es prima, wenn die Fixkosten anteilsmäßig angezeigt werden. Also wenn man in der Mitte des Monats nachschaut, werden auch nur die halben Fixkosten aufgeschlagen.

Sinn der Sache wäre, dass man besser vergleichen könnte. Sonst sind bei Abbuchung am Monatsanfang erstmal sämtliche Fahrzeuge und Linien in den roten Zahlen und erst am Monatsende weiß man, was wirklich Gewinn oder Verlust erzielen konnte. Entsprechend interessiert auch nicht, welche Linien im aktuellen Monat in den Miesen sind, wenn man in die Linienliste schaut, und kann sich die farbige Markierung sparen bzw. müsste sie auf das Vormonat beziehen.

Wohlgemerkt: Da geht es um die statistische Anzeige des laufenden Monats. Die tatsächliche Abbuchung vom Kontostand kann natürlich zum Monatswechsel erfolgen.

[makie]

Meine Änderung ist, dass die Fixkosten überhaupt für Fahrzeuge und Linien angezeigt werden und die Kosten nicht am Monatsende gebucht werden, wo sie eine vorher profitable Linie überraschend ins Minus befördern.

Es gibt nur eine Routine die beim Monatswechsel läuft. Es gibt keine Halbmonat / Wochen oder Tageswechsel Routine.

Man könnte jeden Tag ein dreißigstel der Monatskosten buchen.
Problem sind die Monat mit 28 oder 31 Tage und die unweigerlich auftretenden Rundungsprobleme.

Ich möchte eigentlich nicht so tief in die Programmmechanik eingreifen.

Der andere Punk ist:
Meine Versuche haben gezeigt 5% vom Erlös sind zu viel, die Kosten würden dominieren und das Spiel sehr schwer machen.

Mein Nächster Versuch wird 2% und etwas Kosten für Geschwindigkeit sein.
Die Kosten beim einzelnen Fahrzeug sind also nur ein kleiner Teil der Betriebskosten.
Erst die vielen unnütz herumstehen Fahrzeuge führen zu relevanten Kosten.

[makie]

Noch etwas:
Da der Monat mit dem Monatlichen Fix anfängt ist es klar als Festkosten zu erkennen. Es ist genau der Betrag Instandhaltung der in den Detail angezeigt wird.
Bei eine anteilsmäßig Buchung ist das nicht mehr so einfach zu erkennen.

[makie]

Die Detail Anzeige entgleist wenn man fixed_cost angibt.
Ich weiß nicht wo man das korrigiert.
ohne fixed_cost:

mit fixed_cost:

[Leartin]

Es gibt nur eine Routine die beim Monatswechsel läuft. Es gibt keine Halbmonat / Wochen oder Tageswechsel Routine.

Man könnte jeden Tag ein dreißigstel der Monatskosten buchen.
Problem sind die Monat mit 28 oder 31 Tage und die unweigerlich auftretenden Rundungsprobleme.

Ich möchte eigentlich nicht so tief in die Programmmechanik eingreifen.

Es geht ja nicht um die Buchung. Es geht um die Anzeige in der Statistik, bzw. das Einkommen, welches unterhalb der Geschwindigkeit angezeigt wird. Das wird überall, wo es angezeigt wird, auch laufend aktualisiert.
Was du machst, ist quasi "Bisherige Betriebskosten diesen Monat" durch "Bisherige Betriebskosten diesen Monat + Monatliche Fixkosten" zu ersetzen. Mein Vorschlag ist quasi "Bisherige Betriebskosten diesen Monat + Monatliche Fixkosten*(Datum-Monatsanfang)/Monatslänge". Da gibt es keine Rundungsprobleme und braucht es keine Wochen oder Tageswechsel-Routinen, es muss auch nur berechnet werden, wenn der entsprechende Dialog geöffnet ist, also kein großer Umstand in der Performance.

Da der Monat mit dem Monatlichen Fix anfängt ist es klar als Festkosten zu erkennen. Es ist genau der Betrag Instandhaltung der in den Detail angezeigt wird.
Bei eine anteilsmäßig Buchung ist das nicht mehr so einfach zu erkennen.

Ist aber auch quatsch, wenn man Fixkosten nur dort einsehen kann und nur, wenn man genau zum Monatsanfang reinschaut. Sollten dann eher statisch neben den Kilometerkosten angezeigt werden.

Du sagst ja selber, dass du die Statistik nutzen willst, um zu sehen, welche Linien profitabel sind. Wenn aber die Fixkosten nicht zeitanteilsmäßig angezeigt werden, sondern immer voll, ist das im laufenden Monat nicht gegeben, weil zumindest am Monatsanfang alles in den Miesen ist, und sich erst gegen Monatsende herauskristallisiert, ob ein Fahrzeug Gewinn oder Verlust macht.

Man darf sich die Statistiken, die Simutrans ausspuckt, getrost vorstellen, als wären es Daten aus der Buchhaltung eines Unternehmens. Fixkosten, welche in regelmäßigen Perioden anfallen, werden immer anteilsmäßig gerechnet, weil sie andernfalls keinen Sinn ergeben. Ganz auf doof: Wenn man die Daten von einer Woche hat, will man eigentlich damit rechnen können, dass ein Monat ca. das Vierfache ist, und nicht nochmal überprüfen müssen, ob das nun die Daten einer Woche sind, in der die quartalsmäßige Mietzahlung fällig war...

[makie]

Mal sehen was Prissi dazu sagt.
Nicht dass er das ganz anders oder garnicht ändert und wir hier um des Kaisers Bart streiten.

Zum bessern Verständnis hier mal die Programmänderung erläutert.

/**
 * convoi add there fixed cost per month
 */
void convoi_t::add_fixed_cost()
{
 jahresgewinn += sum_fixed_costs;
.
.
 get_owner()->book_running_costs( sum_fixed_costs, wtyp);

 book( sum_fixed_costs, CONVOI_OPERATIONS );
 book( sum_fixed_costs, CONVOI_PROFIT );
}

Das ist neu und bucht die fixed_cost ein.

In sum_fixed_cost steht die Summe aller fixed_cost der einzelnen Fahrzeuge des zusammengestellten Zugs. (Konvoi)

jahresgewinn wird beim Jahreswechsel gelöscht. Dieser ist es der unter der Geschwindigkeit und in der Linienliste angezeigt wird.
Soweit ich das sehen konnte dient der Wert nur dieser Anzeige.

get_owner()->book_running_costs( das hier geht ans Fenster Finanzen und kostet den Spieler tatsächlich Geld. Es sind die "Betriebskosten" im "Finanzen Fenster"

book( ..., CONVOI_OPERATIONS ); "Betriebskosten" in der Statistik des Konvois und vermutlich von dort auch der Linie in der Linienverwaltung
book( ..., CONVOI_PROFIT ); "Betriebsgewinn" in der Statistik des Konvois und der Linienverwaltung

Die alte Funktion get_maintenance() habe ich für Fahrzeuge lahm gelegt. Es ist die allgemeine Funktion für Unterhaltskosten für alle Objekte. Also Häuser, Straßen, Gleise usw. Es wird alles in einen Topf geworfen. Es ist nur eine Zahl die jeden Monat vom Konto des Spielers abgezogen wird.
Eine Differenzierung hier und Anzeige wie viel die einzelnen Objekte(Typen) den Kosten verursachen das wäre ein nettes Zusatzfenster. Ist aber ein eigenes Programmierprojekt.

+ // call book monthly fixed cost for convois
+ FOR(vector_tpl<convoihandle_t>, const cnv, convoi_array) {
+ cnv->add_fixed_cost();
+ }

Diese Routine wird beim Monatswechsel einmal und als letztes aufgerufen.

Man könnte diesen Aufruf natürlich auch an eine Stelle verlegen die einmal täglich aufgerufen wird.
Dann addieren mit sum_fixed_cost / 30 (von mir aus auch >>6 das wäre dann / 32)
An welcher Stelle das zweckmäßig und der Struktur des Programms entsprechend einzubauen wäre. Kann nur Prissi entscheiden.

[Leartin]

Diese Routine wird beim Monatswechsel einmal und als letztes aufgerufen.

Man könnte diesen Aufruf natürlich auch an eine Stelle verlegen die einmal täglich aufgerufen wird.
Dann addieren mit sum_fixed_cost / 30 (von mir aus auch >>6 das wäre dann / 32)

Du bist immer noch fixiert darauf, dass es um die Abbuchung geht. Der Zeitpunkt, zu dem die Fixkosten vom Konto abgebucht werden, und die Anzeige in der Statistik müssen nicht übereinstimmen.

Die Fixkosten sollen ja in der Statistik den Betriebskosten zugerechnet werden, und die Betriebskostenanzeige wird nicht monatlich aktualisiert, sondern laufend. Des weiteren müssen die anteilsmäßigen Fixkosten nicht gespeichert werden, da sie ausschließlich in dem Moment, wo sie angezeigt werden, von Bedeutung sind. Wenn kein Statistikfenster offen ist, braucht es gar keine Berechnung, weil das Ergebnis keiner sehen würde.


Ich versuche es nochmal von einer anderen Richtung:
Beginnen wir mit einem Zeitmultiplikator. Das wäre einfach eine Zahl zwischen 0 und 1, welche angibt, wie weit der aktuelle Monat fortgeschritten ist. Also Monatsfortschritt/Monatslänge. Es sei mal dahingestellt, wie häufig der aktualisiert werden muss - selbst wenn man es jeden Frame macht wäre es nicht das Ende der Welt, aber alle 1-2 Sekunden (bei regulärer Spielgeschwindigkeit) würde auch reichen.
Immer dann, wenn irgendwo die bisher im Monat angefallenen Betriebskosten eines Fahrzeuges abgefragt werden, werden stattdessen die angefallenen Betriebskosten + Fixkosten*Zeitmultiplikator ausgegeben.
Zum Monatswechsel werden die gesamten Fixkosten dann zu den Betriebskosten addiert, also am ENDE des Monats. Wenn man also die Betriebskosten eines Vormonats verlangt, sind die Fixkosten enthalten und keine weitere Berechnung nötig, das Ganze betrifft also immer nur aktuelle Monate, und die Daten, welche für vergangene Monate gespeichert werden, wären identisch.

Da es rein um die Anzeige geht könnte es sogar eine Einstellungssache sein. Wenn die Berechnung des Zeitmultiplikators von einer Einstellung abhängig ist und er ansonsten immer 1 ist, entspricht mein Vorschlag dem Verhalten, das du ohnehin vorhattest, und hätte überdies eine dritte Option, bei der der Zeitmultiplikator immer 0 ist. Daraus ergibt sich, dass man sich aussuchen kann, ob die Fixkosten in der Statistik des aktuellen Monats am Monatsanfang, Monatsende oder Anteilsmäßig aufgeschlagen werden sollen.

[Der Trick ist - und das muss ich nochmal wiederholen - dass man die statistische Anzeige und die tatsächlichen Buchungen im laufenden Monat voneinander trennt.]

[makie]

Ich verstehe dich schon.
Aber das bedeutet jede Menge Coding in der Nähe der GUI.
Bisher zeigt das Coding der GUI nur die Daten an, so wie gespeichert.
Ich weiß nicht, ob man das so haben will.
Ich bin einen einfachen Weg gegangen, der sich an der Arbeitsweise des restlichen Programms anlehnt.

[Flemmbrav]

Ich suche mich aktuell in meiner Formel tot, finde aber einfach keine Lösung, und wollte deswegen hier fragen:

Bei mir haben recht ähnliche Objekte, die nach der gleichen Formel berechnet wurden, sehr sehr unterschiedliche Fixkosten.
Normalerweise würde ich sofort sagen, dass das an mir hängt. Jedoch behandle ich die Fixkosten nur in einer einzigen Zeile, die da geht: 

Code:

local FixCost=$(( RunningCost * 850 ))

Und natürlich das Schreiben der dat. 

Jedenfalls äußert sich bei mir der Verdacht, dass ich da ausversehen am oberen Limit des Parameters spiele.
Deswegen wollte ich mal ganz unverbindlich fragen, wo das obere Limit des Parameters liegt.

Die Fahrzeuge, an denen ich das ausprobiert habe, sollen in etwa 40kC pro Monat kosten.
Jedenfalls bei 20 Bits pro Monat.
Sie kosten jedoch nur 184,32C, wenn ich fixed_cost=4000000 eintrage. Ja, das wird sich wohl noch vervierfachen, jedoch gibt es auch deutlich teurere Fahrzeuge im Pakset, so dass ich da noch keine obere Grenze haben wöllte.

Sourcen des Fahrzeugs: https://www.dropbox.com/s/7hfimerfkvwnj7...x.zip?dl=0

[makie]

Da du hier schreibst, hab ich erst vermutet du verwendest meinen Patch. Aber offensichtlich nicht.
Beim Release 121.0 gibt es tatsächlich eine Begrenzung.

trunk/descriptor/vehicle_desc.h

uint32 get_running_cost() const { return running_cost; }
uint16 get_maintenance() const { return fixed_cost; }

Das habe ich ohne zu bemerken in meinen Patch ausgebaut.
uint16 das sind 65536 also 655.36 € nach Umrechnung in 20 Bits pro Monat dann 2621.44.

Hinweis: in der .dat ist ohne Umrechnung auf 20 Bits pro Monat anzugeben.
Das Programm rechnet um auf 20 Bits pro Monat um. Also Wert*4;

Der Patch siehe oben.