There are two version of the Thurbo power car in real life. Some have one pantograph, some have two. I did the one with a single pantograph. You can see both versions in this photo.
If you have a photo of the trash bins, that's really all I need.
Beiträge von ChrisTrains
-
-
I'd say this is all good discussion.
The single biggest thing to understand in TS20xx is that there is no way via scripts to limit traction - or even determine the exact amount of traction being sent to / given by any engine. The game simply doesn't allow it. It's all done by "faking" it in scripts. So when you put the throttle to 100% in the cab, you're really doing nothing other than telling a script that you want "most power". The script then takes that, and spends 500 lines of code altering it to look like it's actually limiting the engine to a certain power output.
Generally speaking, in the Dutch version, AFB on is a limit of 300kN and is required for passenger operation with two engines in 'sandwich' mode. For freight, the AFB would normally be turned off (I think) which then gives access to all the engine's power.@ES64F4 mentions a lot of wheelslip. In reality the engine has software that prevents this by dropping the traction amount to each bogie until the wheelslip stops. As with the throttle - this isn't something that the game supports, so to prevent wheelslip in the game, you either need to manually give less power, or I need to try to figure out how to drop the power automatically when I detect wheelslip in the script.
I don't mind the criticism. Because this saying is true : you can please all the people some of the time, and some of the people all of the time, but you can never please all the people all the time
-
-
You're welcome - I'm glad you like it. It was a lot of hard work.
-
Does the cab "hardware" for the PZB even exist on the MFD? One needs lots of cab nodes or child objects of a few nodes and animation files (.ban) to model all the PZB lights. I always thought only the creator of the cab has the ability to add nodes and cab animations to the GeoPcdx file. If there were however existing PZB light nodes in the cab, adding CVs for them and a PZB script is quite doable (though really thorough and complete PZB simulations are rare
You're right - it does require a lot of work from me - adding animations, deleting all the dutch lamps and lights, getting rid of the ETCS items and code, then putting all the PZB code in and all the PZB lights and warnings.
I'm not 100% sure I understand what @Matthias J. was asking ..
-
Oh I see - you mean reverse-engineering a PZB system into the engine? I don't have a problem with that although without writing all-new scripts I'm not sure how you'd do it ?
-
One question before the release, is it allowed to offer a german PZB (if possible!) as a public update for this engine, or will this option be denied from your site due to a scheduled PZB update in the future?
I honestly don't know now. It was a lot more work getting the Dutch version working with ATB and ETCS emulations than I thought it would be. To do a German version I would have to do a large strip-down of the cab components and scripts and build it up again with all the German wording, messages and PZB code underneath.
It's never 100% out of the possibility but at this precise moment I just don't know. Sorry
-
Alles anzeigen
@'ChrisTrains
Your tutorials are so exellent. Short, clear, no hesitations (happens to ften wenn people make video's without some kind of script on paper or in their head!)About dirt. People ask so much from the developers: repaints and variants. So there will always be something to wish for, All the versions without dirt, with a little bit of dirt, with a lot of dirt.
I will not complain about anny dirt! But I accept your choises and what you offer for money. As the French say "chapeau".
groeten maerklin
Thanks for the compliments - I appreciate it. It's hard work getting these things built, tested, documented etc. The German crowd seem to understand the complexities better than most, which is nice.
-
There is a little bit of dirt. But for the last project - the RS1 - I put dirt on the windshield and everyone on this forum complained
-
For thinks like buttons is this true. But you can set the visibility of nodes in child objects with lua. So you can put for example your display lights in the child and control them not with the control values directly, but with the lua script.
This is sort of true. However it makes the scripts a LOT more complex than they already area. A lot of the controls have lights attached to the blueprints as "interior visibility object" - so they lights come on and off automatically based on the control value. To remove that from the functions given to me by the game and write it into my own scripts is just too complicated. For the digital speedometer alone it would be hundreds of extra lines of code, plus I'd have to have a global override to turn them all off when the player wasn't in the cab.
Trust me. I've looked into all these options many times
-
But you could put some nodes in child objects? As example: You could export all nodes for one display as one child object and then you don't have a problem anymore...
Technically no. The "user interface" section of the blueprint only contains a single entry - the IGS file for the cabview. ONLY things in that file can be used in the cabview. I can make child objects attached to the engine blueprint, but they would not be controllable in the cab. Only objects in the cab geometry file can be addressed by the controls in the blueprint.
-
It's more to do with the total number of objects that the IGS file format can contain (the in-between files that the models are made from).
The blueprint compiler will not accept any model with more than 255 objects.This sounds like a lot but you have to consider everything. For example the digital speedometer in the middle of the display has three digits. The first digit can be 1 or 0, and the other two can be 0-9. Just to do the digital speedometer numbers takes up 22 objects. I used nearly 10% of the available objects to make a digital speedometer that is only 1.5cm high
Each "invisible" button on a display is an object. Each "light" on a display is an object. So the menu where I allow the player to change voltage - 6 variations of voltage means 6 labels (lights), and 6 buttons (because the lights can work independent of the buttons). The ATB / ETCS / "off" selection is 3 buttons, 3 lights. The buttons around the outside of the LCD panel are another 6 objects.
Because the game doesn't really allow "circular" meters like the main traction / braking meter, there is so much complexity in there I can't even begin to describe it. If I put a "blown up" picture of all the components needed to make a circular traction meter work, your mind would melt
So you see you can very quickly run out of objects.
-
There will be a facebook post on friday explaining more about this topic
-
But you only need them if you want to build some special scenario, don’t you?Is it possible to start ETCS on any route in any scenario?
Yes - if you just want to use ETCS yourself, you don't need the scenery objects. They're more for route builders and scenario builders
-
I have a reasonable emulation (not simulation) of ETCS modes SR, FS, override and SH. Also with scenery objects to communicate ETCS modes to the train
I've been working with a couple of drivers for the last month to try to get it as close to reality as possible within the limits of the game. -
Any chance that the MEMOR-system will be emulated as it is a simplier version of the AWS?
Probably not. In Holland they only use ATB and ETCS and this is primarily a Dutch release in v1.0
-
Any chance for a marker like the LZB marker wich automatically activates or deactivates the ETCS so that a route or scenario builder could determine where the ETCS starts or ends? @ChrisTrains
Oooh. I like that idea. I'll have to see about adding that towards the end of the project.
-
Yes. At v1.0 there will be ETCS and ATB and you can choose between them with the touchscreen menu
-
Ok just to jump in and try to answer a couple of questions here
(1) I'm trying to add an emulation of ETCS so that Dutch players can get a better sense of the safety system when driving on the HSL (high speed line) in Holland (where ETCS is used)
(2) It's a "passive" system like my ATB - in that it does NOT require any track signalling in the route. This means it will work on ANY route. Whilst this isn't technically correct, it's why I call these systems "emulations" not "simulations". I have to make some assumptions, and work within the limits of what is possible in the game, but a "passive" ATB system has been extremely popular with the Dutch players because it means the route builders don't need to do anything special and it functions about 90% accurate to the real world. My ETCS emulation will be similar (but there's just no way to do the ETCS planning screen).The biggest challenge in the limits of TS2018 is making circular graphs like the ones needed to traction / braking, and the distance and overspeed graphs in the ETCS screen. The game does not have any built-in way of making these - all you can do is translate and rotate different things in the cab and try to make all the instruments using just those two methods. Normally, for levers, brake gauges etc, this isn't a problem. But when you're trying to replicate an LCD screen it becomes incredibly difficult to do.
I won't even try to explain the problems I've had to overcome just to get this far, but lets just say I wouldn't wish this level of complexity in a cab display on my worst enemy
Anyway - I'm going to tune the system a little bit and perhaps see if I can add a little more functionality, but I think for most players, even a 75% working ETCS emulation will be more fun than nothing at all
-
Maybe but I'm still busy with the 186 project right now.
