Danke Michael.
Ja, feine Funktion.
Die Reichweitenbeschränkung der Flugzeuge auch! Wenn das geht, wäre es doch auch bestimmt möglich so etwas für Dieselloks und Dampfloks zu implementieren, oder?? Ohne regelmäßiges Anfahren eines Bw ist dann nicht mehr

Jein... das ginge nur für Bahnhöfe/Wegpunkte, und wäre damit leicht umgehbar...

Ich hatte mal die Idee, die Betriebskosten abhängig der am weitesten auseinanderliegenden Punkte im Fahrplan zu gestalten, aber das ist etwas umständlich zu implementieren.

Eddi schrieb:Ich hatte mal die Idee, die Betriebskosten abhängig der am weitesten auseinanderliegenden Punkte im Fahrplan zu gestalten, aber das ist etwas umständlich zu implementieren.

In TTDPatch gibt es eine Variable "cargotransittime" (0x3f), auf der man eine Abhängigkeit der Betriebskosten aufbauen kann, aber wirklich viel weiter führt das auch nicht.

@Bernhard
Für Flugzeuge macht das Sinn, und ist auch leicht implementierbar (gewesen), aber für andere Fz (ausser für Schiffe, möglicherweise) sehe ich das nicht.

Gruß
Michael

(14.12.2011 10:26)mb schrieb:  @Bernhard
Für Flugzeuge macht das Sinn, und ist auch leicht implementierbar (gewesen), aber für andere Fz (ausser für Schiffe, möglicherweise) sehe ich das nicht.

Die nötige Infrastruktur zu schaffen... wäre doch interessant.
Es ist doch irgendwie blöd, das ein simples Depot reicht alle Arten von Loks/Zügen zu bauen/beschaffen/unterhalten.

Wenn zu Dampfloks ein erreichbares Bw gehört ... des gleichen für Dieselloks ...
Genau so könnte man darüber nachdenken, ob Loks + Waggons nur in besonderen, teureren Werkstätten gekuaft werden können... und evt. an den Dienstort überführt werden müssen.
Ich wollte es immer mal auf einer großen Karte ausprobieren (Fahrzeit Start-> Ziel ca. 1 Jahr) ob es sich lohnt, die Züge am Ziel zu verkaufen (und am Start neu) um sie nicht leer zurück fahen zu lassen!

Bernhard schrieb:Die nötige Infrastruktur zu schaffen... wäre doch interessant.
Es ist doch irgendwie blöd, das ein simples Depot reicht alle Arten von Loks/Zügen zu bauen/beschaffen/unterhalten.

Für dich schon, für andere nicht.

Bernhard schrieb:Wenn zu Dampfloks ein erreichbares Bw gehört ... des gleichen für Dieselloks ...
Genau so könnte man darüber nachdenken, ob Loks + Waggons nur in besonderen, teureren Werkstätten gekuaft werden können... und evt. an den Dienstort überführt werden müssen.

Man kann durchaus so vorbildbezogen spielen: keine Teilstrecken bauen, mehrere Depots unterhalten, keine Fz verkaufen, ...

Bernhard schrieb:Ich wollte es immer mal auf einer großen Karte ausprobieren (Fahrzeit Start-> Ziel ca. 1 Jahr) ob es sich lohnt, die Züge am Ziel zu verkaufen (und am Start neu) um sie nicht leer zurück fahen zu lassen!

Das wird angeblich in MP-Spielen wo es auf jeden Euro ankommt so gemacht.

Gruß
Michael

(14.12.2011 14:21)mb schrieb:  

Bernhard schrieb:Ich wollte es immer mal auf einer großen Karte ausprobieren (Fahrzeit Start-> Ziel ca. 1 Jahr) ob es sich lohnt, die Züge am Ziel zu verkaufen (und am Start neu) um sie nicht leer zurück fahen zu lassen!

Das wird angeblich in MP-Spielen wo es auf jeden Euro ankommt so gemacht.

Gruß
Michael

wo hast du denn sowas gehört? Die meisten Server werden so ein Verhalten verbieten... Aber eine der ersten KIs (Rondje om de Kerk) macht das so.

Und das mit dem "nur ein Depot" funktioniert nur, wenn du Pannen und Wartung abschaltest.

(13.12.2011 21:43)planetmaker schrieb:  

(13.12.2011 18:16)Timmaexx schrieb:  Ebenso super! Wurde mir doch vor ~2 Jahren noch in einem Suggestions-Thread gesagt das wäre unmöglich aufgrund der vielen versch OS. Gerade Anfänger wird das bei Problembehebungen und weiteren Infos helfen.

Ja... wurde auch noch vor zwei Wochen. Bis wir feststellten, dass es quasi auch auf jedem Linux, auf welchem wir nachschauten, auf genau eine Weise immer funktionieren scheint... - die man dazu aber erstmal kennen mußte Der Patch ist für seinen Nutzen erstaunlich kurz

Besser jetzt als nie!

[OT]

Eddi schrieb:

mb schrieb:

Bernhard schrieb:Ich wollte es immer mal auf einer großen Karte ausprobieren (Fahrzeit Start-> Ziel ca. 1 Jahr) ob es sich lohnt, die Züge am Ziel zu verkaufen (und am Start neu) um sie nicht leer zurück fahen zu lassen!

Das wird angeblich in MP-Spielen wo es auf jeden Euro ankommt so gemacht.

wo hast du denn sowas gehört?

Nebenan.

Eddi schrieb:Die meisten Server werden so ein Verhalten verbieten...

Mag sein.

Ich wollte Bernhard lediglich bestätigen dass es funktioniert.

Gruß
Michael

Hallo

(14.12.2011 13:43)Bernhard schrieb:  

(14.12.2011 10:26)mb schrieb:  @Bernhard
Für Flugzeuge macht das Sinn, und ist auch leicht implementierbar (gewesen), aber für andere Fz (ausser für Schiffe, möglicherweise) sehe ich das nicht.

Die nötige Infrastruktur zu schaffen... wäre doch interessant.
Es ist doch irgendwie blöd, das ein simples Depot reicht alle Arten von Loks/Zügen zu bauen/beschaffen/unterhalten.

Wenn zu Dampfloks ein erreichbares Bw gehört ... des gleichen für Dieselloks ...
Genau so könnte man darüber nachdenken, ob Loks + Waggons nur in besonderen, teureren Werkstätten gekuaft werden können... und evt. an den Dienstort überführt werden müssen.

Das Kaufen der Fahrzeuge in speziellen Fabriken/Werkstätten/WhatEver wurde ja schon mehrfach angeregt. Ich persönlich hielte das für übertrieben. Wer soetwas simulieren will, baue sich ein Depot, dass speziell diesem Zweck dient und überführe die Fahrzeuge durch entsprechende Zubringerstrecken. Die Wartung erfolgt dann in den streckennahen Depots. Dafür braucht man nichts neu zu erfinden/implementieren.

Der Wartungsintervall ist doch schon die Unterbrechung, die du mit dem Gedanken an Bekohlung und Betankung im Sinne hast. Wenn du so spielen willst, wähle einen entsprechend kurzen Wartungsintervall und schaffe mit den Depots die nötige Infrastruktur. Auch hier ist nichts weiter nötig als die Nutzung der vorhandenen Möglichkeiten.

Tschö, Auge

Nochmal zurück zum Feature "cargoaging".

Kann mir jemand sagen in welcher source-Datei das konkrete "aging" vorgenommen wird? Bzw, was genau alle 185 ticks mit dem Frachtwert passiert? Wird dort ein konstanter Wert abgezogen? Oder ist das noch von irgendetwas anderem abhängig?

Gruß
Michael

(16.12.2011 10:27)mb schrieb:  Kann mir jemand sagen in welcher source-Datei das konkrete "aging" vorgenommen wird? Bzw, was genau alle 185 ticks mit dem Frachtwert passiert? Wird dort ein konstanter Wert abgezogen? Oder ist das noch von irgendetwas anderem abhängig?

Es wird simpel ein Zähler hochgezählt, der die Transportdauer zählt. src/cargopacket.cpp:380
Mit dem Frachtwert passiert gar nichts, der wird erst gemäß der Cargoproperties und der tatsächlichen Reisedauer ausgerechnet, wenn die Fracht wirklich abgeliefert wird.

planetmaker schrieb:Es wird simpel ein Zähler hochgezählt, der die Transportdauer zählt. src/cargopacket.cpp:380 [...]

Naja, dort wird cp->count dazu addiert. Der selber aber an verschiedenen Stellen verändert wird, und zudem "The amount of cargo in this packet" (-> cargopacket.h) darstellt? Also durchaus keine Konstante ist.

Worauf ich hinaus möchte ist die Bestimmung dieses "a" in y = b - a/x.

Gruß
Michael

(16.12.2011 11:45)mb schrieb:  

planetmaker schrieb:Es wird simpel ein Zähler hochgezählt, der die Transportdauer zählt. src/cargopacket.cpp:380 [...]

Naja, dort wird cp->count dazu addiert.

Zu den Cargo-Transit-Stunden (analoge Einheit zu Mann-Stunden oder Kilowattstunden). Aber nicht zum Alter, welches, wie gesagt, simpel in days_in_transit gespeichert ist.

DeliverGoods in economy.cpp:992 regelt die Bezahlung bzw. GetTransportedGoodsIncome in 882

Im übrigen ist das Verhalten natürlich in den offiziellen NewGRF-Specs dokumentiert: http://newgrf-specs.tt-wiki.net/wiki/Act...11.2C12.29

planetmaker schrieb:Zu den Cargo-Transit-Stunden (analoge Einheit zu Mann-Stunden oder Kilowattstunden). Aber nicht zum Alter, welches, wie gesagt, simpel in days_in_transit gespeichert ist.

DeliverGoods in economy.cpp:992 regelt die Bezahlung bzw. GetTransportedGoodsIncome in 882

Du hast nicht verstanden worum es mir geht. Möglicherweise habe ich die Frage oben schlecht gestellt.

Wiki schrieb:This property allows to modify the period in ticks after which cargo carried by the vehicle is aged. By default, cargo is aged every 185 ticks. [...]

D.h. also dass unter der Voraussetzung dass einem Spieltag 74 ticks entsprechen, Fracht alle 2,5 Tage "gealtert" wird. Setzt man den Wert höher (> 185) erfolgt die Alterung langsamer, setzt man ihn niedriger an, so erfolgt die Alterung schneller. Es ergibt sich damit also eine Hyperbel wenn man den Transporterlös über eine bestimmte Strecke (bzw Zeit) gegenüber der Frachtalterungs-Periode aufträgt (s. Bild).

Es wäre jetzt interessant zu wissen, wie die schon erwähnte Konstante "a" in y = b - a/x zustandekommt, um eine Aussage über die Anwendbarkeit dieses Features zB auf verschieden grossen Karten treffen zu können. Aus der (hypothetischen) Kurve sieht man ja bereits dass eine Vergrösserung des Alterungsfaktors für bestimmte Streckenlängen/Transportzeiten weniger bedeutsam ist als eine Verkürzung. Was allerdings von dem genauen Wert für "a" abhängt.

planetmaker schrieb:Im übrigen ist das Verhalten natürlich in den offiziellen NewGRF-Specs dokumentiert: [...]

Es gibt keine "offiziellen" newGRF specs, auch wenn ihr das immer wieder behauptet. Und natürlich kenne ich den von dir verlinkten Text, ich habe ihn nämlich vor vielen Jahren selber geschrieben.

Gruß
Michael

Ich bin mir immer noch nicht sicher worauf Du hinaus willst.

Die CargoAgeProperties der Fahrzeuge ändern einfach das Intervall von alle 185 ticks, wo die Fracht altert, auf den Werte des entsprechenden Properties, welches den Abstand des Aufrufs der Cargo-Aging-Routine in Ticks festlegt.

Die Formel, von der Du sprichst, sehe ich weder im Quellcode noch in den offiziellen NewGRF-Specs.

(16.12.2011 11:45)mb schrieb:  

planetmaker schrieb:Es wird simpel ein Zähler hochgezählt, der die Transportdauer zählt. src/cargopacket.cpp:380 [...]

Naja, dort wird cp->count dazu addiert. Der selber aber an verschiedenen Stellen verändert wird, und zudem "The amount of cargo in this packet" (-> cargopacket.h) darstellt? Also durchaus keine Konstante ist.

"cargo_days_in_transit" ist einfach nur ein Cache und nicht weiter wichtig. Entscheidend ist, dass alle cargo age interval Ticks (standardmäßig 185) die Variable "days_in_transit" um eins erhöht wird.

Am Ende landet das Ganze dann bei src/economy.cpp:882 in der Variablen "transit_days", die dem t aus http://newgrf-specs.tt-wiki.net/wiki/Act...11.2C12.29 entspricht.

Sprich, ersetze in dem Satz "t is the time the delivery took, the unit is 185 game ticks" die 185 mit dem Wert von Prop 2B. (Mit Umladen wird es natürlich etwas komplizierter, aber das kann man hier ignorieren, denke ich.)

michi_cc schrieb:[...] Sprich, ersetze in dem Satz "t is the time the delivery took, the unit is 185 game ticks" die 185 mit dem Wert von Prop 2B. (Mit Umladen wird es natürlich etwas komplizierter, aber das kann man hier ignorieren, denke ich.)

Ja, danke, das beantwortet meine ursprüngliche Frage (ob noch mehr dahintersteckt. Tut es nicht.).

Gruß
Michael