Development update [7.2]

Topic: Development update [7.2] (Read 11589 times) previous topic - next topic

Development update [7.2]

January 29, 2010, 11:48:49 pm

Apologies to everyone for the delay in releasing the latest version of Simutrans-Experimental: I have been especially busy in the last few weeks, and have not had much time to work on the code. 7.2 is in progress, however. Planned enhancements for 7.2 include:

Further updates to the physics engine (Bernd Gabriel)
If goods or p****engers are discarded en route because of overcrowding, the player has to pay a refund based on an estimate of what they will have paid for their journey so far (this prevents an exploit reported here).
P****engers only register as "happy" at their origin halt once they arrive at their destination, rather than as soon as they leave, in order to prevent p****engers discarded in transit due to overcrowding registering as "happy"
Weight limits per axle rather than per vehicle

I should be interested in any feedback on those planned features before the release. One of the factors causing a delay in preparation of 7.2 is the fact that Simutrans-Standard is undergoing a number of structural changes to prepare it for networking, which are time-consuming to integrate into Simutrans-Experimental. I am working on methods of addressing that, however.

I should like to thank all Simutrans-Experimental players for their patience - I hope that people will look forward to the next release. (Incidentally, 7.1 is now available for Linux - see here for details).

Re: Development update [7.2]

Reply #1 – January 31, 2010, 03:27:16 am

How will those new features affect save games saved with prior versions? I remember that was quite problematic previously when it suddenly enabled all new features for old save games, leading to quite dramatic changes, and altering the simuconf would have no result.

(Later I found out a workaround is first making a line and running a train on the start-up island before loading the old save games; by doing this it seems that the edited settings that have been changed in the simuconf are carried on to the newly loaded save game as well. It works every time.)

Re: Development update [7.2]

Reply #2 – January 31, 2010, 12:18:33 pm

Junna,

none of the changes from 7.1 to 7.2 have any bearing on simuconf.tab settings: no new simuconf.tab settings are created, and no existing simuconf.tab settings are changed.

Re: Development update [7.2]

Reply #3 – February 01, 2010, 12:43:11 am

for the weight limits, the axle weight is the key for tracks on ground, but for bridges there's axle weight + total convoy weight limit on each support column. Usually the bridge is build for the application, but occasionally some super heavy vehicles, but with a low axle load go over only the sturdiest of bridges.

tracked construction vehicles and Schnabel cars for instance.

Re: Development update [7.2]

Reply #4 – February 01, 2010, 12:55:31 am

Quote from: jamespetts – on January 31, 2010, 12:18:33 pm

Junna,

none of the changes from 7.1 to 7.2 have any bearing on simuconf.tab settings: no new simuconf.tab settings are created, and no existing simuconf.tab settings are changed.

I mean the effects of the changes to the physics engine, how will they affect save games made prior?
(and will the boat speed issue be resolved?)

Re: Development update [7.2]

Reply #5 – February 01, 2010, 09:38:55 am

AEO - how could that be implemented in the code?

Junna - the new physics will work in saved games in the same way as it works in new games. And what is the boat speed issue?

Re: Development update [7.2]

Reply #6 – February 01, 2010, 12:40:40 pm

@james. I would just go for something like

if convoy weight is greater than max bridge weight limit, then go at 15km/h or 5% speed, whichever is less.
if convoy weight is greater than 115%? max bridge weight limit, then cannot cross.

personally, I don't think it's super important since these sort of things are rare and the vehicles were either not built with this in mind (like tanks or very large tracked construction equipment), they're very infrequent (i.e Schnabel car moving a power transformer) and/or very slow to begin with.

I just thought I'd mention it

Re: Development update [7.2]

Reply #7 – February 01, 2010, 01:13:25 pm

But axle weights are important for bridges, too, aren't they?

Re: Development update [7.2]

Reply #8 – February 02, 2010, 01:06:14 am

Quote from: jamespetts – on February 01, 2010, 09:38:55 am

Junna - the new physics will work in saved games in the same way as it works in new games. And what is the boat speed issue?

The issue with boats moving at minimum speed when loaded and so on? This was an issue that appeared with the new physics.

Re: Development update [7.2]

Reply #9 – February 02, 2010, 01:49:02 am

@james
both axle load and total weight is important when the convoy is on the bridge.
it's just in some special cases, the convoy or engine might be very heavy, yet have a light axle load compared to the weight because there are so many of them.

something like this for instance, 500t on 16 axles
caution: huge image. http://home.att.net/~iiitoo-4/rrpix/schnsilh.jpg

tracked vehicles can be over 60t, but put less ground pressure on the surface than a 5t truck does.

Re: Development update [7.2]

Reply #10 – February 02, 2010, 12:46:49 pm

Junna,

I know that there are some physics enhancements in 7.2, but Bernd Gabriel knows the details more than I do, as he is in charge of the new physics engine.

AEO,

what precisely is the interaction between these two factors? This looks as if it could be enormously complicated: do we have to take into account the distance between bridge supports, how much of a long convoy is on the bridge at its maximum extent, the relationship between the axle weight and the total weight, or other such things? Do you have any logic that you can suggest for dealing with these various factors?

Re: Development update [7.2]

Reply #11 – February 02, 2010, 09:17:16 pm

Quote from: Junna – on February 02, 2010, 01:06:14 am

The issue with boats moving at minimum speed when loaded and so on? This was an issue that appeared with the new physics.

Yes, ships and other convoys (e.g. some busses in pak128) will be back to normal movement.
Additionally the "maximum speed at given weight" preview in depot frame becomes more precise.
It warns you, if your ****embled convoy might become unable to move and shows the maximum weight, which can be moved and at which speed.

Re: Development update [7.2]

Reply #12 – February 02, 2010, 10:12:55 pm

@james

Since there game already gives you a calculated total convoy weight and convoy tile length, I would use those. The bridges can be specified a maximum length so I would use that as well.
I would not use support column distances, since they can be deleted graphically and the bridge's maximum weight value would already have that factored in.

so maybe something like...
if convoy weight is greater than max bridge weight limit, then go at 15km/h or 5% speed, whichever is less.
if convoy weight is greater than 115%? max bridge weight limit, then cannot cross.

+
if bridge length = not specified, only axle load rule applies.
when convoy length is less than bridge length specified in .dat file, weight/axle rule applies normally.
when convoy length is greater than bridge length specified in dat file, weight/axle rule applies, but with bridge length divided by convoy length (to get a decimal value)

I would ignore the case of having two or more heavy convoys on the same bridge at once. That sounds really complicated.

Re: Development update [7.2]

Reply #13 – February 02, 2010, 10:53:23 pm

AEO,

interesting thoughts, but I'm somewhat worried that this might be difficult to communicate to the player effectively. What, for example, would be on the toolstrip for purchasing new bridges?

Re: Development update [7.2]

Reply #14 – February 03, 2010, 02:24:44 am

i'd suggest to stick with axle weight for the moment. tanks or extra heavy transports aren't in Simutrans, and won't play a role. At least until someone starts a reactor or turbine industry chain.

Re: Development update [7.2]

Reply #15 – February 03, 2010, 06:20:55 am

@james
I would leave it up to the pak creators to just make vehicles that fit within the loading gauge or make bridges that can handle super heavy vehicles.

these sorts of special vehicles that don't fit within the loading gauge either have their own dedicated roads/tracks or are routed in such a way as to avoid bridges that can't handle their weight.

As for the display, I think the bridge should just display "super heavy" as part of the name and have whatever special vehicle have the same "super heavy" in its name.

Re: Development update [7.2]

Reply #16 – February 03, 2010, 09:06:28 am

Definitely go with either axle weights or total weights and not a combination of the two - you will almost certainly confuse and lose some players if it ends up with all possible combinations of complexity seen in real life? I know this is the experimental version and aims for greater realism, but eventually you need to stop - I'm sure most players wouldn't want to design every bridge with to chartered civil engineer standards especially designed to fit the required circumstances. At the end of the day, people just want to play with trains (to a more or less real degree)

Re: Development update [7.2]

Reply #17 – February 05, 2010, 02:33:02 am

I would think axle weight is not particularly important for bridges; To the track installed on the bridge - yes; To the bridge structure - not so much; Except in the case of really short bridges of course. In Simutrans scale, almost any bridge that gets built in game would likely represent a huge structure in life. Hence most/all of the train would be on the bridge making total weight the dominant factor.

For gameplay simplification, either axle or total weight would likely be best. Using axle weights would have the benefit of allowing abominations like the Baldwin Centipede to have a purpose! Bridges could be deemed to be built super strong where the track always fails before the bridge structure.

If both are to be used, an axle weight limit for track on flat ground, and total consist weight limit for on a bridge wouldn't be overly confusing. Determining bridge and train lengths is, I think a bit much.

Re: Development update [7.2]

Reply #18 – February 05, 2010, 05:28:53 pm

This, I think, involves a delicate balancing act. On the one hand, The Hood is entirely correct in stating that it is important that the weight limits system is simple enough to be comprehensible. Currently, I am struggling to see how a system involving two different kinds of weight limits for bridges can be readily comprehensible without more radical changes to the GUI than are feasible. On the other, the fundamental economics of weight and load-bearing such as importantly informed civil engineering decisions and vehicle design and choice decisions need to be preserved in so far as possible in order best to achieve one of the fundamental goals of Simutrans-Experimental: to make the choices that a player can make have the same effect in the Simutrans world as they would if they were made in reality.

It is to achieve that goal that the plan to switch to axle weights was conceived: a number of vehicles were specifically designed (at greater expense) to have additional axles to spread the weight of an otherwise heavy vehicle to allow it to be used on roads or rails with low weight limits. The AEC STL 'bus from the 1930s, for example, has the two axles - there would be no utility to the additional cost unless it had some bearing on weight limits. Similarly on the railways, the Bulleid "light" pacifics are, in overall weight, very close to the GWR King cl****, but that weight is spread across more axles, giving them a greater route availability. Both of those vehicles would be of rather limited value if overall weight, not axle weight, is measured.

I have been trying to ascertain whether there is a similar economic imperative in respect of convoy weights for bridges. Certainly, it could, I suppose, be relevant to long, heavy freight trains, although the complexities of comparing bridge length to train length immediately become manifold (and I disagree that we should take the structures to use the 250m/tile scale - they would need to be treated as being on the same scale as the vehicles themselves, or else there would never be any short bridges, which would be bizarre and perverse). I cannot immediately see such imperative (it appears to be potentially relevant only to rail in any event; for other forms of transport, vehicle weight and convoy weight are hard to separate), but I should be interested in any further thoughts on the matter.

Re: Development update [7.2]

Reply #19 – February 05, 2010, 05:40:52 pm

you could just use average weight per tile of a train (convoy). specify the maximum weight acceptable for a bridge and divide it by it's length. then check only for a single tile.

Re: Development update [7.2]

Reply #20 – February 05, 2010, 05:41:45 pm

How would a user easily be able to work out whether a particular convoy could take a particular route, though?

Re: Development update [7.2]

Reply #21 – February 05, 2010, 08:00:45 pm

The convoy ****embler could show the weight per tile. All needed infos are already in there.

BTW: I was following the axle weight discussion superficially. I think axle weight is a too fine specification for simutrans, and will required a new parameter for *all* vehicles and: how many axles has a horse

?

Weight per tile might be a good compromise and does not need new a vehicle parameter.

Re: Development update [7.2]

Reply #22 – February 06, 2010, 06:59:39 am

weight per tile sounds good.
the heavier vehicles with more axles are normally longer or wider to accommodate the extra axles so it would make sense that weight per tile is used.

Re: Development update [7.2]

Reply #23 – February 06, 2010, 08:04:27 am

Quote from: jamespetts – on February 05, 2010, 05:28:53 pm

Currently, I am struggling to see how a system involving two different kinds of weight limits for bridges can be readily comprehensible without more radical changes to the GUI than are feasible.

That's why I suggested using only convoy weights for bridges as the dominant limiting factor. One limit for regular ways, one for bridges.

Quote from: jamespetts – on February 05, 2010, 05:28:53 pm

I have been trying to ascertain whether there is a similar economic imperative in respect of convoy weights for bridges.

Convoy weights for bridges provide the economic imperative for a variety of bridge types in the pak, just as axle weights provide for a variety of rolling stock. i.e. The pak could contain multiple bridges with the same parameters (speed limit) but a higher weight limit and the resultant higher cost. Checking only axle weights would allow both the GWR King cl**** and Bulleid "light" pacific to cross even if they're heavyweights. This would also provide a reason for lightweight, yet high axle loading vehicles to exist in a pak. Do any such vehicles exist though...

Quote from: jamespetts – on February 05, 2010, 05:28:53 pm

event; for other forms of transport, vehicle weight and convoy weight are hard to separate), but I should be interested in any further thoughts on the matter.

Well, on further thought, there's no real reason to separate out vehicle weight and convoy weight. That just adds needless complexity. Vehicle and convoy weights are just scalar to each other anyway. A 1000t 8 vehicle train on a 5 tile bridge with 1200t limit or a 125t vehicle on a bridge with 150t per vehicle limit -- same thing. This also applies to those other forms of transport.

Worrying about number of vehicles on a bridge or per tile is also needless complexity. Think of your local road bridge with a posted weight limit. Posted may be a 30t limit, but this doesn't mean 2, 3, 4, or more 29t trucks couldn't be on the bridge at once. The posted limit takes into account the total weight of the number of vehicles that can fit on the bridge.

Per vehicle weight limits are what is in the game right now - no changes needed except to only have them apply to bridges. Whether this is worth it gameplay wise???

Re: Development update [7.2]

Reply #24 – February 06, 2010, 01:16:00 pm

Interesting thoughts - I see an absence of consensus! Firstly, per vehicle weight limits already do apply to bridges. The suggestion initially made was to replace all per vehicle weight limits with per-axle weight limits. This is not inherently difficult: all that needs to be done is to have a parameter called "axles" for each vehicle, and to divide the total weight by the number of axles to produce an axle weight.

To save pakset authors work, there would be sensible defaults, so that the number of axles would only have to be specified in the .dat files where they were unusual. So, for example, all road vehicles would default to two axles, and the pakset authors would only have to set "axles=3", for example, in unusual cases. Likewise for rail vehicles, goods wagons, for example, could also default to two, while p****enger vehicles might default to two or four depending on the introduction date, and so on. There would be an axle weight display in the vehicle information section in the depot window which would give the weight per axle of the vehicle in question. It would not be inherently difficult to implement or understand by the player. The question is whether it would produce economically realistic behaviour to a greater, lesser or equivalent extent to per vehicle weights.

The economic imperative of having different weight bridges is already present in the existing system: changing from weight per vehicle to weight per axle does not affect that. What is perhaps relevant, however, is that bridges in reality may well be more sensitive to total weight than axle weight. Turfit correctly observes that using convoy weight would mean that a player has to worry about how many vehicles are on a bridge at once, which would be tricky for trains and, in the case of a road bridge used by multiple vehicles at once, quite impossible. That would involve extra effort and confusion on the player's part for little or no extra reward in gameplay enjoyment or realism.

So, the candidates seem to have narrowed themselves to the two existing choices: vehicle weights (as currently implemented) or axle weights. Further, my view at this stage is that it would probably be extremely confusing to use vehicle weights on bridges but axle weights elsewhere, although I should be interested in people's views as to whether or not they would find that confusing, or whether there is an easy UI device that can ****uage that confusion.

Given the ongoing debate, I shall leave things as they are for the next release (i.e., vehicle weights for all kinds of ways, including bridges) and garner further thought and feedback before making changes in this respect.

Re: Development update [7.2]

Reply #25 – February 06, 2010, 01:42:36 pm

Seems to me that axle weights don't really add very much over vehicle weights (and indeed I understand from a rail engineering point of view there is some debate over whether axle weights or total weights are more important). Axle weights also come with the added complexity and need more understanding. Given a few people already seem to be confused with vehicle weights and routing of vehicles in experimental (judging by help requests), I'd advise against changing it again.

I'd only introduce axle weights if you can demonstrate an example where having axle weights instead of total weights materially influences the choice of infrastructure and vehicles and show that the gameplay effects of this are significant in terms of p****engers transported / profit etc. Otherwise it seems a lot of effort for so little gain.

Re: Development update [7.2]

Reply #26 – March 21, 2010, 10:07:49 pm

Use vehicle weights for everything for now. A fancier weight limits system is an idea for a future decade.

Rationalize it as follows: while axle weight is what matters from the point of view of "will the track fail today", from the point of view of *long-term maintenance*, vehicle weight is probably more important. So if you use axle weights you'd want to also vary the running costs based on number of axles.... and this is just too much work for now.

Re: Development update [7.2]

Reply #27 – March 22, 2010, 12:09:06 am

Thank you all very much for your feedback on the axle weights issue. For the time being, I think that I shall leave things as they are, using vehicle weights, particularly given the complexity that arises when considering bridges.

Re: Development update [7.2]

Reply #28 – March 26, 2010, 03:29:30 pm

gratulations on the release of 7.2 and the new version of the pakset. i didn't expect it that soon, you must have worked on it like mad!

excluding the convoy replacer seems to be wise, as you can get some feedback on the many changes, before you realease 8.0

Re: Development update [7.2]

Reply #29 – March 27, 2010, 06:29:49 am

Congratulations on the release from me too. I look forward to downloading and start testing it.

However, I'm sorry to have to report that I got webpage errors on attempting download of the binaries, configuration files and Pak.Britain-Ex yesterday evening and again this morning. It appears the site may be offline at this time.

Re: Development update [7.2]

Reply #30 – March 27, 2010, 07:21:39 am

Quote from: Dutchman on Rails – on March 27, 2010, 06:29:49 am

However, I'm sorry to have to report that I got webpage errors on attempting download of the binaries, configuration files and Pak.Britain-Ex yesterday evening and again this morning. It appears the site may be offline at this time.

I'm successfully downloading the configuration files and Pak.Britain-Ex as of now.

Of course, it isn't compiling for Linux without fixes, but see my other topic for the patch. :-)

Re: Development update [7.2]

Reply #31 – March 28, 2010, 06:42:10 pm

Apologies to those who had trouble downloading 7.2 - the servers seem to be working now. Anyone who had difficulties should try again. Thank you everyone for your patience!

(As to the Linux version - I have applied Neroden's patch, so the Linux version should be available to-morrow).