@JachyHm thanks for the explanation on the wheelslip behavior. But can you maybe also tell us where it is located? I would like to set it in a different way because it is really annoying that you can never get more than 190kN without wheelslip. I'd rather prefer none of it at all.
script.out. You can edit it using almost every text editor which support hex edit. But you'll need to know ASM at least bit and you have to understand the script and how it does work.
Also das e bedeutet bei Computern 10x. Also: 1e+009 = 109 = 1.000.000.000 = 1 Milliarde
Da kann wohl nur @JachyHm bei diesem speziellen Rolling Friction Coefficient weiterhelfen. Um zu erfahren, wie eine geänderte Variable für einen besseren Reibungskoeffizienten auszusehen hat.
Why are the variables for dry, wet and snow-covered tracks equal to 1e+009? Other locomotives have dry = 0.35, wet = 0.25 and snowy = 0.30. What does a modified variable look like for a better coefficient of friction?
I'm really sorry, that I noticed this so late. But anyway, it's because TS adhesion is bugged and causes many glitches (e.g. starting with/without carriages), so we decided to use our own adhesion model. For this we measured tractive and adhesion effort on the locomotive in many diferrent conditions and based on that we seted constants of commonly used adhesion equation.
adhesiveTractiveForce = ((7500/(absSpeedKPH+44)+161)*0.001*9.81*decisiveAdhession*mass) where decisiveAdhession is calculated from these values:
ADHESE_USABLE = 0.95
ADHESE_DRY = 1*ADHESE_USABLE
ADHESE_WET_START = 0.5*ADHESE_USABLE
ADHESE_WET_TIME_RAISE = 70
ADHESE_WET = 0.7*ADHESE_USABLE
ADHESE_WET_TIME_DECREASE = 300
ADHESE_WET_AFTER = 700
ADHESE_SNOW = 0.5*ADHESE_USABLE
ADHESE_COEF_LEAVES = 0.3Therefore we had to ensure, that no one would ever get to hardcoded adhesion, because otherways that can limit the tractive effort way below, than it should be.
Testfahrt Os3731 mit ČD460 [WIP] von Olmütz nach Mährisch Schönberg.
Das mit der Traktion geht mit [ shift , ] und [ . ], Schau dir mal das Video von Ritschi weiter vorne im Tread an.
Was die Sifa betrifft must du damit leben. Wie bei der PZB LZB geht sie auch nicht zu deaktivieren.
Habe zumindest noch nix gefunden wie es funktioniert.
I think he thought the minimum limit of these bars.
That are as in reality, so there is no chance to change them. 
(20% kN and 30% power)
@Torsten Figura auf der HUN 70 (https://www.nagykorosts.hu/termek/train-simulator-vac/), also eine Ungarische.
@Schwarzwaldbahner ok, hab ich nicht gewusst. Dann liegt es wohl sicher daran!
If you want to use MIREL, you must at first complete D1 test.
That is "self" diagnosis test.
Each part of test is displayed using one line of MIREL's display.
For successfull completion you need to:
Yup, we have big problems with 380, as on bad weather all trains operated by 380 are having big delays, because of wheelslips 
However, thanks to @Trainsa and @ES64F4 i`ve found another point in script, which could potentially cause QD crash on some other computers, so i uploaded v0.9.6.1b.
https://rw.jachyhm.cz/download/2019/04/je-to-tu/
We wish you pleasant journey
Gerade versucht mit nem Euorocity und gut 500t am Haken, über die Tauern zu kommen. Keine Chance. Maximal 25% Traktion, ansonsten gibt es Radschlupf. Die vR 101 hat damit kein Problem.
Because our 380 has implemented real adhession.
This is graph of maximal force, which 380 can make and adhession on best weather, best rail and everything...
In real you will almost never have these conditions.
The purple curve is maximal force.
You can see, that it is almost same until aprox 100km/h and there it begins rapidly lowering. That is because of maximal power.
Simply as P = Ft * v, you would have to increase maximal power to increase max force in high speeds.
And now to the "problem" - the hatched one curve is maximal adhession at IDEAL CONDITIONS.
So you can see, that except of speeds < ~5-10 km/h you can use max force only at speeds higher than ~160. Otherways it will always end in wheelslip.
Btw. Curtius-Kniffler is not accurate, in reality it is bit higher, so also in the game is.
But for autumn, you can multiply that adhession curve by approx. 0.3 and you will get the right one.
And so the script does.
Btw. 101 obviously do not do this, as it does not have any script controled wheelslip and adhession in game is totally fucked up... I do not have any graph for 101, but i think it would be also very similair as weigths of 101 an 380 is almost same.
But that everybody knows... At least developers
Btw. if you are interested in more details, the exact way, how 380 calculates immediate adhession force is this:
function CalcAdhessionKNforAxle(coef, v, locoMass, numberOfAxles)
local speed = math.abs(v*3.6)
local maxkN = ((7500)/(speed+44)+161)*0.001*9.81*coef*locoMass
return(maxkN/pocetNaprav)
endOh. Okay.
I will look on it in next update.
And reverser? Which problem is there?
Bedienbarkeit mit der Maus und HUD Anzeige für Reverser (Richtungsschalter)
And that does not work? :O
For me mouse does work for every controller in cab either the reverser is shown in HUD :O
Okay guys, uploaded v0.9.6b!
QD should now work without problems.
PZB issue from @FabiaLP should now work properly.
And some other not important things
Alles anzeigen
Hello, you can make the locomotive clear that they can be driven with a control car, because that is not.
The wobble of the combination lever, came because in the train a control car was there, without there are no problems with the combination lever.
Is it possible to fix that again, for the next update?
If the control car works based on "transmitting" VirtualThrottleAndBrake" through unit, it will never work. Use vR control cars f.e. "DB BR120 Bpmbdzf IC ExpertLine". Or some other EL control cars.
the regulator goes up and down without control the green light trembles and blinks, you push the regulator of the hud and returns to lower the solo, and also the thrust lever.
If i get your description right, it is already repaired. It will be included in next update.
Okay guys!
I have awesome news!
I discovered and succesfully repaired that bug with crashing QD!
It was caused by this part of code, which i bit rewrited and tested with @Trainsa and it does not cause problems anymore.
I will edit some things with main votage filter voltage and i will pack it and upload!
Hopefully you will not have any problems anymore 
The traction setting doesn´t seem to work correctly anymore it seems. In the 0.941 there was a clear change in trraction when it changed from slow to high setting. This didin´t occure anymore (the bugs were placed well appart and no wheel slip). Also moving the slow speed bug did affect the traction when the loco was well over 30, so it shouldn´t care about the setting of the slower bug.
It was simplified in older versions and i repair it finally today.
It works bit different.
The Ft (left arrow) sets maximum tractive FORCE from 0-275kN lineary, whereas the Pt (right one) sets tractive POWER from 0-6400kW lineary.
In low speeds it may seem, that it is doing same, but in higher speed you will see, that if you have Ft on 50%, the real throttle will be much above it.
And lastly two things which could be added: If the LZB speed goes down to a slower speed, the AFB speed bug should step down with it accordingly. So for example I´m traveling at 200 kph and the LZB goes down to 160, the speed bug shluld go down with it. If the speed goes up then again, the speed bug should follow as well again. This should only kick in when the train was traveling at a higher speed before the reduction. So if I`ve set it to 160 and LZB goes up to 200, it remains at 160. That´s at least how it´s supposed to work.
From the docs which i have for 380 i am not completely sure, if 380 does this.
And a second idea is about the AFB speed and LZBEnde: The speed bug will jump down to 0 after LZBEnde. That´s fine as it´s correct. But this means full braking is initiated then till teh speed bug is over the current speed again. That´s very annyoing and not very realistic. I´d suppose after it jumps to 0, just cut the traction, so the user must put the bug back up to the desired setting and reset traction via the lever back to "V" and then "J" again. In a Br 101 for exmaple the traction is cut and you have to get the speed setting back to your desired speed and the reengage power.
On 380 it works bit different.
If you are on LZB and you were using AFB you have after showing LZB Ende 10 seconds to confirm the end with Frei and 10 seconds to click 0 speed on AFB. But the 0 is not really set up for next 2 seconds, which you have to select new speed.
If you will not confirm Ende by Frei, than Emergency brakes will apply and you will not be able to release them until stop.
If you do not confirm by zero speed, or do not set new speed, than it will only set 0 on AFB and the loco will start braking with maximum brake, but emergency.
Also you can everytime set new speed.
If you are not using AFB, you just confirm it by Frei key.
About that showing wrong speed, are you sure, that there was not any red signal in next 10km?
Because it should not display 000 instead of 200 just by itself...
I will check it, maybe it is really bug.
Sorry ice, aber das ist doch nun wirklich falsch. So eine Zugriffsverletzung wird vom TS selbst provoziert und ausgelöst. Das hat überhaupt nichts mit anderer Software oder gar Hardware zu tun. Der TS greift bei so einem Fehler in einen Topf in dem ihm halt die Finger abgehakt werden, weil er zu dem Zeitpunkt in dem Topf nichts zu suchen hat. Das macht er schon immer. Früher waren es eben die Dumps, jetzt zeigt er den Fehler eben so an. Geändert hat sich da nichts. Woher die Fehler rühren ist bis Heute ein Rätsel. Das kann alles mögliche sein. Von fehlerhaften Modelldateien, über zerfummelte Blueprints bis hin zu schlampig oder übereifrig programmierten Scripten. In jedem Falle ist der TS selbst das verantwortliche Programm für den Fehler.
However, maybe ice is not as far from truth, as somebody on Czech forum (or my sites, I do not remember exactly) has written, that registry clean with CCleaner helped him.
Then some other people also confirmed, but also there were some, to whom it does not help.
However ACCESS VIOLATION simply means wrong pointer to point in memory which is not allocated to that program (in our case TS).
But that can mean completely anything 
Only the brake and throttle tremble a bit when you put it with the mouse on full power and then let go so he stays in the green area.
QDrive does not cause any problems either.
Oh. I do not use mouse for controlling, so I did not test it...
However, I would try to do my best to solve it
This is question more on Dominick as I don't even remember which repaints we have ;D
But I think all, or almost all repaints, that 380s have in real
Yes I only use QD ... ok that would have been a shame that would be a normal problem ... thanks anyway for the answers.
You can send here log from LogMate if we would be able to find anything useful, but I do not think so
Were you using QuickDrive, or normal scenario (Free roam, Standart, Career does not matter)?
If QD, than do not use QD.
That is everything I can say for now.
I absolutely do not know, what can cause this error, as there was not even any error in log...
For me and for some others works QD good 
Soweit läuft jetzt fast alles, der Kombi Hebel zum Bremsen, oder Beschleunigen wackelt immer vor und zurück, soll das so sein ?
Can you record that on video?
It is probably an bug
Were you deleting completely previous version?
CS_addon/Kal000px/Preload and CS_addon/Kal000px/Railvehicles?
Okay, 0.95b uploaded, i did some more changes, that i planned before.
However it should be one of the last updates before releasing the "full" version with other repaints.
Download link is same as usual :
https://rw.jachyhm.cz/download/2019/04/je-to-tu/
Changelog:
