Frank and I talked a bit about design issues in Simutrans, and Frank brought up the suggestion that some engines should be only for passenegr trains, becuase this would help to balance different engines in a set better.
Technically I imagine this fairly easy - the engine gets a new flag "passenger train engine" (in the dat file and in the internal data structures), and the code will check that only passenger and mail cars are allowed in such a train (would work the same for road vehicles and ships, even if not so urgent there).
I think Frank would be happy if one of the programmers or patch makers could introduce this. He wants to improve the balance in pak.german and this spawned the suggestion.
This would be a good idea I think, but another suggestion I have is to have a short description field that would appear in the depot window to describe the ideal usage of a vehicle. E.g. "Express passenger" or "Metro" or "Light Freight".
That would help to balance the paks by treating as different groups passenger and freight locomotives. Thumbs up :)
Anyway, AIs don't check constraint thing...
but what of the mixed use locomotives?
alternatively, how about constraints? (although I know this is tedious work)
Coding constraints for every possible option would be seriously tedious for some situations. It reminds me of the discussion some time ago about constraint classes - combined with this request that would be very powerful.
See http://forum.simutrans.com/index.php?topic=2203.0 for discussion, although sadly it looks as though this idea lost interest and petered out.
Quote from: AEO on February 22, 2010, 09:40:58 AM
alternatively, how about constraints? (although I know this is tedious work)
The constraints are too unflexible IMO, thus I want to suggest this as a flag for the engine, and not as an element of the constraints.
Quote from: AEO on February 22, 2010, 09:40:58 AM
but what of the mixed use locomotives?
Engines that re not marked as "passenger train only" could be allowed to pull any type of car.
But if really needed we can have three states:
- general purpose
- passenger only
- freight only
This should be about as easy to implement as the initial suggestion.
Also, such a flag would allow easy grouping into depot tabs, which will be very hard with a constraint based solution.
I fail to see the purpose as passenger locos are usually weaker with a higher topspeed and thus are not usuable for freight much. In a setup with speed bonus they have higher maintenance costs. Also given the number of passengers cars in most sets (with the exception of pak128) constraits can achieve this. pak64 has only seven kinds of passenger cars, and only four of them would be a passenger car for higher speeds. And constrains are there, it is just a matter of copy&paste to add them, if a pak set author want to force certain combinations. That is the purpose of constrains.
Normal speed cars were coupled often to freight /mixedengines, it was rather the rule than an exception. For instance this happend in German after reunification: Former freight egines run S-Bahn services and regional express (120-160km/h). Also often some passenger locos with time went to freight. Not to mention mixed trains with a single passenger car serving remote factories (my style of playing actually).
You can mark passenger engines by setting type as freight=passengers and capacity=0. Then they appear in the passenger tab and usually nobody uses them for other purposes. (This is used for ages.)
Simutrans gives the player lots of freedom. I am not very keen on cutting this and additionally handling complains "but there is this foto of xyz pulling passengers/mail/freight" Moreover, it would mean rebalancing paks, which is a very tedious exercize I want to avoid doing regularely.
Quote from: prissi on February 22, 2010, 10:41:25 AM
Moreover, it would mean rebalancing paks, which is a very tedious exercize I want to avoid doing regularely.
I don't want to argue about the other points. But this is just not true. Default could be "general purpose" engine, and therefore all the existing DAT/PAK files would continue to work just as they are.
Reason for this request though, was that Frank wants to rebalance pak.german, and that he thinks that pak.german will benefit from the split.
So you have one pak maintainer who wants to do it, and you have a "no harm done" situation for everything and everyone else. The Hood also showed interest, so you might even have two pak maintainers who would like to rework their sets with the new option.
There is a system which is working (and has been tested) contrains. They even reduce clutter, since non-matching vehicles are not shown with them.
I feel more like a political question: Should there another pak-set specific feature added, which breaks consistent documentation for the engine (since it will require a different depot layout again). Which is exclusively railway related. Given my resources for depot extension, and the above arguments, I am not yet convinced this will enhance gaming experience.
Finally, I still fail to see the problem solved by this. Passenger engines are already more expensive than freight engines, if one would use the speed bonus intended for this purpose. What would change now?
I'm thinking about it again, and if the only purpose is to simplify the pak balancing, I would consider only to change the locomotive freight as "Passagiere". That would result in make the locomotive to be in the passenger tab, so it's clear enough that it is an engine with that purpose.
On the other hand, that locomotive would be tweaked (RC & cost) for a passenger service (high bonus -> high RC), as prissi explains above. The user can still use that locomotive for freight services, but the passenger classification is clear enough, and there is no need to make any change in the code. And constraints would keep working as they do now.
So, my suggestion would be: use passenger as freight (despite it has payload=0); then tweak RC/cost as passenger loco. After that, user does what he/she likes most. I did it for a couple of spanish locos for pak128 and was easy and effective.
Quote from: prissi on February 22, 2010, 11:33:54 AM
Finally, I still fail to see the problem solved by this. Passenger engines are already more expensive than freight engines, if one would use the speed bonus intended for this purpose. What would change now?
Running costs for passenger engines can be calculated differently than freight engines - for example if one has a cheap, light and fast passenger engine, players might feel tempted to use it for freight transport too, to earn more money. But the engine is not meant for that, and such cross-use damages the pak balance.
To me the engine type looks like a simple and convenient option. The constraints never were to my taste, but there was a solution needed to tell which vehicles are compatible and which are not, also for positional constraints (don't know if such are there nowadays).
Constraints have a big drawback: The explicitely list the vehicles which match. So 3rd party PAK files most likely cannot be made to match into a constraint based set structure.
While a class based structure would allow this. We do not have it (as mentioned and linked above http://forum.simutrans.com/index.php?topic=2203.0 ) and so the engine flags would help the pak maintainers.
I'll drop out of this discussion now. I'm not interested in it myself but I thought it's a good idea and worth promoting, particularly since the original idea bearer has troubles to argue in English. I tried to promote the idea, and if the response is a "no" then it's a "no" and it's good for me.
It is under discussion ... so far we have very little opinion on that point. But the trouble with addons is, that those are almost never matched with a certain pakset balancing. Thus if one goes all the way and want people to use certain engines for certain tasks, constraints are the only way.
If one has a cheap light and fast engines, then it certainly also disturbs balancing for passengers ... or it is cheap fast and not powerful, creeping along with the heavy oil tankers and clogging the network. BUt I confer, that this is difficult to discuss without an example with real numbers.