maxweight problems?

Recently a couple of folks have noticed that hoppers that used to load up to the edge with auran coal have stopped doing that and are only loading a bit over halfway.

We noticed this with socalwb909's bethgons but it appears to be happening with other rolling stock as well.

As near as I can tell this is something new. The gons have not changed so far as I can determine so it must be either the coal product or the way that volume is calculated from maxweight. Removing the maxweight parameter from the config.txt solves the problem but that is a kluge and not a fix.

Help!

It's probably the coal product.
<kuid:44179:60013> -- mass 0.86
<kuid2:44179:60013:1> -- mass 1.35 (correct for a solid block of coal, but not for a load of coal)
For cars which check only the size of the queue, would animate the load in the same way as before. Car which limit the weight of the load, would not fill the queue.

Peter

Thanks Peter that sounds like the problem. I'll submit a help ticket.

Edit: This is probably affecting most steam locomotives that use Auran coal. This was changed on Nov. 27, 2019 (at least on my system), surprising no one noticed before now.

You know I was just going to PM scratchy that in TRS19 the K&L PRR 2-10-0 decs stall out in the session he made for them (available on the K&L site). I ran it several times in TANE but in TRS19 I can't get the 14 loaded hoppers up the short 2.2% grade on the curve after the stop at the red signal (224900) at junction RT1. I drive a lot of steam and something changed.

Thanks, I'll check out the tonnage difference in the load and see if that's problem here.

Definitely a show stopper for many "coal" sessions I'd think. Who authorized that one?

Bob Pearson

[Edit] PS

normhart said:

...
Edit: This is probably affecting most steam locomotives that use Auran coal...

Click to expand...

Well it will affect most hopper and tender weight with coal loads but it's effect on steam locos might not be all that much. The standard way N3V handle things is by volume for queues so we get more weight (mass) in the same tender volume unless we have a script that limits the volume available to load the coal so it won't exceed a specified maximum weight.

In either case though unless N3V have changed the game code from TS10/12 days the shovels of coal are specified in kgs not volume and the mass density (in the game code) for any fuel used by steam locos is 0.86 kg/ltr - the same as the base Auran coal density and it is hard coded not read from the product config - an oversight that rises to a suggestion box crisis but I gave up mentioning it 8 to 10 years or more ago - and that's what is used to determine how many ltrs of coal are used per shovel fed into the firebox. Of course to make it a bit more interesting the queues use integer math and the shovel and firebox use floating math so some truncation of amount takes place in the conversion. I hope they have made some changes in the last say 8 years but even if not what's it all mean?

Since the steam loco espec specifies both the kg of fuel per shovel and the energy per kg of fuel in the firebox nothing is changed. Oh if a max weight is enforced on the tender by a custom script then you'll have to stop and fill it up a little more often if the coal has a higher density.

Anyone know where <kuid2:44179:60013:1> came from?

In both TANE Sp3 and TRS19 100240 when I search for it, it comes up "unknown".

So this can't be the cause of the problem I see in the Coal Country session. Certainly would have been the easy way out though.

Bob Pearson

I'm not sure. It is listed as built-in so it probably came with <kuid2:354694:100700:1> Belarusian woodland DLC most likely in the <kuid2:151575:4003:1> CO17-1171_tender that came with the route which I installed on Nov. 27th.

It is probably included in the Russian CO17 locomotives and locomotive pack too.

Since it is built-in I can't delete it or edit it.

In TRS19 SP1 it's a base asset. It's not part of any package, but it's in the resources folder of the program.

Peter

Thanks to you both for the replies. I have not upgraded to SP1 yet. I was waiting for the 1st "hot" fix to arrive. Now it seems there's more to look out for.

Bob Pearson

Gents,
I want to thank p-dehnert for that intriguing detail about the coal loads changing.

I went back to the session TS19 Coal to Richmond and started as usual. Once I had loaded all the coal hoppers, I edited the session on the fly. I was going to change the coal loads from the full 90800 to around 2/3rds of that. I roughly calculated that to be a load of 90800 x 2/3 = 60534 (rounded up). The session wouldn't let me change the loads to the cars, so I deleted them and replaced them with the same 12 coal hoppers, but this time loaded them with 60534 instead of the 90800.

At the message to hit V (sander) and throw the throttle to notch 8, I was doing 18mph. I did this and was speeding at 24/20mph limit as I hit the base of the hill. From there I lost speed quickly, but was doing 12mph across the trestle and 11mph as I started up the grade after the trestle. I made it all the way up.

I retried this, but only hit the V key at the message, and didn't throw the throttle to notch 8 until almost at the 20mph sign. So, I wasn't speeding as I started up the hill. Speed bled off quickly again, but I was doing 11mph as I approached the trestle, and kept up the 11mph all the way over the trestle, and actually increased to 12mph as I got close to the switch to the siding. Again, success.

The long and short of this is, by reducing the coal amount by 1/3, which is about what the Auran Coal kuid change was, I am able to finish the session as intended by Scratchy.

That kuid change definitely had a negative impact on sessions that had been created using coal loads. I'm thinking that the sessions 03 - Coal Service and the PRR Decapod Coal Load will now be successfully completed if the coal load is reduced by 1/3rd for each coal hopper.

Heinrich505

re Posts 4 and 9

Hi Bob and Garry

I’m trying to get to grips with the whole issue of loading coal and the impact it can have on session performance. I’ve experienced the same problems that have hit others on Coal Country, Hinton, also on my own Welsh Valley route. Basically, it appears that the session success is directly related to locomotive performance, the topography of the route and the weight of the trailing load. It’s the last of these three that is causing me most concern in that there appears to be number of very strange variables.

As a test exercise I selected 7 US Hopper wagons – the RPPX 100 ton unit and six other PRR standards (TRS 19 – Build 105096). These were set up on a level test track and individually weighed (Net Weight) using the “View Detail” facility (Ctrl + RMB). They were then assembled and the total trailing weight of the consist was established and recorded. The consist was then loaded using the JR Parker Tipple/FGLoad 5mph asset. The trailing weight of the entire consist was first established and then the consist was split up and the coal load and the gross weight of each individual hopper was recorded. All these figures are shown on the accompanying chart together, where appropriate, with the net, load and maximum permitted gross weights for four equivalent prototype hoppers.

The disparity and inconsistency between the net, load and gross weights of the simulations is glaringly obvious as is the disparity between each of the simulated hopper and its prototype equivalent. A number of questions come to mind but foremost among them is, do all these net, load and gross weight figures have any true relevance in the equation which determines the X load/performance factor in all the sessions, if they are all relevant how do you explain the obvious inconsistency and if they are not all relevant – why are they included?

I’m probably asking for the moon but a few pointers would be good because at present these figures don't make any sense.

Gary, while I accept that altering the 90,800 figure by 2/3rds solves the problem of getting up the gradient, I'm just hoping there's a better solution.

regards

John Webster

Hi All
We are currently looking into the coal commodity weight issue. It appears that this was updated mid last year to correct the mass to be more accurate, but of course if assets have been designed to carry the correct 'weight' of coal (rather than the correct volume of coal, with 'bulk' commodities being 1000 cubic centimeters - this is how the mass is then meant to be figured out for a commodity; the mass of that commodity in 1000 cubic centimeters), then this will make them overweight.

We have been looking into this, and at this stage it is very likely that we will release an update for this commodity to revert the mass back to it's previous weight. This should result in vehicles carrying the correct weight of coal, but likely having a higher number of 'units' than they should. Unfortunately, if a creator has made a vehicle hold the correct volume of coal (ie 1 unit = 1000 cubic centimeters, then multiplying units to reach the correct volume in the wagon) then the wagon's maximum load will be substantially under weight.

Of course, creators wanting to get the correct maximum weight based on volume (ie for lighter items, the maximum capacity will be lower than it's maximum load weight) should be able to do so. You would need to work out what volume the 0.86kg mass is, if you assume that 1000 cubic centimeters is 1.35kg.

In theory this should be ~636.95 cubic centimeters of coal to make 0.86kg of coal.

So our calculation should be, I think, something like:

volume of wagon in cubic centimeters/1000 * 1.57 = number of units

I think. The first division I think should give us the number of units of coal the wagon could physically hold, if the mass were 1.35kg. The multiplication of 1.57 then takes into account the incorrect mass of the coal (ie it's too light, so we need to artificially make it heavier).

Please correct me if I'm wrong on this calculation though, it's been quite a while since I've actually tried to calculate volumes/etc like this!

Regards

Will this help? https://www.simetric.co.uk/si_materials.htm

There was a time when tenders started to have a full load of coal floating above the top of the tender. It happened last year about half way through the year I think. At that time you could reduce the amount of coal in the initial load and all looked ok. but if you refueled the tender at a coal mine or at the steam filling station it then floated above the tender again. This made me think that the load animation had changed slightly because even if you reduced the max load figure it did not make any difference.
The amount of animation set in the .kin file should always be the same over different versions of Trainz.

Cheers,
Bill69

John,
That's a pretty impressive and very revealing chart you have. Nicely done, as even a novice such as myself can see the disparities.

I like to run 140 car consists on the Powder River Route, and with the change in the kuid for coal loads, this has me flying by the seat of my pants when trying to figure out motive power. At least on that route, the grades run around 2% and are steady, unlike climbing that beast of a mountain in Coal Country. My 2/3rds calculation was mainly based on the change in the kuid that seemed to roughly increase the weight by a third. It was definitely not a figure that was scientifically calculated. But, it did work. I liken it to the statement that even a blind squirrel can sometimes find an acorn. :hehe:

Just like you, I'd guess there has to be a better solution. Going down an entire consist of, say, 140 bethgons, and knocking off 1/3 of the coal load seems to be a very inefficient and cumbersome way of approaching a fix.

Gary

From Bill69's table

Coal, Bituminous, broken - 833 kg/cu.m
Coal, Bituminous, solid - 1346 kg/cu.m

<kuid:44179:60013> -- mass 0.86
<kuid2:44179:60013:1> -- mass 1.35

Pretty obvious that the original mass was correct and, if I understand Zec's post, there is no reason to be concerned about volume. The volume contains a lower mass for broken coal because of the air space between chunks of coal.

normhart said:

... Pretty obvious that the original mass was correct and, if I understand Zec's post, there is no reason to be concerned about volume. The volume contains a lower mass for broken coal because of the air space between chunks of coal.

Click to expand...

Norm I'm not sure I follow the comments on volume you made. Volume is important and in fact volume is the only thing Trainz considers when it loads cargo into a railcar.

I started a reply to John and Zec but I think some clarification of how Trainz treats all this is relevant:

The railcars in trainz have a tag called mass that is the unloaded or empty mass and in the US this is equivalent to the tare weight - note weight and mass are related in that weight is the force of gravity pulling the mass towards the surface of the earth. The weight of the loaded railcar is called gross weight and native Trainz has no tag to represent that. In order to carry cargoes in Trainz railcars need to have product queues specified. These queues specify the VOLUME not mass or weight of the product (commodity or cargo if you like) that the queue can hold. Products in Trainz are assets and the ones for bulk commodities like coal have a tag called mass but it is really the mass desnsity of the product. Volume for the queue is specified in units of 1/1000 cubic meters (litres) and mass densities of the products are specified in kg/ltr. You can convert between metric units and imperial and US standard units and also between mass and weight based units using standard conversion factors.

A point of fact: when loading railcars, native Trainz does not consider mass/weight at all - only volume. Real life railcars have weight limits imposed on them - the Maximum (allowed) Gross Weight , but native Trainz does not impose any weight limits. It loads the railcar by determining how much volume (space) is available and then filling up that space with the product. So an industry will always transfer x litres of product to the railcar - sufficient to completely fill the volume available in the railcar's product queue. That is without some custom script to intervene.

Physically real hopper cars have a maximum volume that can be filled with the cargo. The volume of the hopper measured to the top edge plus maybe some extra that can reasonably be heaped up above that is the maximum volume available to carry bulk cargoes and we can specify that as the maximum volume of the product queue. Typical densities used to determine how much mass or weight of cargo that occupy that volume take into consideration how big the individual "chunks" of it are. It's an average value especially for minerals/rock/stones that are mined/quarried and consist of pieces and chunks of varying sizes that pile up with random sized void spaces in between the chunks. With coal that's been graded we can see numerous values based on mineral content and graded size of the "chunks". Here's just some of the coal products available in Trainz:

It is only after the product is loaded into the railcar that Trainz uses the mass density to determine how much mass has been added. It is calculated from volume of product in the queue times its mass density. But a real railroad wouldn't fill the hopper up to the "brim" using all available volume if the weight of that cargo plus the tare weight of the railcar exceeds the maximum allowed gross weight. The gross weight value can't be exceeded in operation of the car. With lite density cargoes all the volume will be used and the gross weight will be less than the max allowed gross weight. With heavy cargoes there will be unused volume left over but the gross weight always equals the max allowed gross weight.

We could do as Zec mentions and work around this by specifying a queue and setting the volume of the queue artificially based on the product's mass density so the product loaded plus the tare weight would not exceed the railcars maximum allowed gross weight. In fact in native Trainz this is the only way we can do this. Of course every bulk product we load would need a separate queue and volume determined by it's mass density. But typically in real hoppers cargoes won't be mixed and the same cargo space is used for all cargo products carried.

Using the method Zec discusses we still have the problem where a heavy cargo would not fill the "real" hopper up when it reached the max weight limit but we'd see the hopper 100% full in Trainz because the queue we specified is 100% full. Would we need different animations to represent each product density? Or a custom script and a way to determine what % of total hopper volume this queue represents? The actual volume available to load in the real car never changes but doing it this way we have to change that volume for each product carried.

Well, back in TRS04/06 era some creative content creators (lars was one) set up a script system and a railcar tag, the maxweight tag, to fix this. The maxweight tag provides a way to specify the maximum allowed gross weight of the car. I believe and many others back then did too that this was an oversight in Trainz. It is still not part of native Trainz and therefore up to each content creator to make use of this or similar systems or not make use of them as they see fit. But in short, systems like this work like the real world does and limit both the volume loaded so it does not exceed the volume available and at the same time also ensure the weight loaded will not cause the railcar's maximum gross weight to be exceeded - regardless of what product is loaded into the hopper. This system uses both the available volume in the queue and the product's mass density to determine how much product is loaded. And I'll repeat: native Trainz does not do this. And to implement it we only need the 1 additional tag and the 1 queue volume that represents the actual volume for the railcrar hopper to work with any bulk cargo.

Bob Pearson

Some creators have made an effort to sort the weight in a given traincar. I have seen hoppers that have a different max load for different products. But the fact remains, if you specify a given car with a max of 65000 units of wood shavings, then specify the max load for iron ore at 6500 units in the same car the volume in the car will look the same for each load.

Sorry, when I was referring to volume I was speaking to hoppers that did include the maxweight parameter. My experience with these has been that they seem to accurately reflect the expected volume for a given weight (unless the mass is wrong in the commodity or the maxweight value is wrong for a given car.)

I do find the whole thing somewhat confusing since in virtually every picture I've seen of modern coal hoppers they are full to the top and above.

Was the download available on the DLS yesterday for coal 2:44179:60013:3 an attempt to correct this whole coal hopper thingy?
Dean

danddhud said:

Was the download available on the DLS yesterday for coal 2:44179:60013:3 an attempt to correct this whole coal hopper thingy?
Dean

Click to expand...

Looks like it! My 100 car SATX unit train loaded to the gills without problems. Now that's what I call a speedy response!



OK in TRS19 too (and there are some new Bethgons on the DLS!)



Thanks Zec and the programmer guys!

Norm,
Just got done earlier downloading the newest bethgons- Thanks Revans!
Dean