Topic: Pak64.Experimental 0.1

[Carl]

Pak64.Experimental is a modified branch of pak64 for use with Simutrans-Experimental. Many of the features of Simutrans-Experimental are currently difficult to access, because they require a compatible pakset---and there are not enough compatible paksets available (though there are some!). This pakset will give players easy access to these features, including the following:

• Tilting trains
• Comfort ratings
• Catering vehicles (e.g. restaurant carriages)
• Bi-directional trains
• Liveries*
• Overcrowding capacity on passenger vehicles
• Way constraints
• Increase in maintenance for obsolete vehicles
• Fixed maintenance costs
• Industrial obsolescence
• Variable loading times for different vehicles

A fuller description of these (and other) features of Experimental can be found here. Pak64.Experimental aims to make it easy for players to take advantage of the above features by providing an Experimental-optimised pakset. At the basic level, pak64.experimental is just a branch of pak64 with the above features enabled. (* Note: liveries will be enabled soon.)

Download links:

Pak64.Experimental 0.2 -- NB. now points to 0.2 release
Simutrans Experimental [REQUIRED -- this pakset will not work with Simutrans-Standard. You may also need to download this file.]
Sources

Pak64.Experimental also aims to aid Experimental's developers by providing (another) stable pakset-environment in which to test new features. All new Experimental features will be enabled here so that they can be tested. On yet another level, pak64.experimental aims to be to pak64 what Simutrans-Experimental is to Simutrans: an environment where new (or old) features can be tried out for size, and a version where ideas which are too radical for the trunk can be made available to players.

Feedback/bug reports gratefully received! Feedback is especially invited on balancing issues -- is it too easy/too difficult to make a profit? Are some goods/vehicles too profitable/not profitable enough?


Screenshot (click for larger)



CHANGES FROM PAK.64 (so far)

• Changes in all vehicle data to implement the above Experimental features
• Changes in industry data to allow for industrial obsolescence/upgrading
• Changes to ground textures (to give the pakset its own distinctive look and feel)
• A few new vehicles to fill in gaps in the timeline
• A few new city buildings (mostly modified versions of open-source pak128 files)
• Addition of way constraints for a new waytype, "Subway Tunnel", and one vehicle to go with this
  
• Various small changes to building data (mostly "chance" parameters)
• Speed bonuses altered (hat-tip to pak128.Britain-Ex, whose data we are borrowing for now )
  
• Other small things that I've no doubt forgotten

TO-DO LIST

• Incorporate Experimental features. Upgrading vehicles and liveries will be implemented soon.
• Tweak existing changes. At the moment vehicle data has been updated in a rather haphazard manner. More attention will be required to get the values right.
• Balancing. Experimental's revenue/economic changes will no doubt require altering some of the settings to allow for balanced economic features. This will require testing.
• Add more vehicles. Pak64 is easily supplemented by addons. That's more difficult for this pakset, since any vehicle addons will not have (for example) fixed maintenance costs or overcrowded capacities, and so will interfere with the balance of the set. Because of this, it is planned to fill out the vehicle offering in pak64.experimental somewhat. If anyone has pak64 graphics that they wish to submit to this project, do let me know.

KNOWN BUGS

• Graphical bugs with ground textures. Shores look bad and some climate changes are clumsy. This is because texture_shore and texture_slope are very difficult to modify with any success. Any help with this gratefully received.
• A few minor alignment issues with new vehicles -- especially combining new passenger carriages with old locomotives.
• Some new buildings lack winter view

[colonyan]

This is exciting!
I look forward for your project.
Also, after 2years old 64 size building is getting used.... I'm so happy.

[Milko]

Hello

Good project, I'm a fan of simutrans experimental and I missed the pak64. Thanks!

Giuseppe

[Milko]

Hello Carlbacker

I'm making airplanes for the "pak128britain" if you are interested in any of them I can create versions for "pak64Exp" you're following. If you notice any aircraft that may interest you tell me that I try to achieve it, alternatively I can also provide you with the original file blender.
You can find my designs in the forum "Pak128Britain".

In general, this ad is also valid for the "pak64 standards" and "pakgerman standard and experimental."

Giuseppe

[Carl]

Hi Milko,

Thank you for your kind offer! When I get around to looking at the aircraft offerings, I will probably take you up on it!

[Milko]

Hi

At the moment I have these available models:

Airbus: A318, A319, A320, A321
BAE: 146_100, 146_300
ATR: 42, 72

But I do not have much time to work on models and then I'm a bit slow.

Giuseppe

[Carl]

Thanks! I'm working mainly on attractions at the moment, but surveying what vehicles are needed is certainly high on my list of priorities.

Here's a quick work-in-progress preview of one of the new attractions that will be in 0.2 -- a small hospital:

[greenling]

Hello Carlbaker
you have be start a new pakset for simutrans exp.!
The picture what have be view look good out!

[colonyan]

Simutrans Experiment won't start on my home pc...
I hope I can find a way to be able to.
I tried few dozen minutes in work place in lunch time and for instance, oil is lucrative for
what its being simplest chain to complete. I suppose its the petroleum extractor who
gets the big share not the transporter. (In real world too)

[greenling]

colonyan
the Simutrans exp to install it´s difficult!
befor you Simutrans exp install must you look after you operating system what you have!

[Carl]

Hi both,

Many thanks for the feedback!

Simutrans-Experimental should work on any computer that can run Simutrans. What seems to be the trouble when you try to load it on your home PC?

Edit: I've just seen that you posted a bug report in the Experimental forum, so no need for me to ask about it here :-)

Colonyan -- do you think that it's too easy to make money with oil, or just about easy enough?

[infernalmachine]

colonyan,

Did you get Experimental from the link that says "Simutrans Experimental " in carlbaker's first post in this thread?  That turns out to be only the executable + dll's (or it was when I tried it ealier this week).  I believe you also need the fonts directory, etc, for the game to run.

You can either put the executable in a normal simutrans directory (which has the other files required) or you can grab the complete package from http://forum.simutrans.com/index.php?topic=1894.0 if you are using Windows, and install it to its own directory (which is what I did).

[Carl]

Aha -- I should update my original post to reflect this. Thanks infernalmachine.

[colonyan]

carlbaker
Hi, I think oil is little bit lucrative. Not too easy but kind of easy. So if you want to make pak hard, you might
want to reduce the oil price and increase the starting fund.

infernalmachine
I got the files from where you mention. Well, anyways, I will retry. Thanks for infos though.

Edit:Both. It works in another/new account in same pc.

[colonyan]

Another Finding/Question.

In a town, there was a daily factory which consumes the milk as the final product.
I placed two bus stop in the town to cover the entire town, and the factory got production boost.
1.Is daily factory should get a "consumption" boost from the first place?
  If increased consumption rate contribute to above 100% growth speed, it would make some sense.
  (Which I assume does not happen)
  But the boost is big for just two bus stop and single bus. 1250>1450
2.Does increased consumption rate affect base growth rate?
  I think it works same as if consumer is connected with power line in older version.
  It consumes faster but growth rate is not affected.
  On the other hand, it makes the supply even harder.
  At default, a consumer could consume 100unit per month and it counted 100% from what it affected the
  overall town growth. If its doubled to 200unit per month at exactly same effect on growth, its plane
  useless unless a player wanted more income. But artificially increasing income is not very good as financial
  section game balance/idea.

[Carl]

Many thanks for the feedback, colonyan!

Another Finding/Question.

In a town, there was a daily factory which consumes the milk as the final product.
I placed two bus stop in the town to cover the entire town, and the factory got production boost.
1.Is daily factory should get a "consumption" boost from the first place?
  If increased consumption rate contribute to above 100% growth speed, it would make some sense.
  (Which I assume does not happen)
  But the boost is big for just two bus stop and single bus. 1250>1450

It seems that the dairy has a large "passenger_boost", which (as I understand it) means that if more passengers are delivered to the factory then it will produce more. (This is unchanged from pak64, incidentally.) I agree that this seems somewhat bizarre, and I'll look into reducing or indeed eliminating the passenger boosts for some industries.

2.Does increased consumption rate affect base growth rate?

I'm not sure I understand -- could you explain the question a bit further?

[colonyan]

Simply put.

I think final consumer should start under default value.
Then the optimal pax/mail delivery to the final consumer increase back to the
full potential consumption speed.

So now it boost from 100% to above 100%, but I thinks its better to put as
below 100% to 100% as result of pax/mail delivery.

[Carl]

Ah -- I see now.

I agree completely with this point. Factories shouldn't be able to produce at their full capacity until they're getting passengers (i.e. workers) supplied to them.

We can do something like this in pak64.experimental, but we can't fully implement this feature without changing the program itself. For instance, we can't stop the factory from displaying '100%' without passengers and (e.g.) 200% with passengers. (You could post an extension request either in the main forums or in the Experimental forum to see whether the developers would be willing to change this.)

However, here's what we CAN do in the pakset. We could try lowering the production values of all the factories to a much smaller value, and then give these factories a large passenger boost. The effect of this would be that the factories would only reach "normal" levels of production when passengers are supplied. The downside of this would be that, when producing at "normal" capacity, the factory would display (e.g.) 500% production level. But as I said, that can't be altered within the pakset.

Any feedback on this latter idea would be very welcome.

[colonyan]

Indeed, number can be changed depending on the design and the nature of the industry.
Since pure 100% final consumption is getting taken account into the cities industrial growth factor.
I think integrating pass/mail sector to industrial freight sector can make ST really more dynamic, organic
bring in more complexity if its done right. Before I make any extension request, I will polish the idea more.

EDIT: For instance, you could reduce the boost on some and increase on other as you seems appropriate
depending on its nature.

[Milko]

Hello

I need help. If I wanted to create a "pak64exp" updated from source as I do?

Is there any script that is usable under windows xp?

Giuseppe

[greenling]

Milko
can your wish wait tomorow until 17:00 o clock?
I must morning go to Job and buy a tickit for a internetstick!

[Carl]

Milko,

I haven't yet figured out how to "mass-compile" -- so far I've just been manually compiling everything I've updated. But if you wanted to access the changes made since 0.1 then, because my files are disorganised, you'll find plenty of the .pak files themselves amongst the sources on github.

[Carl]

PREVIEW OF NEW FEATURES FOR 0.2: CITY ATTRACTIONS


Version 0.2, which will be released soon, will be the first big departure from pak64. The big theme is improving city attractions. Feedback is welcome!

The short version: Many new city attractions Organised 'sets' of city attractions corresponding to different sectors of the economy Main purpose: to better simulate passenger traffic between and within important cities                 National Museum (WIP) The long version: Pak64.Experimental 0.2 will more closely relate city size to the amount of facilities, attractions and amenities a city has. Here's an illustration. Imagine an area with one large city of 400,000 people and eight smaller cities of 50,000 people. There are a total of 800,000 people in the region. Now imagine a random passenger appearing this region. What's the percentage-chance that the passenger will be travelling to the large city? In Simutrans, the answer will usually be more or less 50%. But in reality this chance should be much higher. Why? Because jobs, hospitals, entertainment, etc, will mostly be located in the large city. The largest employers will be based there, and the largest entertainment venues will be located there, and the best hospitals will be located there. So although the city only has half of the region's population, we should expect it to attract significantly more than half of the region's passenger traffic. In Simutrans, the way to simluate this is to give the large city more 'attractions'. Attractions don't add population to the city but do attract more passengers. Pak64.Experimental 0.2 will greatly increase the frequency of attractions. In version 0.2 there will be lots of attractions corresponding to different `areas' of the economy, such as education, health, finance, entertainment, and government. Some attractions (e.g. a parish church, a city park) will be present even in the smallest cities. But as a city grows, more and more attractions will be built: a small school, a doctor's surgery, local newspaper; and so on. Here's an example of one 'track' of attractions, the `health/science' track: Note that 'Doctor's surgery' appears three times here. That's because as a city grows, it will come to need more than one doctor's surgery. The same will be true of schools: a large city will need several schools. Large cities might also have multiple art galleries, libraries, sports stadiums, etc. (By the way, the 'citizens' figures in the above table are just for example -- they're likely to change as I'm still testing how this will all work in-game.) Certain 'sets' of attractions include special unique buildings which will only be built in very large cities. For instance, a large city will build a National Museum, a National Gallery, a Central Bank, or a Stock Exchange. These will be classed as 'monuments', so only one of each kind will ever appear on a map. Of course, not all of the buildings mentioned here are "attractions" in the traditional sense. In this pakset, however, an "attraction" is just anything which (a) doesn't contribute to the city's population but (b) generates a significant amount of traffic. So schools, banks, etc, are perfect candidates. What's more, having a building as an "attraction" allows for greater control over exactly when it appears in a city. That's crucial for many of the types of buildings discussed here. These changes will, I hope, allow for better simulation of passenger flows both between cities and within cities. I'm currently gradually working through making all these new attractions -- when I've done so, 0.2 will be ready for release. I have around 20 left to do!

[greenling]

Carlbaker i have a Tip for you!
Please use the Mainmenu out pak128.Britain.
In the Mainmenu from pak128.britain Be are now all waytyp useable.

[prissi]

Just a warning, as I see an asymmetric building: Be aware that you need to specify also a rotation of that building.

Apart from taht, more attraction in pak64 style could easily benefit also standard.

[colonyan]

Small notes.
1. I think there is little too many city cars running around in the beginning of the game.
2. Are there specific reason for catchment area to be set as 3 spaces?
3. Purchase cost of vehicles/vessels are very low in general.
4. Due to 3, fixed maintenance cost is very low too in my opinion.

[infernalmachine]

I agree 100% with Colonyan on these points.

However, I discovered that city_cars is not set in pak64-exp simuconf.tab, but in the Exp 9.12 simuconf.tab.  It has been set to 16 (the highest possible value).  I don't know why.

I think pak64-exp should set its own values for cars, both this city_cars one and the special 3 that determine how many drivers will take (or won't take) public transport. Clearly these latter 3 will influence the economy of passenger travel, while the first determines whether road vehicles are feasible to use.

I usually play pak128.open, and the low vehicle prices in pak64.exp were a real shock.

But I did find that it's nearly impossible to break even shipping paper (by rail or by sea, didn't even try with trucks because of the traffic).  I tried in 2 games both with timeline.  First in 1930 and then in the recommended 1956, in case 1930 was too early.  It didn't make a difference. Lines are always in the red. OTOH books are very well renumerated and more than make up for the loss, so perhaps this problem is intended behaviour?

Speaking of timeline and dates, are you planning to keep the 1956 recommended starting date?  Speaking for myself, I prefer starting earlier than that.

[colonyan]

More general sense finding.
In my logic, it is always better to reduce the route length shorter.
Thus I tend strongly to place stops so in the way that the route is shortest.
What result is that station/stop at furthest possibly placed from the industry.
This is pronounced as the catchment area becomes 3.

This also create a controversy from the initial logic that I could make the route much longer up to 14 tiles longer and even more depending on the size of the industry building to obtain more revenue since Simutrans
     ***Rewards player with revenue based on the distance.***

As an actual game example, a truck transporting oil from oil well to power station gets
25 credit when stations are placed closest, 100 credit when placed further away as much as possible.
If this is whats its meant to be it ends there but its kind of silly.

Am I taking this too serious...? But it seems its not logical.
Or, any time the stop is not placed directly beside the building, it must generate some kind
of penalty depending on the distance its put apart.

EDIT: Distance between industries could be set much higher. Simply. (But then, it could become
source of excessive profit if vehicle maintenance cost / per cargo value are not balanced.)

___

EDIT2: After some observation, City car generation level 11 or 12 seems more appropriate.

[Carl]

Hi both,

Many thanks for testing, and for your useful feedback!

I'll take the issues one at a time:

1. City cars: good call on this. I'll make sure that the pakset's configuration files specify a lower value in the next version. (As I understand it, these will take precedence over whatever is found in Experimental's simuconf.tab file).

2. Low purchase costs and fixed maintenance costs: There is a known bug in Experimental 9.12 concerning vehicle costs and fixed maintenance costs, and this may be causing many of these problems. This will be fixed in the next version of Experimental, and once this is released we will have a better idea of which vehicles need to be more expensive to buy/run. In general, the fixed maintenance costs have been set quite conservatively at the moment to ensure playability -- the idea is that these will be made more accurate and appropriate through testing.

3. Paper: I'll increase the value of paper in the next version. I'd like it to be possible to make a profit, not least because I'm adding a new city industry ('stationer') which receives paper.

4. Catchment area of 3 squares. I set this higher than usual mainly because cities tend to 'sprawl' far more in Experimental than in Standard -- making it harder to cover the whole city with 2-square stops. Do you think 3 is too high, on balance? Colonyan -- your story about oil makes me think that it might be appropriate to reduce this to 2. Any further thoughts on this?

5. Recommended starting date: although this can be set by the player each time they start a new game, the default value should presumably reflect the year that it's 'best' to start in. I'm not really sure how to judge this.

Just a warning, as I see an asymmetric building: Be aware that you need to specify also a rotation of that building.

Apart from taht, more attraction in pak64 style could easily benefit also standard.

Thanks for the tip on the asymmetric building.

Of course, if any of the new attractions make the grade then I'd be more than happy for them to be ported to standard.

[colonyan]

Raw Wood costs and weight similar to oil but raw wood transporting train car per kilo
maintenance is way lower resulting in the freight operation very lucrative.

Edit:Add
Going back to station/stop catchment area.
I think you can leave it to 3 since city tend to sprawl more.
I think you can make the problem little less significant by fine tuning the
car perkilo-maintenance and fixed maintenance.

[colonyan]

one large city of 400,000 people and eight smaller cities of 50,000 people.

The thing is that in ST, every single cities grow following exactly same rule.
The result is the cities of resembling sizes.
I want cities to have different growth schemes.
There is a button to allow/disallow the growth of city but should a mere transportation entity should have
such an important power?

[sdog]

The thing is that in ST, every single cities grow following exactly same rule.
The result is the cities of resembling sizes.
I want cities to have different growth schemes.
There is a button to allow/disallow the growth of city but should a mere transportation entity should have
such an important power?

Code: [Select]

# The rate at which towns grow depends on their size. There are three different size categories:
# "Villages", "Cities" and "Capitals". The following settings define the thresholds (in numbers
# of population) above which towns become "Cities" and "Capitals". Anything smaller than
# city_threshold_size is a "Village".

city_threshold_size = 2500
capital_threshold_size = 25000

# These values represent the rate at which towns grow. The raw growth number is *divided*
# by the growth factors; ergo, the lower the number, the higher the growth. Longer games
# should have less growth, whereas shorter games do better with more growth.

growthfactor_villages = 895
growthfactor_cities = 600
growthfactor_capitals = 350

that's from pak128.britain-experimental's simuconf.tab
there are different growth factors for different city sizes.

here's the pak128 standard version:

Code: [Select]

# town growth is size dependent. There are three different sizes (<1000, 1000-10000, >10000)
# the idea is, that area increase by square but growth is linear
growthfactor_villages = 400
growthfactor_cities = 200
growthfactor_capitals = 100

It is quite sensible to allow the player to disable city growth. consider it not as part of the simulation, but as setting the game, eg. the transport company doesn't terraform the map either, the player chooses a map.

[colonyan]

there are different growth factors for different city sizes.

There are three different rule depending the size of the city, yes.
But it is still the same from the fact that all cities follow the rule.
They just have different rule on different times. If the rule is taken as the
history, then all cities go through exactly the same history(growth rule).

Edit:Add If cities size proportions maintained, what carlbaker propose
will work. Its just that I borrowed this occasion to say that all cities
will grow following the single rule. A rule which growth speed rule differ only
what the size of the city. But not what city's characteristic is. End of Edit

Since I can not give any alternative, I will say no more.
(Well its not that what I will say will be good enough neither so... )

but as setting the game,

I understand player can setup the map in the very beginning.
But one should not being able to alter it while game goes on.
It feels more natural that the button is exclusive to the
public player mode.

[sdog]

I understand player can setup the map in the very beginning.
But one should not being able to alter it while game goes on.
It feels more natural that the button is exclusive to the
public player mode.

that is reasonable, perhaps you should write an extension request. Before netgames there was not much need for the distinction of rights normal or public players have.

[Milko]

Hello

4. Catchment area of 3 squares. I set this higher than usual mainly because cities tend to 'sprawl' far more in Experimental than in Standard -- making it harder to cover the whole city with 2-square stops. Do you think 3 is too high, on balance? Colonyan -- your story about oil makes me think that it might be appropriate to reduce this to 2. Any further thoughts on this?

Very good, catchment=3 for me is the best setting.

Giuseppe