Škoda 109E Freeware

Zitat von Stefan2385

This is the dump

Die häufigsten Ursachen für den Fehler "0xC0000005: Zugriffsverletzung" sind: beschädigte Registrierung, Malware, fehlerhafter Arbeitsspeicher oder Gerätetreiber, falsch geschriebene, installierte oder aktualisierte Software oder sogar Windows-Sicherheitsfunktionen.

Softwarefehler würde ich ausschliessen, daa es ja bei anderen (die meisten) ohne Fehler läuft.

The most common causes of the "0xC0000005: Access Violation" error are: corrupted registry, malware, bad memory or device drivers, misspelled, installed or updated software, or even Windows security features.

Software error, I would rule out, since it is running in other (most) without errors.

@JachyHm

VIDEO0350.mp4

Das Handyvideo, zeigt das Problem mit dem Kombi Hebel.

und was kann ich dagegen tun @ice?

Zitat von ice

Die häufigsten Ursachen für den Fehler "0xC0000005: Zugriffsverletzung" sind: beschädigte Registrierung, Malware, fehlerhafter Arbeitsspeicher oder Gerätetreiber, falsch geschriebene, installierte oder aktualisierte Software oder sogar Windows-Sicherheitsfunktionen.

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.

Steht doch da ...

TS Logmate auslesen /TS Hauptverzeichnis)
Grafiktreiber prüfen erneuern
DirectX
Virusprüfung PC
Speichertest ...im Startfenster ..diag eingeben (Win7(bei W10 weiss ich nicht)
Mal ohne Viruswächter installieren..
usw ...

Zitat von Maik Goltz

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.

Irgendwas an seinen System oder Pfaden stimmt nicht.
Ich bekomme hier keine Acess Violation und der Gro0teil aller Nutzer der Lok auch nicht. Da muss es wohl eher an einen Wackelsystem oder Umfeld liegen. Vielleicht ein Nootebook oder Bürorechner.

Zitat von Maik Goltz

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

SuperRitschie: I’d like to do all repaints of 380 possible - the standard livery of 380.001 will be only this one, but then I’ve almost done 011, 013 and 017 at this moment.

Habe einen Gaming Laptop...Ja na dann geht es halt nicht man kann auch nicht alles haben. Das sind die log datein.

Zitat von JachyHm

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.

That's just by chance, and some days/tries later it will crash again. In QD or heavier scenarios this has something to do with the amount of assets that were loaded and if there are some corrup files/proccedures within them. That's clearly by randomness dependend of the selected vehicles that are loaded in and the order of it. T simply test if it is the loco itself, put them onto a simple route with no other assets. That would give some clear results.

Besides that, we both know how heavy and unconventional your scripts are working. That could give another chance for random chrashes.

Zitat von JachyHm

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

Yes, and it is always within that single programm. TS causes this and reported it, no other programm or proccess is involved here. The shame at least is, that TS does not backtrace the error itself. If so, we would know where to search. But isn't.

Laptop Systeme werden offiziell nicht unterstützt vom TS Simulator. (Das ist schon einmal der erste Fehler)
Man müsste den Dump auslesen ..das Logfile ist mehr wie ein Kassenbeleg ..
Es kann an so vielen unterschiedlichen Sachen liegen.
Mal in 32 Bit oder 64 Bit versuchen.. oder nach Start von Steam ..vom Internet trennen und den Virenwächter ausschalten ..und neu installieren und dann erst den TS starten ...mehr als Versuchen geht nicht.

Die Absturzkanidaten halten sich aber hier in Grenzen..
die überwiegende TS Gemeinschaft hat damit kein Problem.
Vielleicht weil sie keine limitierte Hardware wie z.B.oft Laptops haben oder andere schädliche Software im Einsatz haben.

The crash candidates are limited here ..
the vast TS community has no problem with that.
Maybe because they do not have limited hardware such as often laptops or other malicious software in use.

Also bisher ging alles auf diesem laptop...kaufe mirja nicht ohne grund einen teuren gaming laptop von msi...egal nun es geht nicht und damit muss ich nun leben gibt ja noch genug anderes zum fahren.

also, ich hatte noch keine Probleme.... habe generell seit meinem Upgrade der Hardware (vor allem die CPU) kaum noch Probleme mit abstürzen... unter 2K4T hatte ich wirklich alle 5 Stunden einen Dump/crash, jetzt habe ich unter ähnlichen Bedingungen kaum noch Probleme.

Es scheint unter Umständen eine Korrelation zwischen Auslastung der Hardware und der Anfälligkeit des TS zu Abstürzen zu geben, aber mehr kann ich aus meiner Beobachtung nicht ziehen.

Hierbei beachte ich nur Abstürze von "unbekannten Gründen" sprich, wenn ich bastel und mein Script oder meine Sim zerschieße geht der dump "aufs Haus".

mfg

FabiaLP

Zitat von Stefan2385

Also bisher ging alles auf diesem laptop...

Der 30 Jahre alte Fernseher ist kaputt mit Röhrenschaden ..Wie kann das den passieren ? fragt die Omi den Elektriker..

Auf den ein oder anderen Laptop kann es ja durchaus gut gehen ...sind ja alle unterschiedlich stark.

@JachyHm,

einfach genial, was Euer Team da auf die Beine gestellt hat - ganz großes Kino. Meine erste Testfahrt hat super funktioniert. Spende geht am Wochenende noch raus - so etwas muß einfach honoriert werden.

Gleichzeitig ein Dankeschön an @ice für die schnellen Repaints.

Ich fahre seit 2015 den TS auf meinem 9 Jahre alten Sony Vaio (8GB) und es läuft von Anfang an. Warum laufen Szenarien bei dem Einem und bei dem Anderen nicht? Ich denke, es gibt im TS etliche Korrelationen, die immer für irgendetwas verantwortlich sind. Nichts genaues weis man nicht.

Wer weiß wo der fehler diesmal liegt...egal geht auch so weiter

@JachyHm Thank you for the patches! Now the flashing with restricted 500hz is working just fine. And the LZB braking curve is now properly maintained. Great!

Some other things have changed with the new version 0.95 I found on a high speed LZB run on Frankfurt High Speed: The display didn´t show the speed "200", it just showed "000" when it should have been otherewhise. Other speed restrictions were fine though.
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.

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.

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.

Bei mir lief die Skoda auch am Anfang ohne Probleme. Das Prob. trat bei mir z.B. erst auf, machdem ich die Signale von SignalTeam upgedatet hatte mit dem Dump.

Zitat von Schwarzwaldbahner

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.

Zitat von Schwarzwaldbahner

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.

Zitat von Schwarzwaldbahner

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.