[OTTD] 2cc TrainSet - The Trains of the world in 2cc

[Transportman]

Like I said in your other topic, does this happen to all metro vehicles or just this particular one?

Just a quick check I did, it goes wrong because it is intended to use the Metro Wagon (at least as a last wagon), that will display the closed end, while the normal metro doesn't show the closed end. Also happens with other metro vehicles.

[Purno]

So, let me rephrase to check if I understand;
The bug occurs when coupling multiple engines together rather than using only 1 engine which is coupled to passenger wagons?

[Transportman]

So, let me rephrase to check if I understand;
The bug occurs when coupling multiple engines together rather than using only 1 engine which is coupled to passenger wagons?

Yes, you understood it correctly, although I think it is fine to couple multiple engines and then a passenger wagon (haven't tested), as the passenger wagon gives the closed end.

[Purno]

So to me, that doesn't really sound like a bug, but as a user using the set in a way which wasn't intended. There's no limited functionality here, right? But if you want to make a 2-car metro, you should use an engine plus a wagon, rather than two engines, right?

Still checking if I got this right

[Voyager One]

IIRC what DJ has told me about the code itself...

1 - you buy the front engine -> visible gangway
2 - each new carriage you buy becomes the rear engine
3 - if you add a new engine to the back of the train you basically go back to #1 above

Nothing wrong with the code, that's the way it's supposed to be. Doesn't mean it couldn't/shouldn't b e changed...

[Purno]

So a set of two 2-car metros coupled together would be made by buying engine-wagon-engine-wagon?

Sounds fine to me

[Voyager One]

Yep. That would be it.

HOWEVER...

Metros in 2ccSet get additional power and TE for each new carriage. Therefore, it's not required to buy multiple engines (you basically end up with same power, TE and stuff) because IIRC this multi-engine variant costs more and has higher running costs afterwards.

[TinyMusic]

I don't know if someone asked this already, but is there a version of this train set in their original colours?

[Voyager One]

Nope. There is no "world set" like you're asking...

[Purno]

I don't know if someone asked this already, but is there a version of this train set in their original colours?

Thing is many engines and trains are used in several countries by different companies using different colors. What would be their "original colours"?

But this set didn't aim for realism, which is why there isn't any limit on train consists and such. Flexibility

[AdrienMR]

Is there any chance to update the AGV model? This picture shows the new AGV train model (I know it is from and old newspaper but I haven't found any newer one) http://www.railwaygazette.com/uploads/p ... -model.jpg

P.S. The current model is already awesome, just asking!

[Purno]

As long as someone draws it, and someone codes it, there's a chance. But I'm kinda done with spriting

[Voyager One]

@AdrienMR - Both AGVs are mine, I'll take a look at this new design. Keep in mind that the small OTTD scale doesn't always allow to make big enough differencies. If it turns out to be a difference in just 1 or 2 pixels, it won't be worth it, IIRC the AGV has MANY sprites.

[AdrienMR]

As long as someone draws it, and someone codes it, there's a chance. But I'm kinda done with spriting

And let me take the chance to thank you for all your work!

@AdrienMR - Both AGVs are mine, I'll take a look at this new design. Keep in mind that the small OTTD scale doesn't always allow to make big enough differencies. If it turns out to be a difference in just 1 or 2 pixels, it won't be worth it, IIRC the AGV has MANY sprites.

Thank you for taking a look at it! . Yeah I know, and the difference between the "old" and this new model isn't very big so I understand that it may not be worth the effort. Anyway I'm glad you gonna take a look thank you again!

[MasterMeNL]

Ignore this post, it was impossible to understand properly. That's what I get for being sleepy. x)
Check out the next post.

It looks like I (probably) found a bug for this (and the latest nightly version of 2cc) with this being the only NewGRF enabled on a brand-new world.

When a train is forced to wait at a signal it jumps to low running cost for just a second but the regular running cost while driving comes back. It keeps refreshing the running cost every now and then and I can see the correct running price for a very short amount of time but the full running cost comes back still.

I tested this with one of the newer nightlies, picking up cargo in a station or actually stopping the train still results in low/correct running cost.
It might just be a bug in the nightlies but I really doubt so.

Regards,

Melvin.

[Voyager One]

This is actually not a bug. A vehicle (even IRL) costs less when standing still and costs more when driving. Many other sets work like this too.

[MasterMeNL]

This is actually not a bug. A vehicle (even IRL) costs less when standing still and costs more when driving. Many other sets work like this too.

Thing is, it doesn't work when standing still due to a red signal over here.
The running costs stays in the train running at normal speed condition while actually standing still.
And I can see it just to be amount of money it should be every now and then but it's only like 0,1-0,5 sec or so, after that it jumps straight back to the wrong running cost.

I'll test it in stable 1.3.2 as well, will edit this in a bit.

Edit: problem also exist in stable.

It only happens with non-path signals: block signals, entry signals, etc.
With a path signal the status is "waiting for free path" and running costs are low as they should be.
However, with a block signal it is "heading to X, 0 km/h" and running costs are high because 2cc probably thinks the train is actually moving.
The running cost will jump to low cost for a very very short time but it still jumps to the high running cost after it and it stays there until the game refreshes every 5 sec (in which case it is low running cost again for 0,1-0,5 sec).

Regards,

Melvin.

[Voyager One]

I understand now. Unfortunately, I know nothing about coding so I can't help you. This could be a game "issue" or a NewGRF "issue", I can't tell. Sorry.

Maybe someone else can say...

[planetmaker]

The code used in 2ccTS is like (might be different for other engines, but I don't believe it is):

Code: Select all

//Low cost when standing still, for use in the '10' at the RUN cost spot HEAD
-1 * 0  02 00 EC 82 B4 00 FF 01			// 1 case
                          MU_nnn_RCOST_IDLE 80 00 00	        // Standing still cost
                          MU_nnn_RCOST 80	// RUN cost

//Low cost when standing still, for use in the '10' at the RUN cost spot WAGON
-1 * 0  02 00 ED 82 B4 00 FF 01			// 1 case
                          MU_nnn_RCOST_IDLE 80 00 00	        // Standing still cost
                          MU_nnn_RCOST_WAG 80	// RUN cost

Thus it checks variable B4 (current speed) when determining running costs. It's set to MU_nnn_RCOST_IDLE when speed is 0. And MU_nn_RCOST otherwise.

I'm not too familiar with the exact movement code...

It only happens with non-path signals: block signals, entry signals, etc.
With a path signal the status is "waiting for free path" and running costs are low as they should be.
However, with a block signal it is "heading to X, 0 km/h" and running costs are high because 2cc probably thinks the train is actually moving.
The running cost will jump to low cost for a very very short time but it still jumps to the high running cost after it and it stays there until the game refreshes every 5 sec (in which case it is low running cost again for 0,1-0,5 sec).

might actually be true. It smells a bit like something one might want to investigate in detail in both the code of this set (which vehicle exactly? Every one?) and OpenTTD's movement code... but not before sleep for me

[Voyager One]

Thank you Planetmaker, much appreciated!

but not before sleep for me