Historical RT2 Mod

[pcopa]

1. TGV

This one is a tough nut but I think, there is still a chance to subdue it

(I'll take a look at that at this weekend).

If our efforts do not succeed, we should ban it from the game, we have another three TGVs.

2.Buying industries

Thanks jerry's work I am finally able to buy a geothermal power plant (2M $).

I can buy military depots and barracks too and it makes me quite happy

because they don't disappear abrupt any more.

It' also possible to buy houses but I think, it would disfigure the game play to much.

On the other hand it would open new options for scenario design.

P.S.

Jeffryfisher, I suppose you've already known this. If not:

exe data – Bldg Sched – column C t/f

3.Own weight of locomotives

Sorry, but the fact that the Trevithick has the same own weight as the Big Boy (60t),

both more then the GG1 (30t in game, historically around 215t) gives me no rest.

I've tested the Trevithick and the GG1 with different own weights (without cargo cars).

There is an impact upon the performance but not very dramatical.

I'm working on it and testing further.

As near as I can tell, "free weight" is the amount of weight that an engine can pull before it suffers a speed penalty (a drop below its maximum speed). I think that a train's max speed drops by 1 mph for each free-weight amount of weight of the whole train (engine plus consist).

I experimented a little bit with this issue and I think you're right.

It's a pitty, I don't know how it works exactly (a formula).

[jeffryfisher]

I am finally able to buy a geothermal power plant (2M $). I can buy military depots and barracks too

Do depots and barracks make money after you make them buyable?

exe data – Bldg Sched – column C t/f

Aha, good catch somebody!

I also now notice that the logging camp is the only object with a '1' in column J, so that's probably the tree requirement. Column AF appears to be a "used in the game" flag.

Other columns have tantalizing clues that I haven't figured out yet:

* The coal mine is the only object with a '1' (true) in col L. What's unique about a coal mine's placement on the map (or graphics)?

* Columns O, P & Z are identical. Cattle, Dairy, Grain, Rubber and Sugar are zero (false) in all three of these columns. All other constructs are true. I am thinking that these and other columns around them might pertain to terrain types, so these flags might prohibit placement in tundra, alpine, mountain.

* One of these columns must be some sort of economic cost (how much "growth" is expended by placing the building/farm/mine on the map. Maybe it's col F with 1 for house, many 2's, a few 3's and a couple of 4's. Then again, that could be minimum economic state required.

* Col K: Cattle=0; Cotton/Dairy/Grain/produce=1; All others=2

If you like puzzles, maybe you can crack one of these. Note: All industry conversions (demands, products, boosters) are in a separate table. What we're talking about here is how a building interacts with the map and the players. Graphics (sprites) such as smoke might also have parameters in this table. Vulnerability (tendency to disappear) could also be a factor.

Own weight of locomotives Sorry, but the fact that the Trevithick has the same own weight as the Big Boy (60t), both more then the GG1 (30t in game, historically around 215t) gives me no rest. I've tested the Trevithick and the GG1 with different own weights

Where is a locomotive's own-weight parameter? I should be able to find it, but I am not seeing it. My best guess is that each engine and each tender weighs 30 tons. These values appear in the cars table (all 30's, no exceptions). It might be interesting to vary these somewhat.

[pcopa]

Do depots and barracks make money after you make them buyable?

I've tested it very briefly but yes, they do make money, housing as well.

If you like puzzles, maybe you can crack one of these.

Yes, I actually do, but these ones are something for an aspirant to a higher school of clairvoyance.

There is only one small thing that I could find out. I was looking at the building list and I noticed,

apart from TSC buildings, they were all in a strict alphabetical order ( if you read “log mill” and “oil refinery”).

The only exception was “Textile Fake” in the place of.... port. I did some testing and it IS the port.

Consequently, the column AF can't be a "used in the game" flag (tested)

but rather something to do with customs duty or water (?).

Where is a locomotive's own-weight parameter?

Your guess is right. I changed for sure the values in both columns (E,F).

As you know, all steam locomotives have two units (tender) as well as the F3 and the E656,

the sum total appears in the game.

@ The (dam...) TGV

I've finally found by testing the year of appearance [Edit] (0x79602).

It seems to work fine, the engine and the displayed year appears correctly in 1981 but....

there is no the usual announcement in the game "a new engine is available!" >:(

I give up (for a moment?)!

[jeffryfisher]

I noticed,

apart from TSC buildings, they were all in a strict alphabetical order ( if you read “log mill” and “oil refinery”).

The only exception was “Textile Fake” in the place of.... port. I did some testing and it IS the port.

How do you figure?

[jeffryfisher]

Because of the TGV problem, I've update my uploaded file in the OP. The unfixable 1955 TGV is again "TGVx" at poor reliability. The other TGV goes back to being an electric becoming available in 1981.

I am still wondering if I should vary engine weights. I'll sleep on that for a little while longer.

[pcopa]

How do you figure?

I'm not sure I understand your question correctly.

I changed the year of appearance (exe file), went into the game editor, map options,

industry, port and checked the yellow display of the year on the image.

Because of the TGV problem [...]

It would be a pity right now.

As I mentioned in my last post, everything seems to work properly.

The only flaw is the lack of the pop-up window on the first of June 1981.

!!!Typing error!!! The correct file offset is: 0x79602

I am still wondering if I should vary engine weights.

Yes, it should be thought out very well.

However, in my humble opinion, some changes are indispensable.

It would enrich the game only marginally but the game would be certainly more “historical”.

Maybe a few “classes” only e.g. 20t, 40t, 80t, 120t.

[pcopa]

@ TGV

I've got it! Oh my Goodness, the problem wasn't the exe file but my save files!

It took a long time to find it out. The program sets a flag in a save file that says

“the engine has already appeared” and therefore there is no pop-up window in the game.

So if you want to test the TGVs, do NOT use a file saved after 1954!

I've tested it several times already and I am really happy now, it works perfectly.

All that have to be done in Jeffry's modified exe (if I'm not mistaken):

offset 0x79602 > BD07

and 0x79609 > 0F27 (probably not necessary)

I've discovered something new too, the column L in table "cars" means:

engine side-view skin/graphics.

[jeffryfisher]

I changed the year of appearance (exe file), went into the game editor, map options,

industry, port and checked the yellow display of the year on the image.

That's a good indicator. I wonder why the port starts with most of the data from a textile factory. Maybe it was a convenient block to copy-paste into some source file when the data was generated.

I am also left wondering what block one pertains to if not the port.

As I mentioned in my last post, everything seems to work properly.

The only flaw is the lack of the pop-up window on the first of June 1981.

I don't think so. I started a new scenario in 1955, and the TGV (formerly TGVx) popped up on June 1 even though I had set the intro year to 1981. The other TGV (PSE) at the tail end works correctly, but not the one near the top (near John Bull and Dewitt Clinton data).

!!!Typing error!!! The correct file offset is: 0x79602

I don't understand the offsets you're using. My loco data starts at x013cec0. That's six hex digits from the start of the file. Is your editor counting from the end of the file? Maybe you have a more sophisticated editor that understands EXE file structure so that it can count from some boundary between executable code and data resources?

Yes, it should be thought out very well.

However, in my humble opinion, some changes are indispensable.

It would enrich the game only marginally but the game would be certainly more “historical”.

Maybe a few “classes” only e.g. 20t, 40t, 80t, 120t.

I'm open to suggestions. At least the earliest, weakest engines should have a chance to get lighter numbers, and a few of the monsters might get heavier. However, before we use any historic tonnages, we should check to see if cargos are anywhere near their historic tonnages. It would be a mistake to mix real tons with pseudo-tons that are off by some multiplier like 10 or even 3.

There's also the ratio between cars attached to a game consist and real-world consists that are much longer. After "weighing" these considerations, we may find ourselves giving engines weights that are some fraction of their real-world weights. My early guess is that we keep the game's 30t as a mean or median weight and adjust the lightest and heaviest proportionately.

[pcopa]

My loco data starts at x013cec0.

...and that's it! For some incomprehensible and curios reasons, an additional TGVx entry date

is located outside the loco data section “in the middle” of the file!

So my editor counts just normally, from the start of the file.

Check it out please.

[pcopa]

if cargos are anywhere near their historic tonnages

Astonishing but single cargo and passenger cars are!

Here is some data I've found [source: German railways forum]:

Cargo cars used at present days:

2 axles: from 14t (empty) to max 35t (loaded)

4 axles: from 20t (empty) to max 70t (loaded)

6 axles: from 25t (empty) to max 100-120t (loaded)

Note: 6 axles cars are very rare!

Modern passenger cars:

double-decker coach, bilevel car, Dosto (ger. Doppelstockwagen) - total (loaded) weight 55-58t

"normal" passenger car - total (loaded) weight 36-40t

Note: For passenger cars the load weight (passengers) is assumed to be 5t average

So the difference (laded - unloaded) is relatively quite low.

Another examples (passenger trains):

Shinkansen 52-58t per car (integrated electric motors)

Eurostar 2 engines + 20 cars – total weight 750t (empty), 815t (loaded), 34-37t per car

The new AGV (TGV) about 40t per car

There's also the ratio between cars attached to a game consist and real-world consists

This is the major limitation of the game, regrettably very unrealistic.

"weighing" these considerations

That's what must be done, unfortunately it's not very easy.

[jeffryfisher]

Astonishing but single cargo and passenger cars are!

Here is some data I've found [source: German railways forum]:

Cargo cars used at present days:

2 axles: from 14t (empty) to max 35t (loaded)

4 axles: from 20t (empty) to max 70t (loaded)

6 axles: from 25t (empty) to max 100-120t (loaded)

Note: 6 axles cars are very rare!

Modern passenger cars:

double-decker coach, bilevel car, Dosto (ger. Doppelstockwagen) - total (loaded) weight 55-58t

"normal" passenger car - total (loaded) weight 36-40t

Note: For passenger cars the load weight (passengers) is assumed to be 5t average

So the difference (laded - unloaded) is relatively quite low.

Strange, I found bigger numbers. A loaded coal or iron hopper is 110-120t (metric). An Amtrak superliner is 67t loaded, maybe 60t empty (64 pax plus crew, luggage, water etc). In general, the weights I saw were half-again or double the heaviest (most modern) editions in the game.

An interesting factoid I encountered is that there was an era of "heavyweight" passenger cars starting in 1910 with the all-steel construction by Penn. Pullman cars of that era topped 80t.

The era ended in the 1940s with more clever use of the steel that shaved 25% of the weight. Going by that, the pax cars would be 40t from 1910 until maybe 1945, and then they'd go back *down* to 30t (loaded)

[pcopa]

there was an era of "heavyweight" passenger cars starting in 1910 with the all-steel construction by Penn.

Pullman cars of that era topped 80t

Very interesting, I didn't know that. I think, I've read that the late

mostly wooden passenger cars were heavier as the first all-steel ones.

I've learned, the key and decisive value is the maximum axle load allowed (mala)

for railroad trucks. Rail networks, lines or even individual sections have a category.

Depending on this category there are different malas.

In Europe (also UK) the mala does not exceed 16-19t with the exception of Sweden,

where few new lines have 25t. I've read also, in North America the mala is usually bigger

as in Europe. The highest mala (world record) have some lines in Australia, 40t!

By the way, as well as the world record for the longest train ever - eight engines

pulling 628 cars of 99732t total weight, imagine such train in RRT2

I think, american cars are also slightly longer and higher as their equivalents in Europe,

they even look “heavier”. Furthermore, as you noticed for sure, the north american diesel locomotives

are usually much heavier as the european engines, and last but not least,

there can be some confusion concerning weight units.

Concluding, I am actually quite satisfied with the cargo weight values in RRT2,

they aren't unrealistic or imaginary.

On the other hand I don't mind to adjust them, especially the empty/loaded pax cars

or making some cars heavier e.g. steel or cement . They couldn't be too heavy of course,

since the balance with the engines power would be lost.

Question: In the game editor there is “traction” as an adjustable value for engines.

Is this the “free weight” in your locomotives data table?

[jeffryfisher]

I think, I've read that the late

mostly wooden passenger cars were heavier as the first all-steel ones.

That's highly unlikely, contradicting what I read just yesterday.

I've learned, the key and decisive value is the maximum axle load allowed (mala)

for railroad trucks.

MALA is decisive for road construction / maintenance, but it doesn't relate directly to acceleration or hill-climbing.

By the way, as well as the world record for the longest train ever - eight engines

pulling 628 cars of 99732t total weight, imagine such train in RRT2

I once figured that each RRT "car" represents 5 loaded cars in the real world (instead of one engine and six cars, a real train might have six engines and 180 cars -- 30 cars each)

as you noticed for sure, the north american diesel locomotives are usually much heavier as the european engines

American freight engine design has been utterly warped by union-owned government regulation since mid 20th C. If you play my US History scenario, you'll get a taste of it. Consider these two rules alone:

1) The 100 mile day (increased to 110 miles in the 1990's) makes speed worse than useless. Going fast just means stopping more often to change crews.

2) Speed limits following two 1946 rail accidents. American rails are rated according to signaling and safety requirements written by bureaucrats, not engineers. Only a few lines can move freight over 59 mph (pax 69 mph). But with a 110 mile "workday", who'd want to pay billions to upgrade track and equipment?

As a consequence, Americans have built (fewer) long, heavy slow trains rather than more shorter, lighter faster trains. Only the government is stupid enough to operate trains at "high speed", and even that is only about 110mph (180kph), pathetic by European standards (Acela has a few stretches at 150, but averages 68).

The speed classes still exist, and unless work-rules have changed since the 90s, the union still punishes upgrading. All I can say is that if the pro-union Obama administration builds truly high-speed rail, then I want one of those driver jobs paying me 2.5 days' wages for about an hour per day of work (110 miles outbound and 110 miles "overtime" back home). I'd make about $200k per year working an hour a day with four weeks of paid vacation, paid medical, and a gold-plated pension. Is it any wonder that the government loses money on every segment of the Amtrak system?

I am actually quite satisfied with the cargo weight values in RRT2,

they aren't unrealistic or imaginary.

I think the loaded weights are all about half of what's actually in use now. For instance, a loaded coal car in game is 65t, but real world is ~120t.

This halving should guide any enginee weights we use. The Big Boy's 345t (+155t tender!) IRL should at least be halved to 170+75. Moreover, we might want to "amortize" engine weight over train length (because of the ratio between the game's six-car max and the real world's 30+ cars per engine).

Question: In the game editor there is “traction” as an adjustable value for engines.

Is this the “free weight” in your locomotives data table?

That's still somewhat mysterious to me also. I'm not sure whether "traction" changes weight-hauling ability or hill-climbing (or both).

[pcopa]

That's highly unlikely, contradicting what I read just yesterday.

From Wikipedia: “With the 1930s came the widespread use of stainless steel for carbodies.

The typical passenger car was now much lighter than its "heavyweight" wood cousins of old. " (?)

MALA [...] doesn't relate directly to acceleration or hill-climbing.

I meant it in the car weight context. How does axle load affect performance characteristics

of locomotives, I've not dealt with this topic yet.

For instance, a loaded coal car in game is 65t, but real world is ~120t.

As I already mentioned, there are probably significant differences between USA and Europe.

In Europe there are only max 4 axle coal cars (type open-top, gondola), so there's no normally operating open coal cars

with total weight exceeding 70-80t.

Unlike in the game, the heaviest cars are the so called (steel) coil cars. They have mostly 6 axles and up to 120t (in Europe).

I've found the most informative website on this topic so far, with really detailed data. Unfortunately, the most interesting part,

the freight car catalog, is in german only, but maybe you'll have a look

[www.stinnes-freight-logistics.de/gueterwagenkatalog/deutsch/gueterwagen/index.html]

For the first time I was looking at the cars in game and … counting axles.

Apart from fertilizer, uranium and cement they are all 4 axle cars (the last versions),

I'm not sure about weapon (4 or 6).

========

I studied and updated the cars sheet from your exe data yesterday. The only duplicated (spare) line is the fdin3 data.

Probably like pax cars a fourth version was planed and then discarded.

I replaced the data with falco and tested in game. It seems to work fine, so I've finally got a light and a heavy alcohol car!

[dodleh]

The modding idea is certainly a very highly praised move. The problem in my opinion remains the fact that RT2 has a large number of bugs that can make the gameplay very unpleasant. If what I will be saying is inappropriate feel free to move the comment in another thread.

Present features that might be adjusted through modding and that might be helpful:

- bridge availability. It is clear that bridges can be built out of stone even before 1900 yet in 1800 it is possible to use only wooden bridges which is indeed a very strange choice.

- inconsistencies in the way electrified track is available or considered in terms of maintenance cost. It is clear that electrified track costs a lot more to maintain that standard track yet I am not sure if this can be corrected in a reliable way

- innacuracies in the way cargo is being used. Milk can be delivered directly to a city even though its attractiveness would be lower due to variation in eating habbits in modern world. Coal as well as logs are still an useful fuel source even today for heating homes so its demand could just be lower not entirely gone. Strangely enough the RT2 game engine considers logs as not acceptable in villages, towns, cities.

- cargo delivery rate. It is clear that some industries might deliver a lower or a larger amount of cargo yet this is not reflected in the game. For instance cargo delivery rate is the same only that cars became heavier and somewhat more profitable in the first years since introduction but useless as you advance in the game. Also the problem that you cannot use a lower weight car with an engine is also manifested. The choice of cargo cars shall be free at any moment the only downside for older cars being less profit.

Present bugs that affect gameplay

- the "rocket" locomotive or engine (not Stephenson Rocket kind... :) ) effect. When an engine waits a long time for cargo it might literally shoot out of the station at top speed if it waited enough. This is a bug that has never been adressed.

- missing cargo. The index system used for engines and cars is very devilish. Since in an era you might not have a certain car in your consist that number may point to a different engine that is added to the consist. In short: a train had a dining car while being set and if the game time is changed to before that car is available a Stephenson Rocket might be added instead to the consist. The strange aspect is that you cannot use more than one engine in a consist even if the game engine clearly shows that this is possible.

Note: In a normal game engine anything, whithin some saneness limits, might be added in a car set and the car limit might be pushed to more than 6. Engines like Brenner, Big Boy or Dash 9 are not really paying of if pulling only 6 cars. This is a known game limit and probably not easy to change.

- demanded cargo calculation. If a train stops at two stations that cover the same area the demanded cargo limit is shown differently depending on the point were the train delivered cargo the last time. At that station demanded cargo is shown as being very low.

- determining breakdown and crash probability for engines. It is almost impossible for an engine to suffer a catastrophic failure while being relatively new yet this can occur in the game. The problem of breakdown rate increased with the engine speed is not quite correct from an engineering perspective. The problem of engine load, tractive effort and engine maintenance factor should be used. Total travelled distance might be or not a triggering factor for breakdowns. Speed alone is not enough to damage something. Also due to the game engine breakdown management is very badly done. An engine might be used even a hundred years with a maintenance cost within limits determined from the interval between rebuilds.

- financial profitability. It is clear that interest on money deposited in a bank account can cover part of the expense the problem is that it is not realistic. You either impose inflation in every area related to operational costs or you get rid of interest for the current bank balance. Otherwise the larger you grow as a company the more you can cover costs and losses through interest which is not what it always happens in real life.

- economic cycles. It is obvious that when you introduce periods of growth and decay the same thing might affect your company (not only your cargo) yet this is never taken into account. Your operational costs might go lower in a period of economic decay due to workforce affordability (wages) while your typical costs for maintenance will go lower at first and the higher due to scarcity. In the game you see just that your cargo goes lower and perhaps some industry goes bust which is not entirely correct.

In the end, in order to improve the community effort in modding the game I would propose that the idea of delivering a game values modifier tool to be considered. In that way by increasing the interest in the game for fans the chances of a successful revival of the game and perhaps even more than that could be achieved.

[jeffryfisher]

Wow, this is a lot to digest. I'll reply to most ideas below, and we might take away some new points for our Open RT2 "Wish Lists" thread.

The modding idea is certainly a very highly praised move. The problem in my opinion remains the fact that RT2 has a large number of bugs...

Agreed. Most of us have probably modified our playing styles more than we realize to avoid the worst of the bugs.

Present features that might be adjusted through modding and that might be helpful:

- bridge availability.

I've hunted for the bridge availability dates in the EXE file, but I have not found them. If anybody has an idea, I'm open to it. However, I did search the whole EXE file for the 16-bit value of the known stone-bridge year, and none of hits looked like anything I could use (nor were any hits near a wood-bridge year and a steel-bridge year).

inconsistencies in the way electrified track is available

I think that electric track becomes available to you with the first electric engine.

inaccuracies in the way cargo is being used. Milk can be delivered directly to a city even though its attractiveness would be lower due to variation in eating habits in modern world. Coal as well as logs are still an useful fuel source even today for heating homes so its demand could just be lower not entirely gone. Strangely enough the RT2 game engine considers logs as not acceptable in villages, towns, cities.

I have found where to mod both industry and city/town demands. However, I don't see your examples as the problem that you do. "Milk" in the game is a raw material that is consumed directly in the early years but processed before consumption in later years. There's about a ten-year overlap during which there can be some of each.

Logs are also a raw material that (in the advanced economic model) must be cut into lumber before being sold to cities and towns. In my US History scenario, I have set up events that make track building cheaper if you create more lumber than you deliver (and more expensive if you do the opposite or ignore the lumber industry for too long).

One change that I have made is to add a city demand for diesel (representing gasoline) after about 1950.

Present bugs that affect gameplay

- the "rocket" locomotive or engine (not Stephenson Rocket kind... :) ) effect. When an engine waits a long time for cargo it might literally shoot out of the station

Yes, that's odd, but it doesn't matter much. I'm more worried about what else is going wrong in the background because of whatever error is causing that visible behavior.

missing cargo. The index system used for engines and cars is very devilish. Since in an era you might not have a certain car in your consist that number may point to a different engine that is added to the consist. In short: a train had a dining car while being set and if the game time is changed to before that car is available a Stephenson Rocket might be added instead to the consist.

I've never seen this bug, so I am not sure what you are describing. Are you talking about scenario design where you can create companies and trains and then alter the game-year for the start?

The strange aspect is that you cannot use more than one engine in a consist even if the game engine clearly shows that this is possible.

Yeah, I wondered about that. A more advanced program would let us put 6 big diesels on the front end of a 200-car train, but then it would be a little (more) tedious as a game.

Similar gripes: On a continental scale map, a train should not stretch out across 60 miles of track. Track should not be limited to 60 degrees of curvature per 5 miles of travel. Whole switch-yards (infinite passing in all directions) should fit in a single cell. Urban buildings should be able to exist in the same cells as track (but not switch yards) and vice-versa, though construction through buildings might cost more for the real estate. Remember Sid Meier's original game?

demanded cargo calculation. If a train stops at two stations that cover the same area the demanded cargo limit is shown differently

This is a known issue that is sometimes exploited by players (including me). I've been known to deliberately build two stations at a destination just so I can double the demand there. A more logical model would have attached demand levels to buildings instead of to stations. However, the town and city demands depend on station radius...

[jeffryfisher]

It is clear that interest on money deposited in a bank account can cover part of the expense the problem is that it is not realistic. You either impose inflation in every area related to operational costs or you get rid of interest for the current bank balance.

You raise an interesting point for long-term scenarios. It has crossed my mind, and I even thought about how I might add events to my US History scenario to simulate inflation. However, I gave up because I couldn't inflate all of the things that needed inflating, and that would have created bizarre imbalances.

The game appears to use a nominal interest rate (what one would see at a bank), but what a game without inflation should use is a real interest rate (the nominal rate minus the current inflation rate). Then it would make sense to have a negative interest rate at times, which would destroy the wealth of cash-rich companies and players.

One problem with this is that the game does not provide enough outlets to hedge against inflation. There's no gold and no steady stream of new companies to invest in. There are industries on the map, but there are problems with investing in them (like you'd need to supply all of them in order to not go broke).

economic cycles: In the game you see just that your cargo goes lower and perhaps some industry goes bust which is not entirely correct.

You're right that more costs could change with the economy. However, there is more than what you list. Track construction becomes cheaper. Interest rates also change.

Unfortunately, the game's economic model gets interest rates exactly backward (or at least 90 degree out of phase). It's in a continuing boom that interest rates rise as sanguine entrepreneurs and greater fools race to throw money at every crazy idea predicated on a never-ending cycle of abundance. The bursting bubble follows, and then rates plummet until money is so cheap that even a pessimist thinks that his meager profit forecast will cover it.

Maybe the confusion come from interest being a feature of the economy's direction more than its position.

to improve the community effort in modding the game I would propose that the idea of delivering a game values modifier tool

Interesting idea. With several versions/patches of the game in existence, the tool would need a map (set of data offsets) for each, and preferably a way to recognize which EXE it was looking at. If I were designing the tool, I would store data in some kind of portable, human-readable form that could be exchanged between players and applied to whatever game-version another player might happen to own. Such a tool should also goad players into backing up their canonical original/patch in a read-only way that won't be clobbered by any number of edits. Keeping an extra copy of the last known working version is also a good idea

[letsdance]

However, the intro year stubbornly refuses to change, and I have no idea where the 1955 value is coming from.

Suggestions?

did you find it yet?

could it be a relative value? for example, the game could use 1800 as the year "zero", that would make 1955 the year 155. it could even use months instead of years (trains don't occur at end or start of a year, right?), which would make such a relative approach more likely.

edit: i'm just going through your exe_data. i've been looking for something like this for years! thank you so much =) i notice there is a value 1800 in the 14F9F0 section. might be a year.

is it possbile to mod the distance factor? it always bothered me, that long distances yield so much more revenues, especially for goods (lumber etc.) where it shouldn't really matter at all. the challenge for such goods should be to make distances as short as possible to reduce transport cost...

[jeffryfisher]

No, the TGV in 1955 is an oddity. All other engines respond to my edits in one data area, but the TGV stays at 1955 even if I change its year to something else (but I can change other parameters of that TGV there, so I know I found the right record). That suggests that the TGV was hard-coded to ignore the start-date in the table. It at least behaves differently from all other engines, so I'll never be able to tease out its rule. With just one engine on its own rule, there's no pattern to discover.

[jeffryfisher]

I've updated the zip in the OP (top of page 1). It didn't change much, just refining some modern engine dates. I also tried to separate the Thalys from the Eurostar so that each will have a role, but I'm not sure I succeeded.

BTW, all of the files except the cargo sheet are also in my US History zip.

As usual, this mod is taken from the Platinum CD version of the game, so it probably won't work with Gold or Steam. You could try to buy a platinum CD, but there's a chance it's pirated, since the Platinum CD was not copy-protected.

[jcco]

Hello everyone, this is my first post on this forum. First, I'd like to thank jeffryfisher for uploading all these docs which helped me experiment with all the datas in the exe file and helped me solve a few problems with the industries and also experiment with cargoes datas and discover a few neat things I'd like to share with you.

 

First, Industries : Some of you may have noticed that, with the exception of steel mill, all the industries in the game using more than one input cargo (cannery, auto factory, munition factory etc..) had a demand for the second input that immediately dropped to zero after the first delivery and never recovered. This is because, the floating number for demand of the second input is in the WRONG place!

 

Look at the EXE Data.ods provided by Jeffryfisher in the OP and open the CONVERSIONS table. The column N which is labeled as "Demand?" of input 2 is in fact the "BOOST" factor of input2! Demand for input2 should go in column P (look at the steel mill)! In fact, Datas for input 2 match exactly datas for input 1, that is, columns L to P for input 2 works exactly the same as columns G to K for input 1.

 

So, for exemple,  if you take the auto factory, the demand for tires (which is 2.5) should be moved into column P, that is 5 bytes further.....As it is now, tires would provide a production boost of 250% more autos, if only the auto factory was set as a raw producer (with a 1 in column D) wihich it is not, hence this number has currently no effect.

 

I tried it, and it works like a charm.....just move the datas for the 2nd input and now all factories works as intended BUT ports!

 

PORTS: ok, we solved the problems with all factories, however ports as well have their demands dropping to 0 on first delivery and never recovering afterwards and THIS cannot be solved by editing the EXE file.....However, I found another way around this problem. The thing is that production and demand for ports is determined through the editor as you create a new Map....That means that the table governing production and demand for ports must be written somewhere in the MAP files. I searched a little and BINGO: On each MAP file there is a data block, starting at 0x8703, wich looks exactly like the data blocks for other industries. And, as I suspected, I discovered that the editor failed to write anything where there should be a floating number governing the demand for input cargoes! If you want ports to work properly you then need to open the MAP file before playing the scenario and enter the demand level for each goods manually.....tried it and it WORKS.

 

Best thing is you can do stuff that would otherwise be impossible with the editor: You can for exemple set your ports to behave like other transforming undustries, for exemple producing 2 goods out of one cotton and one wool, or set your ports to produce a set amount of goods (let's say 2) and at the same time demand other stuff that acts like production boosters (like grain for cattle ranch) etc...

 

Finally, I recently started experimenting on the "Rot factor" and the "Distance factor" (that is, how much the vlaue of a cargo increases with distance travelled) . This is still a work in progress and I'll post more about this in another post. However, what I discovered is that the formulas that governs these are extremely complex and also depends on game year and many other parameters (more on this later).....Anyway, all this led me to experiment with the cargo datas and I discovered a few things that might be interesting for some of you.

 

Now, look at the cargo table in the EXE data.ods. What is labeled as "Rot factor", in column F (0.54 for mail; 0.45 for PAX) , IS NOT the Rot factor! I discovered that this number is the DISTANCE factor and governs how fast the value of a cargo increases with distance, everything else being equal (that is economic state, game year, demand level and cargo type and so on...). Sadly, you cannot directly calculate a value for a cargo at a certain distance because it is not a simple linear formula...as I said, the shape of the curve depends very strongly on the game year. For exemple, in 1820, for pax, the value would sharply increases in the first 20 cells, then increases linearly with distance up to about 100 cells (that is at 100 cells cargo value is about 5 times the value for 20 cells) and then suddenly increases exponentially after 100 cells. However, in 1900, it works very differently, the value increasing linearly up to about 400 cells. and after 1950, the value of pax does not increases as fast as the distance, that is, for 200 cells value is less than twice what you'd get for 100 cells!

 

Anyway, still this number is interesting because, everything else being equal, it shows how fast the price increases with distance...so we can see at first glance that PAX with a distance factor of 0.45 holds its value with distance much better than coal or logs which have a distance factor of 0.21.....this means you can move pax on long distance with good profits while you should avoid if possible delivering your coal at the other side of the map ! Food and Produce will make also a nice profit on medium to long run, but not Iron or Lumber.

Just one warning though: If you play with these numbers and put too high of a value for the distance factor, then there seem to be some kind of overflow in the formula and value will drop to 0 whatever the distance...don't use anything over 0.54 (the distance factor for mail).

 

And now, the Rot Factor. SInce what is labeled as "rot factor" in the table is in fact the distance factor, where is the actual number that giverns how fast the value dops with time? Well, I found the answer with a little experimenting. The "Rot factor" is in fact closely linked to the "DAys to deliver" number. In fact, these two aspects are the same....by putting 50 instead of 500 for PAX I discovered that ,everything else being equal, the value of pax with time would drop 10 times faster. and by putting there a very high number instead, the value of pax would never drop with time (nor would the cargo disappear from a station) but for the decrease in value, each january, due to the change in game year (see distance factor above).

 

So, the "days to deliver" number governs both how long a cargo will stay in a station and also How fast it will rot.....in fact I discovered it is the same thing. The value of a cargo left unpicked at a station will drop with time (rot factor) and will disappear when it reach a certain percentage of its value without being picked up....in both case, this is what should be called a "rot factor". You can use the table to see which cargo needs to be delivered as fast as possible. Milk for exemple, has the same rot factor as mail! 

 

Note that like for distance, the way the value of a cargo drops with time, is also dependant on Game Year (it goes much faster as time passes) and is ALSO dependant on the distance a cargo starts from its destination (it goes much slower, in percentage of total value, if the cargo starts at 450 cells rather than 100 cells of its destination)....this means that the farther the cargo starts from its destination the more time you get to deliver it. Example : At 100 cells, the value of a cargo might drops by 20% in a year, while at 400 cells, it might only lose 5% of its value in the same time. Note, that this is only true once the cargo has been picked up by a train and the destination set.....also, this behaviour changes with game year and I'l post more about this later.

 

 

Ok, sorry for this long post. Hope it is helpful for some of you.

Bye,

 

Jean-Christophe

[akuenzi]

Hello everyone, this is my first post on this forum.

Welcome Jean Christophe!

 

First, Industries : Some of you may have noticed that, with the exception of steel mill, all the industries in the game using more than one input cargo (cannery, auto factory, munition factory etc..) had a demand for the second input that immediately dropped to zero after the first delivery and never recovered. This is because, the floating number for demand of the second input is in the WRONG place!

 

Look at the EXE Data.ods provided by Jeffryfisher in the OP and open the CONVERSIONS table. The column N which is labeled as "Demand?" of input 2 is in fact the "BOOST" factor of input2! Demand for input2 should go in column P (look at the steel mill)! In fact, Datas for input 2 match exactly datas for input 1, that is, columns L to P for input 2 works exactly the same as columns G to K for input 1.

 

So, for exemple,  if you take the auto factory, the demand for tires (which is 2.5) should be moved into column P, that is 5 bytes further.....As it is now, tires would provide a production boost of 250% more autos, if only the auto factory was set as a raw producer (with a 1 in column D) wihich it is not, hence this number has currently no effect.

 

I tried it, and it works like a charm.....just move the datas for the 2nd input and now all factories works as intended BUT ports!

Please forgive me what likely is a simple question to everyone else, but modifying the exe file is way over my head!  How does one make these changes?  Do I need to have special software to do this?  The same applies to what you mention about modifying the map files.

Finally, I recently started experimenting on the "Rot factor" and the "Distance factor" (that is, how much the vlaue of a cargo increases with distance travelled) . This is still a work in progress and I'll post more about this in another post. However, what I discovered is that the formulas that governs these are extremely complex and also depends on game year and many other parameters (more on this later).....Anyway, all this led me to experiment with the cargo datas and I discovered a few things that might be interesting for some of you.

 

Now, look at the cargo table in the EXE data.ods. What is labeled as "Rot factor", in column F (0.54 for mail; 0.45 for PAX) , IS NOT the Rot factor! I discovered that this number is the DISTANCE factor and governs how fast the value of a cargo increases with distance, everything else being equal (that is economic state, game year, demand level and cargo type and so on...). Sadly, you cannot directly calculate a value for a cargo at a certain distance because it is not a simple linear formula...as I said, the shape of the curve depends very strongly on the game year. For exemple, in 1820, for pax, the value would sharply increases in the first 20 cells, then increases linearly with distance up to about 100 cells (that is at 100 cells cargo value is about 5 times the value for 20 cells) and then suddenly increases exponentially after 100 cells. However, in 1900, it works very differently, the value increasing linearly up to about 400 cells. and after 1950, the value of pax does not increases as fast as the distance, that is, for 200 cells value is less than twice what you'd get for 100 cells!

You're absolutely right, it does also depend on game year.  I did some of my own experimenting and observed similar things, especially that the underlying formula was 'extremely complex.'  However, I did NOT notice that the rate of the value change depended on the distance.  In my experiments, I used lumber.  You used passengers.  Could it be that this effect changes depending on what is being hauled?  I'd be curious to have your thoughts on another thread where these things were explored:  http://forum.dune2k.com/index.php?showtopic=23978

 

Anyway, still this number is interesting because, everything else being equal, it shows how fast the price increases with distance...so we can see at first glance that PAX with a distance factor of 0.45 holds its value with distance much better than coal or logs which have a distance factor of 0.21.....this means you can move pax on long distance with good profits while you should avoid if possible delivering your coal at the other side of the map ! Food and Produce will make also a nice profit on medium to long run, but not Iron or Lumber.

Just one warning though: If you play with these numbers and put too high of a value for the distance factor, then there seem to be some kind of overflow in the formula and value will drop to 0 whatever the distance...don't use anything over 0.54 (the distance factor for mail).

 

And now, the Rot Factor. SInce what is labeled as "rot factor" in the table is in fact the distance factor, where is the actual number that giverns how fast the value dops with time? Well, I found the answer with a little experimenting. The "Rot factor" is in fact closely linked to the "DAys to deliver" number. In fact, these two aspects are the same....by putting 50 instead of 500 for PAX I discovered that ,everything else being equal, the value of pax with time would drop 10 times faster. and by putting there a very high number instead, the value of pax would never drop with time (nor would the cargo disappear from a station) but for the decrease in value, each january, due to the change in game year (see distance factor above).

 

So, the "days to deliver" number governs both how long a cargo will stay in a station and also How fast it will rot.....in fact I discovered it is the same thing. The value of a cargo left unpicked at a station will drop with time (rot factor) and will disappear when it reach a certain percentage of its value without being picked up....in both case, this is what should be called a "rot factor". You can use the table to see which cargo needs to be delivered as fast as possible. Milk for exemple, has the same rot factor as mail! 

 

Note that like for distance, the way the value of a cargo drops with time, is also dependant on Game Year (it goes much faster as time passes) and is ALSO dependant on the distance a cargo starts from its destination (it goes much slower, in percentage of total value, if the cargo starts at 450 cells rather than 100 cells of its destination)....this means that the farther the cargo starts from its destination the more time you get to deliver it. Example : At 100 cells, the value of a cargo might drops by 20% in a year, while at 400 cells, it might only lose 5% of its value in the same time. Note, that this is only true once the cargo has been picked up by a train and the destination set.....also, this behaviour changes with game year and I'l post more about this later.

 

 

Ok, sorry for this long post. Hope it is helpful for some of you.

Jean-Christophe, thank you for making this 'long' post.  I'm sure I'm not the only one that enjoyed reading about what you did!  Thanks for sharing, and I look forward to what you share in other posts.

[jeffryfisher]

Hello everyone, this is my first post on this forum.

 

Hey, what a way to introduce yourself. This is exciting stuff. I'll have more to say when I am in the mood to do more modding (probably later this week).

 

First, I'd like to thank jeffryfisher for uploading all these docs

 

You're very welcome. Your discoveries are a nice dividend.

First, Industries : Some of you may have noticed that, with the exception of steel mill, all the industries in the game using more than one input cargo (cannery, auto factory, munition factory etc..) had a demand for the second input that immediately dropped to zero after the first delivery and never recovered.

 

I must confess that I hadn't noticed the demand tanking for 2nd cargoes. However, I had noticed some first-cargo tanking, such as when milk was delivered to a town. I have also experimented with houses boosting pax production in response to goods, but the goods demand is killed by the first delivery. The result is that I can make only one good goods delivery to any sub-town "village" of houses to try to coax them into developing. I can dump more goods on them at demand zero, which I suppose is better than "undemanded", but I would prefer to solve the recovery problem.

The column N which is labeled as "Demand?" of input 2 is in fact the "BOOST" factor of input2! Demand for input2 should go in column P

 

I'll look at that  :)

PORTS: ok, we solved the problems with all factories

 

Not all of the problems have been solved: I still can't figure out why some of my modded factories' supply and demand labels cease to show up after a certain year. For instance, if I filter the map for weapons, the supply doesn't show even though the factories are still there and working. That means that I need to find them the hard way  :(

the table governing production and demand for ports... is a data block, starting at 0x8703, that looks exactly like the data blocks for other industries.

Very cool!

[jcco]

Bonjour and merci for your comments and answers.

Welcome Jean Christophe!

Please forgive me what likely is a simple question to everyone else, but modifying the exe file is way over my head!  How does one make these changes?  Do I need to have special software to do this?  The same applies to what you mention about modifying the map files.

yes, you need a Hex editor (which you can find on the web). I use Hexedit which is very basic but gets the job done and is quite simple to use. However, if you've never done this before, you should be very careful before tinkering with your EXE file (make a backup). you should learn how to convert different kinds of decimal numbers (signed and unsigned integers, floating numbers) into hexadecimal and vice versa.

 

When you open a file with Hexedit you should have a main window with rows upon rows of 2 digits number looking something like this : 00 0A 3C 22 01 00 00 10 0B 02 31 F0 and so on.....all these 2 digits numbers represent one byte of Data and have a value between 00 and FF (that is between 0 and 255 using decimal numbers) however, most datas are stored in blocks of more than one byte (most commons are blocks of 1, 2, 4, 8 and 16 bytes). On the left of the main area you should have one column of numbers, starting at 0, this is simply the adress of the first byte of the adjoining row. on the right of the main area you should see some strange symbols and letters or dots, this is simply the translation of the hexadecimal numbers of the main area into ASCII symbol.....don't bother with that, this is here because sometimes the hexadecimal code does not really represents hard data but text which is encoded in hexadecimal numbers that you can read using the ASCII symbols.

 

What you want to edit are the 2 digits numbers in the main area. Of course, you need to know WHERE to make these changes (that is, you need to know the address of the byte or blocks of byte you want to mod) and WHAT to put in there (that is, you need to know what those numbers represents). This is of course the trickiest part : It's usually a game of guess, trials and errors, patterns finding and so on... It can takes a lot of time and sometimes you won't even find what you're looking for!

 

However here, as I said before, Jeffryfisher has already done most of the hard work (thanks again!!) and you can download some documents in the OP (you'll need open office to read these) where you will find the addresses for most of the relevant datas and how they are organized (that is, number of bytes, type of data (integer, floating number) and so on..) VERY HELPFUL !! (you should look at the EXE data.ods file, keep in mind it is valid only for the platinum version of the game).

 

Now, some other important things you should absolutely know:

 

       - in many hexadecimal programs (and it's the case here) data that are stored in blocks of more than one byte are written in reverse order, starting with the byte of less weight!   Sounds complicated so I just give an example: the decimal number 1800 ( you find it a lot in RRT2 since it is the starting date for most of the industries) converts to 708 in hexadecimal. since you need to write with bytes of 2 digits it should be coded 07 08 if written within a block of 2 bytes, or 00 00 07 08 in a block of 4 bytes.....but, here, it is written in reverse order! that is 08 07 (if 2 bytes block) or 08 07 00 00 ( 4 bytes block).  So, if you want to replace all occurrences of the date 1800 (708 in hexadecimal) into 1820 ( 71C in hex) you will first have to find all blocks of data containing 08 07 and overwrite those with the value 1C 07 (which is the reverse of 07 1C or 71C)

 

     - When I say "go to address 0x8703" 0x is not part of the number. It is a convention which means that I'm talking about a hexadecimal number.....the number is 8703. For example, in the documents provided by Jeffryfisher, it says that the blocks of data concerning the different cargo types start at address 0x1404B0. this means that the starting address is  1404B0 written in hexadecimal numbers....when using the function "go to address" with Hexedit, you just type 1404B0 without 0x.

 

     - There are two ways to edit the main area when using Hexedit. The first one is to overwrite the bytes of data as you type (which you should use) however, by default, the program use the second mode which is to insert what you type and just shift all the following data blocks .....This can be extremely dangerous and can have some very strange results! make sure you use the overwrite mode.

 

Hope this will help you making your first steps in game modding.

 

 

 

You're absolutely right, it does also depend on game year.  I did some of my own experimenting and observed similar things, especially that the underlying formula was 'extremely complex.'  However, I did NOT notice that the rate of the value change depended on the distance.  In my experiments, I used lumber.  You used passengers.  Could it be that this effect changes depending on what is being hauled?  I'd be curious to have your thoughts on another thread where these things were explored:  http://forum.dune2k.com/index.php?showtopic=23978

Jean-Christophe, thank you for making this 'long' post.  I'm sure I'm not the only one that enjoyed reading about what you did!  Thanks for sharing, and I look forward to what you share in other posts.

You are right here. I ran tests with Pax, mail, produce, milk, food and coal. Depending on the value of the "distance factor" results can vary greatly even using the same game year. That is, passenger and lumber or food reacts differently to distance. As I said in my previous post, I'll open a new thread to talk about this as soon as I'm finished testing and have some time.

 

Hey, what a way to introduce yourself. This is exciting stuff. I'll have more to say when I am in the mood to do more modding (probably later this week).

 

 

You're very welcome. Your discoveries are a nice dividend.

 

I must confess that I hadn't noticed the demand tanking for 2nd cargoes. However, I had noticed some first-cargo tanking, such as when milk was delivered to a town. I have also experimented with houses boosting pax production in response to goods, but the goods demand is killed by the first delivery. The result is that I can make only one good goods delivery to any sub-town "village" of houses to try to coax them into developing. I can dump more goods on them at demand zero, which I suppose is better than "undemanded", but I would prefer to solve the recovery problem.

Hello Jeffry, I already knew about the milk and this is one of the first thing I corrected after I downloaded your precious documents. All the industries with 2 inputs showed this behavior except for the steel mill which always worked perfectly. Try with a cannery if you wish and you'll see that demand for steel or aluminium stays tanked at 0 after the first delivery. Was easy to correct though, since data blocks for second input have a perfect symmetry with data blocks for first input....all these industries had the demand in place of the boost factor! (steel mill is the only one with demand at the right place).

 

You got me curious so I did some more tests today and just solved the problem you had with house not recovering their demand for goods! I discovered that, for all the industries (houses included), demand will drop to 0 and never recover if demand value is less than 1.00 !! you had set the demand for goods at 0.5 and that was the problem....I changed it to 1.00 and several other values over 1.00 and it worked perfectly....mail production was boosted and even villages with only one or two houses would demand goods and the demand would recover with time.....So, demand just need to be set at 1 or over, not 0.5. However, the cure might be worse than the illness here because with a demand value of 1.00 even the smallest village will crave for goods so much that the demand is very hard to quell !! with cities and metropolises it is even worse since the overall global city demand is added to all the demands from all the houses!! Might be a balance breaker!

 

This also led me to discover that some industries like produce farms or rubber plantations shared the same problem. Demand for fertilizer was set at 0.5....I ran some test and discovered, as I suspected, that demand for fertilizer also stayed tanked at 0 after the first delivery (must confess that I had never noticed this before, but all  tests proved it was the case! ). I changed the demand to 1.00 (like grain farms) and now it works perfectly.  I then proceeded to change all demand value of less than 1.00 into the minimum of 1.00 (was the case for rubber in weapon factory, sugar plantation etc...)

 

I also made a bonus discovery while running tests on this topic:  No matter how high you set the demand for fertilizer, none of the farm will show a demand for fertilizer until you have placed  at least one fertilizer plant on the map! That is, even if you allow the industry in the general settings, then set your ports to produce fertilizer, farm will not demand it as long as there is not at least one fertilizer plant on the map. You CANNOT create a scenario where all fertilizer is produced abroad and shipped in through your ports....there MUST be at least ONE fertilizer factory somewhere.

 

 

Not all of the problems have been solved: I still can't figure out why some of my modded factories' supply and demand labels cease to show up after a certain year. For instance, if I filter the map for weapons, the supply doesn't show even though the factories are still there and working. That means that I need to find them the hard way  :(

I've never noticed this myself....this being said, I hardly ever use that feature of the game...I usually looks around the map "the hard way" while the game is on pause. I'll try to look into this when I've got time.

 

Very cool!

Note that the address I gave refers to the Map file, not the EXE file....I found no way to mod the behavior of ports from within the EXE files.....need to edit every single map after completion for ports to work properly.

 

 

That's all for today folks....hope this post is helpful to you.

By the way, I'm french, so I just hope my english is correct enough for you.

 

Au revoir,

 

JC

 

[jeffryfisher]

yes, you need a Hex editor (which you can find on the web). I use Hexedit ...

 

I use "Neo". As a bonus, I can set it to display each byte in decimal (0..255) so my brain can know what the numbers are.

 

It's probably just as well that we don't have too many people modding. Although everyone should be able to fix a bug or two, we might want some configuration management on any "deep" lines of modding like mine. It would be better for me to combine new suggestions into what I've already done than for a dozen branches to break off (except as tests).

 

I wonder how open-source projects manage...

 

All the industries with 2 inputs showed this behavior except for the steel mill which always worked perfectly

 

I need to look at the steel mill again.

 

You got me curious so I did some more tests today and just solved the problem you had with house not recovering their demand for goods! I discovered that, for all the industries (houses included), demand will drop to 0 and never recover if demand value is less than 1.00.  You had set the demand for goods at 0.5 and that was the problem... I changed it to 1.00 and several other values over 1.00 and it worked perfectly....mail production was boosted and even villages with only one or two houses would demand goods and the demand would recover with time. However, the cure might be worse than the illness here because with a demand value of 1.00 even the smallest village will crave for goods so much that the demand is very hard to quell !! with cities and metropolises it is even worse since the overall global city demand is added to all the demands from all the houses!! Might be a balance breaker!

 

Indeed, maybe the one-time "bonus" followed by better-than-nothing demand=0 is reasonable for sub-town villages one wants to stimulate.

 

This also led me to discover that some industries like produce farms or rubber plantations shared the same problem. Demand for fertilizer was set at 0.5....I ran some test and discovered, as I suspected, that demand for fertilizer also stayed tanked at 0

 

I probably copied (or emulated) that modest demand when I created house-demand for goods.

 

I also made a bonus discovery while running tests on this topic:  No matter how high you set the demand for fertilizer, none of the farm will show a demand for fertilizer until you have placed  at least one fertilizer plant on the map!

 

Oh, I'm not sure that's the rule. The farm's own industrial data should place a date on when fertilizer will be demanded. Aside from that, fertilizer might have a date set in a cargo table. See if those aren't the actual constraints.

 

That is, even if you allow the industry in the general settings, then set your ports to produce fertilizer, farm will not demand it as long as there is not at least one fertilizer plant on the map. You CANNOT create a scenario where all fertilizer is produced abroad and shipped in through your ports....there MUST be at least ONE fertilizer factory somewhere.

 

I know that can't be right. I have a map with zero rubber plantations, but rubber is still demanded.

 

Note that the address I gave refers to the Map file, not the EXE file

 

That was obvious from the address. It's way to low to be in the EXE.

 

By the way, I'm french, so I just hope my english is correct enough for you.

 

I think that most of us are Americans, not English, so we're dialectically flexible. If we can understand Texans, then we can understand you too.