Fuel Cost depends on weight and distance traveled (to test)

[RulerofRails]

Proposed Fuel Cost principle:

Fuel Cost is tied to weight and distance traveled not speed. However, increased speed will cause a train to travel further and thus it will seem to consume more fuel in the same period of time.

I had a little time to run a test on the Big Boy. I thought the easiest way to vary it's weight was to make one adjustment to the engine file. I was going for total weight (including tender) and how it affects fuel costs. To make things even simpler, I tested with an empty train. The results on my test track of a down and up with no stops with a brand new train (Lirio's specs):
Engine and tender weight = 155 tons; Fuel Cost = 28k
At 310 tons: 55k.
At 620 tons: 108k.
At 1240 tons: 222k.
At 2480 tons: 441k.

Extra: added (320 tons of cars to the 2480 engine tender combo)
At 2800 tons: 475k. (25mph)

The ratio looks so near linear that I am surprised. This formula could be quite simple to approximate. The Load Miles Hauled ledger entry seems a bit fickle as I get varying results (when I have checked it's been betwen 4170 and 4192 for the total run). As a rough approximation, fuel cost in this test is about $0.042 cents per ton per load mile hauled. (This is beside the point of this particular test, but it will be interesting to see if it's consistent against further tests.)

---

I then decided to try stopping the heaviest trains (with and without cars) to see if acceleration and speed makes a difference. I especially made sure to stop the train on the return journey as it was tackling the smallish sections of 5% uphill grades so it would take as long as possible. There was no observable difference in fuel cost when average speed was roughly half.
Empty (2480 tons): Fuel cost 443k.
8 cars (2800 tons): Fuel cost 475k. (At 12mph)

I double confirmed this one, and the costs are virtually the same for up and down. At 2,800 tons 237k down vs. 238k up for example. It should be noted that I am losing about 45% of one Milk car due to rot on the trip down so it isn't a super solid figure.

Then to take the concept even further, using the 2,800 car train, one at a time I did the following:

• I placed in-line maintenance services for two extra stops in each direction. Fuel cost 474k.
• Then I tried to double maximum speed to 140mph. The result: 55mph average round-trip with, who would guess, a 474k fuel figure.
• Next I tried doubling the free weight to 1070 (used to be 535). No change in fuel cost.
• Finally, I set acceleration to maximum (Instant). The result: 54mph round-trip with a fuel cost of 474k.

Obviously, data is easy to gather, interpretation is the hard part. I drew the beginning conclusion mainly from this test. The idea of a test generally is for people with doubts to prove that it ISN'T so. Throw everything you can at it. If it's right, great, then I can try to test something else.

[Gumboots]

That is a fascinating start. I'm surprised it seems to be that basic. It never would have occurred to me. Nice work.

So obviously it should also be tied to fuel economy rating. If it isn't, something is very wrong. That's the next thing to test I suppose (along with trying to disprove your initial conclusion just to make sure).

I would also expect fuel consumption to be tied to grades, with less fuel consumption for the same tons over the same miles on dead flat terrain. Again, if it isn't then something is wrong with the game's coding.

Come to think of it, if you can accelerate like a rocket (Instant rating) and still only burn the same fuel as when accelerating like a drunken donkey, I reckon that Newton bloke must have got his equations wrong. The RT3 devs might be up for a Nobel Prize in physics.

I'm not surprised that varying "free weight" didn't affect fuel consumption. As far as I know it's not really a genuine weight reduction. It's just a fudge factor that stops speed reducing so fast for the same load on flat terrain. I'd expect that varying pulling power wouldn't change fuel consumption either.

I'll see if I can get some testing done on these factors too.

---

(Come to think of it, and this is off-topic for this thread but you just reminded me of it, if your average speed for the trip roughly halved when using inline sheds that's a large difference in route speed. What I should test sometime is the overall turnaround time difference between spurs and inline. IOW, not the one-station-loading-to-next-station-unloading trip speed that RT3 records, but how long it take to shift a given number of loads with each system. That should be a smaller difference, since the spurs do require time that is not logged as part of your average speed in the ledger.)

[Gumboots]

By the way, I overlooked your comment about fuel costs being the same uphill and downhill. Assuming it can be confirmed by more testing that's really surprising, and shows how far they went in simplifying things when coding the game engine. This leads to a few other guesses about the coding.

Fuel consumption is coded on a scale from 1 to 10 in the .lco file. If for a given fuel economy rating you are getting a simple linear correlation between tons x miles hauled and fuel burned, then it may also be that the simple 1 to 10 rating number is used directly as one of the variables in the game's formula. So if that turns out to be the case, what you'd see is a locomotive with a rating of Atrocious burning ten times as much fuel as a loco rated Outstanding for a given (tons x miles hauled), while one rated Below Average would burn 50% more than one rated Above Average.

Since it looks like fuel consumption is probably just (total tons x miles hauled x fuel economy rating x some constant) then it is likely that other calculations are similarly basic. For instance, the deterioration in reliability with use may also just be a product of tons, miles, a constant, and another variable to take account of varying oil level over time, but with no allowance for the effect of grades. It may be that grades only affect speed, and don't affect anything else.

So the apparent lesser reliability of faster locos over time, assuming a given nominal reliability rating, may simply be a result of them covering a lot more miles. This could be tested, but is going to be a longer and more difficult process. If this is the case, then the current idea of probably reducing express weights to help get a larger difference between freight and express could give a direct linear benefit to the usable life (in years) of faster locomotives.

A similar formula could account for the greater sand, oil and water consumption I noticed for the Schools and Berkshire when testing against the P8 over 30 years or so. I used a large scale on that map to test out giving the feel of "real rail trips" and "real ocean journeys", which also gave the trains enough room to really wind right out. The Schools is a lot faster than the P8, so obviously on a map like that it will be covering a lot more distance in the same time.

Since on this test map every train was full most of the time the tons hauled per trip was pretty much constant, or at least would average out, so the only variable is distance covered (as a function of speed). The Schools top speed is around 50% greater than the P8, but that won't equate directly to 50% more distance covered since the loading and unloading times will be the same for all trains, and when meeting on a line they will randomly stop according to their exact cargo value at the time. I found oil, sand and water consumption seemed to be roughly 20% higher for the Schools, which as a rough guesstimate could tie in with a basic (tons x miles hauled) formula.

Same goes for the Berkshire. Similar oil, sand and water consumption to the Schools, but quite a bit lower in top speed. However, a lot heavier than the P8, and capable of hauling full freight consists at its maximum speed on flat terrain, and with a lot of pulling power to tackle grades, so capable of much higher point to point speeds than the P8 when fully loaded. So, more distance travelled than the P8 in the same time, hauling more tons per trip due to the greater locomotive+tender weight. Again, by a rough guesstimate this could tie in with the same simple formula.

[RulerofRails]

I didn't say that the 12mph average speed was due to in-line service. I achieved that figure because I was stopping the train on purpose to try to get it to "work harder" on acclerating that heavy load multiple times, 6 or more.

My test track isn't a good place to test whether up and down hills makes a difference. I went and checked out the stats and going by what the lake tool says the difference in elevation of the end points is 2,898 vs. 3,005. Maximum height attained is 3,476ish. I was stating this as an observation not as a tested principle. This should be tested more.

Fuel consumption is coded on a scale from 1 to 10 in the .lco file. If for a given fuel economy rating you are getting a simple linear correlation between tons x miles hauled and fuel burned, then it may also be that the simple 1 to 10 rating number is used directly as one of the variables in the game's formula. So if that turns out to be the case, what you'd see is a locomotive with a rating of Atrocious burning ten times as much fuel as a loco rated Outstanding for a given (tons x miles hauled), while one rated Below Average would burn 50% more than one rated Above Average.

Ran a quick test with a few settings that confirms this. For the normal Big Boy on this route (620tons+340tons of cars) normal (Average setting) fuel consumption is 140k. At Excellent setting the cost is 28k. At Atrocius it's 280k. Ran a couple more numbers and the principle seems to hold true.

The linear spacing on these means that there is a much bigger difference between the levels on the "Good" end of the scale than on the "Bad" end. Going from Excellent to Very Good, fuel consumption is doubling! Meaning, that in real-terms, the "Bad" end is more adjustable. The question is then, Can it be utilized better?

A little sample to illustrate:

.

---

A little extra is that the scale seems to continue past the Atrocius 10, at the same increment. I tried 15 and got 669k on an empty 1240 tons. But, the events are setup with those 10 levels, so will show Atrocius.

Also, my events that appear to change fuel consumption in-game (the rating changes) are making no difference to actual fuel costs. The cost must be adjusted in the file with the hex editor. This is in 1.06. I have made no real attempt to find the problem or see if it exists in 1.05. Just a heads up for when you go to test.

[Gumboots]

Err, right. So that really is excessively simplified coding then.

So although the increments are linear (one integer at a time) the effect is exponential due to the way the fractions change from one rating to the next. I hear what you're saying about about the top end of the scale being less flexible, but at the moment I'm not sure if that can be useful knowledge for writing scenarios. Worth considering though.

And it looks like you may have found a bug in the editor's coding too, if its events are only changing displayed ratings but not changing actual fuel cost. I don't think the 1.05 vs 106 differences would have affected that (might be wrong, of course).

I like that you tried setting fuel to 15 in the hex. That ties in with my next thought, which is that if the game engine is just taking whatever value is in the hex and using it as a basic multiplier, is it actually limited to integers? If it's just using whatever is there, it may well accept any value at all. Maybe a loco rated Average could have an actual value anywhere between 5 and 5.9999999.

If this is the case, it would allow a lot more flexibility in locomotive coding even though the visible text would still be restricted to the given names.**

I had an idea about testing for grades too. Grab the old California map. Either my version or the original would do since the terrain is identical. The run from Macho Grande (IIRC) up to Crestview and back would be ideal for testing the effect of grades. It's heavy grades all the way up, and about at the limit for a steamer water capacity.

**This may apply to any of the ratings that usually use integers. If it does, that would be great.

[Gumboots]

Hey I just ran a quick test of my own (have been up to my eyeballs in modelling but took a break). So this is for water and sand and oil consumption.

I just opened a blank map in the editor and put a whacking great mountain range right through the middle of it, because I was over trying to find an existing map that had a continuous grade long enough to run a steamer out of water. Put one station just at the bottom of the range, then I laid a line uphill, averaging probably 3-4% grade with some bits down to 2% bits (not many) and some (not many) up to 6%, all the way to a handy level spot with an awesome view. Put another station there.

Ran a test while still in the editor, and this second station just happened to be where an empty Berkshire would get to with a tiny bit of water left. Ok, so save map, then open it again as a sandbox. Put one Berky at the bottom station with 8 freight cars. Another Berky at the top station with no cars at all. Bet you can guess what happened.

If you guessed that both locomotives consistently used exactly the same amounts of oil, sand and water, whether they were going uphill or downhill, with 8 freight cars or no cars at all, you'd be right.

Ok then, what happens on dead flat terrain? So I laid another track starting from the same bottom station and extending off across the plain to wherever. Eyeballed the distance between the first two stations, and picked a spot on the plains track that looked as near as I could get it to the same distance. Put another station there.

So, get two more brand new Berks (green ones this time) and set one running with no cars at all, and the other running with 8 freight cars. No surprises here. They both used exactly the same amounts of oil, sand and water as each other. Not only that, but they both used exactly the same amounts of oil and water as the two black Berks that were going up and down the mountains, over the same distance but with different grades.

Conclusion: oil and water consumption is solely dependent on distance travelled. Weight doesn't matter. Grades don't matter. Speed doesn't matter. It's only distance that matters.

Sand consumption is different. Dead flat track uses no sand at all. Graded track will use the same amount of sand whether the locomotive is going uphill or downhill, and regardless of the weight it is hauling.

Conclusion: Sand consumption depends on distance and on the grade. Presumably it works it out based on the actual grade percentage, and I'm guessing this is linear too. So 0% grade definitely uses 0 sand. 1% grade presumably uses 1x something amount of sand, 2% probably uses twice that much, 3% probably uses 3x as much, etc.

Incidentally, that mountain track that was laid about the maximum grade most of us generally like to lay track at (3-4% ish) also happened to run the Berkshires out of sand at the same rate it ran them out of water. So it looks like the game is balanced so that steamers will run out of sand and water at the same time on moderately steep grades. Makes sense to me.

It has another effect too. On flat terrain diesels and electrics need fewer stops because they don't need water at all, and don't use sand on flat track. However, on graded track of 3-4% the electrics and diesels will (assuming they use sand at the same rate as steamers) still run themselves out of sand as fast as a steamer runs itself out of water and sand. So in that case the steamers will have just as much useful range as the others.

[RulerofRails]

Good work on testing the sand, water and oil. I never dreamed this stuff could be that simple to calculate.

I tried a setting of 1.5 and 1.4999 and the game treated it as a number 1. So at first glance at least, that's a no-go. I also tried 0.4 and the effect was that there is no fuel cost. The game shows a zero. This is pretty good evidence that this figure is a multiplier in the fuel cost formula.

As to whether or not non-integer numbers will work for the other ratings, that would be harder to test. In Pjay's LCOspec file all of them are listed as int (integer?) except fuel cost which is listed as float.

As an extra I tried cutting the Pulling Power (value at 42 in the hex) from 45 to 22. No effect on fuel cost.

I tried to test the event to change the fuel cost setting in 1.05 and it isn't working there either. From what I can see at this stage, this means that the scenario designer has no control over the fuel costs in his scenario except to make them appear different.

There is always a remote chance that by using a standardized event in each scenario that apparently "adjusts" fuel costs down 5 to 10 levels (it really does nothing), a better range of fuel costs could be obtained with settings in the bottom spectrum or possibly even down to 15.

Of course, this would require very light cars and engines. A fuel setting of 15 would need 155 tons total train weight to achieve a reasonable (approx 80k) fuel cost on this test run. I really don't know how much tight adjustment there is with the engine settings and the acceleration might have to look a little slow otherwise trains might turn into rockets. It's a long-shot, but still a possibility.

The simple way to adjust fuel costs is going to be to have one setting (Average) and use engine weight adjustments, which possibly wont affect perfomance if free weight is also adjusted by the same amount. With heavier trains, fuel costs will likely have to be at Good. A one step rating change to Very Good would be almost impossible to account for cleanly without lots of extra ballast weight shunting reliability.

[Gumboots]

Bummer about the fractional values being a no-go. It makes sense for anything that is defined as an integer in the hex. It doesn't make sense for anything that is defined as a float, because those are generally used specifically so that they can take any value. That makes the coding of fuel economy a bit of an outsider in that really it should have been coded as int, but apparently we're still stuck with integers anyway. Hey ho.

So I'm now assuming all the other named ratings will require integer values as well. Some things might be worth trying:

1/ There aren't any 0 values listed for fuel economy and reliability but they may exist. Not that anyone would really want a 0 rating those two factors but I'm slightly curious now.

2/ Since you could get even worse fuel economy by using 15 as the integer there may also be an 11 value for reliability (presumably Perfect, if it exists).

3/ According to PJ's notes, the acceleration scale goes from 0 from 11. So I guess the 0 rating (named "Is It Moving?") results in no acceleration at all (IOW no, it aint moving).

4/ It may also be worth trying values above 3 for passenger appeal, just to see what happens to express prices.

5/ I suppose you could even try 4 for fuel type. Who knows? Maybe they threw in Nuclear as an Easter Egg?

---

Pity about the editor being useless for adjusting fuel cost. Yet another bug. At least it'll save people having to write those events in future.

[RulerofRails]

Maybe I don't know what I am doing with the fractional values, it may be worth you having a go at them too. Especially the "integer" values, I wouldn't know what to even try.

I haven't tested if the Fuel Cost change event is working if set to "At the start of the scenario". Might be worth a shot.

1. A fuel cost setting of 0 gives free fuel to an engine. The fuel cost stays at zero.

A reliability of 0 seems to have an effect, at 2 (Atrocius) the breakdown chance on a new stationary Big Boy is 8.6%, off the scale at 1 it's 12.2% (actually displays as Extremely Poor), at 0 (displays as Atrocius) it's 18.9%. At 11 (Near Perfect) that chance is 0.3%.

2. Um. 11 is Near Perfect, the highest level. I tried 12 and onwards without seeing a change in reliability. I couldn't get a lower figure by trying higher numbers. I tried both straight in the hex and in-game using events. Thank-fully the reliability adjustments work! For easy testing, I set this event to trigger when a small section of track is placed and I can virtually change reliability at will.

I wont do a full test now, but using the 1.06 cheat of "wolverine@msu" to skip years changes displayed engine age and reliability. This might be useful in determining if the amount of load miles traveled or "wear and tear" has an effect on the reliability. What's the chance it's a simple formula to do with age, weight, speed and oil level? I have my doubts that the total load miles traveled is tracked for each engine.

3. I tried a test for acceleration, after discovering that I am having trouble changing this with event also. Same thing, text changes, but train behaves almost the same. I did get some change, but it almost seemed a little random, but the amount of change was nothing near what I got by properly changing the numbers in the hex.

This is not a solid test, because some of the values were varying. It seemed that the time at which I replaced to avoid a water stop had some effect. But, I tried it on some other levels where it made NO difference. Anyway, My test map isn't good for testing acceleration. Average speed is also a debatable way to measure it.

Anyway, Pjay's misses the number 9 in his list. So Instant is 10. I don't see the need for values above that. I tried two, but any potential difference is probably negligable in this enviroment. So, this doesn't prove anything, more for whoever's interested.

4. See this thread:
viewtopic.php?f=67&p=40456#p40456


5. I tried to put some new values for engine type. It seems that the train behaves like a Diesel in terms of no water bar, and the Engine Type: will display as either some other text or blank. One extra class could be created, that you could maybe sort of control with an all engines effect and then counter them with an opposite effect over the three existing classes.

[Gumboots]

What's the chance it's a simple formula to do with age, weight, speed and oil level? I have my doubts that the total load miles traveled is tracked for each engine.

Bear in mind that to calculate fuel usage the game already has to track load miles for each train. So the data is already there, and to apply it over the course of the scenario would only require adding increments to one stored integer for each train. This is going to be a low cost calculation, so I think it is likely that it is used.

I've also noticed in the past that you can screw a loco's reliability by running it low on oil and after that it will never recover. It stays less reliable regardless of servicing and consist weight. By that I mean servicing and consist weight will still have an effect, but the breakdown chance for that one loco will still be consistently higher than others of the same type and age.

I have also noticed that the reliability is tied directly to age. That's definitely one of the multipliers in the formula. If you buy a loco and just leave it sitting in a "railway museum" for years, it will get less reliable over time even though it's not being worked at all.

5. I tried to put some new values for engine type. It seems that the train behaves like a Diesel in terms of no water bar, and the Engine Type: will display as either some other text or blank. One extra class could be created, that you could maybe sort of control with an all engines effect and then counter them with an opposite effect over the three existing classes.

Might be useful for steamships or whatever.

[Gumboots]

Fuel consumption is coded on a scale from 1 to 10 in the .lco file. If for a given fuel economy rating you are getting a simple linear correlation between tons x miles hauled and fuel burned, then it may also be that the simple 1 to 10 rating number is used directly as one of the variables in the game's formula. So if that turns out to be the case, what you'd see is a locomotive with a rating of Atrocious burning ten times as much fuel as a loco rated Outstanding for a given (tons x miles hauled), while one rated Below Average would burn 50% more than one rated Above Average.

Ran a quick test with a few settings that confirms this. For the normal Big Boy on this route (620tons+340tons of cars) normal (Average setting) fuel consumption is 140k. At Excellent setting the cost is 28k. At Atrocius it's 280k. Ran a couple more numbers and the principle seems to hold true.

A little sample to illustrate:

---

A little extra is that the scale seems to continue past the Atrocius 10, at the same increment. I tried 15 and got 669k on an empty 1240 tons.

Hey RoR, I just looked at these figures again and noticed something.

You have fuel cost of $220k on Atrocious, with a weight of 620 tons. With 8 of 40 tons cars added, you would have a weight of 620 + 320 = 940 tons. That is a 51.6% increase in overall weight. However, fuel cost only increases from $220k to $280k, which is an increase of only 27.3%.

The game is rounding things off to the nearest $1K, but what it looks like from this one example is that when calculating the effective weight for the purpose of figuring out fuel cost, the game is taking the entire locomotive weight but only taking half the consist weight.

I have to question your consist weight figures though. I assume you are using default PopTop cargo cars (WP&P's custom cars have different weights). Given the time setting of the Canyonlands scenario, I also assume you are running in the C era (1900-1950).

C era freight cars have a 40 ton cargo weight (.cgo file), but to that you also have to add the 20 ton weight for the empty freight car (.car file). The total loaded weight per freight car is 60 tons. Eight of these gives a consist weight of 480 tons. Add that to your base figure of 620 for the loco/tender combo and you have a total weight of 1,100 tons for the entire train.

This is an increase of 77.4% in weight. However, your fuel cost still only increases by 27.3%. Something very odd is going on here. This definitely needs more testing with a range of consist weights and locomotive weights to nail it down some more.

We don't have the whole story yet.

Then you have your quick test of setting the empty locomotive weight to 1240 tons and the fuel rating to 15. This is exactly double the weight of the standard locomotive/tender combo and 1.5 times the fuel rating, which should give 3 times the fuel cost if it is a straight linear thing. Three times the fuel cost would be $840k. However, you got a fuel cost of $669k. That's only 239% of the fuel cost when the rating is 10. That has no mathematical basis that I can see offhand.

So we don't yet have the whole story here either. It may well be that the fuel rating scale exhibits similar behaviour to the passenger appeal scale, and once you move outside the default range of values things start getting unpredictable. So this is another thing that needs more testing if anyone wants to utilise values greater than 10 for fuel rating (not that they're likely to).

[Gumboots]

Meh. I had a brain fart in my previous post. I took the wrong fuel cost figure when commenting about the economy rating of 15 not matching up with the resulting fuel cost. It does match if the right figure is used, so disregard the last two paragraphs of that post.

Anyway since I'm deep into the language file from messing with pax appeal ratings, I also took a look at the text strings for reliability, acceleration, and fuel economy. I found them easily enough, but the way they are used will make some of them difficult to edit.

If they had used a different string for each different context that a particular word was displayed in, we could edit the strings to make them say anything we like. They didn't do this. They went for maximum brevity. The strings for Average, Below Average and Above Average are not just used for fuel economy, reliability and acceleration, but are also used for graphics quality settings, tunnel and bridge laying settings, and maybe some other things. So if we change the fuel economy text from Below Average to Crappy for example, it will show that everywhere that the term Below Average was used.

For ones that aren't used all through the gui there is more scope for editing. We could utilise the higher end of the fuel consumption scale and change the text there, but it would still affect the corresponding text for reliability and acceleration. So if we want to change the Atrocious fuel rating to be the new Poor for example, and compensate with adjusted train weights, we can do that as long as we can figure out how to fit the same text in with the reliability and acceleration ratings.

Just had another thought too. It might (meaning wild guess at this stage) be possible to get other non-standard ratings for some things. We already know that we can hijack the text strings for freezing of time in sandboxes, and use their hex values to implement custom pax revenue multipliers. These follow closely from the strings for acceleration, etc. The default pax ratings come after reliability and acceleration and then it goes straight into the sandbox stuff.

Code: Select all

	;The next 8 are reliability ratings.
	2673 "Atrocious"
	2674 "Extremely Poor"
	2675 "Very Poor"
	2676 "Poor"
	2677 "Good"
	2678 "Very Good"
	2679 "Outstanding"
	2680 "Near Perfect"

	;The next 4 are acceleration ratings. Also see @3172.
	2681 "Is it moving?"
	2682 "Ultra Fast"
	2683 "Virtually Instant"
	2684 "Instant"

	;@gumbootz: 2685 is deprecated by @3173 later in the file.
	;			Due to being deprecated, 2685 cannot be used.
	2685 "Hideous"

	;@gumbootz: Customised passenger (pax) appeal ratings begin here.

So, it may be possible to hijack the remaining sandbox strings that we don't want for pax appeal, and use them to get handy multipliers for fuel economy or whatever. The catch is that they use a different scale. They're based on 10% increments rather than whole integer jumps. This works well for pax appeal but would completely up-end the other scales and would probably require a lot of testing to get something useful. However, just as one possibility, since the current Outstanding fuel rating gives fuel cost of 1x and the Very Good rating gives fuel cost of 2x, then perhaps we could nick the hex value of 13 00 00 00 (string 2704 "Frozen at 9am") and use its multiplier of 1.5 to get a new fuel rating halfway between Outstanding and Very Good.

[RulerofRails]

Yep, I'm using default cars. And, yep, I didn't include the 20 ton un-loaded weight in any of these diagrams. Also, anything I tested above 9 as an integer may be off, because I wasn't taking the hex numbers into account. I think the "15" (represents the decimal value of 21?) fuel setting should be ruled out at this point, along with any higher acceleration levels.

I agree that the consist weights seem to be counted differently to engine weights. I was always planning to test some more on what the effects were. Who knows if the scale is linear also, but cost is applied at a different rate for each ton the train is dragging? Maybe I will get some time in a couple of days to run some more testing.

[Hawk]

Double post.

Do you not have this option available?

---

Edit 1: I checked the permissions and I'm guessing you didn't have that option before, but you should now.

[Gumboots]

Oh that. Never noticed it. I was looking for the delete button at the top right of the post. It wasn't there.

[Hawk]

I guess it got moved in the new version. It might not have been there before for regular users. I made a change in the ACP so I don't know if it was there before or not.
Either way, you got it now.

[Gumboots]

Cool. I can see it now. Makes things nice and obvious.

Edit: Oh I remember now. It's one of phpBB's quirks that the delete button at the top of posts only shows for the last post you made. This is still the case. Beats me why they coded it like this, but they did. Posts older than the most recent one have to be handled on the separate reply/edit page. As long as I remember that I'll know where to look in future.

[Gumboots]

I agree that the consist weights seem to be counted differently to engine weights. I was always planning to test some more on what the effects were. Who knows if the scale is linear also, but cost is applied at a different rate for each ton the train is dragging? Maybe I will get some time in a couple of days to run some more testing.

I've just done a few quick tests myself. These are limited and basic, but do seem to clarify a few things.

I used the same scenario start I was using for the pax appeal testing. I increased the fuel rating integer in stages: from the usual 04 to 05, 06, 07, 08 and 09. Also threw in 10, which of course is 16 in hex.

Picked a train that was just about to leave Canberra with 6 freight and 1 mail (all 100% full) and 1 pax (80% full). Tracked it all the way to Sydney, which is a good long run. This is a mostly downhill run, on moderate grades. Results looked like this:

Rating.........Fuel cost
----------------------------
04..............$16K
05..............$20K
06..............$25K
07..............$29K
08..............$33K
09..............$37K
10..............$65K (double the cost of the 08 rating)

So yup, you were right. That's definitely linear. Also tracked similar trains uphill back the other way (consist weights were slightly different) and the fuel cost was within 1 or 2 K either way. So yup, grades don't make any difference, as your own tests indicated. It's definitely down to just weight and distance. That's the easy bit.

Now for the good bit. I accurately calculated the consist weight, using the values in the .cgo and .car files. These are all for WP&P's cars in 1935.

Type.......Car weight.......Cargo weight
------------------------------------------------------
MailC.......20 tons...........40 tons (x 1)
CoachC....20 tons...........32 tons (80% full)
BoxC.......20 tons...........40 tons (x4)
PulpC......20 tons...........40 tons (x2)
-----------------------------------------.
Total consist weight........472 tons.

Berkshire weight............150 tons.
Tender weight................40 tons.
------------------------------------------
Complete train weight......662 tons.

Next step was to get an empty Berkshire and tender (190 tons total) and run it down the same route. I used the 08 fuel rating, just to get higher numbers for better definition. Result was a fuel cost of $17K. This is near enough to half the fuel cost of the loaded train, allowing for rounding off to the nearest $1K.

So: 472 tons of consist has the same effect on fuel economy as 190 tons of loco and tender.

Next increase the locomotive weight to 622 tons, giving 662 tons for loco and tender to match the complete train weight. Result was fuel cost of $67K, or double the cost of the complete train with the locomotive at normal weight.

So a fuel figure of $17K (50% fuel) for loco + tender at 190 tons (100% weight).

8 car consist fuel of $16K (50% fuel) for a weight of 472 tons (248% weight).

Complete train fuel of $33K (100% fuel) for a weight of 662 tons (348% weight).

Then a fuel figure of $67K (200% fuel) for a heavyweight loco + tender (348% weight again).

This means that the weight in the locomotive costs three times as much in fuel as the same weight in the consist.

Default freights are currently around 50% heavier than default express consists. My guess is we want freight to end up at least twice as heavy as express. If we leave express alone, that would mean increasing freight weights by around 33% or so (1.5 x 1.3333 = 2). That would only increase fuel usage on freight trains by about 17% (50% x 1/3), even if we don't change fuel economy ratings at all. We could leave the fuel economy just like it is now, and if necessary reduce locomotive weights by around 33% or so.

Alternatively, we could leave freight where it is now and just reduce express consist weight by 25% or so (2/3 x 3/4 = 1/2), with appropriate reductions in pulling power and free weight for express locos. This would knock about 10% off express fuel costs for the same fuel rating.

---

I was running a Red Devil and found that after 3 years I had a breakdown rate around 45%. Switched back to normal weight (different product) and the breakdown chance dropped to 15%. Given that the Red Devil has a good rating, this doesn't bode well for the poorer engines.

I just remembered this, from when you tested some of WP&P's multiple cargo cars. So the limiting factor isn't going to be fuel economy. That's easy to deal with. The limiting factor for consist weight is going to be its effect on reliability. At the moment freight consist weights work pretty well for reliability, even into the post-1950 era. A post-1950 8 car freight consist has a weight of 960 tons (@ 120 tons per car). This plays ok with reliability ratings of Above Average or Good.

We should probably keep some scope for 1950's onwards locos to haul whatever freight weight we assign them without having to set them all to Near Perfect reliability. That may mean that we use the current D era 960 ton consist as a baseline for weight in the mid to late 20th century and work backwards from there. 21st century locos can be given higher reliability ratings, so we could gradually increase 21st century weights to whatever plays well. I'm thinking the ultimate weight may not be over 1200 tons or so, but maybe as high as 1500.

[RulerofRails]

This means that the weight in the locomotive costs three times as much in fuel as the same weight in the consist.

This seems to be the case. However, this doesn't fit with the utter uselessness of the Big Boy in-game. So, I did another test, just quick, but it gives me a new hypothesis that:

the code shortcuts using the cargo weight entirely.

This fits with the 1/3 cost you saw because the game is only using 1/3 of the total weight (cargo value is by default 2x car value).

This means that locomotive weight is playing a much larger factor in performance. In the case of the Big Boy, 8 default D-era cars weigh just over half what the loco does. This fits with an increase in fuel cost from 108k to 168k (51% increase) with a weight increase from 600* to 920 (51% also). (ETA: I got my figures confused here. The Big Boy always was 560t engine and 60t tender for 620 tons, but in the process of editing the file so much I got the engine weight confused with the free weight value which is 545, knew it was even to the tenth place, so used 540. )

This is another shortcut in the code. It doesn't affect the plans for heavier cars as long as we change both values in the same proportions (if we even bother). Reliability is on a brand new, loaded train at the same point of the return run. Naturally speeds will be different when the game is seeing a different "weight" value so it's not meant for an accurate calculation of ratios. The whole test was made with the default Big Boy on the Canyonlands test track. For comparison, a reminder that the empty (600 "tons") fuel cost is 108k.

[Gumboots]

That's interesting. It leads to asking why there is even a weight value in the .cgo file at all. It could be just a leftover from alpha. Perhaps they were initially thinking of using a more sophisticated algorithm, but decided against it.

Ok, so this means we can ignore the .cgo files as far as weight goes. It may even make sense to set them all to zero weight, just so people are reminded it does nothing. The only relevant files for weight are the .car ones. That's good in that it will simplify testing. We only have to edit half the number of files (yay!). Come to think of it, this may well be why they did it that way.

However, what it does mean is that any cargoes that share the same base model (like anything carried in box cars, for example) would be forced to share the same weight effects in the game. Not a problem, just something to be aware of. Introducing separate models to differentiate cargoes is not difficult. They can even share the same mesh and skin if we want that, and just distinguish on the basis of the .cty file and a few others.

Re reliability: useful data there. Matches up with what I found earlier.