Altered prices bug

[undertoad]

Hi all!

I'm currently enjoying playing the built-in (possibly Coast-to-Coast) scenario "New Beginnings". This is the one in which you start off in Europe just before the fall of the Berlin Wall. Lots to do: a whole pan-European high-speed network to build, including a Channel Tunnel (actually bridge ).

The only thing spoiling my fun is that RRT3 prices bug, which I came across a few years ago playing in Britain (Flying Scotsman campaign). There, a famine event raised (or lowered, I can't remember) Livestock prices by a percentage. As soon as that happened, horrible, nonsensical blotches of high price would start appearing on the price map, and growing like a sinister skin disease.

And here it's happening again, this time with Steel, which has a permant +30% price modifier applied right at the start of the scenario:

There's no reason whatsoever that people in Schwerin should start paying a lot for Steel: there's no industry or other demand there. But this happens at least once or twice a year in this scenario - deep green blobs of Steel demand appear randomly, in the middle of nowhere. On a couple of occasions I deduced (from the eventual wider spread of the price gradient) that the "demand" was centered somewhere in the middle of the North Sea!

Because that's the trouble: these price-spikes spread, as if an industry with a very wide "reach" for its input good (can't remember the technical term: it's what e.g. Steel Mills or Auto Plants can do, in terms of "calling for" an input good far across the map by creating a far-reaching rise in price) had appeared. On that picture you can see that the "stacks" of Steel on industry in Hamburg, Berlin and Szczecin are still intact: but once the enormous, fake demand spreads out across the map, these stacks don't have a chance. Even a Tool & Die built right up against a Steel Mill can't grab any Steel, it's pouring so fast down the demand gradient towards... nothing - the Steel just disappears somewhere near the middle of the demand.

You can see this happening in the next picture: Berlin, Hamburg and Szczecin are OK, and the infection hasn't reached Saarbrucken, but my Auto Plant in Düsseldorf (in the green zone, just south of the meeting of two rivers) sits there doing nothing: any Steel I ship to it immediately disappears down the Rhine to Holland, where it just gets dumped in the sea or something. And what's happening in Bavaria and the UK, only God knows:

Once that price-spike has just started to settle down, here comes another one! This time centred on some one-cheese town in the French countryside:

Once it hit Saarbrucken (a Steel Mill and three green demand arrows), the industry there was kaput for the next few years. It didn't make a difference when I stopped my trains taking the Steel away: the Tycoonatrons got so excited by the demand that they shipped it away themselves at enormous speed. Eventually I started scheduling trains to interrupt the "natural" flow of Steel and ship it back to Saarbrucken (at a loss), but even so my industries there only managed to grab 1.0 loads or so per year before it flowed away again.

This is the problem with these price spikes: somehow they're so powerful that they completely wreck the game mechanic that establishes a "stack" of goods where there's a demand. It's a bit like the initial situation when you build an industry, before it's had time to wave its hand, go to parties and network and tell everyone that Steel Is Demanded Here - but it's permanent. And just being on the same map as the price-spike makes the local price of Steel so high that your industries naturally don't bother operating, because they could only sell whatever they produce (e.g. Goods or Autos) for less than their input costs!

The only solution, I've found, is to cheat. I put in a one-off Event lowering the price of Steel by 30% (reversing the scenario's +30% modifier), and now things are starting to settle down.

It's a pity, because price modifiers must be a useful way to adjust a scenario. In this one, for example, the higher Steel price was probably designed to make producing Goods and Autos harder (but conversely making Steel Mills very profitable). That in itself would be a game challenge - but the bugs it causes are a game turn-off. Another one to add to the list of infuriating bugs that don't quite manage to ruin a great game!

[Gumboots]

Well you could always just not worry about running steel-consuming industries, and just exploit the price breakouts. That can be fun sometimes. Otherwise, removing the offending event is the sensible option.

Come to think of it, given the number of utterly useless options in the editor, it would be a nifty mod to get rid of the ones nobody ever wants to use (at least half of them, AFAICT). Pity we can't actually replace them with useful ones.

[Gumboots]

Just thought of something. What effects do price reductions have? Any weirdness there? Or does it just behave like it should?

What I'm thinking is that if price reductions behave properly, you could get the same intended effect just by reducing prices on some other things (iron, coal, goods, cars etc) and leaving the steel price alone.

[undertoad]

Well you could always just not worry about running steel-consuming industries, and just exploit the price breakouts. That can be fun sometimes.

That's exactly what the AI trains do - if I let their greasy little wheels onto my nice clean network. But this kind of arbitrage and inefficient waste offends my technocratic sensibilities. Playing RRT3, for me, I realise more and more, is not about being a tycoon, a simple creature of money and power. No, I want to control everything, like Joh Federsen in Fritz Lang's Metropolis

- but only for the good of everyone, of course. I am in control of everything because someone rational should be in control .

(Funnily enough, I was just thinking of running a high-speed line right through the mountains from Stuttgart to Augsburg. IRL, DB is planning exactly this, which would be a fantastic engineering achievement: but the citizens of Stuttgart don't seem too happy about some of the consequences. Metropolis is still a great film ).

Just thought of something. What effects do price reductions have? Any weirdness there? Or does it just behave like it should?

What I'm thinking is that if price reductions behave properly, you could get the same intended effect just by reducing prices on some other things (iron, coal, goods, cars etc) and leaving the steel price alone.

Interesting idea. I haven't tested it deliberately, but this scenario (which I've been playing for a while now) has a -30% Livestock price reduction built in from the start, along with the +30% Steel price adjustment. And I haven't noticed any weirdness at all in the Livestock/Meat price structure, apart from a tendency for new MeatPacking Plants to pop up much more often, sometimes cutting off my own Livestock supply lines (as recommended in Oilcan's excellent guide - but I thought this was a trick we humans could play on the AIs, not the other way round!).

More Meatpacking Plants makes perfect sense as an effect of lower Livestock prices, though: it's just a challenge within the game parameters, unlike these weird bugs that the Steel price-rise causes. So this suggests that RRT3 deals with price-reducing modifiers well, but deals with price-increasing ones very badly, with these random price-spikes. Good info for scenario-writers (I haven't joined this group yet, though I'm often tempted to start and probably eventually will ).

[Gumboots]

Handy to know. So the most effective way of getting a price rise on one cargo, assuming you don't want random price spiking, is going to be to drop the prices on all other cargoes.

You could even get different "price rises" on different cargoes by changing the percentage of price reduction from one cargo to another. So drop all other cargo prices 30% to get a 30% "price rise" on steel, but if you also want a 15% "price rise" on logs you'd just drop that 15% instead of dropping it 30%.

Once that price-spike has just started to settle down, here comes another one! This time centred on some one-cheese town in the French countryside:

Maybe the village decided to build a 500 foot tall steel statue of Napoleon's genitals, just as a tourist attraction.

[RulerofRails]

I agree with the topic of this thread. I have encountered this bug many times.

Using a price reduction event: good idea. However, there are side-effects because affected industries will become significantly less profitable, may run at lower production, and be much more likely to disappear (if unowned).

I asked Orange46 in the NA Rail Sim thread, if he has seen any side-effects to price reductions. If that turns out to be negative, perhaps we could try increasing all the prices in the .cgo files, then use reduction events to bring them back to normal. Then by reducing said "reduction", we will get higher prices without these ugly price outbreaks. A downside is that we would need to use a standardized reduction event for all existing scenarios without price modifications to play correctly.

[Gumboots]

I agree with the topic of this thread. I have encountered this bug many times.

Using a price reduction event: good idea. However, there are side-effects because affected industries will become significantly less profitable, may run at lower production, and be much more likely to disappear (if unowned).

AFAICT it would have most effect on profitability of the primary producers (mines, farms, logging camps, etc). Factories should be less affected, since their raw materials costs will go down in proportion to finished article prices.

It may be possible to work around this by using events to reduce industry overheads by the same proportion. Does the editor allow adjustments to industry running costs?

I asked Orange46 in the NA Rail Sim thread, if he has seen any side-effects to price reductions. If that turns out to be negative, perhaps we could try increasing all the prices in the .cgo files, then use reduction events to bring them back to normal. Then by reducing said "reduction", we will get higher prices without these ugly price outbreaks. A downside is that we would need to use a standardized reduction event for all existing scenarios without price modifications to play correctly.

That could work too, apart from express cargoes (which have their prices locked into the .exe). All of these options are certainly worth a bit of exploration.

To get around the problem of incompatibility with the majority of (unadjusted) scenarios, the easiest way out is probably to just have scenario-specific packs of .cty files to set whatever base price is desired. Admittedly this is another level of complexity to keep track of, but copying over an extra folder for another RT3 installation isn't hard. Overwriting a bunch of files in CargoTypes is an easy process too.

[undertoad]

Maybe the village decided to build a 500 foot tall steel statue of Napoleon's genitals, just as a tourist attraction.

Interesting ideas on how to get round this bug.

I agree with the topic of this thread. I have encountered this bug many times.

Using a price reduction event: good idea. However, there are side-effects because affected industries will become significantly less profitable, may run at lower production, and be much more likely to disappear (if unowned).

AFAICT it would have most effect on profitability of the primary producers (mines, farms, logging camps, etc). Factories should be less affected, since their raw materials costs will go down in proportion to finished article prices.

It may be possible to work around this by using events to reduce industry overheads by the same proportion. Does the editor allow adjustments to industry running costs?

I like the ingenious idea of "faking" a price increase by reducing all the other prices: but I can see it would have bad effects on the primary producers, who don't have any input costs that can be adjusted downwards accordingly. I guess the effect would be that farms/mines would either fail to appear (if the random "generate industry" algorithm is sensitive to profitability), or appear and then soon disappear if you don't buy them. (On that question, I think the "generate industry" algorithm does take profitability into account: if I build, buy or develop e.g. a high-demanding Textile Mill, Sheep farms will tend to appear around it, rather than anywhere else, as long as they're "switched on" for that region at all: but this is just a hunch).

Just took a quick look in the Editor, and unfortunately there's no "Industry Overheads" adjustment possible.

I wish there was a Demand adjustment available, rather than a Price adjustment. RRT3 only seems to implement demand curves in one causal direction: high demand (e.g. a Lumber Mill demanding Logs) makes the local price rise, and conversely low demand makes the local price fall. There's no effect in the opposite direction, with price affecting demand (e.g. lower Alcohol price makes people consume more Alcohol). Probably because that would make both the internal code that calculates it, and the visible playability both extremely complicated.

But if you could increase demand for the output of farms/mines, while lowering the price, maybe that would work. Perhaps it is possible to hack consumer demand, on a global level. I wonder where the individual Houses' demand figures (0.05 of this per year, 0.03 of that) are stored?

Taking of consumer demand, I've just noticed something unheard of in this scenario: complete saturation of the Tycoonatrons legendary, insatiable appetite for Alcohol!

That's the benefit of a European free-trade area!

[undertoad]

Now that I've played on a few years in this scenario (New Beginnings), I've found that unfortunately setting the price back to normal, while it may be doing some good, doesn't solve the problem.

I've checked in the Event Debugging that there are no steel price modifiers in effect. There is a general, permanent +10% Cargo Price adjustment - but if that was causing the problem, why would it affect only Steel? (I haven't seen any weird effects on the price-map of anything else).

I'm still getting these weird price spikes, but not as badly as before. Is there perhaps something particularly buggy about Steel price calculations? Or is it perhaps still an after-effect of the previous price-spikes (it's about 3 game years since I removed the +30% modifier from Steel)?

One thing's definitely true, which is that this kind of spike upsets the cargo prices for that cargo all over the map. There's some kind of mechanism (very clever) by which prices are higher at stations, not because of a demand right there but because of a demand somewhere else on the network: the higher price represents the possibility of hauling stuff from the station at a profit. With an insane price anywhere on the network, stations start creating their own little spikes in response: because you could haul stuff from them to the actual original spike. You can see this on the picture near Berlin: stations around Berlin are asking for Steel, even though Berlin has far more need for it, because they think they can load Steel and ship it off to France to be turned into giant statues of Napoleon's genitals .

So I've now tried another approach. I've laid on special trains to move Steel right to the middle of the price spike (as well as other trains to take most of it to where I actually want it - which is laborious because, to get the trains to load, the destination has to be "faked" and then changed just at the right time). A kind of therapeutic delivery of Steel, to stop the price-spike getting out of control. Let them build their statues of Napoleon or whatever, as long as they leave the rest of the economy alone! So you can see stacks of Steel in the picture, where I've dumped them in the middle of green zones right in the middle of nowhere. I hope this will work...

[Gumboots]

But if you could increase demand for the output of farms/mines, while lowering the price, maybe that would work. Perhaps it is possible to hack consumer demand, on a global level. I wonder where the individual Houses' demand figures (0.05 of this per year, 0.03 of that) are stored?

Data/BuildingTypes/House.bca

[RulerofRails]

You can increase the demand for any cargo to some degree, by increasing the production rate of the industries that demand it or in the case of the consumer cargoes, increasing either the house .bca as you already mentioned. If you try adjusting the house .bca file, see what you come up with. I tried a little experiment to increase their demand hoping to limit the natural re-hauling. The results were inconclusive, as I found that each cities' demand was even more reactive than before. But I didn't have time to experiment very much. There's probably some better settings than what I chose. I multiplied all house demands by 10.

Even though we can adjust demand a little. Those efforts are futile compared to the massive strength of this price increase outbreak bug. I have seen strong links between the outbreaks and the way that the demand at a station is calculated. I tried a test once by letting a map run without ever building a rail network, and I didn't get the outbreaks. That's not a workaround, but gives me reason to believe the stations/trains and their effects on demand are in some way responsible.

[Gumboots]

Is there a lower limit to when spiking will start? Obviously it happens with a 30% price hike, but what happens at 10%?

[undertoad]

Is there a way to read the numbers in House.bca? In Notepad, I see the names of various cargoes, and the phrase {Demand Only}, but no numbers. I'm guessing the numbers are encoded as actual numbers (represented in Notepad as rarely-used ANSI characters), rather than as ANSI phrases: [1-byte code for 0][1-byte code for "."][1-byte code for 0][1-byte code for 5] to represent 0.05. I haven't done much work with hex-editors and such-like, can you recommend one to use, and where the numbers are in the stream? (perhaps Notepad++, which I like, allows you to view the hex and character representation at the same time?)

Even though we can adjust demand a little. Those efforts are futile compared to the massive strength of this price increase outbreak bug. I have seen strong links between the outbreaks and the way that the demand at a station is calculated. I tried a test once by letting a map run without ever building a rail network, and I didn't get the outbreaks. That's not a workaround, but gives me reason to believe the stations/trains and their effects on demand are in some way responsible.

I'm convinced you're right that it's the way demand at a station is calculated that makes this price increase outbreak so strong and disruptive. The Goods Price map really shows its worth in helping you see this. (RRT3 was ahead of its time: in the data and business-intelligence world I work in at the moment - while waiting for the call from a headhunter looking for a pan-European Controller Of Railways - people started going about "heatmaps" as the Latest New Big Thing in about 2008. The Goods Price map is exactly this).

What the map shows is that in normal circumstances, even with a newly-built strong demand or supply, the price-gradient is smooth, and adjusts smoothly. The effects of the price-spike bug stick out like a sore thumb on the map, because they're ugly. Deep blotches of colour, spreading quickly, with no smooth graduation into the surroundings. Pixelation. Weird 1-unit-wide limbs of high price sticking out in one direction.

And these effects happen far away from the actual price-spike itself. In my current game, the spikes happened in France. (But, see below, I think they may actually themselves be symptoms of a big spike in the Thames Estuary - offshore from London!). But they caused smaller, but equally obvious, ugly, pixelated smaller price-spikes in the surroundings of Berlin. Leipzig, Dresden and Magdeburg suddenly developed their own ugly little zones of high price - enough to drag Steel away from Berlin, which was the only place in the region that actually wanted Steel (Tool&Die and Auto Plant).

Even some place in Poland just over the border, whose name I can't remember, had a price spike pricing Steel higher than in Berlin, even though it had a Warehouse pumping out 5 Steel/year. (It's not Poznan or Szczecin. The selection of "notable places" in built-in scenarios is often really bizarre: e.g. Kirn, near Frankfurt. Kirn? population 8000? Looks like a nice place, but I wouldn't build a railway to Kirn first rather than to Wiesbaden, Mainz or Koblenz )

In its own time and in its own way, every station on the network reacts to a price-spike, however far away it may be (oddly enough, I saw big shifts in the price map whenever a rival tycoon bought into or sold out of my company - maybe that kicks off an automatic recalculation?). A price-spike happens somewhere. But faraway stations then suffer their own price-spikes, because they're connected by rail to the original spike, and are sensitive to the price anywhere on the network. This makes perfect sense - it's what makes RRT3 playable, with stations "telegraphing" a high price along the line to each other. With an extreme, buggy price-spike, though the effect is that real local demand gets drowned out.

Ports are even worse for this. I think I may have found an independent bug, which is to do with re-entrant coastlines. (I vaguely remember reading somewhere, in the mass of accumulated experience here from scenario-writers, that people have come across this one already), The mouth of the river Thames, just east of London, is this kind of coastline, narrowing to a corner. Here's the current Steel price map for it:

It's impossible for you on the forum to see this, because the price map is blank for sea/ocean, but the price just off the coast is much higher ($340) than on the land right next to it ($290). All this Steel has got stuck in the mud, and doesn't know where to go. I suspect that the pricing mechanism which carries goods effectively along coastlines and across short stretches of water breaks down when it runs into a "corner" of Ocean like this one. Moving my mouse around and looking at the price in the status bar, I can see that the buildup of Steel is completely logical in its own terms: $340 is the highest price on the map, and the goods can't move in any direction along the coast without moving down to a $339 or $338 price, which they won't do. And I think they can't land, and make things turn out sensibly with some mediation between the offshore price and the onshore price, because only a Port can make that happen, and there isn't one - is that right? (I've just built two Ports, using the Editor, to see what happens).

Alcohol and Tires, the two other goods produced near the coast (but on the European side) have also piled up in this corner:

suggesting that it's not, as I thought, just a Steel problem (though the probably completely independent "price-spike" bug probably was Steel-related),

What's interesting is how badly this distorts the prices at other Ports, and in turn across the entire map (because of the knock-on effect on stations connected to the ports). Ports on the same body of water seem to adjust to a very close price to each other, far closer than stations. Probably because there's no need to allow the tycoon players to make money off the difference; or because it represents the cheapness (and slow speed) of water transport. But they even adjust closely to prices anywhere on the body of water, whether or not there's a Port there. So this dead-end price spike of $340 off England, with no Port, makes the price rise insanely high to $330 at the new port of Caen in France (red triangle, showing it actually produces Steel!), at Middelburg in Holland (no triangle, but you can see the flow towards it), Brighton in the South of England (again, which produces Steel), and Hull in the North of England, even though apart from Brighton they're miles away from it:

For my first scenario (whenever I get round to writing it ), I've got two guidelines already: no price-increase events, and no estuaries without a Port.

[Gumboots]

Wasn't aware of the estuary bug. That's a good one.

It's obvious price increase events bork freight. What about express? Express operates on an entirely different system to freight, AFAICT, so express price increase may not causes spiking problems. Anyone got any info on this?

[RulerofRails]

Is there a way to read the numbers in House.bca? In Notepad, I see the names of various cargoes, and the phrase {Demand Only}, but no numbers. I'm guessing the numbers are encoded as actual numbers (represented in Notepad as rarely-used ANSI characters), rather than as ANSI phrases: [1-byte code for 0][1-byte code for "."][1-byte code for 0][1-byte code for 5] to represent 0.05. I haven't done much work with hex-editors and such-like, can you recommend one to use, and where the numbers are in the stream? (perhaps Notepad++, which I like, allows you to view the hex and character representation at the same time?)

I was going to answer, but got side-tracked. I use HexEdit, as recommended by Gumboots. Works perfectly for what we need. Link for their download section: http://www.hexedit.com/download.htm.

There are two resources available to help with the bca files: Pjay's notes in "RT3 Notes" and the second sheet of WP&Ps "Hex Editing Building Planner Spread-Sheet". Both are available for download from the Tips and Tutorials RT3 section of the main Hawk and Badger Site. The Spread-Sheet is more visual, but Pjay's info is better in some aspects because he assumes that you are able to easily find start of each production entry.

Hex code is rather nasty to look at, with little understandable to the human brain. Simple maths can help a lot with that.

For example, bca files have production entries as well as some header and footer information. Each production entry takes up 188 bytes. The header (55 bytes) and footer (174 bytes) is a combined 229 bytes. Hexedit displays the length of the file in the status bar (bottom of the screen when in Decimal Address mode: Toggle with Alt+D). To caculate how many production entries in the current file: (Length of File - 229) / 188. The House.bca file is 4359 bytes long. So we have 4359-228=4132/188= 22 Production Entries.

If we know the entry we need to find, for example the 10th one, we can do (Production Entry * 188) + 55 {Header offset}. This would give a location of 1935 for the start of the 10th Production. It's easy to wip up a spreadsheet with this formula that will give us a list of the values for possible starts of Production Entries (the .bca file for the house is the longest one, most only have a couple of entries).

Proceed by then adding the value that locates the bytes you want to edit. For the "input cargo 1 qty." we get a location of 72. You want to look at Pjay's notes for these. For the 10th entry we get 1935+72=2007.

Demo:

See where I entered "2007" in the second toolbar? This is the "Jump to Decimal" option. Put the location you want to jump to in there.

You can tell from the display on the right that we are looking at an entry for Toys. That's one of the only things that's thankfully understandable.

The Properties box that I have pulled can be accessed by right clicking anywhere in the file, and choosing the lowest option. Notice how it is interpreting the Float values here? Notice that I have the "Real" tab selected. Use this for Float values. The other possibilities (Byte and Int. which is short for Integer) are self explanatory for the tabs. Remember to check in the documentation for what type of value we are working with. Both the spreadsheet and notes have it.

We can enter a new value into the Properties box, however, if you followed these steps you probably have a greyed out box. The reason is that the file is in read-only mode. I am yet to find out how to disable read-only mode by default. In the meantime, I click on any of the nearby zeroes; press the "0" key; then a notice will come up saying "Do you want to turn off read only mode?"; answer Yes.

One more important step, you must remember to press the "Enter" key after inputting a new value. This applies it to the file.

Obviously, you must save the file in the hex editor and also restart RT3 before you will see any of the changes you did in the game itself. I recommend backing up the file you are changing first. Copy it to a spare folder before attempting any changes, then if things go badly wrong you can restore to the original.


I'm not an expert at hex stuff by any means, but I hope this gives you a start on the hex stuff. Let us know how you go.

[undertoad]

I was going to answer, but got side-tracked. I use HexEdit, as recommended by Gumboots. Works perfectly for what we need. Link for their download section: http://www.hexedit.com/download.htm.

That - I mean your whole post, not just what I quoted - is an impressively thorough introduction to editing the .bca files. Thank you! I look forward to digging into these with help from your info - though it probably won't happen before the weekend .

It's obvious price increase events bork freight. What about express? Express operates on an entirely different system to freight, AFAICT, so express price increase may not causes spiking problems. Anyone got any info on this?

Given that express cargo already operates according to a complex formula involving the current right ascension (in the destination city) of the constellation Draco, the Pantone value for the colour of the mouse you're using, last Tuesday's highest bid-price for zirconium futures on the Buenos Aires commodities exchange, and something incomprehensible to do with the precession of the orbit of trans-Neptunian object MJ332X-3H, there's probably not much that a price-spike could do to disturb it further...

But seriously, or at least a bit more seriously: I haven't tested it, but I think you're right that the completely different system used by express should preserve it from this kind of price-spike problem.

Just as an intuitive hunch, I think the mechanisms are radically different enough for express to be unaffected. The price of a good is a function of a single location, and the problem is with the feedback mechanism between the local price and remote prices: RulerofRails' test showed that price-spikes only spread (or maybe only occur at all) if the locations are connected by rail. What seems to happen is something that encourages medical or homeostatic analogies, especially since the Goods Price map allows you to visualise it so well. When the bug hits, it's as if the local exaggerated price becomes only a transmitter to other locations, rather than being also a receiver of the surrounding context. This reveals how clever the RRT3 price-transmission mechanism is, when (as it usually does) it works: a new, demanding factory will raise the local price, but not to the extent of overwhelming the original low price that surrounds it and gives it a competitive advantage. The feedback goes both ways.

The price-spike bug reminds me of a skin rash, or of old Pavlovian theories of insanity as arising from isolated areas of the brain which become autonomous, no longer listening to their surroundings (at least this is the slightly bonkers and very entertaining account of it I remember from Pynchon's Gravity's Rainbow). And like a skin rash, I found I could "soothe" it by delivering quite small quantities of Steel (in this case) to the affected locations, which buffered the outbreak a bit. The one outbreak I couldn't soothe was off the shore of Britain, because it's hard to build a station in the middle of the sea (though, incidentally, if you open up New Beginnings in the Editor, a large area of Germany between Frankfurt and Basel, and the North Sea both share a common region called "Ocean", probably because the map designer ran out of regions. Which made wonder whether the North Sea was also sprouting lots of invisible Grain and Produce Farms on the ocean floor... and what that might do to the price-map...). And that outbreak off the shore of Britain had its own special infinite-loop problems.

Because Express prices seem to already be a function of two locations rather than one, I think this bug shouldn't affect them. Though of course someone might test it and prove me completely wrong...

[Gumboots]

The one outbreak I couldn't soothe was off the shore of Britain, because it's hard to build a station in the middle of the sea...

A port should do the trick, but IIRC you ended up trying that. Did it work?

...(though, incidentally, if you open up New Beginnings in the Editor, a large area of Germany between Frankfurt and Basel, and the North Sea both share a common region called "Ocean", probably because the map designer ran out of regions. Which made wonder whether the North Sea was also sprouting lots of invisible Grain and Produce Farms on the ocean floor... and what that might do to the price-map...). And that outbreak off the shore of Britain had its own special infinite-loop problems.

If it was seeding any farms there you would see them. Anything built of the bottom of the ocean in RT3 is visible, as if it was built on zero altitude land.

I don't think the game will actually seed in ocean anyway, although you can set parts of it to land and build on them, then set it back to ocean. That works, if you ever need to (some of us have used this trick before).

[undertoad]

A port should do the trick, but IIRC you ended up trying that. Did it work?

It did do the trick eventually, but I ended up having to build multiple ports. Once my ports around the Thames in the UK had lowered the local price-in-the-ocean a bit, all the Steel very slowly went and floated off to a new price hotspot, which turned out to be just off Caen in France. Which had two ports already! But the price hotspot just stayed there, just offshore from the ports, with the ports making no difference at all. So:

- I built a port as close as possible to the French "hotspot", sticking its arm out into it;
- I built a port on the route the "Flying Dutchman Steel" was taking from the previous hotspot off the UK to the new hotspot in Caen - somewhere near Calais, thinking that since the effect was ocean-wide, the more connections from sea to land the better.

Both of these had interesting effects:

a) They instantly raised the local onshore price to close to the offshore price; but this effect was very localised, restricted to the "cell" occupied by the port
b) The port quickly spread its high price into the surrounding area, in a sharp, extreme gradient that looked very like the previous "price-spikes". But, very slowly, the influence of the surrounding land and its low price fought back, slowly decreasing the port's onshore price and the offshore price. You you could imagine this effect as real, human steel buyers going "you what? $300 for some steel that's been floating around in the sea for ages? I don't care if those crazy Flying Dutchmen out in the ocean think steel is worth $300 - we're not paying that!". But it operated very, very slowly.
c) No steel ever flowed from the sea onto land, because the port price always remained below the offshore price. This may change now (see below for long this took).

So the crazy thing is how long it took for prices to return to normal. It turned out that this insanely high price, left over only in the sea, completely disconnected from any real demand, had been artificially inflating the Steel price over the whole map since the start of the scenario. This was still the case even when the Price map starting looking more "normal", with no strange outbreaks. And the outbreaks were clearly caused by the presence of this inflated price at sea, because once the price at sea started dropping, the price map changed radically.

I kept waiting for a real demand price (e.g. in Paris, which had a hungry Tool & Die and Auto Plant) to emerge, like an island, out of the falling waters of the generalised inflated price. But prices everywhere dropped, as the price at sea dropped. Eventually, it turned out that a price of about $205 was the real market price where there was demand. The price at sea started off around $400! For it to drop from $320 down to $205 took 17 years (which of course I "played" on the fastest speed).

This bug is a complete pain. And resolving it once it's hit will take longer than most people even want to play a scenario.

I don't think the game will actually seed in ocean anyway, although you can set parts of it to land and build on them, then set it back to ocean. That works, if you ever need to (some of us have used this trick before).

Very interesting - perhaps I'll try building some things in the Ocean some time just for the giggles. I must say that what you did putting trains into "ship-drag" is a completely insane, impressive achievement!

[Gumboots]

"Ship drag"

The ships themselves weren't that big a deal. The hard bit was getting the track graphics sorted, which I still don't have a complete solution for.

Anyway, interesting stuff about the ocean/price spike problems. The Chile map also gets insane price spikes (in crystals). However it depends on how you play the map. Sometimes it will start spiking. Other times it won't.

That map has some offshore warehouses to simulate an overseas demand for crystals. These were obviously just built in the editor with that area set to land, then set back to ocean after building. I've never checked the price out there. I did notice that the way to get maximum spiking happening seemed to be to concentrate on maximum shipping (by rail) of crystals up and down the coast as early as possible in the game. It may be that this semi-starves the offshore warehouses of crystals and therefore the price out in the ocean goes sky high. I'll have to check that.

[undertoad]

I was going to answer, but got side-tracked. I use HexEdit, as recommended by Gumboots. Works perfectly for what we need. Link for their download section: http://www.hexedit.com/download.htm.

There are two resources available to help with the bca files: Pjay's notes in "RT3 Notes" and the second sheet of WP&Ps "Hex Editing Building Planner Spread-Sheet". Both are available for download from the Tips and Tutorials RT3 section of the main Hawk and Badger Site. The Spread-Sheet is more visual, but Pjay's info is better in some aspects because he assumes that you are able to easily find start of each production entry.

I've now had time to look into this. Thanks - that's great documentation, and obviously the result of a lot of detective work! I've found it very easy to take the spreadsheet and add in a calculated location helper, whereby you type in the index of the production entry you're looking for (e.g. 1 for the 2nd one) and it calculates the actual location of all the bits of that entry for you.

Had to recall the little I ever knew about bigendian vs littlendian, 2s complement etc...

One thing I've noticed is that a lot of the entries which take up 4 bytes actually only make sense as 2-byte (16-bit) numbers. For example, the "Cargo 1 input qty" at 127-130 of the production section. Looking at house.bca's Goods demand (503-506 in the file), there's a value in 503-504 that works out as 0.05 as a 16-bit IEEE Real. But there's also something in 505-506 (4C 3D), which would make the value completely different if the whole 4 bytes were read as a 32-bit Real. I guess I just have to ignore those extra 2 bytes (unless they're something to do with the mysterious "rel" mentioned in the documentation?).