Feeder systems are great!
Moderator: OpenTTD Developers
- Henkie
- Engineer
- Posts: 46
- Joined: 09 Oct 2004 14:37
- Location: Zeelst, Veldhoven, Netherlands
- Contact:
Feeder systems are great!
The new feeder system (transfer in the order list). Is a very handy option, that is included in the newest nigthly build (http://nightly.openttd.org/) (Build 2444). Now i can build vast sytems without the need to connect every raw industrie with another industrie using long tracks with large numbers of station's and trains.
Look at the save game (you need the nightly build installed) to see what i have build in a short time.
Very nice feature Devs
P.S. sorry i needed too use the cheats for money couldn't wait
Look at the save game (you need the nightly build installed) to see what i have build in a short time.
Very nice feature Devs
P.S. sorry i needed too use the cheats for money couldn't wait
- Attachments
-
- Uitricht Transport, 23rd Feb 1981.sav
- First try with feedersystems
- (215.68 KiB) Downloaded 189 times
Last edited by Henkie on 16 Jun 2005 15:25, edited 1 time in total.
Houdoe
Henkie
P.S. I like playing with trains.
Henkie
P.S. I like playing with trains.
screenshots please!
james
james
(British) Modular Stations Set - Thread: | Website:
Swiss Set - Thread: | Website:
Route Map Creator
My Screenshot Thread
Swiss Set - Thread: | Website:
Route Map Creator
My Screenshot Thread
- Henkie
- Engineer
- Posts: 46
- Joined: 09 Oct 2004 14:37
- Location: Zeelst, Veldhoven, Netherlands
- Contact:
By request some screenshots
- Attachments
-
- View with shuttle trains
- Uitricht Transport, 24th Oct 1981.png (95.53 KiB) Viewed 765 times
-
- View with pass on to the next train
- Uitricht Transport, 1st Nov 1981.png (115.31 KiB) Viewed 802 times
-
- orderlist
- Uitricht Transport, 11th Nov 1981.png (87.57 KiB) Viewed 910 times
Houdoe
Henkie
P.S. I like playing with trains.
Henkie
P.S. I like playing with trains.
Good job!
I do wonder how it is determined how much profit a transfering train makes when it drops the load for pickup by another train, however at least now income at least goes to all trains involved in transporting the cargo instead of giving all to the train that delivered it to the destination =)
-Abraxa
I do wonder how it is determined how much profit a transfering train makes when it drops the load for pickup by another train, however at least now income at least goes to all trains involved in transporting the cargo instead of giving all to the train that delivered it to the destination =)
-Abraxa
Nice system Henkie!
I like the way that works, i might give it a go sometime.
Cheers
James
I like the way that works, i might give it a go sometime.
Cheers
James
(British) Modular Stations Set - Thread: | Website:
Swiss Set - Thread: | Website:
Route Map Creator
My Screenshot Thread
Swiss Set - Thread: | Website:
Route Map Creator
My Screenshot Thread
I'm sorry to say... But the entire system is completely broken. And I'm afraid that's not a bug, but a fundamental design flaw.
A feeder train gets 'virtual' money. The money is not real, but it's shown in his profit. The money is just based on the price of getting goods from the first station to the transit station, it has no basis in reality. The train who brings goods the rest of the way gets payed for bringing goods from the original source to the final destination. So basicly you get paid twice for the same cargo. Only virtually the first time, so there's no real money gain, but your profit graph will basicly go fubar. I checked, but the money gain by the first train isn't deducted from the second train's profit.
Now you could call that a bug. But the problem is much more fundamental. I just tried building a coal mine and power plant next to eachother. Feed the coals to a station on the other side of the map, and bring them back. That works, you get payed heaps.
It becomes worse when you feed a station by multiple lines. Or when the station is supplied in the normal way by an industry as well. Only the latest source counts. So if 239 tons of coal in your train come from halfway the map, and the final ton comes from nearly, you get payed next to nothing. That... sucks. And the other way around is possible as well. If you have a very productive normal industry next to your feeder station (which many will have. Since next to an already existing producer is a logical place for a feeder station), this one will almost always be the one to fill the train. So the extra distance covered by your feeders is lost...
A feeder train gets 'virtual' money. The money is not real, but it's shown in his profit. The money is just based on the price of getting goods from the first station to the transit station, it has no basis in reality. The train who brings goods the rest of the way gets payed for bringing goods from the original source to the final destination. So basicly you get paid twice for the same cargo. Only virtually the first time, so there's no real money gain, but your profit graph will basicly go fubar. I checked, but the money gain by the first train isn't deducted from the second train's profit.
Now you could call that a bug. But the problem is much more fundamental. I just tried building a coal mine and power plant next to eachother. Feed the coals to a station on the other side of the map, and bring them back. That works, you get payed heaps.
It becomes worse when you feed a station by multiple lines. Or when the station is supplied in the normal way by an industry as well. Only the latest source counts. So if 239 tons of coal in your train come from halfway the map, and the final ton comes from nearly, you get payed next to nothing. That... sucks. And the other way around is possible as well. If you have a very productive normal industry next to your feeder station (which many will have. Since next to an already existing producer is a logical place for a feeder station), this one will almost always be the one to fill the train. So the extra distance covered by your feeders is lost...
Updated to nightly . . .
COOL!
But . . .
NO NO NOoooooo!!!!!!
All my trains are crashing now!!!!!!!!
Somebody royally messed up the signals . They stay green even when they should become red.
COOL!
But . . .
NO NO NOoooooo!!!!!!
All my trains are crashing now!!!!!!!!
Somebody royally messed up the signals . They stay green even when they should become red.
"If a man does not keep pace with his companions, perhaps it is because he hears a different drummer. Let him step to the music he hears, however measured or far away" --Henry David Thoreau
the first part is done better in ttdpatch, the second part was even a problem with normal ttd (using unload order).Diadem wrote:I'm sorry to say... But the entire system is completely broken. And I'm afraid that's not a bug, but a fundamental design flaw.
A feeder train gets 'virtual' money. The money is not real, but it's shown in his profit. The money is just based on the price of getting goods from the first station to the transit station, it has no basis in reality. The train who brings goods the rest of the way gets payed for bringing goods from the original source to the final destination. So basicly you get paid twice for the same cargo. Only virtually the first time, so there's no real money gain, but your profit graph will basicly go fubar. I checked, but the money gain by the first train isn't deducted from the second train's profit.
Now you could call that a bug. But the problem is much more fundamental. I just tried building a coal mine and power plant next to eachother. Feed the coals to a station on the other side of the map, and bring them back. That works, you get payed heaps.
It becomes worse when you feed a station by multiple lines. Or when the station is supplied in the normal way by an industry as well. Only the latest source counts. So if 239 tons of coal in your train come from halfway the map, and the final ton comes from nearly, you get payed next to nothing. That... sucks. And the other way around is possible as well. If you have a very productive normal industry next to your feeder station (which many will have. Since next to an already existing producer is a logical place for a feeder station), this one will almost always be the one to fill the train. So the extra distance covered by your feeders is lost...
Creator of the Openttd Challenge Spinoff, Town Demand patch
After action reports: The path to riches, A dream of skyscrapers
After action reports: The path to riches, A dream of skyscrapers
- latinoloco
- Transport Coordinator
- Posts: 315
- Joined: 24 Apr 2005 23:06
- Location: Sydney, Australia
I think the first vehicle should get a ratio of getting the goods there.
Like train X goes from factory (with goods) to ouskirts of big city C. Bus Y goes from the ouskirts of city C to the inner city. If the train traveled 9/10ths of the way, it should get 9/10ths of the money. And the bus (obviously) 1/10th. Its calculated by the time it took for the goods to travel that ammount of squares.
Like train X goes from factory (with goods) to ouskirts of big city C. Bus Y goes from the ouskirts of city C to the inner city. If the train traveled 9/10ths of the way, it should get 9/10ths of the money. And the bus (obviously) 1/10th. Its calculated by the time it took for the goods to travel that ammount of squares.
Sounds simple, unworkable however. Consider, at the time you deliver goods from source A to feeder station B, you have no idea where the final destination C is. So, you don't know it's "9/10ths" of the way anywhere. So, to account for it, each and every unit of items (like an individual cow) would need to remember where it came from so that you can compute the ratio of delivery when it finally does get revenue.latinoloco wrote:I think the first vehicle should get a ratio of getting the goods there.
Like train X goes from factory (with goods) to ouskirts of big city C. Bus Y goes from the ouskirts of city C to the inner city. If the train traveled 9/10ths of the way, it should get 9/10ths of the money. And the bus (obviously) 1/10th. Its calculated by the time it took for the goods to travel that ammount of squares.
Since you don't know the ratio until the final delivery, you'd also have to retain, for each and every unit of items would also need to retain which train brought them to the feeder station so they could properly credit the correct train when you finally do get the revenue.
Plus, as was stated before, you have do to this for each and every unit individually to avoid the "co-mingling" that happens if the feeder station gets items from many source stations and/or is supplied by a local industry itself. The system just globs together all the items at the feeder station.
So, as was stated before, the basic design of the economy doesn't support proper accountiing for a feeder system. Doesn't mean you can't have fun with it and create neat rail networks, you just can't be anal-retentive about the money.
mega rail: doesn't work. If you take 200 tonnes of coal from station a to station b, then another train takes it from station b to station c, and a third takes it back to station a, you have an infinite loop where you keep getting paid for carting stuff around without it getting anywhere...
Whilst that might be realistic, what with EU subsidies and so on, it probably isn't what the game should be doing
Whilst that might be realistic, what with EU subsidies and so on, it probably isn't what the game should be doing
mpettitt wrote:Whilst that might be realistic, what with EU subsidies and so on, it probably isn't what the game should be doing
What about the simple way: wait until the cargo is delivered and then calculate the price to pay and split the profit through all involved parties?
And to make sure you don't cheat the system why not calculate the distance beetween the source and the destiny (in a direct line) instead of the tiles the cargo travelled?
Uncle Dex Says: Follow the KISS Principle!
Again, simple idea, doesn't work. Consider a Coal Mine next to a Power Station. To use your idea, I should run a feeder service from to coal mine to another station, say 100 squares away. Get 100 squares of money. Then, have another train bring it 100 squares back to the original station and get paid for 100 squares of money.mega rail wrote:if the feed train moves 200 tons of coal 20 squares from A to B it should get paid for that.
and the train that takes the coal the other 20 spuarres gets paid only for the 20 squares it travveald
How would that compare to using a truck to bring it one square from the mine to the power station.
Again, this is the kind of tweak that isn't supported by the basic economy model. Still, makes for some cute rail networks.
I tested some more, and found a worse problem. It looks like this patch broke the entire feeding system. If you deliver coal to a station the station says 'xxx tons of coal en-route from blabla'... However the moment a train actually picks up the cargo the source becomes the station the train is picking it up from. And you get payed for that distance. So the entire original lenght is lost. Not only if you have multiple sources, but even with 1 source already.
Now I thought a lot about possible solutions. The conclusion is that there is no perfect solution. At least not one that can be implemented easily. To pay every train for the amount is was involved means either too much to keep track of, or too much to calculate.
However, we can use implementation from the current patch. The feeder systems get payed in virtual money. It shows in their profit, but you don't actually get it. The money shows in yellow in the map, and you can probably show the profit of such trains in yellow as well on the train listing.
However, the next part we change. On a station we don't just use one source. So the list on station foo would read: "x tons of coal from foo", "y tons of coal en-route from bar", "z tons of coal en-route from baz", etc. Basicly a linked list of sources. Same in the train when you pick it up. And when you deliver it, you pay for seperate sources seperately, based on overal station distance.
Now I thought a lot about possible solutions. The conclusion is that there is no perfect solution. At least not one that can be implemented easily. To pay every train for the amount is was involved means either too much to keep track of, or too much to calculate.
However, we can use implementation from the current patch. The feeder systems get payed in virtual money. It shows in their profit, but you don't actually get it. The money shows in yellow in the map, and you can probably show the profit of such trains in yellow as well on the train listing.
However, the next part we change. On a station we don't just use one source. So the list on station foo would read: "x tons of coal from foo", "y tons of coal en-route from bar", "z tons of coal en-route from baz", etc. Basicly a linked list of sources. Same in the train when you pick it up. And when you deliver it, you pay for seperate sources seperately, based on overal station distance.
Hi
Well, the I'm pretty much aware of the problem with the payments, but with the current implementation of cargoes in general there is hardly any solution. However, we're just trying to find out how to implement things a better way so that source stations don't get lost, and that will enable us to implement destinations as well, but you gotta be patient.
Celestar
Well, the I'm pretty much aware of the problem with the payments, but with the current implementation of cargoes in general there is hardly any solution. However, we're just trying to find out how to implement things a better way so that source stations don't get lost, and that will enable us to implement destinations as well, but you gotta be patient.
Celestar
I think it would be pretty easy to add an Station *original_source and TileIndex original_tile to the cargo struct carried. The original_source would ALWAYS keep the station where the cargo was picked up (original_tile is just in case the station was destroyed. Perhaps this is enough all by itself since you can just do GetStationFromTile(original_tile) to get the station) and calculate any net profit starting from that source. This would eliminate the A->B->A huge profit bug.
Also about the virtual profit, a TTDPatch style calculation would be ok I guess. Vehicle delivers cargo from A->B and gets profit. Vehicle picks up cargo from B and gets a virtual loss the amount of profit A->B made. So on and on, until the final delivery when you are actually paid.
Also about the virtual profit, a TTDPatch style calculation would be ok I guess. Vehicle delivers cargo from A->B and gets profit. Vehicle picks up cargo from B and gets a virtual loss the amount of profit A->B made. So on and on, until the final delivery when you are actually paid.
TrueLight: "Did you bother to read any of the replies, or you just pressed 'Reply' and started typing?"
<@[R-Dk]FoRbiDDeN> "HELP, this litte arrow thing keeps following my mouse, and I can't make it go away."
<@[R-Dk]FoRbiDDeN> "HELP, this litte arrow thing keeps following my mouse, and I can't make it go away."
What you're saying Darkvater is pretty much exactly what i'm saying isn't it?
It's the obvious solution. And it should be doable. You'd have to keep track of multiple sources for one train. And when a source gets split you have to make sure you don't deduct the full virtual profit, but only as much as the trains picked up. Few more things like that, but it's all doable.
It's the obvious solution. And it should be doable. You'd have to keep track of multiple sources for one train. And when a source gets split you have to make sure you don't deduct the full virtual profit, but only as much as the trains picked up. Few more things like that, but it's all doable.
the only problem is, what happens if you have 3 loads of coal from different mines arriving at a feeder station?Darkvater wrote:I think it would be pretty easy to add an Station *original_source and TileIndex original_tile to the cargo struct carried. The original_source would ALWAYS keep the station where the cargo was picked up (original_tile is just in case the station was destroyed. Perhaps this is enough all by itself since you can just do GetStationFromTile(original_tile) to get the station) and calculate any net profit starting from that source. This would eliminate the A->B->A huge profit bug.
Also about the virtual profit, a TTDPatch style calculation would be ok I guess. Vehicle delivers cargo from A->B and gets profit. Vehicle picks up cargo from B and gets a virtual loss the amount of profit A->B made. So on and on, until the final delivery when you are actually paid.
Perhaps you could simply display all the loads of coal separately.
But then what do you do if a train arrives that needs to take those loads along?
Creator of the Openttd Challenge Spinoff, Town Demand patch
After action reports: The path to riches, A dream of skyscrapers
After action reports: The path to riches, A dream of skyscrapers
There can be 3 possible options.
1. Last delivered cargo takes over all sources (eg as it is now, I have X cargo from A, Y cargo from B arrives, now I have X+Y cargo from B)
2. Take an average of the distances since the source to even things out
3. implement full seperation of inter-cargo sources. Most difficult to do and you still have to set some limit on how much cargo of the same type with different distances are available.
Of course the easiest solution is to rework the cargo handling since distances don't have much to do with payment
1. Last delivered cargo takes over all sources (eg as it is now, I have X cargo from A, Y cargo from B arrives, now I have X+Y cargo from B)
2. Take an average of the distances since the source to even things out
3. implement full seperation of inter-cargo sources. Most difficult to do and you still have to set some limit on how much cargo of the same type with different distances are available.
Of course the easiest solution is to rework the cargo handling since distances don't have much to do with payment
TrueLight: "Did you bother to read any of the replies, or you just pressed 'Reply' and started typing?"
<@[R-Dk]FoRbiDDeN> "HELP, this litte arrow thing keeps following my mouse, and I can't make it go away."
<@[R-Dk]FoRbiDDeN> "HELP, this litte arrow thing keeps following my mouse, and I can't make it go away."
Who is online
Users browsing this forum: No registered users and 23 guests