Cargo & Industry fixes for 1.06

A private forum for those folks working on patches for RRT3.
User avatar
RulerofRails
CEO
Posts: 2063
Joined: Sun Dec 08, 2013 1:26 am

Re: Cargo & Industry fixes for 1.06 Unread post

Nice. This is useful. !*th_up*!

How come we missed editing the Crystals production start date till now. *!*!*!

Actually I think that there isn't that much demand for Machinery. Sure there is a demand at a lot of buildings that take it, but the rate is super low. Machinery is hard to produce, so can only be a worthwhile endeavor if produced in bulk (if you focus on it). The rate is so low that little real consumption takes place, it doesn't rot fast either, so the typical thing is for a mass scale re-hauling around the map -- whether you intentionally take advantage of that or not.

This was where the idea came to add demand at Mines, Logging Camps etc.. And to get some production boost too. I had the concept for this worked out with Blackhawk. Akin to Fertilizer at farms, but a little more tricky thanks to these resources often running in lower demand environments (houses provide map wide background demand and therefore typically decent prices for farms) and Machinery is higher priced than Fertilizer. Our solution was to use two chains: one production and the other for the actual conversion. This lets real consumption take place + giving a boost effect. In super low price environments we could potentially see these resources take a little more loss (production/profit), but it seemed manageable to me.

A conceptual (it's in TM) use for Machinery was as a boost in a conversion industry. An example 3 Logs + 0.2 Machinery = 6 Lumber. However, there is a single value that caps all conversion entries (this is the problem with putting multiple conversions into a warehouse/port). Unless someone works out a super low resource map style that doesn't use much micro, my testing didn't show that this could be helpful on the typical map, and it's definitely not a boost. The "boost" possible (seen at the default farms) is achieved because it combines a Production and a Conversion entry.

On the topic of Machinery try this from a long time ago: http://hawkdawg.com/rrt/rrt3/hp/h-c.htm


PS.
Actually, I'm pretty sure that the express values in the bca files work. One evidence would be that Ned added express demands to a lot of buildings in TM. Production events work for express too (even by territory, proof in some of Oilcan's maps like Canyon Lands, or Zambu Email).
User avatar
Gumboots
CEO
Posts: 4828
Joined: Mon Aug 13, 2012 4:32 am
Location: Australia

Re: Cargo & Industry fixes for 1.06 Unread post

RulerofRails wrote: Wed Dec 19, 2018 9:51 pmNice. This is useful. !*th_up*!
I'm thinking of adding some more to it, so we can see demands over time in a form that makes sense to the eye.
How come we missed editing the Crystals production start date till now. *!*!*!
Dunno. Maybe we're just a bit thick. :lol:
Actually I think that there isn't that much demand for Machinery. Sure there is a demand at a lot of buildings that take it, but the rate is super low. Machinery is hard to produce, so can only be a worthwhile endeavor if produced in bulk (if you focus on it). The rate is so low that little real consumption takes place, it doesn't rot fast either, so the typical thing is for a mass scale re-hauling around the map -- whether you intentionally take advantage of that or not.
Ok, but the rate of demand from each house is pretty low for a lot of cargoes, but the number of houses makes consumption pretty good. Goods is an example. Demanded at only 0.05 loads/year for small houses, and not demanded anywhere except houses, but it's usually a profitable cargo with a pretty stable price.

OTOH, Cheese is a cargo that can tend to crash easily. It's demanded at 0.02 loads/year for small houses, which are usually the most common ones IME. It also has a much faster rot time than Goods, which would tend to increase consumption and stabilise price, so the difference between a 0.02 demand and a 0.05 demand obviously has a dramatic effect on price stability. This sort of thing is worth thinking about when setting demands.
This was where the idea came to add demand at Mines, Logging Camps etc.. And to get some production boost too. I had the concept for this worked out with Blackhawk. Akin to Fertilizer at farms, but a little more tricky thanks to these resources often running in lower demand environments (houses provide map wide background demand and therefore typically decent prices for farms) and Machinery is higher priced than Fertilizer. Our solution was to use two chains: one production and the other for the actual conversion. This lets real consumption take place + giving a boost effect. In super low price environments we could potentially see these resources take a little more loss (production/profit), but it seemed manageable to me.
Yes, I can see that forcing higher priced cargoes into the production chain could adversely affect profits. Having some of them as demands only would allow more flexibility. And you'd want to be careful about which industries got a production boost, and by how much.
PS.
Actually, I'm pretty sure that the express values in the bca files work. One evidence would be that Ned added express demands to a lot of buildings in TM. Production events work for express too (even by territory, proof in some of Oilcan's maps like Canyon Lands, or Zambu Email).
Yes, I know production events work for express. My Latvia map has them. ;-) But the Barracks, for example, has no Troops mentioned in the .bca and the Hotel has no pax mentioned, so obviously some express production is locked into the .exe. This makes sense, because we know express prices are locked into the .exe too, and are not affected by events or by .bca edits.
User avatar
RulerofRails
CEO
Posts: 2063
Joined: Sun Dec 08, 2013 1:26 am

Re: Cargo & Industry fixes for 1.06 Unread post

Um. Passengers, mail, and troops supply/demand have special values in the footer of all buildings.

From Pjay's notes

Code: Select all

102 (-067)	:     4 : float	: passengers : (commercial 0.5, house 1, hotel museum 2, church cinema deptstore 3, stadium 5)
106 (-063)      :     4	: float	: passengers : (commercial 0.5, house 1, hotel museum 2, church cinema deptstore 3, stadium 5)
110 (-059)      :     4	: float	: mail : (commercial 2, house 1)
114 (-055)      :     4	: float	: mail : (commercial 2, house 1)
118 (-051)	:     4	: float	: troops : (barracks 1)
122 (-047)	:     4	: float	: troops : (barracks 1)
I have never done a serious attempt to adjust these but I think the 1st is production and the 2nd demand.


I highlighted the values for the Hotel bca.
Hotel pax values.jpg


Is it funny that we might be surprised when something works as it should?
User avatar
Gumboots
CEO
Posts: 4828
Joined: Mon Aug 13, 2012 4:32 am
Location: Australia

Re: Cargo & Industry fixes for 1.06 Unread post

Ah, I was thinking they'd be in an insane location like, y'know, the production/supply chains section of the file. Silly me. *!*!*!

I wouldn't bother adjusting them for actual gameplay. AFAICT the balance there is one of the things they got right, although I suppose we should test an adjustment just so we can see how (or if) it works.

BTW, I'm thinking at the moment of splitting the Furnace into two industries as a sort of "private alpha 1.07" test thingy. I can then test play any 1.06 maps by editing them to suit. They should still open in 1.06 as long as cargoes stay the same and no industries are removed. IIRC we have 16 industry slots still available, so no problem with creating a few more. It's only removal that could cause instant CTD.

Which is why I'm thinking the cargo chain should be left alone. If we change that to ditch some 1.06 cargoes and substitute others, then I expect that any maps that call the defunct cargoes simply would not open in "1.07", and of course you wouldn't be able to edit them to "1.07" in 1.06 because it would lack the necessary cargoes. Catch 22.

There's also no room to add extra cargoes, so no chance of editing by creating a test installation with several extra ones (some of which would be redundant during play). Unless I'm missing something, you would have to directly edit the .gmp hex to update to "1.07", and that is a rather daunting prospect.

Edit: Come to think of it, we can always implement cargo changes by simply renaming things in RT3.lng and changing a couple of icons, but I'd prefer to avoid that since it means building in inconsistencies on the back end.

Edit again (brain farts rule): I suppose there would be a workaround, in that you could open a 1.06 map in 1.06, then edit out any of the changed cargoes, then save the thing before opening it in "1.07", and then editing the required cargoes back in. Sounds pretty tedious, and I'm not sure I'd be up for it.
User avatar
Gumboots
CEO
Posts: 4828
Joined: Mon Aug 13, 2012 4:32 am
Location: Australia

Re: Cargo & Industry fixes for 1.06 Unread post

Ok, updated the sheet with the correct express cargo supply and demand. !*th_up*!
Attachments
106_Industry_Chain_update.zip
(22.74 KiB) Downloaded 174 times
User avatar
Gumboots
CEO
Posts: 4828
Joined: Mon Aug 13, 2012 4:32 am
Location: Australia

Re: Cargo & Industry fixes for 1.06 Unread post

Hey question, for anyone who knows for sure.

In terms of industries and cargoes, what determines if a map will load without CTD?

I know 1.05 maps load in 1.06, since they don't have any conflicts with missing stuff (it's just missing). OTOH, changing an enabled industry will definitely make a map CTD.

What about industries that aren't enabled? Are they ignored, or not? For example, if you disable all 1.06 industries and cargoes, would a 1.06 map then load in a "1.07"?

I'm basically wondering how much we can change before existing 1.06 maps become impossible to work with, and what process would have to be gone through to update them to work with any new patch. If it involves hunting through .gmp hex then I think it's effectively a no-go.
User avatar
RulerofRails
CEO
Posts: 2063
Joined: Sun Dec 08, 2013 1:26 am

Re: Cargo & Industry fixes for 1.06 Unread post

For some basic concept testing: edits in the RT3.lng would probably be useful. You can also test any single input conversion chain in a warehouse, although remember that the running costs per unit produced for warehouses are a little lower than for real industries (based on the build cost and warehouses are cheap).

Where are you thinking to go with this? Are you thinking about polishing up the 1.06 cargoes with balancing measures and smaller adjustments, or go full-scale with new/re-purposed cargoes etc.?

In terms of what will load, I don't know for sure. But I will speculate anyway. zzwhip I just tried to take a 1.06 map: Africa & the Middle East, change the prefix, then load it in 1.05. It loaded fine. Even without disabling any buildings etc.. A port recipe set to demand Crystals before now demands Alcohol (first cargo in the list). So maybe there is some forgiveness in the system?

I know that a manually placed building can cause a missing file CTD if the game doesn't find files for it. That will definitely cause a crash.
User avatar
Gumboots
CEO
Posts: 4828
Joined: Mon Aug 13, 2012 4:32 am
Location: Australia

Re: Cargo & Industry fixes for 1.06 Unread post

RulerofRails wrote: Fri Dec 21, 2018 7:56 pmWhere are you thinking to go with this?
Round in circles, followed by disappearing up my own butt. It is, after all, RT3. :lol:
Are you thinking about polishing up the 1.06 cargoes with balancing measures and smaller adjustments, or go full-scale with new/re-purposed cargoes etc.?
I think there's general agreement that we don't much like 1.06 as it stands. The cargoes and industries weren't thought through properly. OTOH, I think that's its big selling point is the extra event logic that 1.06 has available. That's really good stuff, and is really the only thing I want 1.06 for. But there are some extras, like custom newspapers and in-game-buildable docks, which potentially add interest. Locos are slowly getting fixed, so are slowly becoming more usable. So the basics are there for something good, especially if we base things on an .exe which has had track counts and price islands and whatever else fixed.

The big issue is cargoes. We're tightly limited on those (IMO industries have adequate scope) and they have to cover a timeframe from 1830 to at least 2030, and everyone wants to argue endlessly about which ones we should have. That makes me think we should only fix stuff that is definitely screwed.

The less we change, the easier things will be. Balancing measures are fine. They shouldn't break anything, so we can implement as many of those as we like, but I'm inclined to keep cargo changes minimal. Every time we create something new, we're also creating a new testing cycle. So I think the best way to approach it is to start by listing "Stuff that is definitely screwed", and then ruthlessly go for the easiest and sanest solution to make it not screwed.

Taking the obvious one, I'd say we go ahead and split the Furnace into two industries. I'd be fine with an ore smelter being called "Furnace" for game purposes. A smelter is a furnace anyway, so there's no real need to bork anything by changing the name. If you want to use a 1.06 map, just tick off an extra industry (Cement Works, or whatever it turns out to be). Should be easy and trouble-free. Result should be two reliable production chains, which is what is wanted.
In terms of what will load, I don't know for sure. But I will speculate anyway. zzwhip I just tried to take a 1.06 map: Africa & the Middle East, change the prefix, then load it in 1.05. It loaded fine. Even without disabling any buildings etc.. A port recipe set to demand Crystals before now demands Alcohol (first cargo in the list). So maybe there is some forgiveness in the system?

I know that a manually placed building can cause a missing file CTD if the game doesn't find files for it. That will definitely cause a crash.
Cool. That's handy info to start with. !*th_up*! So perhaps the only "updating" issue is placed buildings. That would be an easy thing to update for. Although if ports are wanting Alcohol instead of Crystals you have to wonder what happens at the other end of the list. *!*!*!

Edit; Oh hang on a minute. If industries are being selected by the .gmp on the basis of their position in the list, that is going to overturn half the map if a couple more are added in odd spots. You'd still be able to correct it in the editor if you knew what to expect, but it'd be a fair bit more tedious.

I vaguely remember some discussion between Ned and Stoker about the industry. IIRC they had different opinions on how it works.

Found it: viewtopic.php?f=24&t=3641&p=36398#p36398

This makes me think that if we need to add an extra industry (like a Cement Works) then it may be best to deliberately give it a prefix that shunts it to the end of the industry list. That way it wouldn't upset the existing order, so updating existing maps should be far less trouble. A cement works could be classified as x_Cement_Works, or something like that.

Your PM the other week about RT3.lng edits to change loco names mentioned that it doesn't affect the event availability list but changes the name elsewhere. If the same applies to cargoes and industries, it may be possible to use a prefixed industry name in the editor list but have it show "normally" during gameplay.
User avatar
Gumboots
CEO
Posts: 4828
Joined: Mon Aug 13, 2012 4:32 am
Location: Australia

Re: Cargo & Industry fixes for 1.06 Unread post

Hey here's an idea (just to really screw things up). We have the extra 30 potential cargoes hidden inside 1.06:

Code: Select all

~4459Beer
~4464Candidates
~4466China
~4468Containers
~4471Detergents
~4472Deuterium
~4477Energy
~4478Fish
~4479Food
~4481Glass
~4482Gravel
~4495Money
~4497Newspaper
~4507Paint
~4508Perfume
~4509Potash
~4510Pottery
~4511Prisoners
~4515Salt
~4516Sand
~4518Spaceships
~4520Syrup
~4523Tea
~4525Tin
~4529Tobacco
~4530Tools
~4538Valuables
~4541Wine
~4542Wire
Now if I understand things correctly, the game won't handle having more than 52 cargoes enabled in any scenario. Personally I think this is enough, because once it gets over 45 cargoes in use the cargo display gets annoyingly cluttered anyway. Things start overlapping and going out of position, and it all becomes a bit of a mess. I prefer to not even use all of 1.06's 51 cargoes at the same time, and think that if you can't design a scenario with 40 to 45 cargoes as a maximum then you should probably rethink things.

Still, the game engine handles having 51 or (maybe) 52 cargoes enabled. So, what does "enabled" actually mean? Does it mean "ticked on in the industry list, and assigned to one or more cities/regions"? Or does it mean "has a .cty sitting in CargoTypes and is called by one or more buildings in BuildingTypes"?

If it's the former, then we could have the whole lot set up with .cty and .bca files if we wanted to, providing nobody ever tried to use them all at once (and you can bet some kid will try it). The only catch would be that any .bca that referenced a cargo would be calling if that building was enabled anywhere, so you'd have to give some thought to production chains so that enough stuff could really be disabled.

So, how does it work? If you have (hypothetically) 80 cargo .cty files alive and kicking in CargoTypes, and 80 cargoes called by various buildings in BuildingTypes, would you still be able to construct a viable working scenario by only selectively enabling the relevant industries in whatever cities and regions (keeping the total under 52), or would that all turn to crap?

Edit: Have just been doing a lot of reading up. First thing is it looks like there is a hard-coded limit of 60 cargoes:
Currently, GMP files store event condition types using a four-byte integer. "YTD company <cargo> hauled" conditions, for example, occupy the codes from 000000FDh through 00000139h. This allocation scheme is what limits the game to 60 different cargoes, of which 41 are currently defined.
Presumably, if you had 80 .cty files sitting around in CargoTypes, the last 20 of them would simply drop off the end of the list and you'd never see them in the editor. Which is handy to know before getting carried away. *!*!*!

It's also rather handy in that it ties in well with the CargoIcons_*.dds that does the icons on the sides of cargo cars. Back in that same thread I see that, at the time, people didn't know how these were assigned. That explains why 1.06 cargoes never called them properly, but I figured it out when I made my bugfix patch for them.

Anyway, CargoIcons_*.dds has 64 slots available on it, and we can easily use them all if we really want to. 52 of them are taken up by 1.06, but that includes four slots that are taken by Mail, Passengers, Any Express and Troops. These cargoes don't actually use cargo icons in the game, because the cars are so distinctive anyway so don't need icons, but with those four icons there on the .dds there are 60 slots vacant. This just happens to tie in nicely with the 60 available slots for cargoes in the .gmp coding, so that's all good to go.

What appears to define the 52 cargo limit in practice is this:
Something to watch out for: cargo limit may be lower than the 60 that the event system suggested. The structure representing the economic record for each square of the map is 471 bytes long; there's an array of floating-point numbers representing cargo quantities available 259 bytes into it. If each floating-point entry is 4 bytes, you can see there might be a bit of trouble past the 52nd cargo or so.
So there's the real limit: the game won't allow space for more than 52 cargoes when tallying up activity on any economic cell. That's a hard limit that you can't get around. However, it implies (would need to test) that it would be possible to have up to 60 cargoes defined in CargoTypes, providing that no more than 52 of them were enabled at any one time. IOW, at least 8 of them would need to be unchecked in the industry list, and not assigned to any regions or cities(ie: slider percentage set to zero everywhere).
User avatar
RulerofRails
CEO
Posts: 2063
Joined: Sun Dec 08, 2013 1:26 am

Re: Cargo & Industry fixes for 1.06 Unread post

**!!!** Try and see. Here's some info on the "52 limit": viewtopic.php?p=2256#p2256.

I don't know how a cargo is "enabled" behind the scenes, but If you didn't notice in the Western Geatland thread I recently mentioned finding Milo's info on what makes a cargo available in an actual game, in the context of placed vs. seeded ports/warehouses, but there is probably all the info you need there: viewtopic.php?p=3210#p3210

The majority case is that a cargo is made available when whatever industry produces it is enabled in the list.

When I said the Port was demanding Alcohol when it used to demand Crystals, all that was happening is that the 1.05 game defaulted to Alcohol (the 1st item) when it couldn't find Crystals. I wouldn't assume this is indication of a numbering problem.

PS. Don't really understand it, but I found a quote about the flatbed cars here by Milo. Not sure if it's anything?
The mystery byte at offset 20h is a 'visual appearance' modifier to the car. 1-8 apply to Flatbed cars, while 9-11 are Open_Hopper cars. This is how the Weapons flatbed shows up, for example. The default for cargos without a 'visual appearance' modifier is just to paint the resource icon on the outside of the railcar.
User avatar
Gumboots
CEO
Posts: 4828
Joined: Mon Aug 13, 2012 4:32 am
Location: Australia

Re: Cargo & Industry fixes for 1.06 Unread post

I linked to your first link myself. :mrgreen: The second one is a handy reminder though. !*th_up*! I've seen it before, but had forgotten about it.

It sounds very promising. If scenario authors are sensible about selections (and understand the selection rules) and if some industries are designed so that some cargoes actually can be disabled while still having a viable scenario, then it should be possible to have the full 60 cargo slots set up in the editor.

I'll set something up and give it a good test run. I'm kinda in the mood for testing a few weird things at the moment.
PS. Don't really understand it, but I found a quote about the flatbed cars here by Milo. Not sure if it's anything?
Brilliant! Yes, that makes perfect sense. Got it in one. (0!!0)

The byte he's referring to is #32 in the cargo's .cty file. I just checked, and that has a value of 00 for Alcohol, which comes in boxcars with an icon on the side. It has a value of 04 for Steel, which comes on a flatcar, and a value of 0A (10 in decimal) for Iron, which comes in an open hopper.

This is muchly splendiferously awesomesauce. It should mean that by changing the values for Goods and Rubber to 00, I should be able to get those cargoes (or any other cargoes) showing their correct cargo icons when they are in my custom boxcars. I'll definitely test this, as I can see it being very handy. (Just tested, and it works.)

Edit: Although I still have my doubts if that will affect how things display inside CarSideView_1, because that may rely on some other extra trickery. It suspect that will always be locked to the four default eras and four default icons on that image. Still, it will be useful for flatcar cargoes that I want in boxcars.

Anyway, checked out the .cty file thing. It works like this:

00 at .cty byte 32 means normal cargo icon on side of car.
---------------------------------------------------------------------
01 to 08 inclusive define various default flatcar cargoes.
---------------------------------------------------------------------
01 is Lumber (but CargoModel ID for Lumber is 02).
02 is Weapons (but CargoModel ID for Weapons is 03).
03 is Goods (but CargoModel ID for Goods is 04).
04 is Steel (but CargoModel ID for Steel is 05).
05 is Rubber (but CargoModel ID for Rubber is 06).
06 is Aluminum (but CargoModel ID for Aluminum is 07).
07 is Uranium (but CargoModel ID for Uranium is 08).
08 is Logs (but CargoModel ID for Logs is 09).
---------------------------------------------------------------------
09 to 0B inclusive define various default open hopper cargoes.
---------------------------------------------------------------------
09 is Coal (CargoModel ID is 0A, or 10 in decimal).
0A is Iron (CargoModel ID is 0B, or 11 in decimal).
0B is Bauxite (CargoModel ID is 0C, or 12 in decimal).

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.

This is interesting, because it opens up the possibility of calling some of the default CargoModel slots for non-standard cargoes. WP&P's old pulpwood car already does this, by hijacking the default Goods cargo model and profile icon.

I just checked a copy of his car that I had lying around. It uses the default Goods value of 03 in the .cty file, so it appears that somehow WP&P figured this out. That .cty byte 32 obviously allows Pulpwood to call the default Goods icon in CarSideView and the default Goods CargoModel04.3dp, both of which WP&P then edited to turn them into Pulpwood loads. (0!!0)

Unlike most of his custom cars, his Pulpwood flats only have four eras. This implies that he couldn't get the profile icons working with custom eras while using CarSideView_1.imb as the source. He didn't mess with any other flatcar cargoes, so I think he ran into trouble there and then moved on to other things. But with what we know now, obviously there is more scope for custom shenanigans. You just have to define your own icons with another .imb file.
User avatar
RulerofRails
CEO
Posts: 2063
Joined: Sun Dec 08, 2013 1:26 am

Re: Cargo & Industry fixes for 1.06 Unread post

Sorry about the double-up. Milo left a lot of top quality info laying around. Here's something else, viewtopic.php?p=3283#p3283:
milo wrote:The Bad: We won't be able to skin express cargos. Passengers, mail, and troops all use custom RT3.lng messages and custom cargo code rather than reading most data from the cargo object. That probably kills the most obvious ways to use the Prisoners, Newspapers, Money, and Valuables skins.
Which we discovered the hard way when trying to change passenger price etc..
User avatar
Gumboots
CEO
Posts: 4828
Joined: Mon Aug 13, 2012 4:32 am
Location: Australia

Re: Cargo & Industry fixes for 1.06 Unread post

That shouldn't affect renaming via RT3.lng (those names have to be translatable anyway, so are covered). It should only affect things like rot time and price. Not that I can see any real use for Prisoners and Money anyway.
User avatar
Gumboots
CEO
Posts: 4828
Joined: Mon Aug 13, 2012 4:32 am
Location: Australia

Re: Cargo & Industry fixes for 1.06 Unread post

Hey I'm just looking through this infamous list of hidden cargoes, wondering which ones might be useful enough to test. Some of them seem near enough to useless:

Code: Select all

~4459Beer
~4464Candidates
~4468Containers
~4477Energy
~4479Food
~4482Gravel
~4495Money
~4508Perfume
~4510Pottery
~4511Prisoners
~4518Spaceships
~4523Tea
~4542Wire
~4541Wine
Just thinking about how you'd potentially use them as default cargoes:

Houses already have all their visible demands full. There's no room for more cargoes going to houses. To make room for an extra cargo to houses, an existing one would have to be removed. This pretty much makes different types of alcohol pointless. Even if you did split it up into Beer, Spirits and Wine, you'd need a map full of terminal alcoholics to make them all viable cargoes. Given that the default Alcohol works well as a cargo, it's probably best to avoid ~4459Beer and ~4541Wine.

Candidates seems pointless. Ditto Containers (they need a cargo inside them). Ditto Energy (let's see you pack that into a boxcar). Ditto Food (the game already has several defined types of food, which are known to work). Gravel is just little rocks, and 1.06 already has Rock. Money seems a bit too specialised for general use. I can't see anyone wanting boxcars full of Chanel No. 5, so scratch Perfume too. Pottery is just Ceramics, which 1.06 has. Prisoners seem too specialised (could rename Troops via RT3.lng for a specific scenario). Spaceships is a bit of a joke given current technology. Coffee could be renamed Tea for a a specific scenario (don't think we need both). Wire seems too specialised.

So if you get rid of that lot you're left with:

Code: Select all

~4466China
~4471Detergents
~4472Deuterium
~4478Fish
~4481Glass
~4497Newspaper
~4507Paint
~4509Potash
~4515Salt
~4516Sand
~4520Syrup
~4525Tin
~4529Tobacco
~4530Tools
~4538Valuables
I can see some of these having potential. China is basically Ceramics, but there seems to be a consensus that 1.06 Ceramics is actually Portland cement. So if that gets renamed via RT3.lng then a stand in for actual Ceramics could be useful. Detergents I'm not sure about, but we do use a lot of them commercially and domestically (would also stand in for soap, etc). If you wanted to get really technical you could call them Surfactants, which covers soaps and detergents, but whatever.

Deuterium is an interesting one. Obviously someone was thinking of fusion reactors, which are still sci-fi, or possibly thermonuclear weapons, which have a very restricted market, but it turns out that deuterium has a surprising range of commercial uses. As a low-volume, high-priced cargo for late eras, it could be worth considering. Incidentally, lithium is another obvious cargo for the 21st century (it's going to be big) but it's not on the list anywhere (because back when the list was made people didn't realise how important it's going to be).

I can see some people wanting Fish sometimes. It is a pretty distinct food type with a distinct production process, and a big part of markets in some locations. Ports are one obvious source of supply. Glass is an obvious commercial product with a wide range of applications. Newspaper is a possibility, but is declining these days. Still, it could work for the late 19th century and the 20th century (Australian railways used to have dedicated newspaper vans).

Paint is obviously used a lot, so make sense if there's room for it and a viable production chain. Potash is ideal for fertiliser production and a range of other uses. Salt has a wide range of industrial uses too (domestic use is comparatively minor). Sand is what people think we should have instead of 1.06's Crystals, so why not have it? Crystals are hardly used at all anyway. Syrup I'm not sure about (yes, I know what it covers).

Tin is widely used, and an interesting case. The US produces heaps of it, but only via recycling. The world is actually running out of mineable tin. Tobacco I could take or leave. Horrible stuff, but I realise it has quite a commercial history. Tools could be useful if there is space for them. People seem to like the idea of Valuables too.

So that's 15 cargoes (16 if you shoehorn lithium in too) that I think you could make a reasonable argument for. Only problem is that there is a maximum of 9 slots available, so 15 is 6 too many, and 16 is 7 too many. *!*!*! TBH lithium probably makes more sense than deuterium if you have to chose between the two. In terms of shippable volume this century it will leave deuterium for dead.

Which leads to a thought: where are all these critters hidden? If ~4495Money is largely useless as an in-game cargo, it would presumably be possible to rename it (somewhere) to ~4495Lithium. I know you can do it in RT3.lng, but I assume there's some weirdness hidden in the .exe as well.
User avatar
RulerofRails
CEO
Posts: 2063
Joined: Sun Dec 08, 2013 1:26 am

Re: Cargo & Industry fixes for 1.06 Unread post

You may be getting a little ahead of yourself before doing some proof of concept. ;-) It would be nice if it works, but this is RT3 . . . . . !*00*!

RT3 economy is after all an automated system that's pretty lossy. The lack of don't-haul-this-type on custom consists is a blow to tight cargo management as seen in TM.

Low volume chains aren't going to add that much to the typical game. Even if it makes sense to concentrate enough resources in one area to make a production facility worthwhile, if the product is not demanded at houses there needs to be serious consideration of how to build sufficient demand map wide.
User avatar
Gumboots
CEO
Posts: 4828
Joined: Mon Aug 13, 2012 4:32 am
Location: Australia

Re: Cargo & Industry fixes for 1.06 Unread post

I suppose the easiest way to test the concept is to just grab them cargoes and make "mines" that just produce the relevant cargo, with the relevant files copied from a basic coal mine. To just test the limits of the cargo list, it shouldn't be necessary to have an actual use for the generated cargoes.

And sure, how to use the things does require thought, and in terms of production, consumption and pricing should be based on established cargoes that are known to work well.

I suppose there is scope for having some house demands not being visible, as long as they still work.
User avatar
Gumboots
CEO
Posts: 4828
Joined: Mon Aug 13, 2012 4:32 am
Location: Australia

Re: Cargo & Industry fixes for 1.06 Unread post

Having slept on it (literally) I have a better idea. AoS V has every 1.06 cargo enabled, so is a good test case in that respect. It already uses 6 of the port/warehouse slots, but obviously that means there are another 6 slots not being used. Each port/warehouse can supply or demand up to 5 cargoes, so that's plenty of scope for testing.

10 cargoes on top of the existing ones is enough to push things past the 60 cargo limit. All it needs is four more ports/warehouses set up, two of which supply five cargoes each and two of which demand five cargoes each. This should allow testing them all to check they are actually accessible on the editor cargo listings, with minimum custom files required (should be ten .cty files only). They should all be haulable too (although not all at once, obviously). Actual cargo prices shouldn't be relevant, since the warehouse demand should take care of haulage if all ten cargoes share the same price.

To keep the rest of the cargo chain functioning for as long as we feel like running it, it makes sense to only add .cty files for cargoes which will be listed after the 1.06 ~4513Rock. All the 1.06 cargoes are displayed at the end of the cargo listings in the editor, so I assume if there are too many cargoes enabled the last one will simply drop off the end of the list, and won't be usable, while everything else should function normally.

Fortunately there are eleven cargoes in the "hidden" list that come after Rock:

~4515Salt
~4516Sand
~4518Spaceships
~4520Syrup
~4523Tea
~4525Tin
~4529Tobacco
~4530Tools
~4538Valuables
~4541Wine
~4542Wire

That's easily enough for proof of concept. I'll start setting it up. !*th_up*!

Also had some thought about the "cargoes not demanded by houses" thing. If we leave 1.06 out of it and just consider the 1.05 cargo chain (which is a better setup in general): out of the 41 cargoes available over all eras, these ones are not demanded by houses:

Aluminum
Ammunition
Bauxite
Chemicals
Cotton
Fertilizer
Iron
Livestock
Logs
Plastic
Pulpwood
Rubber
Steel
Tires
Troops
Uranium
Waste
Weapons
Wool

On most maps these cargoes don't lack for demand. On a lot of maps, some of them are notorious for lack of supply. Still, most of them have products that are demanded by houses, even though the cargo itself isn't. So, nailing it down to the ones that never have anything to do with houses we have:

Ammunition
Troops
Uranium
Weapons

I suppose Uranium is a dubious case, since it is demanded by Nuclear Power Plants and I assume the demand for electricity is influenced by the number of houses and industries on the map. So Uranium demand could be very indirectly influenced by houses if you were considering building your own nukes, but not if it was the result of seeded ones.

Troops is a dodgey one, being an express cargo, so for the really strict cases we're down to Ammunition and Weapons. And yup, those two do exhibit somewhat dodgey behaviour if the map is not set up carefully. Production is often tricky or pointless, and prices at demand locations tend to swing rather wildly. IME the Munitions and Weapons factories only really work when you have a range of Barracks in locations that are not too distant, and adequate raw materials at reasonable prices, and little or no competition. So that's definitely something to bear in mind when considering cargo chains.



The other thing that I noticed while checking things out is that the old PopTop California scenario, and my California Uber Alles revamp, only have 34 cargoes enabled in 2050. It's been a while since I played them, but I can't remember ever wishing there were more cargoes. Ditto for the Latvia map. As far as I can tell, by the time you have 30 cargoes running you should have plenty to do.

And there are plenty of early scenarios which have fewer cargoes but still keep everyone busy and entertained. The Guatemala map (which we had a lot of fun with recently) only has 18 cargoes running. It could maybe have benefited from a couple more, but I don't remember hanging out for any. How the scenario is scripted appears to be far more important than the number of cargoes it has.
User avatar
RulerofRails
CEO
Posts: 2063
Joined: Sun Dec 08, 2013 1:26 am

Re: Cargo & Industry fixes for 1.06 Unread post

I don't know really what I am doing . . . . I managed to add Beer but when I tried Containers I got an immediate CTD whenever I try to load/start a map in any form. I tried loading those which shouldn't use all 52 cargoes in the .gmp including 1.05 maps. Maybe I did something wrong, idk.
User avatar
Gumboots
CEO
Posts: 4828
Joined: Mon Aug 13, 2012 4:32 am
Location: Australia

Re: Cargo & Industry fixes for 1.06 Unread post

Weird. I haven't tried it yet. Were you trying to add Containers on top of Beer (ie: 53 cargoes total) or instead of Beer (ie: 52 cargoes total)?
User avatar
RulerofRails
CEO
Posts: 2063
Joined: Sun Dec 08, 2013 1:26 am

Re: Cargo & Industry fixes for 1.06 Unread post

I was adding cargo #53, in addition to Beer. I tried Candidates first, then in a fresh attempt Containers. Maybe this isn't what you were thinking of. It could probably work to manually move cargoes in and out of the folder to keep the total below 52, but if that's necessary may as well do a completely modular approach: a separate set of files on a per scenario basis.
Post Reply