Recent Posts

Pages: [1] 2 3 4 ... 10
1
Pak128.Britain-Ex / Re: Wainwright
« Last post by jamespetts on Today at 09:09:37 PM »
Splendid, thank you for that - it is excellent to see you back in production of lovely new things for the pakset!

One thing, however: I have been working lately on implementing the passenger and mail classes feature, and also the logistics feature. This involves adding a number of new parameters to industries (some of them have been available since the passenger generation work a few years ago but had not hitherto been used in the pakset).

These parameters are:

population_and_visitor_demand_capacity
employment_capacity
mail_demand

class_proportion[0]
class_proportion[1]
class_proportion[2]
class_proportion[3]
class_proportion[4]
class_proportion_jobs[0]
class_proportion_jobs[1]
class_proportion_jobs[2]
class_proportion_jobs[3]
class_proportion_jobs[4]

Adding these to all the industries retrospectively is a large amount of work, so it would be exceedingly helpful if you could add these parameters to new industries that you create.

Many of the industries on the passenger-and-mail-classes branch of Github have these parameters set (and those that do not currently have them set should have them set shortly). Here is an example of an industry that does have the parameters set, as well as some notes to explain how to calibrate a number of them (especially employment_capacity).

The upper group above are all things that will work and be recognised in the current master branch, whereas the lower group will only work in the passenger-and-mail-classes branch (but the .dat files with these things set will still compile in the master branch).

The population_and_visitor_demand_capacity sets either the population if the building is residential or the visitor demand if it is non-residential. Visitors are any arriving passengers who do not work there: those who work there are commuting passengers. This parameter works in the master branch. However, in the passenger-and-mail-classes branch, this has added significance for consumer industries. Consumer industries will now only deplete their stock in proportion to the number of visiting passengers that actually arrive. For example, a consumer industry that now depletes its stock at a fixed rate of 100/game month (i.e. 6 hours and 24 minutes on the short time scale) in the master branch and that has a visitor demand (after adjustment - the figure that you input will not be the same as the actual value in the game because of automatic adjustments) of 10 would now deplete its stock by 10 for every arriving visiting passenger (so that the stock depletion rate would be the same as in the master branch if the actual visitors match the visitor demand).

The employment_capacity sets the number of people employed by the industry (again, this figure is subject to adjustment: see the notes in the comments in the file here for a worked example). This has effect in the master branch, but, as with visitor demand, is more important in the passenger-and-mail-classes branch. In that branch, an industry will only attract commuting passengers if it is producing. An industry that is not producing will lay off its workforce, and commuting passengers will not start their journey to that industry: if they have reachable alternative destinations, they will travel to one of them, or else they will register as a failed journey.

Similarly, an industry with less than a certain complement of staff (I think 80%) will produce at a reduced rate owing to a staff shortage, that rate reduction being proportionate to the degree of shortage. A consumer industry with a serious staff shortage will close, and customers (i.e., visiting passengers) will no longer be able to start their journey to the consumer industry, which will prevent it from depleting its stock.

The mail_demand parameter sets the building's mail demand (again, this is adjusted) and works in the current master branch. There is no current direct link between an industry's productivity and its mail fulfilment, but this parameter is likely to be more important when the town growth algorithm is changed. It is in any event important properly to calibrate mail production.

The class_proportion and class_proportion_jobs figures (one for each of the five classes) work only in the passenger-and-mail-classes branch (but are simply ignored by the master branch makeobj, so can safely be added to industries intended for use in the master branch for the present). They set, respectively, the proportion of (1) population (for residential buildings) or visitor demand (for non-residential buildings); and (2) workers that belong to each class. For example, an office building might have quite a high proportion of higher classes, whereas a factory might have a higher proportion of lower classes. The classes are not intended to be quintiles, so there will not be an even number of people in each of the five classes (and do bear this in mind if producing residential buildings, to which these parameters also apply).

All of these parameters apply equally to town buildings that are not industries as they do to industries.

As should be apparent, these new parameters will be very important for the game to balance correctly once the new features are fully implemented (and this should be fairly close - the pakset work is the main thing delaying merging this with the master branch). You should try to use historically accurate figures in so far as possible, and extrapolate from known data for similar industries (including using the data that I have added for other industries and town buildings) where data cannot be found.

Thank you again for your splendid work - it is much appreciated.
2
Simutrans Extended Development / Re: passenger and mail classes
« Last post by Ves on Today at 08:52:02 PM »
This is good except for one issue: the catering level used by each passenger depends on the class of passenger, not the class of accommodation. A wealthier passenger does not buy a cheap meal simply because he/she has decided to travel in a lower class of accommodation. We do need to show the comfort modification for the catering irrespective of the class of accommodation.

Hmm, I dont really understand. Are saying that a p_class[4] passenger riding in a p_class[2] accommodation in a train featuring a catering car level 2 would not get the bonus comfort?
Or do you mean that a p_class[4] passenger riding in a p_class[2] accommodation in a train featuring a catering car level 4 would go and eat in that car, even though he has purchased a p_class[2] ticket?
I did write it a bit clumpsy however and it might just be a misunderstanding:
The +20 will come to all classes at or above the catering level. Should it do something else?
Quote
Yes, indeed, that would work well.
Great! It will be located above the class sections if there are two classes or more!

edit:
clarification
3
Simutrans Extended Development / Re: passenger and mail classes
« Last post by jamespetts on Today at 08:42:45 PM »
This was the trade off from incorporating it directly in the simconvoy_t and simhalt_t instead of in freight_list_sorter_t. A better way overall would be to have it in the freightlistsorter, changing the sort button to a scrolled list and add a bunch of new sort options, but I had to give up on that since I could not figure out all required steps in the freightlistsorter. I think some remains of my attempts are commented out in that file.
Therefore, I initially did not want to do too much work in the sim..-files. I do, however have an idea that should be quite easy to implement that would achieve what you want.

Excellent - do let me know how you get on or if you have any queries.

Quote
I have made the comfort display in the depot window (and elsewhere) follow this syntax:
"Base comfort + catering comfort"
So if the catering car has a comfort of 100 and is a catering car, it would look like:
"100 + 20"
I like to know the logic behind the comfort, and I think doing it this way helps the player see through the mechanism.
What do you think?

Note that the "+20" only comes visible if the cars class matches its catering level.

This is good except for one issue: the catering level used by each passenger depends on the class of passenger, not the class of accommodation. A wealthier passenger does not buy a cheap meal simply because he/she has decided to travel in a lower class of accommodation. We do need to show the comfort modification for the catering irrespective of the class of accommodation.

Quote
So you mean in the depot window something like:

P_class[0]: 100
P_class[1]: 50
Total: 150

That would actually also solve the overcrowded display issue.

Yes, indeed, that would work well.
4
Simutrans Extended Development / Re: passengers dont take reassigned classes
« Last post by Ves on Today at 08:10:07 PM »
Hmm, I get a crash now.

How to reproduce:

* Open the same savegame as before (classes_GUI_vehicle_tests_4.sve).
* Delete the two white busses on the "(26) Line"
* Build two new identical busses and send out from depot
* When the busses are on the street and have started on their route, open their info window and reassign their classes to p_class[1]. Do this for both busses.
* Now just fast forward some time and the game will crash.
6
It seems as it is libpng version somthing....
Do you have working Makeobj-Extended from latest passenger-and-mail-classes branch to compile latest pak for it?

Do you mind to share here or somehow please?
I tried to compile libpng myself... but lack of VS2015 knowledge I am getting nowhere..  :o
7
I dont think you should touch the makeALL.mos at all, only the parameter.mos. Try get some clean .mos-files and modify only the file path.

My parameter.mos looks like this:

Code: [Select]
#!/bin/bash

# Einstellungsdateifuer die PAK-Erstellung per MOScript
# Bitte anpassen und als parameter.mos umaendern

#der Ort wo sich makeobj befindet absolut
#Absolute filepath to where makeobj is located
!makeobj=makeobj-extended.exe

#der Ort wo die Dateien hinkopiert werden sollen absolut MIT / am Ende
#You need to specify the location of the folder you want to build the pak in here
!OUTPUT=Pak128.Britain-Ex/
I think that with this setup it will only look in *this* folder for the makeobj, and it will create the pakset in *this folder*/Pak128.Britain-Ex/, so it should be failproof as long as the makeobj is located in the same folder as the .mos-files.

However, I think I recognize that error, and that it indeed is because of the lib-somethings. I remember there being some threads about it a while ago.
8
[FR]Français (French) / Re: Renouvellement des images SNFOS
« Last post by gauthier on Today at 06:44:40 PM »
Hem ... je suis désolé de te répondre ça si tu as passé du temps là-dessus (tu aurais mieux faite de demander avant) mais ce n'est vraiment pas l'idée de ces images ! Le but est de montrer des addons en action, montrer une image trafiquée est en quelque sorte "mentir" sur la qualité des addons qui y sont montrés et ça me gène énormément.
9
Changes I made,
I copied and paste Makeobj-Extended.exe I compiled in this pak folder, and

for makeALL.mos,
I have changed

makeobj=%makeobj%
makeobj=Makeobj-Extended.exe

for parameter.mos,
changed

makeobj=C:\Users\James\Documents\Development\Simutrans\simutrans-extended-sources\simutrans\makeobj-extended.exe
makeobj=D:\Proj\simutrans\makeobj-extended.exe
OUTPUT=../../simutrans-extended-sources/simutrans/Pak128.Britain-Ex/
OUTPUT=D:\Proj\simutrans\pak\

It now recognise makeobj-extended.exe and I think executes correct, but ran into another error.




I noticed in makeALL.mos file all defined directories are with / forward slash, but on my windows explorer directory is expressed with backslash \.
Which it worked by modifying directories on parameter.mos file.

Should I change all forward slash to backslash on makeALL.mos file?
Or that might be not a problem, or if it seems is there easy way to change all slashes?

Or is it something to do with libpng?
10
Ah!

I figured, that I was confused between parameter.mos and makeALL.mos.
Now I have found parameter.mos and will have a look at that file.  ;)
Pages: [1] 2 3 4 ... 10