News:

The Forum Rules and Guidelines
Our forum has Rules and Guidelines. Please, be kind and read them ;).

Load long distance passengers patch

Started by Markohs, September 25, 2014, 10:22:07 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

DrSuperGood

QuoteI downloaded the binary by Markohs, then put it in the simutrans folder. I got a "missing dll" message.(libbz2-2.dll)
It appears to require several non-standard dlls to run. These are not part of the simutrans distribution package and their name points towards custom builds of standard libraries. Normally simutrans internally links these libraries so that they do not manifest as external dependences.

QuoteWhat should i do?
Since they are non-standard there is nothing one can do until he uploads them or rebuilds not needing them.

Ters


DrSuperGood

QuoteThey are standard mingw dlls.
Except the sort of person who has mingw installed (so has access to them) can build simutrans from the patch file. The sort of person who needs a pre-build executable is likely not to have mingw installed and will be very confused when he extracts the executable into a working simutrans directory and gets dll missing errors. However I cannot comment as I used Visual C++.

Markohs

Yep, it has dependencies with mingw libraries, dunno why, I just used the standard build mechanism. I just install mingw as a tool to check if my code compiled in other platforms, I am way more comfortable using Visual Studio, the 2013 version at the moment.

Well, I re-compiled it with MSVC2013, all libraries should be static here, except the pthreads one, that I included in the .zip.

It *might* require you to install visual studio libs, they are of no harm to your computer, you can find them here, in microsoft's webpage:

http://www.microsoft.com/en-us/download/details.aspx?id=40784

The simutrans binary I compiled is here:

https://dl.dropboxusercontent.com/u/30024783/simutrans_longdistance.zip

ronnie89b

Thank you very much for your efforts, Markohs!
However, finally i successfully solved my compiling problem!


Markohs


Ters

Quote from: DrSuperGood on October 09, 2014, 08:52:42 PM
Except the sort of person who has mingw installed (so has access to them) can build simutrans from the patch file.

You don't need mingw installed. In fact, having mingw installed doesn't help. The runtime dependencies are separate downloads from the development tools, headers and link libraries. Finding the proper zip file to download within the directory hierarchy can however be daunting even to a developer.

Ters

I have done some fast forward testing with a A-B and A-B-C line pair. Without the option turned on, passengers for C starts accumulating on A. With the option on for line A-B-C, it actually seem that passengers get from A to both B and C with greater efficiency that my previous setup (A-C + A-B-C). I do however get an accumulation of passengers between B and C, but that's likely because I simply changed the A-C line to A-B, which reduces the capacity between B and C. I need to re-test with more B-C capacity.

Markohs

In my tests the option proved to be very useful. The only problem is on your example, passengers from B to C indeed, if they begin to pile up,  you can add capacity to the the long distance or add a B-C regional line. This helps in the way it reduces the number of transfers on your network and makes train more attractive vs airports.

DrSuperGood

But what about the following case?
High Speed = A <> C <> E
Low Speed = A <> B <> C <> D <> E
Ideally you would want people to transfer from the low speed to the high speed as it would give them less in-transit time (and this is what experimental is meant to try and achieve since passenger in-transit time is important there). Currently in standard people from B would stick on the low speed line through to E even though it would be faster to transfer through C. This problem is emphasised more if more stops are placed between the high speed serviced stops (which is what it usually is in real sessions).

The feature of furthest stop first has a very small scope of usability and there are many other mechanics that could greatly improve transport efficiency. It targets a few very specific line layouts that most players will struggle to encounter outside of accidently. It is probably about as useful as the "wait for 1/X months" option however (I really am struggling to find a use case for it that works, I think it may even be broken in RC 120.0).

What if there was an option to make a line "express"? What this does is mean that people will prioritize transferring off immediate "non express" marked lines onto "express" lines even if it results an additional transfers. As far as route finding goes, a transfer from non express to express would appear cheap if not free.

I have a real life example that goes with this. There is a train that runs nearby where I live that goes all the way to Edinburgh. However it is actually slower to take that commuter train than to transfer at Glasgow to a more direct Edinburgh service. Despite an extra transfer, over 30 minutes in-transit time are saved.

Ideally one would want these transfers to be automatically computed, possibly based on line maximum speed and stop distance (ignoring transfer wait). However until then some option to manually prioritize one line over the other in a way that will encourage transfers would be very useful. However maybe this belongs in a separate topic.

Vladki

If someone wants to try long distance patch on Linux, here is 32-bit binary: https://uran.webstep.net/~vladki/simutrans/sim-gcc4-longdist

DrSuperGood - I was thinking about something similar as you point out - I have two lines: A-B-C-D and A-D. There are lot of passengers from A to D but only a few to B and C. When the commuter line comes in, it load those waiting for B and C and fills the rest of the vehicle with pax for D. But when it arrives to B, there are more pax waiting to get on than those that want to get off, so some of them are left waiting for the next round trip - pax for D are occupying the space. But they could have taken the fast direct connection (which arrived just a short while after the commuter line). I was thinking about some way to tell the passengers to prefer lines with less stops. It may be useful in some places and would simulate the real life better. But this would deserve a separate topic.

Ters

Quote from: DrSuperGood on October 12, 2014, 06:30:33 PM
But what about the following case?
High Speed = A <> C <> E
Low Speed = A <> B <> C <> D <> E
Ideally you would want people to transfer from the low speed to the high speed as it would give them less in-transit time (and this is what experimental is meant to try and achieve since passenger in-transit time is important there). Currently in standard people from B would stick on the low speed line through to E even though it would be faster to transfer through C. This problem is emphasised more if more stops are placed between the high speed serviced stops (which is what it usually is in real sessions).

I think that will complicate routing too much, as simply finding the first line that takes you somewhere will not be enough anymore. It is also very likely that the slow line will get the passengers there sooner, as there is no such thing as connections in Simutrans, and the express train/bus might get stuck behind the slow train/bus. Even in real life, this may be the case. I'm not familiar with slow and express service pairs like that described, except as alternate departures, and in that case, switching from slow to express will make you later. A-B-C-D-E + A-C-E-F-G-H is more familiar, but in that case, the latter has far fewer departures than the former, so someone going from A to E would normally choose the former.

Markohs

As Ters expressed already, there are no "transfers" in simutrans, passengers won't leave a train that takes them to their destination, to wait for a "better one". Implementing that, it's not a easy thing, there are lots of complications and aspects to treat. I think it's better this way.

The thing with this long distance loading preference, is that's suposed to be a simple change, that doesn't imply much extra CPU usage, it's simple, and solves many (maybe not so many) problems our players encounter when making long distance, multi stop train lines, that's a concept many players will tend to do, because it's something you find in real life, and even on games like Transport Tycoon. Right now the loading mechanism performs horribly bad, in train lines with more than 2 or 3 stops, that's what I tried to improve, it's a simple solucion and works good enough. And even that everyone in this forum *knows* the current implementation of loading performs horribly bad in this situation, I see that nothing it's done to improve it, just commenting in this thread, that I foresee, will end in nothing, as usual (even there are many good ideas and comments expressed here), because thay won't end being accepted by our leader. And you all know this is true.

One of the other things I liked about this solution is that opened the possibility of adding yet other loading policies to the game. But what I can understand is that other more complicated implementations of mechanisms related to that you were all talking about, are maybe not desirable for the average new user to simutrans. This is related to some of my personal thinkings about how simutrans is implemented, and what Simutrans Experimental is doing, and why they are separate projects.

My personal view of this, is that some or all of the new concepts implemented by Experimental, should be added to the standard simutrans, but in the form of plug-ins. So, simutrans should be just one game, with the ability to install plug-ins with extra capabilities, for example the "confort" factor of Experimental, or the more complicated routing present there.

Decentalization of simutrans development is a must, imho. We should be able to open this to all developers, and if one community plug-in is very popular, maybe ship it with the standard distro, by defaul. Current development it's struck, because of the strong censorship. Opening the game to third-party code, whould improve it's development quality. Simutrans must be made modular, and slimmed. But that is ofc, just my personal opinion, and this is off-topic here.

prissi

I am not opposed to an improved load mechanism but:

This long distance loading does not work better than the current one but for a very special borderline case. However as soon as there is not enough capacity, you will starve passengers either shorter or long haul passengers. The game is about transport, i.e. not starving any of them.

You argue that long distance passengers gets more income. No, that might be wrong. See A-B-C-B-A, hub in A and B, all passengers in B starve and lot of further profit is lost.

If you really want to long long distance first, you have to look at how far they still have to go. That way would really prioritise long distance without the risks of starving intermediate hubs and other stuff. (Same would then working also for waiting times.)

On a different note: I would like to make simutrans modular, but I do not see an easy way to do this. C++ is not really meant for this and DLLs for much more will be very difficult (and only work for windows or rather different for each OS). Especially for core stuff like routing, where you have to access almost all map and many internal structures.

Markohs

About long distance: Well, as you say the mechanism  is not perfect, but it's a tool, so you got more control. On your example you got a line ABCBA marked as long distance, and *another line*, AB. But well, it's not perfect either, I can agree on that.

About modular, maybe we can just implement something in the style of java interfaces, and make plugins include those files, not against the full featured .h . That, giving support to dynamic loading of .dll and .so, and some work on the GUI so plugins can hook their buttons, plus some hooks across the code where they can register themselves as callbacks (maybe on step(), or sub-systems inside step(), like this particular point in simhalt.cc) couls be enough. It's not a easy task, but maybe it's worth it, what do you all think?

We can also create artificial managers, that only take action when interacting on plugins, and hide the complex object management, and copupling, to the plugin, and just offer a pre-set of functions we want to expose. Something similar of what has been done by Dwachs with squirrel.

EDIT: Something on the line of this: http://www.drdobbs.com/cpp/building-your-own-plugin-framework-part/206503957

Ters

Quote from: prissi on October 13, 2014, 02:00:30 PM
See A-B-C-B-A, hub in A and B, all passengers in B starve and lot of further profit is lost.

What I believe long distance loading is useful for is rather Central station 1 - Suburb 1 - Suburb 2 - Central station 2, with local trains also serving one or either half plus possibly other lesser stations. The idea is that passengers to and from the suburbs should not have to go into the central station to catch/disembark a train passing through closer station.

If 90% of the passengers at Central station 1 wants to go to or via City 2 (Central station or suburb) and 10% wants to go to Suburb 1, but far fewer than those 10% wants to go from Suburb 1 to City 2, trains will run with just slightly more than 90% load between Suburb 1 and Suburb 2. This distance will, at least in my games, be much longer than between suburbs and the central station. In pak64, especially as the 20th century comes to a close, that much unused capacity can result in a loss. This only gets worse the more people travel to the suburbs. Adding more local trains between suburb and central station doesn't really work, since the express train might end up taking most of the passengers anyway due to unpredictable timing, resulting in the local train running with many empty seats as well. The solution is either to run the express train between the suburbs rather than the central station, or have the express trains drive straight through the suburb stations, neither of which are intuitive to me based on how real trains run.

I have yet to see the full effect expected of long distance loading, although I did easily overcome the problems I mentioned in post #77. Long distance did still improve throughput over just plain standard loading, although to a lesser degree. I still have to look a bit closer on how the economy is affected. A very profitable mail train drowned out the slightly unprofitable passenger trains. Might not be until next weekend, though.

Quote from: prissi on October 13, 2014, 02:00:30 PM
On a different note: I would like to make simutrans modular, but I do not see an easy way to do this. C++ is not really meant for this and DLLs for much more will be very difficult (and only work for windows or rather different for each OS). Especially for core stuff like routing, where you have to access almost all map and many internal structures.

Not only do you need to access the internal structures, which I don't think is that problematic in itself, but the plugins will likely need to add their own fields to existing data structures. I can't see how this can be done without sacrificing a lot of performance optimalizations. These extra fields must also be saved and loaded in the savegames, so the loading (and even the backwards compatible saving) will not only have to deal with the version of Simutrans, but also of each plugin. Plugins also means that Simutrans won't be able to change it's internal data structures as freely, without risking breaking popular plugins.

Certain types of plugins are easier to provide for, using a much simplified view of the game state, but I can't see how that can be enough for any of the features discussed here.

Markohs

Quote from: Ters on October 13, 2014, 04:16:01 PM
Not only do you need to access the internal structures, which I don't think is that problematic in itself, but the plugins will likely need to add their own fields to existing data structures. I can't see how this can be done without sacrificing a lot of performance optimalizations. These extra fields must also be saved and loaded in the savegames, so the loading (and even the backwards compatible saving) will not only have to deal with the version of Simutrans, but also of each plugin. Plugins also means that Simutrans won't be able to change it's internal data structures as freely, without risking breaking popular plugins.

Not really, the plugin can handle and store that data in its private memory, and store id's or pointers, or maybe hash tables to relate the data, and it's extra data.

About the save game, the system can just ask the plugin to serialize that info, and we just store it as an appendix to the save game, the plugin is responsable to reasemble its data.

Plus, many plugins that come to my mind, won't even need storing data, some can be extra GUI frames, or just operate iterating current data, like for example, the long distance patch, could be written in a plugin, and whoudn't need extra info, just a list of lines that are considered "long", and a a few callbacks, and extra GUI elements.

DrSuperGood

I would generally recommend against plugins for Simutrans. One of the key features of Simutrans is that it performs quite well on older or weaker systems. Although I agree that plugins do not necessarily have to perform poorly, I still doubt that they will perform as well as native functionality.

Take a look at the experimental server. That game is on a 7,000*5,000 map with over 20,000 convoys (half or more probably moving all the time) with several thousand factories and it still performs reasonably on a modern computer. If one starts mixing in plugin functionality which each store data in their own hashtable like systems and possibly even have to change languages I have a feeling a lot of that speed will be lost. Especially for highly key features such as routing/path finding any kind of slowness would majorly affect the performance of the game.

QuoteAbout the save game, the system can just ask the plugin to serialize that info, and we just store it as an appendix to the save game, the plugin is responsable to reasemble its data.
Each plugin would needs a separate indexed entry to a block of its data. You cannot rely simply on a stream approach loading plugins sequentially as they may be turned on or off or have their order changed from session to session. Additionally a bad plugin could cause all other plugins to corrupt unless their stored position is always known. Obviously only affects reading as with writing the plugin determines how much space it needs. Each plugin needs a unique universal identifier field to avoid data collisions, it also needs a version field (or it can append that to the start of its block, however seeing how all plugins should have one it might as well go as a table field) and block metrics (location and size). Unless people plan to use several thousand plugins, a simple unordered list of entries that is linear searched should suffice although one could optimize further and store them as a simple binary tree on the plugin unique identifier.

There is also the issue of plugins and networks. Even if a plugin is GUI only, server administrators might not want them to keep the server fair. Otherwise nothing would stop me from writing a plugin "play bot" and let it run 24/7 connecting all passengers and industries to dominate a server.

Plugins may also need pak defined information such as for specific quantities for certain object types. Since modifying a pak directly might not be possible (eg a closed source pak like 192 comic) then you need a plugin pak extension file which is loaded in parallel to the actual pak data so that additional information for pak objects can be provided separately.

Markohs

Quote from: DrSuperGood on October 13, 2014, 05:31:49 PM
I would generally recommend against plugins for Simutrans. One of the key features of Simutrans is that it performs quite well on older or weaker systems. Although I agree that plugins do not necessarily have to perform poorly, I still doubt that they will perform as well as native functionality.

Nowadays, CPU shoudn't be a problem. And the plugins are written in C++, remember nowadays modern games do this in interpreted languages like LUA, and they run good enough.

Quote from: DrSuperGood on October 13, 2014, 05:31:49 PM
Take a look at the experimental server. That game is on a 7,000*5,000 map with over 20,000 convoys (half or more probably moving all the time) with several thousand factories and it still performs reasonably on a modern computer. If one starts mixing in plugin functionality which each store data in their own hashtable like systems and possibly even have to change languages I have a feeling a lot of that speed will be lost. Especially for highly key features such as routing/path finding any kind of slowness would majorly affect the performance of the game.
Each plugin would needs a separate indexed entry to a block of its data. You cannot rely simply on a stream approach loading plugins sequentially as they may be turned on or off or have their order changed from session to session. Additionally a bad plugin could cause all other plugins to corrupt unless their stored position is always known. Obviously only affects reading as with writing the plugin determines how much space it needs. Each plugin needs a unique universal identifier field to avoid data collisions, it also needs a version field (or it can append that to the start of its block, however seeing how all plugins should have one it might as well go as a table field) and block metrics (location and size). Unless people plan to use several thousand plugins, a simple unordered list of entries that is linear searched should suffice although one could optimize further and store them as a simple binary tree on the plugin unique identifier.

There is also the issue of plugins and networks. Even if a plugin is GUI only, server administrators might not want them to keep the server fair. Otherwise nothing would stop me from writing a plugin "play bot" and let it run 24/7 connecting all passengers and industries to dominate a server.

Plugins may also need pak defined information such as for specific quantities for certain object types. Since modifying a pak directly might not be possible (eg a closed source pak like 192 comic) then you need a plugin pak extension file which is loaded in parallel to the actual pak data so that additional information for pak objects can be provided separately.

All the issues you menctioned are doable, you sound like that was rocket science. There are technical solutions for every problem you raised. We don't need to expose the whole simutrans inner program, just what we feel it's worth doing. I'm not saying it's a easy task, but for the same reasons you raised we'd never have incorporated double height code, started overhauling the GUI or add network mode to simutrans. We are programmers, after all. Don't you think? :)

What I just wanted to know is if it's worth doing it, or not, you oppinions on this. :) If this projecct ever takes off, it won't be certainly be readybefore some months, being optimistic.

prissi

Ok, going offtopic in the fullest now: My feeling is that a scripting language is probably the best you can do for a crossplattform game. Maybe one can somehow incorporate Java (although I have no Java knowledge how to do this) or another JIT language. Then the scrips will be laoded and translated at the start and performance will be back to normal.

Especially with FullHD tablets where weaker CPUs meet insane amounts of pixels, the performance (although most graphical) will stay an issue.

isidoro

Going  back to the loading topic: why not just load proportionally to the amount of passengers/goods waiting?

For example: if 50 passengers wait for A, 20 passengers wait for B, and 30 passengers wait for C, and a vehicle with free space for 50 passengers arrives, just load 25 for A, 10 for B, and 15 for C.

It is not worse than the present system and somewhat prevents starvation if a station is (hopefully temporarily) not well served.

sdog

Quote from: isidoro on October 13, 2014, 10:51:47 PM
Going  back to the loading topic: why not just load proportionally to the amount of passengers/goods waiting?

For example: if 50 passengers wait for A, 20 passengers wait for B, and 30 passengers wait for C, and a vehicle with free space for 50 passengers arrives, just load 25 for A, 10 for B, and 15 for C.

It is not worse than the present system and somewhat prevents starvation if a station is (hopefully temporarily) not well served.

That is an excellent idea. On average it has the same results as random loading, but is much simpler.

in the A-B-C local and A-C-D expres train example, one can shift the odds for mostly passengers to D entering it, by providing more local trains and reducing waitng B and C passengers. The advantage to the present system is, that this still works when the number of people waiting there for each destination exceeds the trains capacity. In which case the express train should it come first would fully load with passengers to C, even when there are more passengers for D are waiting at A.

In such a situation it is also more realistic than the long distance patch, as if all tickets are equal, IRL there would be nothing preventing passengers for C to board the express train A-C-D. Except in very strictly organised societies.

DrSuperGood

QuoteFor example: if 50 passengers wait for A, 20 passengers wait for B, and 30 passengers wait for C, and a vehicle with free space for 50 passengers arrives, just load 25 for A, 10 for B, and 15 for C.
I think you underestimate the complexity of routing. You see, there might be 50 passengers going to A but of those 50 passengers each and every one of them might have different final destinations so are stored as separate cargo units. I believe the current approach is to choose a destination and then start filling all cargo routing via that destination as it can track it down from the stop storage list.

To do what you want would be computationally a lot more tricky. At least 2 passes of the next line block (before it returns to this stop) and all stored cargo at the stop are needed.
1. To work out the total number of passengers that can use the line and the number of destinations on the line they are going to.
2. To load the actual passengers based on the above. Stopping once a certain fraction of cargo has been tracked down for a destination. This pass might be faster if you cache results from 1 I imagine.

This now introduces a new bias "transfer bias" since now it might prioritize cargo to specific destinations based on internal ordering. This probably has always existed except was masked by the larger line stop bias.

Would it make a difference to game performance? Probably not however I am highly certain it will be more resource intensive to compute than the existing implementation or the suggested inverse.

Markohs

That proportional loading was discussed in the past too, here:

http://forum.simutrans.com/index.php?topic=11194.0

The idea of *this* patch was adding the "long distance preference" loading algorithm and make room for anybody else that wanted to implement other loading algorithms as the one discussed there (I think it's the same sdog suggested).

EDIT: What they refer as "hole_ab" in that thread, it's translated to "fetch_goods" or something like that, in my patch, just for your reference.

hreintke

LS,

I am working on getting my "proportional loading patch" from the other thread incorporated in this "Long distance patch".

Herman 

sdog

Quote from: DrSuperGood on October 14, 2014, 04:18:25 AM
I think you underestimate the complexity of routing. You see, there might be 50 passengers going to A but of those 50 passengers each and every one of them might have different final destinations so are stored as separate cargo units. I believe the current approach is to choose a destination and then start filling all cargo routing via that destination as it can track it down from the stop storage list..
I don't think that would necessarily required. As soon as a packet of pax is smaller than n=f(N) a sensible fraction of the convoy size a split depending on size is not required. Still take the largest packet at the station, check if the outgoing convoy serves its routing requirement, divide packet size by overall station occupation, round up to a natural number and load, go to the next largest packet. If the convoy didn't fit the route requirements, go to the next packet. Repeat until convoy is full, or the next largest packet is smaller than n. If that is the case resort to the current loading pattern. (This ought to avoid getting swamped in the case you describe above.)


isidoro

Quote from: Markohs on October 14, 2014, 02:54:23 PM
That proportional loading was discussed in the past too, here:

http://forum.simutrans.com/index.php?topic=11194.0

[...]

Oops!  I didn't remember that post.  Sorry.

Ters

Quote from: sdog on October 14, 2014, 10:18:38 PM
I don't think that would necessarily required. As soon as a packet of pax is smaller than n=f(N) a sensible fraction of the convoy size a split depending on size is not required. Still take the largest packet at the station, check if the outgoing convoy serves its routing requirement, divide packet size by overall station occupation, round up to a natural number and load, go to the next largest packet. If the convoy didn't fit the route requirements, go to the next packet. Repeat until convoy is full, or the next largest packet is smaller than n. If that is the case resort to the current loading pattern. (This ought to avoid getting swamped in the case you describe above.)

Contiually looking for the biggest packet sounds even more complicated than what DrSuperGood wrote.

prissi

I would suggest to have the packets ordered at a step by a certain user defined metric:
mean waiting time
next transfer stop distance
amount

Then hole_ab would just search from the top until it finds something it matches its schedule. It would allow for more loading options with a simplier logic. (Proporptional just would get 3 or so from any matching packet from the top until all satisfied.)

Markohs

But that whoudn't allow to have different loading styles on different lines no?

hreintke

Don't think "pre-ordering" will work.
The order is also dependent on the schedule (order of halts in there) and as such can/will vary across each call to "fetch_goods".

BTW In my work to include Proportional I checked LongDistanceLoading code.
I think the code from fetch_goods_headed_to

        else if (!plan_halt.is_bound()) {
if (grund_t *gr = welt->lookup(schedule->eintrag[stop_number].pos)) {
if (gr->get_depot()) {
// do not load for stops after a depot
return true;
}


Should (also) be in fetch_goods_long. The current implementation only loads goods for halts after the depot instead of halts before the depot.

Markohs

I'll check it out, thanks. I tried to design the code so it was easy to add extra loading schemes, did you faced any problem I can help you with?

prissi

If the ordering is by the final (or intermediate) target distance, then it could easily used for long or short distance (starting form the end or the top of the list ...)

As such you would have many loading options (in principle per stop!):
Closes number of stops (as of now)
Largest number of stops
Shortest coord distance preferred (assuming those get off fast) or the reverse
Longest coord distance preferred (assuming those have to wait the anyway the longest time)
Largest group first (this would lead to equal overvrowding of bus lines under capacity and not starve stops between central hub and last of the bus line) and will lead to some proportional loading if the whole line is not completely overcrowded
Longest waiting time preferred (This will need some tweaking of the structures)

All those are independent of the next vehicle. Next stop is next stop, and if the next stop is not in the schedule, the search from the top will just continue downwards.

Another resonable option on top would be "Direct reachable" (final target on this line, will automatically prefer local trains) This cannot be generated by sorting. Rather one would need two interations, one only for direct and then for interchanging pax.

But anyhow, imho in a transport simulation you should not be able to tell which passenger to board which train. I.e. I fell this should be a game global setting.

Markohs

#103
Quote from: prissi on October 18, 2014, 08:59:45 PM
But anyhow, imho in a transport simulation you should not be able to tell which passenger to board which train. I.e. I fell this should be a game global setting.

Why moving yet another thing to simuconf, there are so many global settings on this game.... Why just not make all setting available from the UI? I'd just move all this settings to the UI, and create a simple settings panel like it's now, and make "advanced" extra settings, just shown to players that take the time to click "advanced settings".

This particular subject (loading patterns) could be easlily solved if there was a setting available in the "options" pannel, named "game options", in wich you could modify some settings that can be changed on-the-fly in the game. In particular, one named "Show advanced cargo loading preferences on schedules". If you check that, the player will be able to modify loading pattern of each schedule/line, given that the current one, "Shortest number of stops prefered", it's the *default* one. This is important to not break old savegames, and confuse players that upgrade the game.

I don't like how this game tends to move everything to simuconf, it's incredible how complicated that file is, with so many obscure settings.

Also, given that we allways have the problem nobody really knows how our players play, I'd suggest adding some functionality so our game accounts wich are the buttons or players *really* use the most, and suggest our players to send that data to us, if they want to help us collect that data.  We are allways heading the game development in the line most developers think the game should go, and we can maybe be surpresed how different the players *really* play, maybe very different of what prissi thinks, or maybe very different of what I do, or other developers, too.

Maybe just sending to us the simuconf file, it's enough, and way more simple.

I'm really curious how many of our players really update simuconf, like our UI, or take obscure way of doing things, very different on how we think they do.

Vladki

I usually add "dialog_tool[27]=,~" to my menuconf.tab and I get a simuconf.tab editor on ~ key.

Prissi is right that in reality nobody usually tells the passengers which convoy they should load. Then to get real pax behavior, random loading should be implemented. But there are some exceptions - I have seen bus drivers on long distance lines to let passengers for the final stop first. Also people themselves make complex decisions on which train to take, usually based on the knowlede of the schedule. I know we do not have schedule in simutrans. But at least we know the estimated arrival of next vehicle, number of intermediate stops before destination, average or top speed of convoy... There's a lot of options, but finally the real world decisions might be considered to be random. So that would be the most real loading preference. Unfortunately FIFO is not possible in standard, but some proportional modes (serve all stops equally, or take pax to the most wanted destination), might also work well.

Its hard to control passengers but for mail and cargo, the transport company can control what will be loaded.