Eurostar rolling stock inconsistencies

[Mariculous]

All those recent fixes of trains encouraged me to rework eurostar roling stock, as there seem to be some issues with it, of which some will need discussion.

Eurostar e300 is designed to be a very long train of at least  in the real world, and the whole power is put on 6 bogies (4 of the power heads and 2 on first and last cars "usual" bogie.

Planned and desired changes in short:
- shorten the car bodies of intermediate cars of e300, so a 20 car set (387m) is as long as 13 tiles (390m)
- lengthen e320 cars, so a 16 car set (390m) is as long as 13 tiles (390m)
- move some part of e300s power from the power heads to the first and last car
- eventually add an unpowered first and last car to e300
- restrict possible configurations of e320 to what is possible to order in the real-world.
- add a first class car to the e320, currently only the power heads are fixed to 1st class.
- cost balancing of e300 and e320.
- validation of technical data, incuding air resistance.


In detail:
car length: shortening e300 should be rather simple, as blends are available, although I suspect car lenghth calculations could strike here again.
lengthening e320 is desired but the blends don't seem to be available, so I suspect we'll have to accept cars to be roughly 1.875m too short.

Moving parts of the power to the first and last car: originally, the e300 has 6 powered bogies (2 powered axles each), of which 4 are underneath the power head whilst the remaining are on the usual bogie of the first and last car. Moving this adds up a little to realism and will allow us more economic short trains.

Restricting configurations to what could be oredered in the real-world:
e300 is part of the TGV family, which usually does not have aditional powered axles on the first and last car and is usually only half as long. The long variant, instead of a pair of shorter trains was mainly  is due to channel tunnels security concept. This is not a technical restriction, so I'd add another unpowered first and last car to allow for more cost-effective short trains and with recombination system in mind, also allow two power heads to couple to each other for portion working, as very ferquently done with TGVs in france.

e320 is part of the Velaro family, which is extremely flexible. I'll simply list options that Siemens claims to be possible according to this Siemens paper
Following numbers are always related to the "standard setup" of 8 cars, if not explicitly stated.
Number of cars: 7, 8, 10, 12, 16
Seating and comfort: fully customisable as the whole interior, they list 510 seating/304 standing as "standard" and 596 seating as high-density.
vMax: 320 km/h AC, 250 km/h DC, up to 360 km/h possible.
Power: 8 MW, up to 11 MW

Further, apart from the 7 car configuration, half of the cars are powered. At least in 8 and 16 car configurations, the remaining cars have a pantograph.

I'd suggest to allow 7, 8, 10, 12 and 16 car configurations, allowing them to operate coupled in pairs.
Further, the 360 km/h 11MW option seems very interessting and might be used as a reasonable placeholder for HS2 rolling stock in the near future.
I'd set the seating capacities according to what Eurostart had actually ordered, as adding further variants will blow the depot window.
By default, the Velaro is  equipped for two electrification systems, but Siemens seems to only offer overhead electrification types, thus it is arguable if we want them to be defined as multi electrification or not.


Cost balancing:
Currently, e320 got exactly twice the cost per poerkilometer of e300, which must be an error. Combined with 50% more power, this results in tripled costs per kilometer.
I'd rather expect e320s cost per powerkilometer to be slightly below e300, because it's a highly efficiency optimised and 20 years newer.
I'll have to figure out if e300s cost is excessively low or e320s cost is excessively high in any case, before balancing these to each other.
It would bre great if the balancing spreadheed would still be somewhere out there, which made this task much easyer.


Validation of technical data:
The usual stuff. Power, forces, weights, vMax and so on. Power and vMax seems to be fine, the others will need some tweaking.
In adition to the usual technical data, I'll put some reseach on air resistance.
The Velaro is 20 years newer and within that time Velaro platform was greatly optimised aerodynamically and at its first introduction already slightly more aerodynamic than a usual TGV of that time. Later on air resiatance was reduced by a further 20%.
On the other hand, the e300 is not an usual TGV, as it has a different shape and generally a smaller loading gauge, reducing aerodynamics either.
So hard to tell this without absolute numbers or a direct comparisation.

[Mariculous]

class 373
General
speed: 300 km/h OK
introduction: 11/1994 OK (no source found, but within construction range)
refurbishment: ?/2012
retirement: 12/2015 OK
weight (loaded): 816t 20 car set / 682 16 car set
seats: 210 1st class, 584 2nd class
brake force: 1046, calculated from "A train travelling at 300 kilometres per hour (186 mph) can slow down to stop in 65 seconds, during which time the braking distance is about 2.7 km (1.7 miles)" Although it is unclear if that is an emergency brake, so the old value (930 in a 20 car set) is kept.
The above is an emergency brake. 0.67 m/s² assumed instead.
air resistance: yet to be researched

Power head
length: 22.15m ~> 13 -> 12
power: 6100 -> 4080
force: 205 -> 137
weight: 68.5t OK
axles: 4 OK

First car
length: 21.48m ~> 12
power: 0 -> 2040
force: 0 -> 68
weight: 44.6 Ok
axles: 4 -> 3
seats 2nd class: 48

Intermediate car
length: 11 -> 10
weight 2nd class: 28.1 OK, although these differ in weight from 28.1 to 29.7t, so I'd prefer to average that out.
weight 1st class: 28.1 -> 29.6 1st class
axles: 4 -> 2
seats 1st class: 39 OK
seats 2nd class: 56 -> 60

Catering car
length: 11 -> 10
weight: 31.1 OK
axles: 4 -> 2
seats: 0 OK
catering: 4 OK

Middle car* (does not exist ingame sor far, see options below)
length: 10
weight: 39.4
axles: 3
seats 1st class: 27

First/Last car unpowered (fictional in Eurostar, but very usual in any other TGV setup, fictional weight and capacity based on simmilar cars)
length: 10
weight: 39.4
axles: 3
seats 2nd class: 48


*That car does not exist in the model so far. Graphically, it's not a problem to simply "recycle" the first/last car.
The technical part will need some considerations as it does only have disadvantages, so players won't use it if they don't have to.

I see the following options:
- Add this middle car and enforce it. That would require to define 1st and 2nd class intermmediate cars thrice (before middle, after middle, and "short train" variant)
The advantage of that method is that it simmulates the train most preciesely.

- Do not add that car and keep the preciese real-world data of the other cars.
The advantage is simplicity, but it would result in the 20 car class 373 to have 24 1st class seats too much and to be 19.8t too light.

- Do not add that car but slightly reduce seats and increase weight of ofter cars, so summed models weight and seats fit to the original.
The advantage is simplicity either, the disadvantage is wrong numbers on th remaining cars.

Brake forces and axle loads
I did not find figures of these anywhere. I'd simply calculate axle loads from cars weight and the number of axles and calculate brake forces from trains overall brake force, assuming brake forces to be the same on each exle.

Sources:
https://documents.epfl.ch/users/a/al/allenbac/www/documents/Fich0512.pdf
https://web.archive.org/web/20140310141759/http://www.therailwaycentre.com/New%20EMU%20Tech%20Data/EMU_373.html
https://www.hochgeschwindigkeitszuege.com/england/eurostar.php
https://web.archive.org/web/20091001014310/http://www.raileurope.co.uk/DOCUMENTS/PDFS/TRAIN%20SEATING%20PLANS/EUROSTAR/EUROSTAR%20SEATING%20PLAN.PDF
https://en.wikipedia.org/wiki/British_Rail_Class_373

Further notices:
The specific class of Eurostars is difficult, as they use a first class concept we cannot simmulate. There are two different first classes, sharing the same seats but differing in service.
From that, I'd simple leave it as "usual" first class, but might consider adding a little more comfort than other trains. Especially the APT does have a higher comfort level than Eurostars. Has there been anything special about the APT? Otherwise I'd just set Eurostars 1st class comfort to the same level or slightly above.

Each set draws up to 16MW with 12 MW (16,000 hp) of traction power

https://en.wikipedia.org/wiki/British_Rail_Class_373#Power
Might be interessting for cost per powerkilometer balancing, might further be interessting once power consumption/fueal and energy costs are simmulated.

class 373 air resistance data: https://www.researchgate.net/publication/265843501_The_parameters_of_motion_mechanical_equations_as_a_source_of_uncertainty_for_traction_systems_simulation
Velaro D air resistance (half a 374)
https://diglib.tugraz.at/download.php?id=5cc8223762fbe&location=browse
ICE3 air resistance (Velaro D predecessor)
https://research.chalmers.se/publication/512310/file/512310_Fulltext.pdf

[Mariculous]

Class 374

Configurations
I am not sure about the configurations. I know what the platform is capalble of in the real world but simutrans concept of static vehicles and the rather restrictive couple constraint concept cannot is too restrictive in this case.

In principle I want to achieve the following:
- Allow the original class 374 configuration
- Restrict the train to be 7, 8, 10, 12 or 16 cars long
- Make each car available in a 2nd clas variant.
- Allow the 7 car variant to have an unpowered restaurant.
- Add an additional 360 km/h variant.


The second point alone would already require quite a lot of cars, so I thought about restricting the length to at least 7 cars instead.
That, in combination with the ability to build the real-world configuration of class 374 results in 4+3+3=10 cars.
To make each car also available in 2nd class, another 6 cars are required, resulting in 16 cars.

Allowing the 7 car train to have an unpowered restaurant car adds another one, so we got 17 cars already.
Adding the 360 km/h variant doubled that number, although the unpowered cars could generally be set to 360 km/h, thuse used for both variants, reducing that number by 8, resulting in 26.

requires to duplicate at least each powered car, which is another 6 cars, resulting in 23 cars.
So this is impractical.

Rejecting the requirement for 7 cars will result in 9 cars, just for the 320 km/h variant, at least another 7 cars for the 360 km/h variant, resulting in 16 or 18 cars.
I'd prefer to strictly seperate these and make them available as upgrade/downgrade instead, so it's still 18 cars.

A simmilar system as with ships might be used: seperate the car body and the interior, where the car body defines the graphics and data related to the car body and pseudo cars add the "interior" and engines.
Such a system would require 4 car bodies(cab twice), 5 interiors(intermediate and cabs differ in capacity) and 4 engines (need to be specific to cab and intermediate again)
That's still 13 cars.

Does anyone have a better idea (not involving a new feature) ?



Technical data

General
speed: 320 km/h OK
introduction: 12/2015 OK, but as always arguable
deceleration: emergency braking of 1.4 m/s?; 0.67 m/s? in service assumed, as this is usual to other Velaros. 
resulting brake force: 30 -> 40
axles: 4 OK

Powered cars generally (cab, Intermediate powered)
power: 2000 OK
force: 71 -> 75
additional weight: +2t

Cab
length: 25.70m ~> 12 -> 13
weight: 60 OK
1st class seats: 36 -> 40
2nd class seats: 60
air resistance: yet to be researched

Intermediate car
length: 24.20m ~> 12 -> 13
weight unpowered: 56 OK
weight powered: 58 OK
1st class seats: 36 -> 40
2nd class seats: 60
2nd class + restaurant seats: 35; +2.55t



next steps
Now I got the technical data and adjusted the dat of class 373.
The next step will be scaling the cars of class 373 in *fearead face* blender, to get the length right.
After that, cost balancing will be done. Any help on this is appreciated, as I suspect I do not fully understand the current balancing. In any case, the relative balancing between class 373 and374 is definitely not correct.
The last step will be aerodynamic balancing. I found some data about it, especially drag coefficients, but I cannot relate these to simutrans air resistance number. If anyone is familliar with this, help would be appreciated here either.
The very last step will be writing te collected data to the class 374 dats. This depends on a decision about the configuration, so I'd really like to get your feedback on that.

[jamespetts]

Thank you for your work on this: this is most helpful. A question about the scaling, if I may: is it your intention to calibrate the scale using the same scale ruler in Blender as used for most other pakset vehicles?

The aerodynamic balancing does have a formula; I cannot immediately remember the exact unit of measurement, but you should be able to infer it from any other unit by calibrating against some known streamlined locomotives, such as the LNER A4 class if you have a drag coefficient for that, too.

As to cost balancing, the current interim balancing was done by Dr. Supergood, who should be able to explain how this works.

I am somewhat hesitant to separate car bodies and interiors of trains, not least because of the problems that this will cause in getting them all to align properly. In ships, this works fine because nothing needs to be behind them; but in a train, exact alignment with following vehicles is needed.

It is possible to set the length of the graphics for the internals to 0, but then they all bunch up on each other. It is not possible to define them without graphics, since, in that case, they will not be selectable in the depot window. The only place where this is done for trains is the "mail boot" of certain very early carriages which sit at the back of trains. Careful testing will be required to ensure that this be workable and comprehensible to the player.

[Mariculous]

Thank you for your work on this: this is most helpful. A question about the scaling, if I may: is it your intention to calibrate the scale using the same scale ruler in Blender as used for most other pakset vehicles?

To be honest, I did not relate these calculations to the blender at all but to simutrans vehicle length unit in relation to 30 meters per tile.
Clas 373 cars are very short due to the jacobs bogies. An intermediate car is only 18.7m long, thus 18.7/30*16=9.97, thus roughly 10.
If that blender ruler differs from the claimed scale, I'll need to recalculate the car lengths according to it. In any case, either 373 or 374 (or both) use the wrong scale.

Well if seperating the car body from the interior does not work, I'll have to define 9 cars puls the same again for the faster variant.

I do not have aerodynamics data of LNER A4 yet, but I might find it somewhere.
I'd prefer to understand the used formula instead to calculate it properly, however.

@Dr. Supergood Help, help!
I thought the whole balancing was about costs per powerkilometer with a little efficiency adjustment factor, but class 374 has twice the cost per powerkilometer than class 373, so what is going on there?
Is it just a typo or intended? I'd rather expect class 374 to have a lower cost per powerkilometer than class 373 as it's more modern and efficient in the real-world.

[jamespetts]

To be honest, I did not relate these calculations to the blender at all but to simutrans vehicle length unit in relation to 30 meters per tile.
Clas 373 cars are very short due to the jacobs bogies. An intermediate car is only 18.7m long, thus 18.7/30*16=9.97, thus roughly 10.
If that blender ruler differs from the claimed scale, I'll need to recalculate the car lengths according to it. In any case, either 373 or 374 (or both) use the wrong scale.

The vehicles in Pak128.Britain-Ex all have their graphical scale defined on the same basis as the ruler: see here for a detailed explanation as to how to set the scale. There has been problematic scale inconsistency in the past, so it is very important to scale all pakset vehicles in a consistent manner using this ruler.

Well if seperating the car body from the interior does not work, I'll have to define 9 cars puls the same again for the faster variant.

I do not have aerodynamics data of LNER A4 yet, but I might find it somewhere.
I'd prefer to understand the used formula instead to calculate it properly, however.

The formula is in convoy.cc here:

Code Select Expand


sint32 convoy_t::calc_max_speed(const weight_summary_t &weight)
{
const float32e8_t Frs = g_accel * (get_adverse_summary().fr * weight.weight_cos + weight.weight_sin);
if (Frs > get_starting_force())
{
// this convoy is too heavy to start.
return 0;
}

// this iterative version is a bit more precise as it uses the correct speed.
/*
float32e8_t v = vehicle_summary.max_speed * kmh2ms;
float32e8_t F = get_force(v);
float32e8_t Ff = adverse.cf * v * v;
if (Frs + Ff > F)
{
// this convoy is too weak for its maximum allowed speed.
float32e8_t vmax = v;
float32e8_t vmin = 0;
while (sgn(vmax - vmin, float32e8_t::milli))
{
v = (vmax + vmin) * float32e8_t::half;
F = get_force(v);
Ff = adverse.cf * v * v;
float32e8_t Frsf = Frs + Ff;
int sign = sgn(Frsf - F, float32e8_t::milli);
switch (sign)
{
case 1:
// too weak for this speed
vmax = v;
continue;

case -1:
// has force for more speed
vmin = v;
continue;
}
break;
}
}
return (v * ms2kmh + float32e8_t::half).to_sint32();
*/

// this version approximates the result. It ignores that get_continuous_power() depends on vehicle.max_speed,
// which results in less power, than actually is present at lower speed.
const float32e8_t p3 = Frs / (float32e8_t::three * adverse.cf);
const float32e8_t q2 = get_continuous_power() / (float32e8_t::two * adverse.cf);
const float32e8_t sd = signed_power(q2 * q2 + p3 * p3 * p3, float32e8_t::half);
const float32e8_t vmax = signed_power(q2 + sd, float32e8_t::third) + signed_power(q2 - sd, float32e8_t::third);
return min(vehicle_summary.max_speed, (sint32)(vmax * ms2kmh + float32e8_t::one)); // 1.0 to compensate inaccuracy of calculation and make sure this is at least what calc_move() evaluates.
}


The air resistance is the "adverse.cf" variable.

[Mariculous]

I guess that scale inconsistency was caused because a 30 m/tile graphics scale of the pak is mentioned in many places, for example in the first post of your linked thread you said:

As a general rule though, 1 tile should represent 30m, this allows a double car tram to fit on one station tile.

That ruler is mentioned on the second page, but it's not mentioned that it's different from 30m/tile scale, apart from airplanes and ships, so I did not care about it, assuming 30m/tile is fine.

In addition, I suspect I do not understand this:

Also, any vehicle over 15 meters in length uses a special logarithmic scaling system, as a linear scaling system would result in large ships and aircraft being too big to fit in the largest allowed size of graphics. However, rail and road vehicles are never this long, so this need be considered only if you are producing ships.

Now I'm even more confused about scaling. Most modern rail vehicles actually are longer than 15m, but I know of none being longer than 30m, so how I would interpret this sentence as "the logarithmic scale is applied to ships and aircrafts above 15m length to prevent them from exceeding the sprites borders, whilst not applied to railway vehicles and busses, as they won't exceed the length anyways", but I'm not sure about this.

Does that rule apply generally to any vehicle exceeding 15m or not?
I had quick attempt to validated the 30m/tile graphical scale according to class 395 before. A car is 23.9m ~> 23.9/30*16=12.75, thus roughly 13, which is also used in the dat files.

That's all confusing. I'll just check that ruler.

Edit, I just imorted the 15m ruler and sclaed it by 18.7/15 to get an 18.7m ruler.
The result can be seen in the following image:

In case of an "logarithmic" scale (it's actually not logarithmic!) The ruler would be even smaller, thus the car body is definitely too long!

[Mariculous]

Cost balancing

I just found Dr. Supergood on Bridgewater and the conclusion was they are both balanced properly to the balancing model he used, but he also stated the balancing has some issues, so it should be seen as a guideline only and may be entirely thrown away in some cases in favor for a more gameplay oriented one.


A little excursion to the balancing calculations and the actual isues with it:
The used model is mainly based on energy costs and vehicles energy consumption.
In fact, according to the Department for Business, Energy & Industrial Strategy, the energy costs (given in GDP index) in the UK did increase quite a lot from 484 to 779, which is an increase of roughly 60%

On the other hand, there is the improved efficiency. According to the quote a few posts above, the 373 turns 75% percent of the power from the catenary into power on rails, whereas this is 80% in case of class 374. (posted that on the forums a few days ago including a source, but don't ask me where...)

According to this, I get a factor in between costs per powerkilometer of class 373 and 374 of exactly 1.5
It is yet unclear why my calculations diverge from Dr. supergoods that much, might be the source of energy cost was simply different (mine in GDP, the other one in Pound?)

Simmulating energy costs that way feels a little strange, as energy costs of a specific vehicle are always fixed to their construction date, causing players to always run their good old, in the real-world inefficient fleet until its obsolescence factor increases to a level which makes them finally more expensive to run than newer rolling stock.
That was observed on stephenson-siemens with the replacement of class 91 and can currently be seen with class 373.
Further, in the real-world ticket prices rise continously to compensate such rising energy costs, whereas in simutrans they are constant.

I see the following options to balance these out:
1. strictly stick to the energy cost model, which means the newer vehicles are often worse in terms of ingame cost/use than their predecessor. In this specific case, the 16 car configuration of class 374 will still be twice as expensive to run than a 20 car 373, whereas it does only have 20% more capacity. The savings in journey time are that small it will definitely run less profitable than simply retaining class 373.

2. use a gameplay cost-use based balancing of class 374 to class 373, that means configure a class 374 ingame in a way that has the same capacity and journey times as a class 374 on the used lines and then tweak the balancing so both trains generate roughly the same profit. Players can then decide to trade a little more running costs for a faster service.

3. use something in between: That means essentially do 2. but put a little more costs on the newer one due to increased energy costs.

I'm tending towards 2, but 3 might also be fine.

[DrSuperGood]

It is yet unclear why my calculations diverge from Dr. supergoods that much, might be the source of energy cost was simply different (mine in GDP, the other one in Pound?)

Because I recall eye balling/guessing it. I did post the spreadsheet so you can see the numbers used in the calculations. Also I balanced around a power per km model which is not quite how physics works but was needed so that faster vehicles moving slowly were not more economical than slower ones moving at their full speed.

If you have better models to use feel free to update the entire balance. The only reason I update everything was because it was still balanced around speed bonus so anything fast for its age had an impossible running cost.

[Mariculous]

Hmmm...
Using https://www.gov.uk/government/statistical-data-sets/historical-electricity-data as a measure for energy costs in the first place might be a good start, but I guess I'm actually too lazy to re-balance each single electric vehicle, especially as it will only be another interims solution due to lack of some balancing critical features.

In any case, thanks for the informations, I'll search for that table and have a look at how costs would change when using energy data from the above table and then consider if it's worth to update the balancing in general or not.

[Vladki]

As long as ticket prices in simutrans are constant, we must assume that energy costs are constant too.

[jamespetts]

As long as ticket prices in simutrans are constant, we must assume that energy costs are constant too.

Indeed - and the feature that changes the one will also change the other.

[Mariculous]

I guess it's actually more complicated :(
In general I agree with this, but there is increasing efficiency, especially per-seat efficiency, which counterplays increasing costs in the real-world in addition to ticket pricing.
That means based on current features, a good balancing might result in the per-seat cost at the same speed to be roughly constant over time, although with some fluctuations to simulate that some ages in the real-world had been more difficult than others.

Getting the speed into these calculations is much more difficult.


Anyways, that feedback given, I will balance the e320 to the same cost per powerkilometer as e300.

[Vladki]

OK I should be more precise - energy costs should be considered constant, efficiency getting better over time. And indeed that is what was roughly set at trams:
It starts at 0.60 c/km/kW in 1885 till 0.1 c/km/kW in 1992. here is my spreadsheet I used for trams and electrostars: http://list.extended.simutrans.org/~simutrans/vehicle-balancing.ods

[Mariculous]

So you suggest class 374 to have the same cost per powerkilometer as 801 and class 373 to have 7% (75% efficiency against 80% efficiency) higher cost per powerkilometer?
Balancing it like this would result in class 373 to be 60% more expensive than currently but class 374 to be 50% less expensive than currently.
It's not too easy to run 373 profitably already, but we may try it out.
There is no right or wrong in balancing currently anyway, as the most important component, which is actually consumed power rather than maximum possible power, is not simulated at all.

[Vladki]

I'm not sure about 801 cost balance. I did not touch that yet. Electrostars are all at 0.15 c/km/kW, class 801 too Trams are at 0.10 since 1990's...  Hmm well 0.15 for 374 seems right, I'm not sure about 373 (maybe 0.20 - check other trains from around 1994). Current balance is 0.10 for 373, and 0.20 for 374 which is clearly wrong... It seems that most vehicles are balanced at these quite discreet values 0.20, 0.15, 0.10, ...

[DrSuperGood]

As long as ticket prices in simutrans are constant, we must assume that energy costs are constant too.

This points towards a more fundamental flaw with Simutrans Extended in that one cannot set prices to offset the actual cost of moving people. In real life the ticket prices are set by the cost of running the line/journey, rather than some arbitrary number gifted to the universe by the great pakset creators.

Varying electrical prices is important to model, just like varying fuel costs. For example with modern aviation, before the recent global crisis, there was a move towards smaller twin jet engine planes as they are more fuel efficient driven by increasing fuel prices. The player should have to make such a choice and accept that at certain stages of the game it will cost more to move the same wares from one place to another with the same vehicle and that upgrading to a newer more efficient vehicle will potentially result in money savings.

The cost of producing electricity has changed a lot over time. Even if one normalizes out the currency inflation.

[jamespetts]

This points towards a more fundamental flaw with Simutrans Extended in that one cannot set prices to offset the actual cost of moving people. In real life the ticket prices are set by the cost of running the line/journey, rather than some arbitrary number gifted to the universe by the great pakset creators.

Varying electrical prices is important to model, just like varying fuel costs. For example with modern aviation, before the recent global crisis, there was a move towards smaller twin jet engine planes as they are more fuel efficient driven by increasing fuel prices. The player should have to make such a choice and accept that at certain stages of the game it will cost more to move the same wares from one place to another with the same vehicle and that upgrading to a newer more efficient vehicle will potentially result in money savings.

The cost of producing electricity has changed a lot over time. Even if one normalizes out the currency inflation.

One can set prices using the passenger and mail classes feature: it is not realistically practical to have any more nuanced system than this that is player choosable. Inflation, of course, is a different thing, and what is planned and has been for a long time is differential inflation for a wide range of different types of costs and revenues.

However, that will have to wait until prior economic features that will affect what categories of costs and revenues that there are in the game have been implemented.

[Mariculous]

The player should have to make such a choice and accept that at certain stages of the game it will cost more to move the same wares from one place to another with the same vehicle and that upgrading to a newer more efficient vehicle will potentially result in money savings.

Yes!
But simulating fuel and energy costs by adjusting costs per powerkilometer directly, including these fuel changes will result in the exact opposite:
Newer vehicles will be more expensive than older ones, thus less efficient in terms of simutrans.
People won't consider ever upgrading to class 374 at all.

For such a balancing to work, we need the following 5 essential features:
- specify a fuel cost timeline spcific to each fuel type (including electricity)
- specify fuel consumption to vehicles e.g. base fuel consumption and fuel per powerkilometer values.
- calculate actual power consumption in the physics engine rather than always assuming maximum power.
- simulation of recuperation
- a system of ticket pricing changes, e.g. a pricing timeline.

The features are ordered by importance, although that's arguable for sure. Any of these alone will improve the situation.

I'm not sure about 373 (maybe 0.20 - check other trains from around 1994).

Class 357 from 1999 is 0.15 either, so I'll just set 373 to 0.16, which to my above sources represents the efficiency of 373 in relation to 374 exactly.
It should at least be a good start.

and what is planned and has been for a long time is differential inflation for a wide range of different types of costs and revenues.

That actually is an increase ticket prices and I guess roughly what is needed to simulate the effect of increasing energy costs in ticket pricings.

I am not exactly sure if that is sufficient to properly balance high-speed trains: In the real-world, ticket prices on high-speed sections are more expensive than tickets on conventional sections and people seem to be willing to pay that price.

[jamespetts]

Yes!
But simulating fuel and energy costs by adjusting costs per powerkilometer directly, including these fuel changes will result in the exact opposite:
Newer vehicles will be more expensive than older ones, thus less efficient in terms of simutrans.
People won't consider ever upgrading to class 374 at all.

For such a balancing to work, we need the following 5 essential features:
- specify a fuel cost timeline spcific to each fuel type (including electricity)
- specify fuel consumption to vehicles e.g. base fuel consumption and fuel per powerkilometer values.
- calculate actual power consumption in the physics engine rather than always assuming maximum power.
- simulation of recuperation
- a system of ticket pricing changes, e.g. a pricing timeline.

The features are ordered by importance, although that's arguable for sure. Any of these alone will improve the situation.

These features are all planned; the second and third were not originally planned, and will add considerable complexity to the vehicle management changes, and I am still not sure quite how to do this, especially in conjunction with fuel capacity, range and the calculation of steam locomotive power, which is predicated on a certain rate of coal consumption per square foot of firegrate area per hour multiplied by an inferred efficiency value, but something of this order will need to be done in order for balancing to work properly.

That actually is an increase ticket prices and I guess roughly what is needed to simulate the effect of increasing energy costs in ticket pricings.

I am not exactly sure if that is sufficient to properly balance high-speed trains: In the real-world, ticket prices on high-speed sections are more expensive than tickets on conventional sections and people seem to be willing to pay that price.

As written above, this sort of differential pricing is what passenger and mail classes are for. Passengers will always choose the fastest route that they can afford, so, if you price high speed trains as medium/very high instead of low/high, then only passengers of the medium class will travel on them, and only those of the very high class will pay first class fares on them; low and very low passengers will have to take other, slower routes.

Similarly with aircraft: early aircraft are set to "very high" by default for this reason (and by reason of their low capacity); the first jet aircraft can attract passengers at a higher price, leaving older slow aircraft to take lower classes of passengers on the same routes, and likewise supersonic travel - Concorde is priced by default at "very high". The ability to do this is the main reason for having implemented the class system in the first place.

[Mariculous]

As written above, this sort of differential pricing is what passenger and mail classes are for.

Yes, the point is ahead of "cannot afford" there seems to be some willingness to spend that money.
Recently, Flixtrain, a private operator of long-distance trains joined that market in Germany, According to their surveys, they do mainly attract price conscious passengers, whilst some stated to travel just because of the price, whilst others stated they had used IC or ICE trains before, but will now prefer Flixtrain.
I am aware a system considering this is considered extremely complicated, so that's just to keep in mind.
In simutrans, we do simulate these entirely new passengers, but we do do not simulate these switching from a faster service to a slower and cheaper one.
That said, the same will very likely apply the other way round: There will be people able to pay a little more, and they will do so if the time saving is sgnificiant, as it was the case on Cologne-Frankfurt line (time savings of roughly an hour, whilst the original route was roughly 2:20) but they won't be willing to, if that saving is only a few minutes.
That said, I am aware that any kind of price (and comfort) considerations in route calculations are considered to be a huge thing, but this should be kept in mind.

These features are all planned;

Yes, this was just meant to pint out which of the planned features are essential to a proper vehicle balancing.
It was not meant to suggest anything new nor to discuss the details.

Without these, we should not attempt to mimic these, as this will lead to strange player decisions.
Instead, these real-world factors should be more-or-less ignored in the interims balancing, in favor for gameplay. They might be considered as a small factor to the balancing, but they should not be the major factor, as power prices currently are.


Well, back to topic, the Eurostars:
I just set the dats up, although I did not change monthly costs nor purchase costs as I don't know how these are balanced.
I just assume they are fine, we will see.

Rescaling in progress, although getting carzy on the hundreds of different objects used for each single pane in the model.

The two points
- lengthen e320 cars, so a 16 car set (390m) is as long as 13 tiles (390m)
- restrict possible configurations of e320 to what is possible to order in the real-world.
Will be left out because it's currently not possible.

So the last point left will be understanding aerodynamics code to get the numbers in a relation to the researched data.

[Vladki]

Reading all this it sounds as my old suggestion: have a maximum financial budget for a journey in addition to time budget. IMHO a less wealthy passenger might be willing to pay for higher class travel for short journey if there was no other option, or if it would take him to the destination in time, while lower class travel would be too long. But I understand that this would be algorithmically much more complicated. There are too many factors in play:

First is the classic time = money. So a long journey in cheap vehicles should have the same "cost/weight" as short journey in expensive vehicles: cost = time * money
But then the comfort kicks in. People may be willing to spend longer time traveling in more comfortable vehicle: cost = time / comfort   and also willing to pay more for comfort: cost = money / comfort.
So the final formula could be: cost = time * money / comfort  (perhaps with some constants to adjust weights as what is more important for each simulated passenger).
Then the search would be looking for minimum "cost". Yet still with max limits for time and money.

Also the 5-class system is IMHO too coarse. The prices in those 5-classes are still fixed throughout the ages. Yet the comfort levels vary quite a lot. So it would make sense to let the player set the costs in cents/km for each class, or good, and let the simulated passengers decide if they are willing (can afford) to pay that.

Also for different prices for goods delivery. I doubt that any transport company charges different money for delivering ton of coal, than for a ton of stone or iron ore. They just delivered a truckload of stuff and you pay for it. They do not care what it is...  Of course a premium price for perishable goods is correct, if the truck has cooling, or is really rushing to deliver in time (newspapers).

[jamespetts]

We are getting a very, very long way off the topic of the Eurostar, and it is extremely difficult to deal with things that might possibly need any sort of action on my part at some point if it is not in a thread where the title makes it clear what the topic is about.

As Vladki indicates, the suggestion that there be a more complex and subtle pricing system has been discussed in the past, more than once. The course system was deliberately chosen as the only workable system that did not cause anomalies and that was not too computationally intensive for larger maps.

If anyone would like to propose a detailed algorithmic solution to the anomaly/computational intensity issues, that will need to be done in response to the post where these were pointed out. I should also note that any fundamental change to the class system requiring any change in pakset implementation for each classed vehicle would require so much pakset work as to delay implementation by many, many years. For reference, the passenger/mail classes system that we have was introduced in 2017, and we still do not have a complete implementation of this for rail vehicles so enormous is the task.

Again, please do not respond to these points here: this thread is for the discussion of Eurostar rolling stock inconsistencies. Please respond to this in one of the threads where a more sophisticated class/price system has already been discussed so that the discussion can be a continuation of that discussion so as to avoid the need for any repetition.

[Mariculous]

After some work on light infrastructure, I just thought I need some blender-free time, so I switched back to Eurostars, just to notice the next step will be rendering the Eurostars. Scaling and a little polishing was already done.

In case of vehicles this should be easy... I thought.

Does anyone have an idea why the render script will render 8 times the exact same perspective in case of class 373 blend files?
The only thing I know is that's not the cause of my object reorganisation as the same does also happen using the unmodified class 373 files.

What's wrong with these? Blender... We won't ever become friends.

Edit: There had been an animation attached to the camera. I just removed all animations, now it's working.