1. Is it possible to create an event that triggers when a train arrives at a station?
2. Is it possible to create an event effect that writes to, or appends to, a .csv file of my own creation?
(I like to track my company's performance using MS Access, including stats on each train arrival. I append each train ID# to a Access table along with the year. But arrivals happen so frequently that it becomes cumbersome to watch the arrival screen and add records. Also, there isn't time to add other fields to the table, such as the YYYYMM, station arrived at, the train arrival profit, and the amount paid to other companies for using their track.) I try plan my train routes so that each train arrives at least once per year, and some complete their entire circuit at least once per year, on average.
Also, dumping the EOY Income Statement, Balance Sheet, Haulage, and other reports into tables would save me a lot of data entry at the end of each game year. I could simply create linked tables in MS Access that would read the .csv files that RTII creates.
3. Are there other variables that Events can have access to that are not listed in the map editor drop-down lists? LIke, [Train ID], for example. Or [Station ID].
4. Does the [Territory ID] variable contain ID numbers for cities and regions also, at values above 24?
5. Can I create new AI players, some fictional, including one bearing my own name?
I am writing a very involved scenario map based upon North American history from 1830 to the present, with many historical events represented by newspaper headlines. Several of the events, triggered by YYYYMM, also have effects in the game, such as strikes, wars (which change "country" alliances, and therefore company/territory access), governmental regulations, economic statuses, etc.)
I'm a newbie at these forums, but a longtime RTII player. Thanks for any feedback anyone can offer on these topics.
Map Editing: A few Questions.
Re: Map Editing: A few Questions.
Not directly. All you can do is track loads to and/or revenue to a station. Even then it has to be done by using territories.John Galt wrote:1. Is it possible to create an event that triggers when a train arrives at a station?
No.2. Is it possible to create an event effect that writes to, or appends to, a .csv file of my own creation?
No.3. Are there other variables that Events can have access to that are not listed in the map editor drop-down lists?
No.4. Does the [Territory ID] variable contain ID numbers for cities and regions also, at values above 24?
You can edit the names of the AI players in the language file (RT3.lng). I don't think you can do anything else.5. Can I create new AI players, some fictional, including one bearing my own name?
Complete express car and caboose packs - Custom double tankers (Alternative F era) - Pennsy H3 Consolidation
Слава Україні! Героям слава!
Слава Україні! Героям слава! 
Re: Map Editing: A few Questions.
Wow. And I thought I was disturbingly into micro-management!John Galt wrote:1. Is it possible to create an event that triggers when a train arrives at a station?
2. Is it possible to create an event effect that writes to, or appends to, a .csv file of my own creation?
(I like to track my company's performance using MS Access, including stats on each train arrival. I append each train ID# to a Access table along with the year.
Seriously though, you're asking really interesting questions, and I'm sad to see that Gumboots has already answered: pretty much everything you're hoping to do isn't possible (as I expected, unfortunately)
.It comes down to a big problem with RRT3: it's not open-source, and not written with a view to exposing all its information. Even though it's probably hardly even being sold anymore, no-one can get at the source code and change it - and the people who do own the source code aren't interested in developing it further.
An extensible version of RT3, that could hook into the rest of your OS (to e.g. write the CSVs you'd like), or allow new components to be slotted in (e.g. "on this event, call this method of a DLL I've written to write out the CSV file"), would be an absolutely wonderful thing. While it is possible to add new and fun objects to the game (locos, trains, industries and their buildings), the basic logic of the game just isn't programmable (even in the sense of just providing interfaces for you to get information out of it in a read-only way) beyond a certain point.
There are many users here who've tried hard to dig under the bonnet (US: hood...
) and customise things, and they've got pretty far but only so far before realising that there's nowhere further to go. Nedfumpkin and milo are the names I remember, whose posts on this subject I've read with interest - if they turn up on this thread they may have more detailed information.If it ever looked possible to buy development rights on the disassembled code from the owners, I'd definitely be putting in my >
to help make that happen.Because this game has so much unrealised potential. For example, let's say Passengers are starting to build up at one of your stations. Is this just a blip, or do you need to do something about it (like add some more passenger trains from that station)? How about being able to list all the trains that call at that station - even with a current location and ETA? That would be child's play given access to the data - but RRT3 doesn't have this feature, and doesn't let you write a helper program that would provide it. (If anyone is familiar with Civilisation 3, CivAssist is a great example of this kind of helper - but it has to work on the latest save file, rather than with live information).
Look forward to your scenario when it's ready!
-
RulerofRails
- CEO
- Posts: 2061
- Joined: Sun Dec 08, 2013 1:26 am
Re: Map Editing: A few Questions.
Unfortunately, I don't have good news about those questions. RT3 has some new editor features compared to RTII, but it also lost some of the best stuff too. Perhaps we will never know if this was coding laziness/lack of time, or because it was thought that some of the new features made some of those things less important. I still think the inability to count station to station hauls is a large let down. 
Perhaps a close examination of the saved game format could allow an extract of some of the data you wanted.
Why freight cargo gets re-hauled in RT3:
One of the primary differences between RT3 and RTII is that RT3 cargo doesn't disappear from the map when it is delivered. There is no hidden cache for industries (like you see at two-input industries). Instead, it will be deposited on the station cell. Unless the station is built on the same cell as a demand industry, the cargo must then travel across a cell or two before it reaches it's destination. Once at the industry the cargo remains exposed in what we call a "stack", the size of which has an affect of dynamically lowering the price in that area. It's quite common for some of that stack to get hauled somewhere else before it is converted because RT3 doesn't instantly convert, instead there is a set rate per year which is also slightly influenced by profitability (strength of prices).
For consumer cargoes like Meat, Goods, Textiles, etc. that mostly go straight to houses, no industrial use means that the demands are spread out quite evenly on the map (at least between the cities which will be the main connections). The slow consumption by houses, some of which are a couple of cells away from the station, means that the local price will start falling before houses really get a chance to start consuming the cargo. The overall demand for these things is hard to overwhelm in a city (as indicated by the colors), but the relative demand strength between a city with even just a few loads (2-3) and a nearby city which hasn't had a supply recently (full-strength demand) gives a good price difference (price of delivery) which is the requirement for train profit. This is the main type of re-hauling (the same load of cargo gets hauled many times) that RT3's auto consist manager does.
In RT3 there is no way to keep cars on a train when it stops at a station. The 1.06 patch adds the ability for hauling at a loss which means that you can reload the same cargo you unloaded regardless of the price of delivery, but all cars are counted as begin "delivered" at each station stop. Often the demand radius for an industry extends past a second station, and the journey of the resources to the industry will be split in two completely naturally meaning that the cargo is counted as delivered twice. This applies to other cargoes as well, this is just the simplest example of an automatic instance in which cargo is counted as delivered twice without any player interference.
What it means for freight cargo haulage counts:
The unspecific counts such as total loads hauled in one year or total loads hauled in the companies' lifetime are naturally inflated a large amount by the game's re-hauling tendencies. When we look at the specific one we have (territory to territory), we find that those tendencies weaken the soundness of the count. There are multitudes of ways to "cheat" (auto consist will even help you!) at this count. Because hauling lots of stuff to one location will depress the price there, auto consist might well decide to haul that cargo away to another location. The surrounding prices might get depressed enough that the very same cargo returns after a few more trips round the countryside.
A simple cheat is to use another station that is a few cells away, but still close enough to capture the main stack from the main station at the site of delivery (possibly warehouse/port if there is a provided demand for this haul which is a good idea). By placing this station in the weakest demand area possible it's not unlikely to get a decent little price difference between the two stations. This makes an infinite loop where the same cargo can be recycled endless times, all of which count towards the goal. So this is a problem that the pickup price from a station is from the cell it sits upon, not the actual price of where the cargo is sitting. Even if RT3 had Station to Station counts, this problem wouldn't be fixed.
There is a bug in the territory to territory count where loads hauled within that particular territory are counted. See Oilcan's illustration. For me this is the final straw in the soundness of the haulage counts. A haulage count still requires some effort to make sure it is fulfilled each year which will require extra trains and possibly infrastructure depending on the strategy, but there is less focus on the actual number required. It's probably not wise to make a haulage count one of the main focuses of the game.
Innovative map creators have come up with ways to make enjoyable haulage challenges. These require using up territories and events so for a large, long map they are perhaps not advisable. Currently, Oilcan regularly employs 1.06's math features to give a bonus for each load hauled of a particular cargo, sometimes to any location and other times to a specific one. This is a good example of a way to have haulage as a side goal and not paramount to the game, but an extra task to provide interest. A good idea is to have high demand warehouses (such as 250 loads per year) at a specific destination that will consume the cargo very quickly (example Panama Canal map for 1.06). The cargo is consumed before local price drops due to an over-supplied condition (a stack just sitting waiting for consumption). Auto-consist doesn't get a chance to re-haul this cargo. There are more extreme measures including/combining multiple tactics such as tiny territories just big enough for one station, large enough territories that it's impossible to place another station to capture any of the main stack, math events in 1.06 that subtract any loads hauled away, and having only one demand for a cargo on the map so there isn't another place to haul it. With lots of care it is possible. It's just expensive in terms of territory count and possibilities.
I must note that express cargoes (Troops, Passengers, and Mail) are much more reliable to count. They get special treatment by the game engine.
Other stuff:
My opinion is that individual train stats mean a lot less in RT3 than RTII. Dynamic prices and cargo that moves on it's own make the whole economy automated. There is no way of predicting what is the best (most profitable) load a train will have available when it arrives at a particular time. Without auto consist the game would fall on it's face. You might hear talk of micro-managing but I tend to believe that this means that people are still using auto consist and what they mean is that they are changing the destination of their train instead of the cargo it is hauling. When we choose what cars to put on a train we call that custom consist. I do use some custom consists mainly for supplying particular industries or for haulage related side-goals, but I haven't seen proof that anybody played a whole game that way.
The main part of making a truly enjoyable RT3 map is the seeding. Oilcan does a great job by keeping things simple and clean. Spacing things so that nice price gradients develop across the map naturally. The main part is to control the city seeding so that there aren't many repeat industries in one city or between surrounding cities. We could view this as competition, but the result is the price gradients on the map get contorted and resources are dragged from one industry to another. Not only does this mean erratic production, but it's also hard to plan what to do with the supply if you have to plan for it potentially coming from two locations. A RT3 game can include a complete plan for all the resources on the map. Industries can be built and bought to maximize use of resources providing a plethora of cargo to keep many trains running at full capacity. Even if no industry building or buying is allowed, RT3 as a train game is still all about supplying industries with resources.
Unfortunately, the price modifier events for RT3 are bugged as well.
At this stage I suspect that there is a bug not in the events themselves, but in the formulas for demand transmission between stations. Somehow, when the game determines the price increase from trains servicing a particular station, the modified price doesn't come through properly and we see wild price outbreaks that disrupt the normal flow of cargo. Unfortunately, those formulas are sure to be locked in the exe file.
This leaves cargo production modifiers (which are rock solid) as most useful for creating any sort of industrial economy boost or restriction. These work over the whole game, or by territory or by company so there are many ways to use them to good effect to change the dynamics of the cargo mix available to an established company.
Looking forward to your map. Don't get discouraged with RT3. There are lots of players here that love it despite it's flaws.
Perhaps a close examination of the saved game format could allow an extract of some of the data you wanted.
Why freight cargo gets re-hauled in RT3:
One of the primary differences between RT3 and RTII is that RT3 cargo doesn't disappear from the map when it is delivered. There is no hidden cache for industries (like you see at two-input industries). Instead, it will be deposited on the station cell. Unless the station is built on the same cell as a demand industry, the cargo must then travel across a cell or two before it reaches it's destination. Once at the industry the cargo remains exposed in what we call a "stack", the size of which has an affect of dynamically lowering the price in that area. It's quite common for some of that stack to get hauled somewhere else before it is converted because RT3 doesn't instantly convert, instead there is a set rate per year which is also slightly influenced by profitability (strength of prices).
For consumer cargoes like Meat, Goods, Textiles, etc. that mostly go straight to houses, no industrial use means that the demands are spread out quite evenly on the map (at least between the cities which will be the main connections). The slow consumption by houses, some of which are a couple of cells away from the station, means that the local price will start falling before houses really get a chance to start consuming the cargo. The overall demand for these things is hard to overwhelm in a city (as indicated by the colors), but the relative demand strength between a city with even just a few loads (2-3) and a nearby city which hasn't had a supply recently (full-strength demand) gives a good price difference (price of delivery) which is the requirement for train profit. This is the main type of re-hauling (the same load of cargo gets hauled many times) that RT3's auto consist manager does.
In RT3 there is no way to keep cars on a train when it stops at a station. The 1.06 patch adds the ability for hauling at a loss which means that you can reload the same cargo you unloaded regardless of the price of delivery, but all cars are counted as begin "delivered" at each station stop. Often the demand radius for an industry extends past a second station, and the journey of the resources to the industry will be split in two completely naturally meaning that the cargo is counted as delivered twice. This applies to other cargoes as well, this is just the simplest example of an automatic instance in which cargo is counted as delivered twice without any player interference.
What it means for freight cargo haulage counts:
The unspecific counts such as total loads hauled in one year or total loads hauled in the companies' lifetime are naturally inflated a large amount by the game's re-hauling tendencies. When we look at the specific one we have (territory to territory), we find that those tendencies weaken the soundness of the count. There are multitudes of ways to "cheat" (auto consist will even help you!) at this count. Because hauling lots of stuff to one location will depress the price there, auto consist might well decide to haul that cargo away to another location. The surrounding prices might get depressed enough that the very same cargo returns after a few more trips round the countryside.
A simple cheat is to use another station that is a few cells away, but still close enough to capture the main stack from the main station at the site of delivery (possibly warehouse/port if there is a provided demand for this haul which is a good idea). By placing this station in the weakest demand area possible it's not unlikely to get a decent little price difference between the two stations. This makes an infinite loop where the same cargo can be recycled endless times, all of which count towards the goal. So this is a problem that the pickup price from a station is from the cell it sits upon, not the actual price of where the cargo is sitting. Even if RT3 had Station to Station counts, this problem wouldn't be fixed.
There is a bug in the territory to territory count where loads hauled within that particular territory are counted. See Oilcan's illustration. For me this is the final straw in the soundness of the haulage counts. A haulage count still requires some effort to make sure it is fulfilled each year which will require extra trains and possibly infrastructure depending on the strategy, but there is less focus on the actual number required. It's probably not wise to make a haulage count one of the main focuses of the game.
Innovative map creators have come up with ways to make enjoyable haulage challenges. These require using up territories and events so for a large, long map they are perhaps not advisable. Currently, Oilcan regularly employs 1.06's math features to give a bonus for each load hauled of a particular cargo, sometimes to any location and other times to a specific one. This is a good example of a way to have haulage as a side goal and not paramount to the game, but an extra task to provide interest. A good idea is to have high demand warehouses (such as 250 loads per year) at a specific destination that will consume the cargo very quickly (example Panama Canal map for 1.06). The cargo is consumed before local price drops due to an over-supplied condition (a stack just sitting waiting for consumption). Auto-consist doesn't get a chance to re-haul this cargo. There are more extreme measures including/combining multiple tactics such as tiny territories just big enough for one station, large enough territories that it's impossible to place another station to capture any of the main stack, math events in 1.06 that subtract any loads hauled away, and having only one demand for a cargo on the map so there isn't another place to haul it. With lots of care it is possible. It's just expensive in terms of territory count and possibilities.
I must note that express cargoes (Troops, Passengers, and Mail) are much more reliable to count. They get special treatment by the game engine.
Other stuff:
My opinion is that individual train stats mean a lot less in RT3 than RTII. Dynamic prices and cargo that moves on it's own make the whole economy automated. There is no way of predicting what is the best (most profitable) load a train will have available when it arrives at a particular time. Without auto consist the game would fall on it's face. You might hear talk of micro-managing but I tend to believe that this means that people are still using auto consist and what they mean is that they are changing the destination of their train instead of the cargo it is hauling. When we choose what cars to put on a train we call that custom consist. I do use some custom consists mainly for supplying particular industries or for haulage related side-goals, but I haven't seen proof that anybody played a whole game that way.
The main part of making a truly enjoyable RT3 map is the seeding. Oilcan does a great job by keeping things simple and clean. Spacing things so that nice price gradients develop across the map naturally. The main part is to control the city seeding so that there aren't many repeat industries in one city or between surrounding cities. We could view this as competition, but the result is the price gradients on the map get contorted and resources are dragged from one industry to another. Not only does this mean erratic production, but it's also hard to plan what to do with the supply if you have to plan for it potentially coming from two locations. A RT3 game can include a complete plan for all the resources on the map. Industries can be built and bought to maximize use of resources providing a plethora of cargo to keep many trains running at full capacity. Even if no industry building or buying is allowed, RT3 as a train game is still all about supplying industries with resources.
Unfortunately, the price modifier events for RT3 are bugged as well.
At this stage I suspect that there is a bug not in the events themselves, but in the formulas for demand transmission between stations. Somehow, when the game determines the price increase from trains servicing a particular station, the modified price doesn't come through properly and we see wild price outbreaks that disrupt the normal flow of cargo. Unfortunately, those formulas are sure to be locked in the exe file.This leaves cargo production modifiers (which are rock solid) as most useful for creating any sort of industrial economy boost or restriction. These work over the whole game, or by territory or by company so there are many ways to use them to good effect to change the dynamics of the cargo mix available to an established company.
Looking forward to your map. Don't get discouraged with RT3. There are lots of players here that love it despite it's flaws.
Re: Map Editing: A few Questions.
That's a whole lot of fantastic information in your post - thanks!
This sounded familiar to me:
This sounded familiar to me:
I took a look into this in this thread: viewtopic.php?f=31&t=2217&p=21121#p21121. Price modifiers are confusing, and definitely bugged!RulerofRails wrote: Unfortunately, the price modifier events for RT3 are bugged as well.
-
RulerofRails
- CEO
- Posts: 2061
- Joined: Sun Dec 08, 2013 1:26 am
Re: Map Editing: A few Questions.
Yep, we're talking about the same thing. Valuable testing information there. My theory about the stations is just a theory. I have no definite proof. If price modifiers are not super strong (lower value of increase) and short-term for just a year or so, price spikes often don't have time to appear.
I have never seen price holes in my experience. I have never tested for them and there seems to be little evidence of them. Maybe this is due to fewer decrease events being used. I do remember that Nedfumpkin wrote about prices bottoming out in one of his test maps, but I believe he was using heaps of events and effects may have been applied too many times.
This leaves the possibility that all the freight .cgo files could have their prices modified upwards, and then a standardized reduction event used at the start of the scenario to return things to normal. Then slight modifiers could be used to control prices, hopeful without spikes. Would need testing and careful calculations for the math. Maybe if prices are always below "normal" the game will never think it needs to increase some more (causing the outbreak). There's nothing for it, but modding some cgo files and testing it out. If it's looking promising I will upload a test-case map.
I have never seen price holes in my experience. I have never tested for them and there seems to be little evidence of them. Maybe this is due to fewer decrease events being used. I do remember that Nedfumpkin wrote about prices bottoming out in one of his test maps, but I believe he was using heaps of events and effects may have been applied too many times.
This leaves the possibility that all the freight .cgo files could have their prices modified upwards, and then a standardized reduction event used at the start of the scenario to return things to normal. Then slight modifiers could be used to control prices, hopeful without spikes. Would need testing and careful calculations for the math. Maybe if prices are always below "normal" the game will never think it needs to increase some more (causing the outbreak). There's nothing for it, but modding some cgo files and testing it out. If it's looking promising I will upload a test-case map.