News:

Simutrans Forum Archive
A complete record of the old Simutrans Forum.

Unit sizes of goods

Started by Mariculous, June 02, 2020, 03:03:14 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

Mariculous

Quote from: jamespetts on June 02, 2020, 01:24:33 PMsuch as unit sizes for produce
If the issue of the industry supply is caused by small amounts of goods, this is immediately related to the current syste, as smaller units will result in largere numbers.
Although it sems like you suggest an entirely new system, in which case that might not matter for sure.
I am not sure if the small absolute number of goods is the issue anyways.

jamespetts

Quote from: Freahk on June 02, 2020, 03:03:14 PM
If the issue of the industry supply is caused by small amounts of goods, this is immediately related to the current syste, as smaller units will result in largere numbers.
Although it sems like you suggest an entirely new system, in which case that might not matter for sure.
I am not sure if the small absolute number of goods is the issue anyways.

I have split this from the discussion about the in-transit system as the discussion becomes unmanageable if we discuss anything other than the in-transit system in that thread, as a very detailed discussion about one aspect is quite different to a broad discussion about a range of aspects and the two are cognitively incompatible.

It is difficult to see how splitting units into smaller subunits will make a difference to the economics of this at a fundamental level: supplying a bakery with 1 unit per game month at 0.18c will not be less profitable than supplying it with 10 units per month at 0.02c (aside from the difference caused by the rounding error, as it is not possible to store monetary values in less than 0.01c units).

Indeed, such rounding errors are a good reason not to do this, as well as the fact that there may be consistency issues with other units of goods that share the same category. It would be especially problematic with freight stop capacities, which cannot be separated by type. Also, changing unit sizes would require a massive amount of work in the pakset.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Mariculous

Quote from: jamespetts on June 02, 2020, 03:44:08 PMIt is difficult to see how splitting units into smaller subunits will make a difference to the economics of this at a fundamental level
It is not meant to.

Quote from: jamespetts on June 01, 2020, 05:28:53 PMThe current system seems to achieve this very successfully, but it seems that this can be a problem when that even demand is very low.
Assuming this statement is true, increasing the demand by reducing the size of units can solve the problem.
It is explicitly intended to have as few impact on economic as possible.

Ranran(retired)

How about using old-age grain as a special freight, for example, 1unit 250kg or 500kg? So the impact is small.
ひめしという日本人が開発者達の助言を無視して自分好みの機能をextendedに"強引に"実装し、
コードをぐちゃぐちゃにしてメンテナンスを困難にし(とりわけ道路と建物関連)、
挙句にバグを大量に埋め込み、それを知らんぷりして放置し(隠居するなどと言って)別のところに逃げ隠れて自分のフォーク(OTRP)は開発を続けている
その事実と彼の無責任さに日本人プレイヤーは目を向けるべき。らんらんはそれでやる気をなくした(´・ω・`)
他人の振り見て我が振り直せ。ひめしのようにならないために、らんらんが生み出したバグや問題は自分で修正しなくちゃね(´・ω・`)

jamespetts

I am having trouble understanding the idea that it is possible to solve the economic problems described in the other thread regarding industries with a measure that is not intended to have any economic impact. How will players transporting 10 units for 1/10th of the per unit profit than at present lead to more profit than at present? I do not understand the suggested advantage of this at all.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Vladki

Maybe it is just a problem with the in-transit calculations, that do not work well for industries with very low (lets say below 5 units/month) storage and production? And that if the units are smaller, the goods flow would be better? 1 ton of goods is pretty much for the old days.

Mariculous

#6
Just as Vladki said.
Obviously, cargo might become more profitable if people were actually able to transport the demand, but I would not call this a change in the underlying economics, rather than fixing issues with the intransit system that prevented the underlying economics from actually working as intended.
Just as the new system you suggested might achieve this.

Anyways, it might simply have been a missunderstanding of what was meant by "changing the economics".


To be honest, I did not even consider the amount of goods a pack horse can carry might be excessive.
However, 1 ton did sound quite a lot, and two units of meat actually are 820kg in case of meat and fish, or 770kg in case of milk, so I did a quick recherche on pack horses.
QuoteMost packhorses were Galloways, small, stocky horses named after the Scottish district where they were first bred. Those employed in the lime-carriage trade were known as "limegals".[4] Each pony could carry about 240 pounds (110 kg) in weight, spread between two panniers.

That means it might be sensible to reduce units to represent 100 kg or something like that, so our pack horses can be balanced to carry 100 kg and the resulting higher number of goods (in terms of simunits, not in terms of kg), might already solve the current transport chain issues.
Again, assuming the issue is JIT not behaving well with small numbers.

jamespetts

If the issue is the present system not working well with small numbers, it is better to fix that than alter other things.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Ranran(retired)

From the observation of bridgewater server:
I think what I find particularly problematic in the industrial chain are meat from livestock and bread from grain.
Is anyone in this industry chain network able to make continuous profits (rather than the initial momentum)?
Most are forced to ship one unit.
ひめしという日本人が開発者達の助言を無視して自分好みの機能をextendedに"強引に"実装し、
コードをぐちゃぐちゃにしてメンテナンスを困難にし(とりわけ道路と建物関連)、
挙句にバグを大量に埋め込み、それを知らんぷりして放置し(隠居するなどと言って)別のところに逃げ隠れて自分のフォーク(OTRP)は開発を続けている
その事実と彼の無責任さに日本人プレイヤーは目を向けるべき。らんらんはそれでやる気をなくした(´・ω・`)
他人の振り見て我が振り直せ。ひめしのようにならないために、らんらんが生み出したバグや問題は自分で修正しなくちゃね(´・ω・`)

freddyhayward

Quote from: Ranran on June 25, 2020, 05:42:19 PM
I think what I find particularly problematic in the industrial chain are meat from livestock and bread from grain.
From my experience, vegetables are also troublesome, while milk, fish and fruits are much better.

Ranran(retired)

#10
Quote from: freddyhayward on June 25, 2020, 11:06:04 PMFrom my experience, vegetables are also troublesome, while milk, fish and fruits are much better.
Currently we can't see the lead time, but what we can see in the tests on the new factory GUI branch is common to one consumer.
So trying to carry vegetables from multiple vegetable farms to one market is likely to be a suicide.
I think that is the biggest difference between an orchard and a vegetable farm.
You can deliberately transport vegetables from afar to get more benefits (rather it is desirable to do so to enable transport in one or more units), but both will collapse when someone else transports you it from near and competes.


It's also unclear how it has chosen its partner, but if you're in a conflict you may not be affiliated when you connect. (´・ω・`)
And I think it causes a kind of instability.

EDIT:Correction of mistranslation
ひめしという日本人が開発者達の助言を無視して自分好みの機能をextendedに"強引に"実装し、
コードをぐちゃぐちゃにしてメンテナンスを困難にし(とりわけ道路と建物関連)、
挙句にバグを大量に埋め込み、それを知らんぷりして放置し(隠居するなどと言って)別のところに逃げ隠れて自分のフォーク(OTRP)は開発を続けている
その事実と彼の無責任さに日本人プレイヤーは目を向けるべき。らんらんはそれでやる気をなくした(´・ω・`)
他人の振り見て我が振り直せ。ひめしのようにならないために、らんらんが生み出したバグや問題は自分で修正しなくちゃね(´・ω・`)