Idea: Improve acceptance of goods in terms of realism

[Picahulu]

hmm .. close but not really
that would be a similar approach but it has following flaw: if the far away source delievers first in the month, then it will "block" the delievery of local supply (e.g. make it less profitable).

the basic idea is : industry should prefer local (=cheap) supply and only accept expensive supply as far as local doesn't fulfill its whole(!!) demand. this might be realized in a different way than suggested, though.

[Xander]

Which was exactly the flaw I was going to point out if you had said "yes"

I can appreciate the idea, but I think you'd be better off looking into the subsidy system. It would be Much easier to reward local suppliers than punish long distance ones, mainly as subsidies can easily tap into the map system and don't need to have things like supply caps and working out how close/far something has travelled before allocating money providing the market hadn't already been flooded!

[Bilbo]

The problem is, that even x4 sub sidy on 50 tiles won't make the thing more profitable than long route for 800 tiles :)

I think we don't need to completely block delivery from far away if there is nearby source, just put some simple measure so the delivery from far away will have significant disadvantage if someone is delivering from nearby source.

[Picahulu]

well, the subsidys.. in online games, they are hardly accepted, because even with factor 3 or 4 its just more profitable to build a ridiculously long route.
which is sort of "abusive" as bilbo stated well.

edit: bilbo was faster

[Serpentbane]

I might be thinking wrong here but I see problems with this, but the result would be several small networks that handle all cargo types in a very local area, with the last receiving industry as the network center. Because you would have to find this last industry in the chain, and the closest supplier to this industry, and then again the closest supplier to that industry, and so on until you reach the first one in the chain.

If you chose the wrong industry somewhere an opponent could in reality ruin your whole network just by being the closest supplier to one of the industries in your network.

You built the following network, and thought you found the closest supplying industry all the way.

It would be like this.

A -> B -> C -> D -> E

Where A is the first industry in the chain, coal mine, sand pit etc, and E is a city or some kind of last link industry. You are happy, you built this nice network.
Then Player 2 discovers a 2nd industry C closer to D, maybe one is just founded right by. Player 2 goes to work, and D no longer accepts cargo from your C.

With advanced networks this would be really fun. Not! Or, not in my view at least.

This could also happen if you begin at A, builds a track to the closest B, and then to the closest C, but when you plan on building a track to the closest D you discover a 2nd C that is closer to D than your C so goods from your C would not be accepted, but that C is not closer to your B.

So you would always have to start building/planning with the last industry in the chain, or this idea is not possible.



Also, sometimes you already have a network ready, why should a train not be able to bring cargo from far away industries instead of going back empty. In real life this would not be the case either...

[Xander]

I'd suggest cracking open the cargo payment file and changing the penalty for late delivery but then on the larger maps the nearest source is still so far away that the late penalties would kick in.

I'll be honest, this system would require an enormous amount of work (establishing nearest sources, deciding what to do if there is an equidistance for a source, dealing with further than local travel, implementing the numbers in a way that the game remains fun for anything other than truck drivers, coping with two deliveries at the same time, dealing with how the transfer system might mess up the movements etc. etc.) for so little return (punished for moving goods more than they have to be) that the only way it'll be implemented is if Picahulu does it themselves.

But good luck, if you pull it off you should consider applying to be a full time dev

[Conditional Zenith]

I'd suggest cracking open the cargo payment file and changing the penalty for late delivery but then on the larger maps the nearest source is still so far away that the late penalties would kick in.

I'll be honest, this system would require an enormous amount of work (establishing nearest sources, deciding what to do if there is an equidistance for a source, dealing with further than local travel, implementing the numbers in a way that the game remains fun for anything other than truck drivers, coping with two deliveries at the same time, dealing with how the transfer system might mess up the movements etc. etc.) for so little return (punished for moving goods more than they have to be) that the only way it'll be implemented is if Picahulu does it themselves.

But good luck, if you pull it off you should consider applying to be a full time dev

I don't usually say this, but I think you are seriously overestimating the amount of work involved.

Establishing the closest source is almost trivial for anyone familiar with the OTTD code base who has done more than a token amount of coding. Equidistant sources can easily be solved by treating them the same for acceptance purposes. The numbers are already screwed up to a point where the game is not fun (at least for many people), this will probably not make it worse. The transfer system already handles single deliveries containing cargo from multiple sources. And one delivery's acceptance and payment will always be dealt with in it's entirety before the next is considered, even if they occur in the same tick.

[Picahulu]

Establishing closest source isn't needed anyway - it can be handled by delievery price per unit which is known to the game anyway. => "the cheaper, the better". quite simple, the industry just needs to remember the prices paid before and decide on that base.

Serpentbane's contra-argument seems way more elaborated to me. I'll think about this and reply later.

[uzytkownik]

I thought about something similar. May be the price paid should be determined by the nearest industry. I don't know OTTD code but I guess it should not be hard as determining nerest industry is easy (at least it was stated so) and there is no need to remember prices etc.

Possible modifications:
- Nearest working industry (i.e. industry to which products are delivered) - industry is interesting in delivery of cargo so it have to order it somewhere
- Nearest industry from which below x% of production is taken - industry 'understends' that no cheaper good is avaible
- Nearest working industry from which below x% of production is taken

[Bilbo]

This would require industry to "scan" the map for surrounding industries, and that could take quite lot of CPU time, especially on large maps.

I think that whatever is used, it should not require ther industry to know about "outside world". What about this:

Each industry will have some distance limit, initially at lenght from one corner of the map to another. If the industry stockpile is full, then the limit start to gradually decrease. If the industry stockpile is empty, it will start to increase.
To avoid the limit getting to zero, industry will remember the shortest distance from which the goods were ever delivered to that industry and will never go below that.

Goods from above the limit would either be rejected, or would be paid same, as if they were delivered from distance equal to the limit.

[Conditional Zenith]

This would require industry to "scan" the map for surrounding industries, and that could take quite lot of CPU time, especially on large maps.

Surely a better way would be to loop through the industries rather than loop through map tiles.

[Bilbo]

That is O(n^2) when regarding count of industries - if every industry will loop through every other industry to determine something every few moments, the game would be really slow on large maps where you can easily have thousands of industries.

For this to work you'll have to create some network graph over industries or some cache or some other structure allowing you to examine only nearby industries in reasonable amount of time.

[Conditional Zenith]

Well only industries that accept something will have to loop through the other industries, that slightly improves the situation.

But I don't see why this should have to happen "every few moments". Surely this would only be checked when something is delivered (or maybe when the player brings up the industry window or the AI queries it), at least for every implementation I have seen suggested here.

And yes, it will cost cycles, it is just a question of whether it is worth the number of cycles it costs for the benefit gained.

However, I think your proposed solution works well, with one problem:

Industry X accepts cargo, A, supplies it. Someone delivers cargo from A to X, the distance is 50 tiles. Industry A closes and the next nearest industry is 100 tiles away. Now the industry effectively has a permanently lowered stockpile limit until a new industry appears which is <= 50 tiles from X.

Essentially, by unreliably caching information about the outside world instead of looking it up, the industries could end up behaving based on outdated information.

Instead of caching the distance, it would perhaps be better to cache the industry. Then every time and industry closes, we can see if any industries need their cache invalidated. There would be strange behaviour for a while (an industry might reject all possible sources until the limit increased to a point where a delivery could be made), but it would be temporary.

[Eddi]

But I don't see why this should have to happen "every few moments". Surely this would only be checked when something is delivered [...]

let me do an example calculation here.

let's assume there are 1000 vehicles in the game (not unusual for a coop game)
let's also assume each vehicle delivers something once per year. (to not get spammed with 'unprofitable' warnings)

that means there is a delivery every 365 [days per year] * 74 [ticks per day] / (1000 [deliveries per year]) ~= 27 ticks
this means there is a delivery about every second.

so what again do you consider "a few moments"?

[Conditional Zenith]

Well that would be one industry looping though every industry every few moments, not every industry looping though every industry every few moments.

Yes, I know this would still eat lots of cycles, but I don't see an O(n^2) operation every few moments with any sane way to implement this idea.

[Eddi]

still, even if it is O(n), this is precisely the kind of operation that was to be avoided in the design of cargodest, where the routing graph only changes upon user interaction, which, in case of industries could mean founding/closing of industries.

so basically, this could mean that each industry has a list of potential suppliers, and can for example alter the transporting fees by some more or less random weight.

e.g. a power station could pay 50% more if the coal comes from coal mine A, standard rates from B and C, and 25% less from D.

this could work similar to the subsidy factor, only it would be more permanent.

[Dave]

Surely in terms of deliveries and slowing down the computer it can be established at the start of the game:

The game pays more if it comes a long distance (eg: the cargo payment table says that the payment is for cargo over 20 squares) - surely, then, it'd be possible (since it already does it) to note the amount of squares travelled, and pay different rates depending on how far it has come.

However, maybe changing payment so it's the same payment per unit regardless of where it comes from is good, as this means that local services wuld be much more profitable - if you ran a 20 wagon coal train across a map for an income of 15,000, but the running cost is 15,000 - no profit. The same train across a distance of 20-30 squares for an income of 15,000 but for a quarter of the running cost (or whatever) would be much more profitable. Obviously this wouldn't work for passengers and mail which are paid for distance travelled anyway.

Still though, surely it'd be possible to remove the correlation between how much a train earns based on how far it travels.

This would pretty much answer the problem without increasing CPU.

[Conditional Zenith]

There are still ways of doing this that don't eat lots of CPU, it's just some of uzytkownik's ideas would require eating lots of CPU.

Still, I think you have pointed out a large part of the competing desires some players have:
* We don't like being able to decide that an industry will get cargo from the other side of the map, and pay for that, when there is a much closer source.
* It's just intuitive that you get paid more for delivering from further away.

Anyway, your suggestion pretty much inverts the problem, short routes are now very profitable and long routes are unprofitable. This aligns nicely with the "Industries should prefer close sources" principle as long as there is a close source. If there isn't a close source, this quickly becomes unfun.

[belugas]

Which comes back to a principle that is well known: pushing realism in the game for the sake of realism is BORING!

[andythenorth]

The conceptually simple (but not simple to implement) solution is that industries place orders (long term contracts) for input cargos with other industries.

The player then constructs routes / provides vehicles on existing routes to deliver according to those 'orders'.

I don't mean we have to draw a little scroll graphic for popup notification of 'orders' or any nonsense like that, I simply mean that for any given cargo, industries only accept that cargo from their preferred supplier(s). Orders would be stable and long term.

This addresses the core problem, that the game rewards players for acting in a way that is both unrealistic (not a problem), but also counter-intuitive to the sense of economic efficiency and good sense that many of us have (reduces enjoyment = problem). Transporting goods from a source far away when there is a source nearby just *seems wrong* to many of us, yet the game *explicitly* rewards it for most cargos. On the other hand, lots of players seem to be fine with it, accepting it as part of the game world.

In fact, if we did take the realism argument, freight companies typically charge per ton-mile, so it's correct to be rewarded for distance travelled. The problem is that the game world provides no rationale for industries accepting goods from a distant source when there is a close source.

So one solution would be to change the game world to provide a rationale for this counter-intuitive demand. i.e. we transport the goods because the industry requests it (we are a transport industry after all, not a manufacturing conglomerate). Customer has a need, we meet it. That's understandable, right?

Orders could be placed with suppliers chosen at random from the list of available industries, but weighted to favour nearby industries. The orders could be placed/replaced on an occasional basis, for example whenever an industry opens or closes, or as part of whatever events system that the production callback uses (I haven't read the code even though I have it checked out, slap me). This should be relatively undemanding on CPU use (I have no idea if this is true, it's just an assertion, slap me).

I would envisage an 'order' being a simple mapping of cargo type, supplier, destination. There would be no quantity - any stockpiling/production control behaviour is already correctly handled by newgrf. Price would be determined by the existing cargo payment calculations. If an industry wants to pay for expensive transportation, assume it has some reason we don't need to go into (we could imagine it's quality for example, or price - plenty of real examples if we need them). But we don't need to worry about that, we're just a transport company...

I'm not suggesting implementing this idea of 'orders' between industries, my feeling is that the result would be sufficiently similar to cargo destinations to achieve the same end goal (more satisfying gameplay). I haven't read all the cargodest patch documentation, nor played a game with that (busy drawing FIRS...slap me), but if cargodest is being actively developed, it seems to make more sense to pursue that.

Having thought about it for at least 30 seconds (slap me) it does strike me that 'most of this' is close to being handled by newgrf. We already have a callback for checking number of industries of type x, and the distance to the nearest instance. We have callbacks for controlling production and cargo acceptance. However we have absolutely no way of identifying where a unit of cargo originated, and that really would kybosh my scheme, as well as no doubt some other things about the internals of OpenTTD that (to devs) it will be painfully obvious I don't understand.

Also, I'm not sure how much my suggestion above will make sense. I have a pretty clear vision of why this 'distance no object' system detracts from gameplay for a certain type of player, and I can see a simple solution, but I don't know if I've explained it clearly (err...slap me).

To me it definitely looks like an issue of proper domain, and any solution that attempts to tweak, distort or modify payment rates is doomed to failure as the payment rates are grounded in a sound economic model supported by both theory and reality, and in tune with our native mental concept of how reward should be operated.

An alternative would seem to be a full market economy with spot prices for all cargos. This was done brilliantly in Railroad Tycoon 3, and I loved it, but the anecdotal evidence was that lots of people *didn't*. I talked to Phil Steinmeyer (one of the lead RT3 developers) about it, and he seemed to think they over-stretched themselves away from the core 'trains trains trains' character of Railroad Tycoon. In any case, I believe a full market economy in OpenTTD is probably a huge non-starter, and probably not desirable as it's not really the essential character of the game. I've been around the game (played original TTD a lot) for the last three years, and no-one is talking about developing a market economy so far that I've seen, so probably unlikely to happen.

cheers,

Andy