Japan Set Development

[dandan]

Looks good. What is it? Would it fit in well with what we have already?

The beauty of it, as far as I can see, is the fact that it is a loco-hauled train, i.e. it would not even require another ID provided any of our existing locos could be used to pull it. And we don't have that many interesting liveries for loco-hauled trains. So if it fits and someone is willing to draw it, I would definitely vote for inclusion.

[Toni Babelony]

It's the new Emperor's EMU train. Class E655. This is maybe a nice option for a Joyful-train refit. Almost all other Emperor's trains were locomotive hauled. Others were a Class 185 and Class 157 with a special 'O-meshi' coach.

Japanese Royal Train
Royal Train (J)
Japanese Royal Train (J)
Class E655 (J)
Class KuRo 157 (J)

[krtaylor]

Well, I'm still not a big fan of livery-refits, I'd rather it just magically appear on its own as a random livery. That way more people will get to see it. Sure is a beauty though, I'd love to have a ride!

[dandan]

Hi all,

another bump, just to keep everyone up to date. Coding of the new trains has not progressed much in the last month for lack of time and also since I am still waiting for some data on the configuration of multiple units. But I am still optimistic that a new version of the train set will be ready some time this summer.

Again, I had to somewhat redesign the running cost scheme. I have run into trouble with my original idea about running costs for multiple units growing linearly with the train length, as implemented in the 415-test grf I posted a while ago. Changing the running cost of the engine with a callback causes various problems and is just not flexible enough. So I have now decided to use running costs for wagons (with a parameter switch for people who do not want that). The big drawback is that this will not currently work with TTDPatch. I have asked about it in the suggestion section a few months back, but it seems the Patch devs are not really convinced of the concept and/or not currently interested in implementing this feature. Maybe some day... in the meantime, no variable running costs in Patch. But I will use different values for Patch (or Open when the parameter is set to off) to make sure that average running costs are about the same and generally sound.

Enough of my ramblings... you'll hear from me again when I have any news.

[krtaylor]

The 415 test GRF seemed to work fine, what was the trouble?

[dandan]

Well, there are several things. Just a quick answer now, because I have to leave home in a few minutes: Running costs are calculated by multiplying a base cost with a factor between 0 and 255. In the test grf, the factor for the loco is increased for every wagon you add. But this means that you have be careful not to exceed 255. In the test grf, a train with 24 wagons costs the same as a train with only one wagon! So you have to impose a limit on the number of wagons (16, 20, 24 or so). That's not pretty but for MUs it might be acceptable. But then you only have something between 10 and 15 different values that you can use, resulting in many trains having exactly the same running costs. That's why I said it was inflexible. Then there are balancing problems between multiple units and loco-hauled trains: If an EMU with 10 cars costs say 30,000$/yr, the same EMU with only 4 cars would cost 12,000$/yr. What then should an electric loco of comparable power and speed cost you? So I believe we need running costs for ordinary cars, too. This causes problems again with the limit on the number of cars (you wouldn't want a maximum length for freight trains, I guess)... There are other little problems, for example with what should get displayed in the purchase menu, with having several engines in one consist etc... So TBH, I just got fed up with trying to get it right when it's clear that the clean solution for what we want is that wagons must have running costs.

[krtaylor]

This issue was discussed with the Patchteam long ago, and no action was taken. However, I've noticed that feature requests often languish for years, UNTIL a project with a working coder actually needs and wants to use them - then, they appear. So it wouldn't hurt to specify exactly the features you are looking for, and make a new post under Suggestions. The worst that can happen is a NO. But I personally feel that the ability to properly allocate running costs to cars would be extremely useful, most particularly for this set.

[dandan]

So it wouldn't hurt to specify exactly the features you are looking for, and make a new post under Suggestions.

I did, and not long ago. You even posted there supporting my suggestions. Lakie was friendly and interested but unconvinced, and no other devs joined the discussion. I think you are right though that once we start using the feature, there is some chance it will get done eventually. Also, I really don't think this is such a big deal. Another reason why I don't want some super-complicated implementation with callbacks. Running costs in the current version of the Japanese Train Set are a bit boring IMO since they are much too low. Costs more in the region of the USSet or the UKRS will make the game more challenging and interesting. I will work on that. Having the costs depend on the train length, too, will be a nice touch but not essential. So this is something to keep in mind, but I really don't think it will break the set for Patch.

[krtaylor]

I agree that higher/more challenging costs are important. I've long been an advocate for finding a way to charge maintenance fees for infrastructure. Well, do your best I guess, and we'll hope for the best as far as Patch innovation. It might not hurt to bump your Suggestion post as a reminder.

[DJ Nekkid]

may i add a few cc's (im the coder of the 2cc set).

first of all, if you add a "high" running cost one one (or all) train type(s) you can also attach this to a wagon.
on the 2cc set i use theese:

with theese settings can you set max running cost of 344 250£/year at 0E \dx4c3c 0D FF (\b255) (0D in the last part there will make that half, i.e. aprox 172k)

Code: Select all

-1 * 0  00 08 01 01 2A 08 0E // Steam running
-1 * 0  00 08 01 01 2B 08 0E // Diesel running
-1 * 0  00 08 01 01 2C 08 0E // Electro Running

and then you can use callback 36 (with VarAct2 type 10) to increase the running cost. This typically applies to a "true" multiple unit with power and thus running cost applied to all wagons(including head).

For example like this:

Code: Select all

-1 * 0  02 00 B5 81 10 00 FF 03 \b45 80 14 14 \b51 80 16 16 \b20 80 0D 0D B4 00 
-1 * 0  02 00 B6 81 0C 00 FF 01 B5 00 36 36 B4 00

in this certain example do i attach this to the (passager-)wagon i will use as a livery override to the current train. in this example can the wagon contain 45 passangers (\b45), it will weigh 51 tons (\b51] and it will use the running cost factor of \b20.
In the passanger wagon action 0 did i ofcourse add running cost base (0E \dx4c3c) but if the 0D is set to 0, this will override it.


If this was unclear, feel free to PM me, or add me to MSN (address in my profile).

ps.
CB36 type 14 is not supported in TTDpatch

[dandan]

Hmm, thanks, but I am not sure I understand what you are saying. Wagons cannot currently have running costs in Patch. It doesn't matter whether you use callback 36 to set property 0D or set it directly with action 0. It will be ignored. The only thing you can do is change the running costs of the loco depending on the number of wagons (with the issues I described above). Does the 2CC set use running costs for wagons?

ps.
CB36 type 14 is not supported in TTDpatch

True, unfortunately. That is the other thing I suggested in the thread mentioned above. But Lakie said there had been some technical problem with implementing it in Patch.

[DJ Nekkid]

Does the 2CC set use running costs for wagons?

Currently only for one train, but im planning to implement it for all "true" MUs... But i did a quick test, and the running costs dont seem to apply to the train this way... altho, a semigood solution is to have the max running costs pretty damn high, and that way you can increase the running costs with pretty damn many wagons before it runs out of range...

Edit:

i think i might have an idea for the CB36-14 (capacity issues), it's not very very elegant, but it's dooable...

make all doubledeckers half length, and use two instead of one... and i _think_ it is possible to build 2 at a time with some articulation involved on the wagon liver override sprites... (remember to add bit 2 in the 1E in the wagon action 0)
However, all in all does it seem like Open have gotten an advantage when it comes to train grf flexibility...

[dandan]

But i did a quick test, and the running costs don't seem to apply to the train this way...

Welcome to the club, I also had a test version using this kind of code and was disappointed it wouldn't work.

a semigood solution is to have the max running costs pretty damn high, and that way you can increase the running costs with pretty damn many wagons before it runs out of range...

It can be done, but it comes with all sorts of annoying little problems. I have thought about it/experimented for a while:

1) First, as you said, there is the thing with the range. You only have 256 different values. If you use a very simple scheme like

"train running cost factor = number of wagons * some base value",

then you will either run out of range very quickly or you will only be able to use very few different base values.

2) If you use some more elaborate scheme, something like

"train running cost factor = some base value + number of wagons * n" (n some small number),

it will be more flexible, but it is confusing for the player. How will he or she be able to compare the running costs of different trains without just trial and error? You can try to set property 0D to some "typical cost" (say for a train with 8 wagons) so that this value gets displayed in the purchase menu and then change it with a callback. (By the way, is there a way to have some calculated value appear in the purchase menu?)

3) There is a problem with balancing between multiple units and loco-hauled trains. If you use wagon running costs only for MUs, then very long MUs will be absurdly expensive or short ones absurdly cheap. If you do it for all trains, you have even more work and also the simple scheme in 1) will definitely not work. It might be acceptable if you only have very few MUs but the Japan Set is all EMUs!

4) The code for the whole thing will be all over the place, so it's even harder to add a parameter switch to be able to turn it on and off.

What I plan to do now (and which will only work in OpenTTD for the time being) is just give some reasonable running cost to all wagons. Certain multiple units will then change that value via callback and have a text displayed in the purchase menu saying something like "50% higher running costs for wagons" or "25% lower running costs for wagons" etc. That way, you will have running costs for wagons and it's still reasonably simple to compare prices.

make all doubledeckers half length, and use two instead of one...

That *is* a funny idea, didn't occur to me at all. The only problem I can see is that the wagons will "break" in curves. If you can live with that, it should work.

[DJ Nekkid]

well, in openttd are neither of theese things a problem, but see my PM

[krtaylor]

Very long MUs ARE absurdly expensive to operate. That's why you don't see them often. They're used in Japan because they're lighter in weight and can go better on the NG and often mountainous tracks.

[dandan]

I guess it depends on your definition of absurd.

I'm not saying they should be the same price as loco-hauled trains, but the effect should not be too strong either, especially not with commuter trains. Express EMUs, let alone the Shinkansen ones, are a different matter.

But values can be easily adjusted. We will all have quite a bit of work with the balancing in the end.

[stevenh]

dandan, a quick heads-up: Twilight Express Observation car is off in nearly all views

[dandan]

Hi Steven, good to hear from you.

Twilight Express Observation car is off in nearly all views

Thanks, I have never noticed this. But it won't matter, because Sanchimaru has redrawn the passenger car sprites from scratch anyway, including the Twilight Express.

[krtaylor]

To the Team:

I have been test-playing dandan's most recent GRF. Yes, there are some things we want to improve for better accuracy and realism. But, my question is, are there any severe playability bugs that would prevent us from doing an official full public release? I don't think there are. And since dandan will shortly be leaving us for 2 months, I'd rather get something out now then let everything hold for awhile again.

This would also be a good opportunity to glance at the readme and see if anything needs to be updated.

Thoughts?

[NekoMaster]

Hey Ppl, I got a small list of Industries taht you could add to the Japan Set : )

The Natural Gas Power Plant shouldnt appear till maybe 2010 or 2012 since Japan this year only Started building a N. Gas Power plant in April. Im not sure if its true so bare with me

Its in Excel (.xls) format