Transport Tycoon Forums

Technically yes but not easily, because the weight calculation code has no efficient way of finding out which grf file has defined graphics for any particular vehicle.

Also technically, the current way of coding it is correct because that's how the specs mandate it, but it does place some limits on what can be done.

However I could define a vehicle flag to be set in prop.27 if necessary, to indicate that each part of an articulated vehicle should have its own weight.

It sounds like that might be nice, since it would allow this useful new feature to work without breaking all the old stuff.

This new feature is perfectly usable.

The only limitation is that you cannot design articulated wagons of varying lengths (e.g. 4 cars before 1980, 3 after 1980), or if you do, the weight will not change depending on the length.

Being on articulated vehicles, wouldn´t it make sense to have all their properties handled in a "unified" way? I mean, why don´t we simply add up props of all constituent parts (power, weight, price, cost, ...) in the same way we do now (only) for capacity rather than using only those props of the first vehicle?

This would allow for a more flexible design and possibly yield a better dynamic modelling? Although I confess I don´t know nothing about the kinematic modelling of a MU in TTDPatch.

On another note, I do have a few refittable MUs and now their train window looks somewhat special when being refitted. O/c that´s only a cosmetic issue and I don´t have an idea ATM how it could be managed in a better way. So that´s just for the record.

Another problem would be the overall capacity shown in the buying menu where only the passenger numbers are summed up, i.e. depending on the default cargo set (passengers vs passengers and mail) two different values would be shown which is slightly irritating, IMO.

There´s also a third problem with MU names in the different windows. Apparently only in the train window the names get right-shifted ATM but not in the buying menu. O/c that causes problems to the .grf makers as shown in the screenshots.

regards
Michael

michael blunck wrote:Being on articulated vehicles, wouldn´t it make sense to have all their properties handled in a "unified" way? I mean, why don´t we simply add up props of all constituent parts (power, weight, price, cost, ...) in the same way we do now (only) for capacity rather than using only those props of the first vehicle?

It's not that easy. There's quite a lot of non-trivial code to be added for each property that should be summed up in this way. Is there anything in particular wrong with the way it's currently done?

On another note, I do have a few refittable MUs and now their train window looks somewhat special when being refitted. O/c that´s only a cosmetic issue and I don´t have an idea ATM how it could be managed in a better way. So that´s just for the record.

What's wrong with it?

Another problem would be the overall capacity shown in the buying menu where only the passenger numbers are summed up, i.e. depending on the default cargo set (passengers vs passengers and mail) two different values would be shown which is slightly irritating, IMO.

All types are summed up, but only the first cargo can be shown currently because the info window doesn't support more than one currently.

There´s also a third problem with MU names in the different windows. Apparently only in the train window the names get right-shifted ATM but not in the buying menu. O/c that causes problems to the .grf makers as shown in the screenshots.

You seem to be using a sprite with a non-standard width. The patch doesn't know how wide the sprite is going to be when the text is placed...

This can be changed but I'd need a test grf to work on it

[ adding up props of all constituent parts of a MU]

> Is there anything in particular wrong with the way it's currently done?

Well, it´s cumbersome in many ways ...

It would be nice if

- power
- running cost
- purchase price
- weight

would be summed up like only capacity is done now.

This would be straightforward (no more sublties with the MUs first veh-ID), reflect the usage of CB 16 in an 1:1 fashion, etc. pp.


[refittable MUs]

> What's wrong with it?

Well, yes. Having the MU refittable to e.g. two cargoes results in two lines of information. That´d be OK because it´s understandable. Unfortunately, sometimes there are three lines for a MU carrying two cargoes (passenger and mail), possibly when the first part of the MU is empty. See screenshot below.


[overall capacity shown in the buying menu]

> All types are summed up, but only the first cargo can be shown currently because the info window doesn't support more than one currently.

Yes, I know. Nevertheless, this is irritating because, depending on the default state set (by the .grf author), the capacity shown would be different. Again, this is more or less "for the record" (-> suggestion list). I don´t have a solution yet but I remember we had already discussed this in the past.


[MU names in different windows]

> You seem to be using a sprite with a non-standard width.

Yes, o/c.

> The patch doesn't know how wide the sprite is going to be when the text is placed...

Mmh. In principle it should know, but obviously that text routine doesn´t take it into account. I see two possibilities here: either use the real width of the sprite shown in the FF-branch of action03 or count the length of the real articulated vehicle in horizontal view. Obviously then, .grf authors would have to take care of that.

regards
Michael

michael blunck wrote:[ adding up props of all constituent parts of a MU]

> Is there anything in particular wrong with the way it's currently done?

Well, it´s cumbersome in many ways ...

It would be nice if

- power
- running cost
- purchase price
- weight

would be summed up like only capacity is done now.

This would be straightforward (no more sublties with the MUs first veh-ID), reflect the usage of CB 16 in an 1:1 fashion, etc. pp.

Possibly, but I tend to think of articulated vehicles as one real vehicle and a number of fake ones added only for visual purposes. This greatly simplifies the handling internally.

Unless there's a clear benefit to adding code for every single property to add up its values for the articulated parts, it's just not worth doing it. Capacity was a special case because TTD already handles that per-vehicle so all I needed to do was display it properly, instead of changing all code that accesses it.

[refittable MUs]

> What's wrong with it?

Well, yes. Having the MU refittable to e.g. two cargoes results in two lines of information. That´d be OK because it´s understandable. Unfortunately, sometimes there are three lines for a MU carrying two cargoes (passenger and mail), possibly when the first part of the MU is empty. See screenshot below.

That's probably a bug, I'll need a grf file and savegame for that too unless it's fixed in the next nightly. It's probably related to the first line having a different "source" even though there's no cargo.

I finally caught the PBS track reservation bug.

As you can see in the picture there is an odd selected piece of track, which is caused by train 0 stopped inside the tunnel.
When you load the savegame wait until the junction behind train 0 is free and then start train 0.
You have to be quick, better hit F1 directly on load.
It will trun around and reserve a track up to the double signal with the reserved piece of track behind it (I have made the Patch reserve that piece).
After the signalwaittime is over it turns around again going inside the tunnel.
In the mean time another train will occupy the junction so that when train 0 wants to trun around again the wrongly reserved track will be made.
I hope you can now determin what causes this.

Another bug found.

If I build a roadbridge with it's bridgehead against a trainstation this roadbridge becomes a tramtrackbridge.
If I then remove the trainstation it reverts back to a roadbridge again, and visa versa.

Save and configs are the same as above.
TTDPatch version : nightly 2.6 alpha 0 r 792

Rob wrote:I finally caught the PBS track reservation bug.

This should be fixed in the next nightly. When reversing failed, a train would reserve all possible pieces behind it, instead of only the one that was reserved before.

Rob wrote:...If I build a roadbridge with it's bridgehead against a trainstation this roadbridge becomes a tramtrackbridge...

Can't reproduce!!

But I did come across some strange ELRail behaviour... DaleStan, you may want to have a look at the attachment!

The overhead wires can be reproduced by building two 1x4 stations beside eachother... the second gets wires when I don't even have "Electrified Railway" build option yet.

stevenh wrote:But I did come across some strange ELRail behaviour... DaleStan, you may want to have a look at the attachment!

Fixed in r825.

And it's not necessarily the second one; it's dependent on the X coordinate of the station tile.

stevenh wrote:

Rob wrote:...If I build a roadbridge with it's bridgehead against a trainstation this roadbridge becomes a tramtrackbridge...

Can't reproduce!!

DaleStan wrote:And it's not necessarily the second one; it's dependent on the X coordinate of the station tile.

Could this also be true for "my" bug ?
Becasue it doesn't happen on every station you build a bridge against.

It doesn't seem to be true, but I wouldn't discount anything. A savegame is probably most useful.
The messages from cht:landinfo from several adjacent stationtiles, and an indication of which ones turn the bridges into tram bridges, might also be useful.

Ok a savegame and a screenshot of the opening part of that savegame, in which a wrongly displayed bridge present.
Configs are the same as in the previous posting.

I have a problem when I attempt to start up TTDP alpha 0 r829. I get the error in the attached file. It only occurs when using a particular GRF File(which I am unable to disclose at this very moment). I will PM the GRF if required. I have tried replacing my TTDP config to no avail.

I have another savegame where only one part of a bridge is tram-tracked. And this tile changes when a train goes by! Could be because of the level crossing??

See screenshot:

Any chance of a list of switches currently in the nightlies? (Which don't exist or work in the Beta) I can't find any such list in the manual.

Just runorwith one version, and then the other.

Either 1) 2.6 will add its new switches to the end of ttdpatch.cfg, or 2) 2.5 will complain about the new ones, and then remove them.

SuperTycoon wrote:Any chance of a list of switches currently in the nightlies? (Which don't exist or work in the Beta) I can't find any such list in the manual.

You can use my new configuration program TTDPC to modify your config. All available switches (and their descriptions) are taken from the 'switches.xml' produced by ttdpatch and, consequently, will always be up to date. You will also see the switches organized by category, which sometimes helps. You can also search through the switches or the descriptions.

Note: If you're currently using TTDXC, please be warned that using TTDPC is equivalent to hand editing your config. I don't know how well TTDXC handles the config afterwards.