Topic: [New Release] Pak64.Experimental 0.4

[Carl]

The latest version of Pak64.Experimental can be downloaded here:
https://github.com/downloads/jha4ceb/pak64.experimental/pak.64-exp0.4.rar

CHANGES FROM 0.3
FIX: Integrated all updates and bugfixes from standard-Pak64 since Sep 2011
FIX: Removed light-pixels on many of the new attractions and several other buildings
ADD: Added streetlist
ADD: Added new demo-savegame
CHG: Decreased chance of Campsite

The integrated changes from Pak64 are quite substantial, so I think it's worth updating just for those. For instance, the 'waste' factory chain is now part of Pak64.Experimental as it is in Pak64.

As ever, you'll need Simutrans-Experimental to run this pakset -- you can download it here. The sources can be found here: https://github.com/jha4ceb/pak64.experimental

---

This version also marks a fork in the road for Pak64.Experimental.

As I discussed here, there are two different ways the project could go. First, the project could closely mirror standard-Pak64 with the continued addition of Simutrans-Experimental-specific changes. Second, it could gradually develop into a completely distinct pakset from standard-Pak64. As I noted in that topic, the two options aren't mutually exclusive -- and after some thought, I think it may be a good idea to pursue both in tandem.

So hopefully in future there will be two different branches of Pak64.Experimental.

One, the "classic" branch, will stick fairly closely to vanilla Pak64. All Pak64 bugfixes and changes will be implemented in this version, and other changes will be fairly conservative. The aim of this set will be to provide a pakset very similar in feel to Pak64 but with Experimental-features enabled.

The second branch will be more progressive and will seek to gradually develop into a new, distinct 64-pixel pakset. I'm not yet sure what this will involve, but my initial priorities lie in changing and tweaking citybuildings and ways. I'm also going to investigate the possibility of making this branch of the project Half-Height, since it seems to me that there are not enough Half-Height paksets (there may be a very good reason for this -- we shall see!)

Also, if this latter branch eventually develops into a new pakset then I'll make sure it has both Standard and Experimental versions.

Any feedback on these ideas is most welcome.

[Carl]

I've updated the "Outdoor Pool" attraction with a simple animation of swimmers moving around the pool. The file is attached to this message; you can simply extract it into your Pak64.Exp folder and overwrite the existing attraction.

[el_slapper]

(probably a stupid question, but pardon me, I'm far from expert)

Do you think it's thinkable to make an automated process to transform datas from PAK.64.standard to PAK.64.EXPERIMENTAL.CLASSIC ? I mean, there are a few datas to add(turnaround, loading, overload). I was thinking of an automated process with a few parameters(buses would have 15% overload, less after 1960, anything.....).

Or is it too much specific parameters for each vehicle, each way?

[Carl]

I daresay one could write some kind of automated tool, but given the relatively small amount of data involved, I doubt it would be a wise investment of time. It might well take longer to write the tool than it would to input all the information.

Aside from the newest pak64 vehicles (which I've realised I forgot to add Experimental-parameters to), most vehicles should now have the required parameters (overcrowding, loading etc). I daresay there are still a few missing -- do let me know when you spot any omissions.

[greenling]

carlbaker
gives from the pool addon the scoure on github?

[Carl]

Yep -- I uploaded the latest sources there today. The link to the github repository is in the first post on this thread.

[jamespetts]

Splendid to see good progress being made on Simutrans-Experimental pakset development!

[jk271]

After some time I have been playing pak64 experimental in era of beginning 19th century.

I suggest some changes of paremeres of factories "old_farm" and "grain_farm" from food industry.

IDEA 1 - farm1.patch

One square kilometer of field yields 441 - 545 metric tonnes of wheat per year. (Data come from some statistic about recent agriculture in Central Europe. Not in English, so I do not link it.)
Square kilometer contains 16 fields in simutrans experimental. *
(* I use default settings: One tile is 250 meters --> 4 tiles is 1km ---> 4*4=16 tiles is one square km)
Dividing 441 by 12*16 yields 2.29t per tile. (There are 16 tiles per km2 and 12 month per year)
Using upper bound (545 t per km2 and year) leads to 2.83t per tile. Rounding previous results to natural numbers yields 2 or 3 t per tile in simutrans experimental.

So I suggest to use production_per_field=2 for old_farm and 3 for grain_farm.

(Using same algorithm for simutrans standard yields 27-34 t per tile.)


Another change deals with landscape. I suggest more fields. My suggestion is to multiply recent values of max_fields by roughly 2.5. It leads to similar amount output goods from fields as it had before the change.

More fields are desired in simutrans experimental according to the thread and I support the the idea:
http://forum.simutrans.com/index.php?topic=2472.0;


I suggest not to increase min_field too much or not to increase at all  as user should have possibility to remove some fields to be able to build a way to farm.


Farm fields very rarely spawn as probability_to_spawn is too low. I suggest to increases it at least 10 times. I changed it from 1 to 20. It playable.
There is a forest plantation in pak128 having forest fields with probability_to_spawn=75. It works nicely - fields spawn appropriately.


Both farms have small distribution_weight: 1 and 2. For example forest plantation (Nutzwald), iron ore mine and coal mine have distribution weight of 100. I suggest to multiple distribution weight by 10. 10 and 20 is still less than other factories have. On the other hand it is not too small (in contrast to value of 100).


IDEA 2 farm2.patch


Another idea:  Lower a little bit productivity of factory (grain_farm, old_farm) and increase number of fields (max_fields). As wheat grown on fields, not in the farm building.

For example:
* old_farm:
    Change of productivity from 80 to 60 give us 20 t of wheat, that acquired from fields. 2t of wheat per tile leads to increase of 10 wheat fields (max_fields).


P.S. These changes should  not increase or decrease significantly total amount of wheat producted by farms.

[Carl]

Thanks very much for the feedback. I'm highly supportive of these ideas. In particular, the half-height pakset I'm developing (see link in signature) has much heavier usage of farms and makes several of the changes you suggest. Nevertheless, I'll look into including these changes in the next version of Pak64.Exp too.

[prissi]

The problem with fields is that too many initial fields will make the industry unprofitable to start with; a too high number will make it too expensive to remove the fields to start with. Thus the original pak64 chooses a higher base prodution.

[jk271]

One step to reality - suggestion to factory parameters change

Raw materials like crude oil or coal are transported for long distances by ship.
Unfortunately it is not possible in simutrans without "leaps" amount of input goods stored in coal power station or refinery. "Leaps" are caused by the fact, that coal power station runs out of the coal before the time of arrival of the ship. Than it receives huge amount of input material. So it has a lot of input material. Producer stops production and coal power station runs out of the coal again. The fact that producer (coal mine) stops production is OK but the fact that ship has not enough time to deliver coal to coal power station before it has no coal available is not.
Not only ship transport is affected - slow freight trains for long distance suffer from "leaps" too.

This is more significant on huge maps 1024x1024 or more.

Solution can be to increase input storage capacity of coal power station to double value or multiple of 2.5. Such a increase is a compromise as bigger values (5times more than current value)  cause input storage capacity to reach value of 15000 and are not suitable as input cargo above 15000 is thrown away.

Currently coal power station can get coal by ship without lack of coal from distance of 547 tiles (137km)
There are some another factories that should be considered too:
chemical plant ... 165 tiles (41km)
oil power plant ... 244 tiles (61km)
oil refinery ... 166 tiles (42km)
steel mill ... 121 tiles (30km) for iron ore and 141 tiles (35km) for coal.
Sawyer's workshop (SaegewrkMHZ) 264 tiles (66km) for wood

 I used following algorithm for distance calculation:
 distance = (storage/consumption_rate)*tiles_per_month_at_100km_per_hour*speed_of_ship*0.01
and parmeters ship speed of 38 km/h and 250m per tile (default in pak64. experimental)

(1522/1352)*1280*38/100 = 547
...

This feature is common for both - standard and experimental. As simutrans experimental players use usually larger maps and have meters per tile parameter it more significant there. I am posting it to experimental as it tries to be more realistic than standard.

[Carl]

Many thanks for the thoughtful feedback, jk271.


So one of your proposals (I take it) is to increase the input capacity of the factories in question?


I'm afraid I don't quite understand how distance figures into the equation -- does this correspond to some parameter which should be altered on the pakset level, or some tweak in Experimental's code?

[jk271]

So one of your proposals (I take it) is to increase the input capacity of the factories in question?

Yes, my proposal is to increase input capacity by 2.5. So 1000 becomes 2500 ... It was whole suggestion of my previous post. Other words were only to support such a proposal.

Equation should have demonstrated way, how I have calculated maximal distance that works without "leaps". Equation yields result in tiles and works for both: standard and experimental. It has nothing new with experimental. So do not have to bother with usage of it.

Explanation of the equation:
Expression in brackets stand for time (in game "months") for which factory has input raw materials. Tiles per month (from goods list window) says distance we can reach by travelling one month at speed of 100km per hour. As ships are travelling at speed of 38 km per hour, we have to divide it by 100 (or multiply it by 0.01) and multiply it by speed of ship.

I used the equation because I needed to support statement of calculated distance values expressing that the storage capacities are low.

P.S. Thanks for quick response.

[Carl]

Thanks jk271. I'll certainly look into implementing this. I recommend that you post a similar thread in the pak128.Britain-ex forum, too, since that Experimental pakset also strives for realism.

[jk271]

I am not familiar with pak128.Britain-ex well. On the other hand 128.Britain-ex seems to be a little bit better balanced in this way. I take it as a good heritage from pak128.Britain. I will make a table with factories from Britain-ex pak to point out factories which needs some changes. Unfortunately it needs some time. I hope that it will take me less than one week to do it.
Edit:

[jamespetts]

Any feedback from usage in relation to factory capacities for Pak128.Britain-Ex would be very much appreciated.

[accord2]

Is this dead?

[Carl]

In terms of new development, yes. Developing and maintaining a pakset is too much like work for me to be motivated to do it in my spare time.

I've still been developing alternative versions of pak.64 as part of my saved games (links in sig) - the GB one adds new vehicles and a different visual style, with many graphics changed, but it isn't economically balanced.