News:

Simutrans.com Portal
Our Simutrans site. You can find everything about Simutrans from here.

The orchard has a much bigger employment and mail demand

Started by Ranran(retired), February 12, 2019, 01:23:00 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

Ranran(retired)

I noticed that the orchard has very large worker demand on my map. (´・ω・`)
It recruits many times more workers than farms and mines.

I made a new map of each age repeatedly and confirmed.
All orchards except Orchard 1750 recruit so many workers. They always demand about 1000-2500 workers.

https://github.com/jamespetts/simutrans-pak128.britain/blob/master/industry/orchard.dat
It seems that there is no problem with the numerical value of employment_capacity even after checking the source. :question:
Are they due to their fields?
ひめしという日本人が開発者達の助言を無視して自分好みの機能をextendedに"強引に"実装し、
コードをぐちゃぐちゃにしてメンテナンスを困難にし(とりわけ道路と建物関連)、
挙句にバグを大量に埋め込み、それを知らんぷりして放置し(隠居するなどと言って)別のところに逃げ隠れて自分のフォーク(OTRP)は開発を続けている
その事実と彼の無責任さに日本人プレイヤーは目を向けるべき。らんらんはそれでやる気をなくした(´・ω・`)
他人の振り見て我が振り直せ。ひめしのようにならないために、らんらんが生み出したバグや問題は自分で修正しなくちゃね(´・ω・`)

jamespetts

Fields will (if I recall the algorithm correctly) affect employment. A great many people are required to pick fruit - far more than are required to harvest wheat, for example, as each item of fruit must manually be plucked from the tree one by one.
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)

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

jamespetts

I cannot recall the exact numbers now; but I am not sure precisely what you mean; does the 1840 orchard employ more or less people (1) overall; or (2) per unit of production than the 1750 orchard?
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)


The left one is 1750 years and the right one is 1840 years.

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

jamespetts

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)

I have made the same number of fields. (´・ω・`)
Both are 28.

1750's


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

jamespetts

This is odd. I cannot immediately discern the cause of this difference. There may possibly be an error in the code, although that will take a long time to track down and I must priorities more important issues first. I will move this to the development forum as this appears potentially to be a code issue.
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)

In dat, Orchard1750 has employment_capacity set to 4, but Orchard1840 is set to 10.
If this difference is not intentional, can not you improve by aligning this? All fields seem to be affected by this difference.
ひめしという日本人が開発者達の助言を無視して自分好みの機能をextendedに"強引に"実装し、
コードをぐちゃぐちゃにしてメンテナンスを困難にし(とりわけ道路と建物関連)、
挙句にバグを大量に埋め込み、それを知らんぷりして放置し(隠居するなどと言って)別のところに逃げ隠れて自分のフォーク(OTRP)は開発を続けている
その事実と彼の無責任さに日本人プレイヤーは目を向けるべき。らんらんはそれでやる気をなくした(´・ω・`)
他人の振り見て我が振り直せ。ひめしのようにならないために、らんらんが生み出したバグや問題は自分で修正しなくちゃね(´・ω・`)

jamespetts

Quote from: Ranran on February 13, 2019, 10:14:44 PM
In dat, Orchard1750 has employment_capacity set to 4, but Orchard1840 is set to 10.
If this difference is not intentional, can not you improve by aligning this? All fields seem to be affected by this difference.

That difference is intentional, but the difference does not appear to account for the difference in employment: the difference should be only a factor of 2.5, whereas it is in fact 7.25.
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.

ACarlotti

Quote from: jamespetts on February 13, 2019, 10:26:33 PMthe difference should be only a factor of 2.5, whereas it is in fact 7.25
The 7.25 was presumably in a case where the number of fields was not the same. In the example where both have 30 fields the ratio is instead 3.75, which is still 1.5 times more than 2.5. Is there anything else that would contribute a factor of 3/2?

jamespetts

I cannot immediately think of anything: I had not realised that the identical fields example was different to the example given above.

The trouble with many of these things is that there is so much detail  that it is easy to forget that there is some algorithm that is intended to have the effect shown in the particular situation in question. A number of times have I spent some time trying to track down a bug only to discover that it was intended behaviour all along. Such is the lot of the amateur programmer for a complex project, I fear.
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)

#12
Considering from the example I reported in this bug report, there is a possibility that the number of Jobs is doubled.




And another curious thing is visitor demand.
All of the population_and_visitor_demand_capacity of orchards are set to 0 in dat, but they have a value in the game. And this seems to behave like employment_ capacity.
The arrival number of the visitor in the consumer industry is correctly recorded in the chart, but I have confirmed that in the primary industry which has a strange visitor it does not count the arrival of visitors. It only counts commuters.




And now Mail demand is not displayed in that dialog, but I added its display and checked it.


@@ -3116,6 +3116,7 @@ void fabrik_t::info_prod(cbuffer_t& buf) const
#else
buf.printf("%s (%s): %d (%d)\n", translator::translate("Jobs"), translator::translate("available"), building->get_adjusted_jobs(), max(0, building->check_remaining_available_jobs()));
#endif
+ buf.printf("%s: %d\n", translator::translate("Mail demand/output"), building->get_adjusted_mail_demand());
// Class entries:
building->get_class_percentage(buf);
buf.append("\n");


Orchards also have unusually large mail demands as well.



EDIT:
I tested it by changing the value of production_per_field.

It seems that the value of production_per_field doubles not only production but also visitor demand, job_demand, and mail_demand.



EDIT2:
In a subsequent test, population_and_visitor_demand_capacity, employment_capacity and mail_demand, these turned out to be treated as 1 if set to 0.
(1 is not a fixed value)
That is, it always have visitor and mail demand for the number of fields.
And it is divided by field_output_divider and multiplied by production_per_field.
These demand values are different from the demand value of the chart. I guess that the chart value is a number excluding the field.
ひめしという日本人が開発者達の助言を無視して自分好みの機能をextendedに"強引に"実装し、
コードをぐちゃぐちゃにしてメンテナンスを困難にし(とりわけ道路と建物関連)、
挙句にバグを大量に埋め込み、それを知らんぷりして放置し(隠居するなどと言って)別のところに逃げ隠れて自分のフォーク(OTRP)は開発を続けている
その事実と彼の無責任さに日本人プレイヤーは目を向けるべき。らんらんはそれでやる気をなくした(´・ω・`)
他人の振り見て我が振り直せ。ひめしのようにならないために、らんらんが生み出したバグや問題は自分で修正しなくちゃね(´・ω・`)

Ranran(retired)

Visitor demand, job demand, mail demand are inversely proportional to the value of Productivity.
Currently, all of orchards are set to Productivity = 1. Increasing this number greatly reduces each demand.

The following image is a test by rewriting the value of the productivity of .dat.

Productivity=1 (default)


Productivity=4


Productivity=8


This means that there is an error in the code.

Conversely, it is proportional to the production of the field.
Currently, each demand can not be zero, so industries with fields will reach great demand depending on the number of fields. Therefore, I think that it is better to modify the following code.

// then, scaling based on month length
scaled_pax_demand = std::max(welt->calc_adjusted_monthly_figure(base_worker_demand), 1ll);
const uint32 scaled_visitor_demand = max(welt->calc_adjusted_monthly_figure(base_visitor_demand), 1);

// then, scaling based on month length
scaled_mail_demand = max(welt->calc_adjusted_monthly_figure(mail_demand), 1);





EDIT:
Quote from: jamespetts on February 13, 2019, 10:26:33 PMQuote from: Ranran on February 13, 2019, 10:14:44 PM
In dat, Orchard1750 has employment_capacity set to 4, but Orchard1840 is set to 10.
If this difference is not intentional, can not you improve by aligning this? All fields seem to be affected by this difference.

That difference is intentional, but the difference does not appear to account for the difference in employment: the difference should be only a factor of 2.5
Production_per_field has doubled in Orchard 1840 and beyond. Therefore it requires twice the number of workers at that time. (Excluding building values)
Furthermore, if employment_capacity is multiplied by 2.5, then the total demand workers will be five times.

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

DrSuperGood

Actual productivity should have nothing to do with job demand. If an orchard doubles its production by upgrading, it might produce less jobs. This is to reflect reality where farms and factories often upgraded via automation and not simply by becoming bigger. Modern farms have huge production and generate very few jobs (on average over the year).

Random variances to production should have a linear effect on job demand, or could even be an entirely separate variance.

Ranran(retired)

Oops, I'm sorry. It is an issue caused by my ghost translator - Dr. Google translate. (known as )
She sometimes makes weird translations as you know. My apologies for lack of confirmation.  :-[

QuoteTherefore it requires twice the number of workers at that time.
I wanted to express "Therefore it requires twice the number of workers in the game." (or in that case)
James said that it should be 2.5 times, but by design it will be five times.

I hope this will be transmitted correctly. (´・ω・`)伝わって?



EDIT:
I found that the industry in the city is not inversely proportional to productivity. If Location = land, it is inversely proportional to productivity.
I tried changing the location setting of pub and tried to increase or decrease the value of productivity, but demands are also in inverse proportion.
It does not seem to matter if it has a field or not. So I think it is not a matter of dat setting, but there is an error somewhere in the rural industry's demand formula.

near this?

const uint32 percentage = (get_base_production() * 100) / max(1, get_desc()->get_productivity());



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

jamespetts

Thank you for looking into this. I am not sure at present how town industries diverge from rural industries: the code to which you refer, which is found in both fabrik_t::update_scaled_pax_demand() and fabrik_t::update_scaled_mail_demand(), but none of those have a test for whether the industries in question are in towns or not. May I ask why you think that an error with this algorithm distinguishes between industries in and industries out of towns?
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)

Quote from: jamespetts on March 10, 2019, 02:06:27 PMMay I ask why you think that an error with this algorithm distinguishes between industries in and industries out of towns?
This image is the result of rewriting the "Location" setting of Pub1750.


The one on the left is rewritten to "Location=land" and the right is "Loacation=city".

Just changing to "Location=land" will show abnormal numerical values.
Therefore, I thought the farm was influenced by the having field or not but by the location setting.


And with Location = land, increasing the Producitivity greatly reduces demand.
This is an image when Productivity is increased from 1 to 100.


Visitor demand decreased from 30624 to 559.



Example of manufacturing:

Brewery1750




If location setting is changed from city to land, demand will be halved, and in this case productivity does not seem to be linked.
But my previous post shows that the demand of orchard is inversely proportional to productivity
ひめしという日本人が開発者達の助言を無視して自分好みの機能をextendedに"強引に"実装し、
コードをぐちゃぐちゃにしてメンテナンスを困難にし(とりわけ道路と建物関連)、
挙句にバグを大量に埋め込み、それを知らんぷりして放置し(隠居するなどと言って)別のところに逃げ隠れて自分のフォーク(OTRP)は開発を続けている
その事実と彼の無責任さに日本人プレイヤーは目を向けるべき。らんらんはそれでやる気をなくした(´・ω・`)
他人の振り見て我が振り直せ。ひめしのようにならないために、らんらんが生み出したバグや問題は自分で修正しなくちゃね(´・ω・`)

jamespetts

Thank you for that: that is helpful. Can I clarify: to what extent have these industries been placed manually compared to being placed automatically by the game?
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)

Although many are placed manually, I think that there is no difference in the change of numerical value by manual placement and automatic placement.

And now I noticed another thing from the image;
Focus on the change in the storage capacity numbers in Pub.
When the location=land, the storage capacity decreases greatly as the productivity increases.
This is consistent with what I reported to other threads.
But it doesn't seem to be the case with Brewery.
ひめしという日本人が開発者達の助言を無視して自分好みの機能をextendedに"強引に"実装し、
コードをぐちゃぐちゃにしてメンテナンスを困難にし(とりわけ道路と建物関連)、
挙句にバグを大量に埋め込み、それを知らんぷりして放置し(隠居するなどと言って)別のところに逃げ隠れて自分のフォーク(OTRP)は開発を続けている
その事実と彼の無責任さに日本人プレイヤーは目を向けるべき。らんらんはそれでやる気をなくした(´・ω・`)
他人の振り見て我が振り直せ。ひめしのようにならないために、らんらんが生み出したバグや問題は自分で修正しなくちゃね(´・ω・`)

jamespetts

My apologies for the delay in replying to this. I have just been looking into this, and I think that there was an error in the formula that you identified. I have pushed a fix to this formula and I should be grateful if you could re-test with to-morrow's nightly build.

Thank you for your report.
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)

Thank you for working on this.
It is difficult to determine if the formula is completely accurate, but at first glance it looks like there are no anomalies in the demand numbers.
I changed the location and productivity and tried the test as before, but I did not see any abnormality.

It should be noted that this change does not affect existing buildings.
However, I think that the game balance will change great with this correction. It is no longer necessary to transport large numbers of workers to the farm as if to transport miners. (But I think it is correct.)


Quote from: Ranran on March 20, 2019, 03:40:08 AMFocus on the change in the storage capacity numbers in Pub.
Inconsistencies in storage capacity can still be seen.
I think that the storage capacity of consumption is not correct.
ひめしという日本人が開発者達の助言を無視して自分好みの機能をextendedに"強引に"実装し、
コードをぐちゃぐちゃにしてメンテナンスを困難にし(とりわけ道路と建物関連)、
挙句にバグを大量に埋め込み、それを知らんぷりして放置し(隠居するなどと言って)別のところに逃げ隠れて自分のフォーク(OTRP)は開発を続けている
その事実と彼の無責任さに日本人プレイヤーは目を向けるべき。らんらんはそれでやる気をなくした(´・ω・`)
他人の振り見て我が振り直せ。ひめしのようにならないために、らんらんが生み出したバグや問題は自分で修正しなくちゃね(´・ω・`)

Jando

Quote from: Ranran on April 12, 2019, 03:29:42 PMInconsistencies in storage capacity can still be seen.
I think that the storage capacity of consumption is not correct.

I'm not sure that's a bug, James will tell. Input storage of industries seems to have no effect really. And in a way, that makes sense even. How many items arrive at a consuming industry depends on how many items are demanded by that industry, sooner or later the items will arrive and thus pile up. And industries commonly demand much, much more than their input storage.

Output storage however for producing industries works fine.