### Recent Posts

Pages: 1 2 3 [4] 5 6 7 ... 10
31
##### Simutrans Extended Development / Re: Agricultural conundrum
« Last post by IgorEliezer on Today at 12:51:46 AM »
Could I... could I give my 2¢?

One hectare (ha) is equivalent to a square whose sides measure 100 meters (m).

1 ha = 100 m x 100 m = 10,000 m².

Additionally, 1 ha has 100 ares (probably this is the source of the confusion). In turn, each are is 100 m² or 10 m x 10 m.

~ Wonders of the International System.
32
##### Simutrans Extended Development / Re: Agricultural conundrum
« Last post by jamespetts on Today at 12:22:56 AM »
Ahh - my error: I had at some point incorrectly believed that a hectare is equal to a square kilometre. I have now updated my spreadsheet (the same link as above). Thank you for that correction: these numbers now seem slightly easier to work with. It is also useful to know about grain storage: that is a good reason to allow for continuous year-round production.

However, the numbers are still below the current precision threshold. For tonne/tile/nominal month (i.e. 6.4 hours), I still get 0.0019 for 1750, up to 0.0085 in 1975. Worse, the figures for tonnes/farm/nominal month are unchanged from the previous values, as the differing size of the hectare is counteracted by the equally differing production by hectare. So, I still get, for average sized farms, a range between 0.02 tonnes/nominal month (6.4 hours) and 0.27 tonnes/nominal month. However, this would be achieved with considerably fewer tiles.

I am just about to adjust the grain farm sizes again on the relevant Github branch. In the meantime, any other thoughts about how to deal with this would be appreciated.

Edit: I have now re-sized the fields. The new figures now make the farms much closer to their original size, ranging from a minimum number of fields in 1750 of 5 and a maximum of 21 to a minimum of 16 and a maximum of 65 in 1975.

Edit 2: Unfortunately, we are still one order of magnitude off being able to use the output factor scaling, as discussed briefly above: all of the per tile values are still in the thousandths rather than the hundredths.
33
##### Simutrans Extended Development / Re: Agricultural conundrum
« Last post by Sarlock on Today at 12:02:53 AM »
100m2 = 1 hectare.  125m2 = 1.56 hectares.  There are 100 hectares in a square kilometer (64 tiles).

Most significant size farms have onsite grain storage capacity.  Grain can be stored here and sold at a later date - this largely resolves the seasonal concern about production spikes.

Average wheat production per hectare is around 3 tonnes/hectare.  It was, of course, much lower than this in decades/centuries past.

A 100 hectare (64 tile) farm would produce ~ 300 tonnes/year.

It helps a bit with the math but it still exposes the economic reality that large tracts of land need to be farmed to feed large populations.
34
##### Simutrans Extended Solved Bug Reports / Re: Road vehicles are not allowing to move if a way has a start of motorway sign
« Last post by jamespetts on Yesterday at 11:42:43 PM »
Yes, indeed: in the absence of any other means of marking a one way road, motorway signs are intended as one way signs, the idea being that one should use two parallel one way roads as motorways.
35
##### Pak128.Britain-Ex / Re: Horse drawn railway passenger services (1832-)
« Last post by jamespetts on Yesterday at 11:41:35 PM »
Very interesting! We do have railway horses from an early age, and railway wagons that can accommodate passengers from 1825 onwards; do you think that we are missing any rolling stock here?
36
##### Simutrans Extended Development / Agricultural conundrum
« Last post by jamespetts on Yesterday at 11:32:02 PM »
Background

In working on the passenger and mail classes feature, I am trying to calibrate with some precision the relationship between passenger production (of various classes), building type and size and freight production and consumption. The passenger and mail classes branch of the code has merged into it the logistics branch of the code, which ties passenger visits to consumer industries with the consumption of those industries, and I have been spending some time calibrating that, too. (In summary, the way that this works is that consumer industries other than power stations no longer deplete their stock automatically as time passes: rather, the only deplete their stock when visiting passengers arrive as happens in reality).

In doing this, I have been adding settings for passenger generation in the buildings' .dat files which have not previously been added, considerably increasing the realism and improving the balance of the simulation. Many of these settings have been available since the passenger generation overhaul in 2013-2014, although I am also adding the specific new settings for the proportion of passengers of each class that each building generates/demands (separately for visitors/commuters).

Initial tests show promising results for balance, with an increased overall level of passenger generation and increased and more realistic densities of populations in towns. Particular improvements in job fulfilment have come from adding a new setting for the minimum as well as maximum numbers of alternative destinations.

One of the important aspects of this work is in realistically calibrating land area as against density. This is straightforward for houses, factories, shops, town halls and the like, where a few simple assumptions can allow me to calibrate that, e.g., one 125 meter squared tile occupied by a house building would in reality hold about 11 houses, and so simply multiply the number of inhabitants by 11, and so forth.

However, there is a difficulty with agriculture because of its very low density land usage.

The problem with agriculture

Research indicates that agricultural production (I have researched wheat so far) is something in the order of 1 - 7 tonnes per hectare of land per year. A hectare of land at 125m/tile is 64 tiles. Industrial production in Simutrans-Extended is (necessarily) scaled to the short timescale of 6.4 hours (6:20) per month. Assuming 16 hour days (as we do not simulate nights), this means that a year's production would take 912.5 game months (or 76 game years) to accumulate.

In reality, of course, farms are not constantly shipping products: there is not an hourly train (or even a daily van) departing full of produce from every crop farm the land over. In reality, there is one harvest a year, and the farm produces nothing apart from at that time. Nonetheless, we do not have any means of seasonal variation in consumption/production (which would require, in turn, seasonal variations in schedules and path-finding caches), so we must simply average the farm's production over a year.

On the basis of these data and research about the sizes of farms over the years, I have produced some calculations about how much that each field of a grain farm should produce for each game month. As will be seen, this ranges from 0.0000199 to 0.0000856. Grain, the output good, is ranked as a bulk good, and the unit size is in tonnes. (This would be extremely difficult to change since it is transported in the same vehicles as coal, iron ore, etc.). Given that the current minimum production per field is 1.0 (tonnes), this is a problem. It can be scaled to 1% (0.01) by specifying OutputFactor[0]=1, but that is still three orders of magnitude too large.

There is no mechanism that currently exists to allow farms to have lots of fields but a very small production. I have been experimenting with giving farms a realistic number of fields, which seems to work fairly well: an old problem with this, which was that it was not possible to delete fields to put in a road connexion, has now been solved by allowing more fields to be deleted. However, these farms, at the minimum production per field of 1, have a production of many hundreds of tonnes per month, which is absurd. A farm with, say, 16 hectares of land (i.e., 1024 tiles) should produce, in total, 0.02 tonnes of grain per game month (i.e., 6.4 hours).

Why a solution is hard to find

I have considered various ways of trying to solve this. One of those was to start with the internal units for industry production and allow these to be divided by a number specified in the .dat files to allow for scaling of the production in this way. Unfortunately, the internal units only scale by a factor of 256, which does not give anything near the level of precision required.

Another problem is that there are quite a lot of different places in the code where the industry's base numbers (including the production per field value, represented in tonnes per game month, i.e., tonnes per 6.4 hours, which is an integer the lowest value of which is therefore 1) are used directly, meaning that a lot of code would have to be changed to alter this, and there would be a very high risk of introducing lots of errors that would take many months of intensive work to fix.

I had briefly considered whether adding a simulation of seasons would help: the crop farms would produce nothing for most of the year, and then produce everything in one of the four seasons. I had long considered adding a simulation of seasons in any event to simulate the seasonality of, e.g., tourist traffic or traffic to football or cricket grounds. The trouble is that this would take a very great amount of work to implement properly and would not in any event solve the problem, as simply allowing values to be divided by four would not allow for enough precision when the correct figures are in the hundredths of thousandths.

Any thoughts?

Therefore, I am posting to see whether anyone - particularly those with some coding experience who understand the code - can suggest an efficient and workable approach to dealing with this issue that involves rewriting as little code and as few .dat files as possible, does not significantly increase computational overhead, is not a kludged hack that will make the game hard to understand and/or the code hard to comprehend or maintain and is the least likely to produce difficult errors that will take months of painstaking work and scores of bug reports to fix.

Any assistance would be much appreciated.
37
##### Simutrans Extended Development / Re: Dat file reference for: Signals and Signalboxes
« Last post by Ves on Yesterday at 08:55:01 PM »
I hope they are of some use, although they are still not updated to feature the latest additions. Also, I need to couple them to the signal windows!
38
##### Simutrans Extended Solved Bug Reports / Re: Road vehicles are not allowing to move if a way has a start of motorway sign
« Last post by Rollmaterial on Yesterday at 07:48:37 PM »
The motorway sign acts as a one way sign.
39
##### Simutrans Extended Development / Re: Dat file reference for: Signals and Signalboxes
« Last post by zook2 on Yesterday at 07:14:55 PM »
Sweet Jesus! He updated the help files! That's the last place I would ever have looked. Thanks!
40
##### Français (French) / Re: Simutrans 64 bit ???
« Last post by Frank on Yesterday at 06:51:55 PM »
Vous pouvez également tester ces paquets.

Forum allemand

Ces paquets sont une première tentative d'offrir des paquets autonomes de rpm/deb.
Pages: 1 2 3 [4] 5 6 7 ... 10