Cargo & Industry fixes for 1.06

[zzc]

I've just realized why goods appear before the factories by watching plastic appear before the factory. So I get that it is to create price ranges - the toy factory starts demanding plastic at the same time. Over time price ranges red yellow green start to appear.

I think power plants doesnt have this? The nuclear plant appears same time as uranium. Which can be bad if you plonk one down near 1 mine before realizing it needs at least 3 mines to feed it, and up to 6 mines to bring extra revenue. Each mine makes 2 uranium, the plant demands 6.

[RulerofRails]

All the original cargoes from 1.05 appear at the same as the factory. For example Cheese, Furniture, Toys, Diesel, Automobiles, . . . . I listed these because they are consumer cargoes (houses use them). They might even have multiple steps in the process (Autos) and the price of output is determining if a factory is viable or not. For these you need to wait before building a factory.

But in your case of Uranium, the Nuclear Power Plant makes more profit if the Uranium price is lower. So, it's not so much of an issue. You are right that the Nuke Plant needs more than one mine. IIRC it can be break-even with two. But especially if you want to upgrade it, you need a lot of mines.

[Gumboots]

I must admit my only thoughts about power stations are along the lines of "rotten !*@*@ things that are always stealing coal and oil that I need for something useful". Although this doesn't apply to the nukes, since they don't steal coal or oil, but as a steam loco nut I don't end up playing many scenarios that have nukes anyway.

I must also admit that, since my thoughts about power stations aren't generally complimentary I have never got into trying to make a profit out of them. I suppose I should try it sometime, just for the experience, on a map that has heaps of unused coal and oil.

[zzc]

Electric plants are good for places where coal and oil converge, but no iron to make steel, so might as well put the coal to use. I've thought of making a new coal liquefaction plant where 1 coal = 1 oil, right now I just use a warehouse recipe.

[Akarin]

Thanks for bringing the Warehouses replacements patch to light. I had missed that before.

[Gumboots]

Ah yes. I did mention something about adding that to the site archives, but I don't think I ever got around to it. Will take a look.

[sbaros]

for some reason, the salt is shipping in auto racks even though it's 1870

This happens to me very often whenever experimenting with hauled rolling stock of any kind (including express cars). It seems automobile carriers are set as default placeholders whenever somebody messes things up, and I find it to be a very clever debugging feature. Instead of the program crashing completely and mysteriously, it immediately points to the problem by displaying this highly unusual commodity in place of the affected one.

[sbaros]

I've seen Electronics cargo appear before the factory becomes buildable. Pharma factory is buildable before chemicals appear. Any idea how to tinker this?

Actually, the ability to delay an industry's startup from its product start date is a significant advantage. You can simulate a delayed development of the specific industry in the region concerned, while the product is nevertheless available through import.
The opposite though (as it happens with the distributed Pharma factory) is a problem. Useful slots are wasted with an industry that produces nothing yet, and its seeding may ruin a session decisively from the beginning.

[sbaros]

I have written some scattered and inconherent notes here, I'd like to hear more opinions on these subjects.

[Gumboots]

Ok. Off the top of my head, since I can't spend much time on it this morning:

1/ The price differential between stations is meant to represent the railway's net profit. Yes, I know it's the same as the differential on the map sans rail, but that doesn't affect play. It's a useful and workable simplification for a strategy game. Trying to do anything more complex is probably not possible without recoding the .exe.

2/ Same applies to buying existing industries that are not owned by any other company.

3/ The cargo chains in RT3 were basically designed on the basis of a mid-to-late 20th century economy. It's out of date for the early 21st.

4/ The big problem with changing the cargoes and industries is checking for balance in a wide range of scenarios. It requires a lot of testing to make sure you have taken account of emergent effects. It's much easier if you only want to make a change for one scenario.

[sbaros]

Perhaps the simplification can be compensated without recoding the .exe, by a cutback of annual freight revenues to just a pre-determinable fee per load mile carried, thus eliminating any undeserved profits. I'll investigate this when I gain more experience in event-writing.

Ah yes I forgot to mention about the shift from relatively useless medicine to a more useful food cargo.

Not so useless, as documented here.
As about balance, it can always be regulated through the density sliders and the port recipes.

[Gumboots]

Perhaps the simplification can be compensated without recoding the .exe, by a cutback of annual freight revenues to just a pre-determinable fee per load mile carried, thus eliminating any undeserved profits.

You could get a similar effect just by a game-wide reduction in cargo prices, or an increase in company overhead. That would be the simplest way of doing it. Doing it by loads x miles is difficult, because the game doesn't allow those events in the editor. It's something the game tracks for the ledger, but not something it offers as an editor option. This mean you would have to figure out some sort of workaround to approximate loads x miles.

[RulerofRails]

I don't think it's easy to make a believable system via event for $ fee per mile for freight. Closest may be average freight speed in relation to loads hauled. However, the editor doesn't include many of the possible interesting events, for example there is no way to check how many locos have been bought by a player, without which such a figure is going to mean a lot less.

If some whizz cracks the exe one day, so you can patch it, how are you going to decide what is a destination for consumables? The RT3 distribution economy for consumables is based around automatic rehauling. Cities filled with a splattering of houses, each with a low demand but exert a combined force to attract cargoes. However, the spacing means that houses don't actually consume signiicant amounts of cargo from the map. By the time cargo moves to the outer houses there is probably a more pressing "need" elsewhere, so a train will take it to a new city. This is a cycle. Check out the amount of rot in a typical game. The dynamic price gradients are the reason for any "natural" shipment. If the railroad can't/wont do it in a timely manner, somebody else will (ship, horse cart, truck, etc.).

I think you will find that the pricing for the game works best on maps of a particular city spacing. Check what PopTop used on the default maps for an idea of how this looks. Refined pricing settings for a different city spacing aren't going to work so well with the default maps. Be careful with pricing because industries and their achieved production rate and price stability all have a dependence on cargo price.

[sbaros]

Well, the omission of load miles from the event editor is a major disappointment. After all, it is the most important factor for the calculation of performance indices of a transport operation. Without it, it's difficult to establish acceptable evaluation parameters to rate users' performance. Absolute figures are not enough. There can be successful small railroads as well as less successful big ones.
However, average speed x loads sounds like a good idea. It works out in load miles per hour, and since time is a universal denominator, I think it will do the trick. Per individual train data are not important, the main thing is that company-wide figures seem meaningful. I have not studied the available editor's parameters thoroughly, so I wouldn't figure this out myself. When I start dealing with events, I'll run some tests for verification and calibrations. If successful, I offer to suggest RulerofRails to the Workers' PR Committee for the Red October Workshop's "Distinguished Contributor" award !

[sbaros]

as a steam loco nut I don't end up playing many scenarios that have nukes anyway.

Decades ago I had read some rumours that the USA and USSR during the Cold War would have to haul nuclear missiles to their final launch sites by secretly stored steam locos, because Electromagnetic warfare might cripple other forms of traction.

[Gumboots]

Electromagnetic pulses from nuclear weapons are short in duration. If you have nukes going off all over the place, you have bigger problems.

Anyway, the RT3 editor is rather annoying. There are stacks of parameters that the game engine tracks for various purposes, but a lot of them aren't available as event triggers in the editor. And, they filled up the list of available triggers with a lot of useless ones (ie: number of transition track pieces, which nobody ever cares about). I would love to re-code the .exe to get rid of the useless options and provide some better ones, but that would be a major exercise and I don't have the skills for it.

[sbaros]

MachineShop.zip

(318 Bytes) Downloaded 71 times

Someone did make a "debugged" machine shop that had the start date changed to match the start date of oil, which is really the way it should have been coded from the start. There's little point in making it effectively duplicate the tool and die. TBH, a problem with the 1.06 industries is that in general they aren't well integrated into the game. The same largely applies to the 1.06 locos. 1.06 has some good ideas in it, but they would benefit from more balancing.

I was also frustrated with this and made a "debugged" one from scratch, in case anyone wants it.
I am willing to assist in concentrating necessary corrections of distributed stuff and organizing a central hub where users will be informed and decide what versions suit them and for which scenario each. As with the waste commodity problem I reported the day before yesterday, we have enough "buggy" add-ons, which may confuse people until they figure out and solve each problem by themselves.

[Gumboots]

If I knew how 1.0.6 was put together we could add fixes like this to the default installation package. I've never looked into how it's all coded.

[RulerofRails]

The main change in gameplay mechanics in 1.06 was no price islands. In my opinion cargo movement is a fundamental mechanic for the game. It is a background process in a sense, but the effects once realized can't be ignored, IMO. Thankfully price islands can be re-enabled. There are some tradeoffs, an extra exploit possible and some scenarios become a little more difficult. I attempted a readme for that: viewtopic.php?p=46039#p46039

In regards to suggesting that any fix should be applied to seasoned files, I would suggest that it only be done if it can be assured that the result will be better. Any such change should be documented minutely. And put up for others to inspect/test first.

I suppose Blackhawk's building set could be placed in the building section. That is a good quality of life for players.

[sbaros]

The CargoModel ID numbers being (.cty byte 32)+1 is clear, and explains something I knew about but didn't know the reason for. The CargoModels don't use the 00 or 01 identifiers for any cargoes. It makes sense now, because the scale has to start at 01 + 1 = 2. Which is where it does start, with Lumber calling CargoModel02.3dp and going on from there for the other cargoes.

I'm afraid something is incorrect here. It seems to me that the CargoModel (i.e. the visible 3dp representation of the cargo when carried in open-type wagons) is defined somewhere else, not in the .cty file. I'd be interested to carry loads in alternative wagon types, so I made the following experiment: I hex-edited the Logs.cty file to be carried in gondolas instead of flatcars, changing only the car reference to "Open_Hopper" at the appropriate byte address. Indeed, the "Logs" were carried in a gondola, however the displayed load was the usual pile of coal, not the intended RT3 logs. What went wrong?