Cargo weight revamping

[Gumboots]

Not sure it really needs a whole 'nother pack. It's just a .car file. I could throw it in my pack as an alternative (in its own "Alternative F era" folder) in case anyone else hates saving the whales.

How about I just link it in my sig for now?

[AMD 103]

Not sure it really needs a whole 'nother pack. It's just a .car file. I could throw it in my pack as an alternative (in its own "Alternative F era" folder) in case anyone else hates saving the whales.

How about I just link it in my sig for now?

That's fine. Though I don't hate the whales, i really do like them. It's just that they're rather uncommon in the scope of things. So much that I think you've made the only 3D Rail Whale out there.

Congrats, RT3 has something nothing else has.

On a more serious note, do the hexadecimal values still check out for a proper car weight?

[Gumboots]

Yup. Perfect match for the whales weight.

Y'know that idea of splitting whales off to a less common cargo would not to be hard to do. In theory it's a bit more processing load on the game engine, but probably wouldn't be noticeable 99% of the time. The only tanker cargoes in my pack are Chemicals, Diesel and Oil. From what I can gather whales seem to have been used for various types of chemicals, so that's probably a good match for them. That way you'd get a bit of a mix in the tankers. I could be convinced to play with that idea.

[AMD 103]

I like that idea actually. It'd focus them around what they usually haul and not have them everywhere.

[Gumboots]

Been thinking some more. The problem with having individual cars for each cargo is that which ones you want to be noticeable will depend on the scenario haulage goals. That means there's probably not much point going for a complex colour coding or anything like that, because it will be hard to remember. However, you could do something like this:

It's a bit over the top on A era boxcars, but would be fine from C or D onwards, and it wouldn't be hard to make the A era icons a bit bigger anyway.

Splitting all of the 1.05 and 1.06 cargoes into individual cars for each cargo is not difficult, but it means a lot of extra files sitting in game folders. Each double car generally has a .car and a .cgo and a .cct, as well as a _Body.3dp, _Truck1.3dp, _Truck2.3dp, _Truck1Bogie1.3dp through to _Truck1Bogie4.3dp, _Bogie1.3dp through to _Bogie8.3dp, _Truck2Bogie1.3dp through to _Truck2Bogie4.3dp, _LengthPoint.3dp and _TrackPoint.3dp, _Profile_A.dds, _Profile.imb, plus _A.dds through to _F.dds skin images.

Some of these obviously exist anyway, but if we were to split all cargoes out to their own car type (which is generally where all of these mod packs always seem to end up heading) that would be an extra 22 car types in 1.05, and an extra 30 in 1.06. That means an extra 44 files in EngineTypes and an extra 650-ish in PopTopExtraContent for 1.05, while 1.06 would have an extra 60 files in EngineTypes and an extra 850-ish in PopTopExtraContent.

Obviously they all have to be processed by the game engine in real time, but that may or may not cause performance issues. It would have to be done and tested before we would know. 850 extra files does seem like a lot though.

Offhand I don't know if different car types can call the same .3dp and .dds files. I vaguely recall some difficulties there but haven't tested it for ages. If we could get away with calling the same .3dp and skin image for every boxcar cargo, that would make this cunning scheme much more workable. Then you'd only have to worry about .cgo, .car, .cct, and _Profile.imb for each cargo.

---

Edit: Just ran a quick test. I split Alcohol out to its own special reefers (already had this set up for my own use) with its own profile icons. Then I edited the xAlcohol-.car files to call xReefer-.3dp and xReefer-.dds, but left the .lco and Profile.imb calls as xAlcohol-.

The result was amusing. What it does is call the correct car models, but the wrong profile icons sometimes. For some reason (dunno why yet) although both Alcohol and Milk will now load in the standard reefer for the era when you're looking at a train on the tracks, the call for xAlcohol_Profile.imb is overriding the call for xReefer_Profile.imb, with the result that when you are looking at your train list, a train hauling milk (or any other non-Alcohol reefer cargo) with be displaying the icon for the custom Alcohol reefers. This is a PITA, because the profile icons are what is really needed.

It's not a case of the last file overriding previous ones, because xReefer comes after xAlcohol. It may be a case of the first file setting the Profile.imb for any subsequent files that call the same .3dp or .dds, which would be bonkers, but not any more bonkers than umpteen other things this game does.

It may be possible to work around this by setting up a custom equivalent of the default CarSideView_1.imb. That would just be a custom .dds that holds icons for all the possible reefer cargoes and eras, with the right one for that cargo and era being called by the byte that usually does the same job for CarSideView_1. If that works it would be a reasonable option. It would not be hard to set up, so I'll test it later.

(I did try not setting the .lco as xAlcohol-, and leaving that at xReefer- too, but what that does is make the train haul empty flat cars. They are still the right cargo internally, but visually it's just empty flats.)

---

Edit again: Ran some more tests. Looks like it's a no go.

I made up a custom .imb that allows icons for a range of cargo cars, the same way the default CarSideView_1 is done. It's not hard to set up, and generally it works, but there's still the same problem with the Alcohol icon overriding generic one, even though they are both called from the same DDS now and even though they (should) call different chunks of the DDS.

As far as I can tell, if you have a number of different cargo cars calling the same .3dp and .dds it will work, but the first .car file to call that .3dp and .dds will also define which profile icon is called for all of them in that era. There doesn't seem to be any way around this. So yes, it's RT3 and it's bonkers. Hey ho.

At least I know for sure now. To work reliably, splitting out cargoes to their own car type has to be done the long way, with a complete file set for each separate cargo. No short cuts available.

[Gumboots]

Decided this thing is getting a bit messy, so I hijacked the first post of this topic for a zip/spreadsheet stash that hopefully anyone can find easily, and that I can update easily.

I've just added an updated express pack that has some extra bug-proofing added. Have also added the final version of the weight scale spreadsheet.

I'll go through all the other car packs in this thread and check them for things that need fixing (ie: cargo icon fixes for some boxcar cargoes, etc) and get them repacked where necessary. Then they can all be stashed in the first post as well.

This should be much saner than the current mess.

[Gumboots]

New caboose pack is now in the OP of this topic.

[sbaros]

it would be possible to cut the weight of the "caboose" post-1990, and only make it weigh as much as a clip-on gizmo. That way you would get the increased reliability, and still lose one car slot, but wouldn't have any weight penalty. Your loco would only be hauling the weight of 7 cars.

This gives me an idea to convert the caboose concept to a banking locomotive concept. This would require:

1. Replacing the caboose skin with a locomotive appropriate for each era
2. Assigning to that ex-caboose a negative weight (say minus 1 car weight, to begin this experiment with something modest).

The effect will be that the train will have a maximum of 7 revenue-earning cars (so leaving behind the least profitable 8th car, which is not a big loss), but run uphill as if it had 6 cars.
As things are now, a long flat route with intermediate short steep sections forces us to define separate train itineraries, since there is no engine-changing capability in the program. This uses up excessive train slots, makes traffic more difficult to manage, and most important, one cannot synchronize their operations between sections. This also renders express locomotives almost useless. Their speed advantage will more than vanish when their cargo awaits the mountain-climbing train at the grade-changing station to pick it up. So, with this proposed banking locomotive concept one would spare train slots and waiting time. You would just have to tick the "Caboose" option for the consist at the appropriate waypoints. And not to forget the fun element, a train with locomotives at both ends on a spectacular mountainous route will look superb!
The main thing is, does the program allow negative weights for the caboose (or whatever car, for that matter)?

[Gumboots]

I haven't tried negative car weights yet. It might work. There's only one way to find out.

I can think of one possible issue. Since the game algorithm uses exponents on the car weight, any odd powers of a negative number will still be negative, but any even powers will give a positive result.

[RulerofRails]

Assuming that negative weights are possible, such a hack idea, while very creative, is unfortunately going to have some unavoidable drawbacks when implemented within RT3's limitations. For example: less train weight means lower fuel costs and lower breakdown chance. Both unrealistic for a train with a "helper" engine. A cool idea for a specific scenario though.

[Gumboots]

If you just wanted to use it for fun, in certain sections, it might work. However, if it is available it automatically becomes a obvious exploit for use in all areas.

[sbaros]

One wouldn't want to use it on uphill sections less than 3% anyway , since it would take out a revenue-earning car without sufficient reason.
On the other hand, there may be some indirect way to financially charge the "helper engine". An impact inverse of the "Reastaurant Car" (which increases the generated revenue), in case this is not "hard coded" within some undetected part of the core program.
Of course, since unlimited "cloning" of RRTycoon3 on the same storage media is possible, one of the instances could contain this variant, it is not necessary to wipe the caboose off the face of the earth (and this includes actual operations too!).

[Gumboots]

Sure, multiple installations allow all sorts of targeted tricks. There are some tricks you could do with a scenario too, such as decreasing reliability by 50% in some areas (to effectively force the use of the caboose to bring it back to normal). There's nothing I can think of that you could do with revenue, except possibly using those same areas (defined as territories) and tracking revenue within them, then adding a monthly decrement to revenue to simulate less revenue/greater running cost.

You could even extend the reliability idea. If most of the map has boosted reliability that would encourage people to not use the caboose except where you want "banking locomotives".

But, the first thing to do is to try out negative weights and see what happens. Make sure to test with an odd weight (ie: -1, -3, -5) and well as an even weight (ie: -2, -4, -6) to cover the exponent issue I mentioned.

PS: I have thought of skinning the caboose as a banking loco + tender before, just for fun. It's not hard to do in principle. The only limits are a/ you have to set the loco body and tender as trucks of one car and b/ the loco and tender skins have to be on one image.

[sbaros]

Maybe a tank engine (not unusual for banking duties) would simplify this a bit?

[Gumboots]

Doesn't really matter, unless you're wanting to use a very large loco/tender combination. Something like a Big Boy wouldn't be feasible, but a Consolidation or a Kriegslok would be fine. But yes, a tank engine would work too.

[sbaros]

I think it worked after all ! Read here the details.
The modified file is attached here.
Update/Caution: Due to the problem reported below, I am temporarily withdrawing the Caboose-to-Banking modification download to avoid eventual screwing-up of inexperienced users' installations.

[Gumboots]

Run it through my spreadsheet. That will give you performance predictions for any weights.

viewtopic.php?t=4194&p=45528#p45528

You are obviously getting increased speed, but without running the numbers it's hard to tell if you're getting the full benefit of the coded negative weight.

[sbaros]

Ohh, if these are shocking news to me! You inform me that I was using the false speed-traction tables all these 15 years, consequently choosing unnecessarily powerful -and costly- locomotives, because the program apparently uses a different formula for the displayed tables than the formula actually applied during the simulation. If there would be a S.O.S. list of the half-dozen more important bugs, this one should really be included and displayed at the most prominent places of the website where users are expected to visit for downloading stuff etc (maybe there are such notices already and I have missed them). Everyone should print the spreadsheet and have it handy, since it's awfully awkward to switch back and forth between the Tycoon screen and Excel.
I would be cursing the programmers, but in fact I have also committed myself a similar embarrassing blunder involving a real railway. I had developed a program simulating a train's movement on a given track and instantly producing the timetable "string diagram" and power demand over time (the latter being superimposed together to visualise the load at substations). This is based on Strahl's formulae for train dynamic resistance. When working a second job for the preparation of the Athens Airport commuter line before the 2004 Olympics, I left one leading zero out of the transmission resistance factor of the Siemens "Desiro" E.M.U. unwillingly increasing it 10-fold! It was a Sunday night's work after an exhausting weekend. The effect was equivalent to the train operating with the brakes slightly on. It made negligible noticeable difference on the timetable (in the order of a few extra seconds between adjacent stations). However, the experienced German consultants of the engineering project found the power consumption excessive, so I looked at the job once again and realized my mistake.
Interestingly enough, the Germans opted to correct only the power consumption and leave the timetable as it was, to allow some margin for eventual delay recovery. They also defended me towards my outraged native colleagues.
I have taken an extensive look at the spreadsheet. I have some important questions and remarks, which I want to gather on a separate piece of text.

[Gumboots]

Ah yes, those dreaded zeroes. Who came up with those anyway?
Feel free to start another thread about the spreadsheets if you like. We probably should organise things a bit better.

[sbaros]

Stop Press ! Serious bug with the caboose/banking loco replacement above.
The negative weight algorithm I proposed above worked with no problems. However, when I replaced the caboose 3D-model with the "Adler" 3D-model as shown above to represent a banking loco, the following weird thing happened: After each section where the disguised "banking caboose" was activated, an additional phantom of the "Adler" attached itself permanently behind the leading loco. The dynamic behaviour of the consist was not affected, but as you see in the embedded picture, after several uses of "banking" the situation looks like this! Notice that these "phantom" vehicles don't count towards the 8-car limit.
The negative weight by itself cannot be the reason, otherwise it would happen with the caboose skin as well. Generally, it happens when you use a locomotive skin for the caboose (or even a tender), but never when you substitute any hauled car skin instead. Some factor causes locomotive skins to reproduce themselves infinitely. I 'll conduct some further experimentation and let you know the results.

---

Notice that when you correct the caboose's .CAR file (i.e. replacing the linked loco 3D-model with any hauled car skin) the phenomenon stops, but all trains in the saved sessions continue eternally with the previously attached "phantom" engines. At least a useful trick if you want to see some of your trains permanently double- or tripleheaded. You use temporarily your favourite loco skin as a "caboose" until it is permanently attached behind the genuine engine, save the session, exit the Tycoon, revert the caboose .CAR to a hauled wagon skin and reload the Tycoon and your saved session. Any "phantom" engines thus created, will persist even after you upgrade the train engine, or dieselise or electrify your operation, whatever.
To add your favourite tender, you have to repeat the procedure, the second time using the tender's skin for the caboose. You can do this individually for additional trains, each such cycle for the next one, while the caboose is turned temporarily off for all other trains.