Atomic Systems

gptech wrote:Martin, which bit of Cortana makes you want/need to get rid of it?

Snoopy, a nosey resource hogging woman, need I say more? And no I'm not talking about "er indoors!"

Sorry for the late reply Gary owd mate we've just come back from a long weekend staying at Kirkby Stephen station!

>>Snoopy, a nosey resource hogging woman

<< Hear Hear.

https://www.tomshardware.com/reviews/di ... ,5846.html

John

ussvoyager wrote:I was changing all the track in an old small route to a newer one, I deleted all the old track until I got to the turntable.. then crash

That's the story we've read many times so what you've experienced may not be because of any update to the game. What you're left with isn't the inability to remove the turntable, but the inability to remove the vestigial image of it. It's no surprise that you can't select it, as it ain't there!
That sounds like the reference to it in the track tile has been removed, but not in Tracks.bin so it still shows in the 2D view.
It should be fairly simple to open Tracks.bin with RW Tools and find the relevant section that needs deleting, just use the "search/replace" feature to look for the turntables file name.

smarty2 wrote:Snoopy, a nosey resource hogging woman

Just tell her that her bum's getting big....she'll leave you alone for months then.

I'm assuming you log into Windows using a Microsoft account, which by default allows loads of apps (not just the nosey woman) to read and use your search history, location, preferences, etc. These can all be fine-tuned within the settings app.
Logging on with a local PC account gets away with all that though----she doesn't bother me here, she's known from day 1 that it's "my house, my rules" and is only there as a quiet, submissive search assistant---once again, no need to upset the system by crippling part of it.

meonia wrote: The access violation is essentially there to protect us from viruses and hackers so I'm wondering what could cause Windows 10 to think some 64bit scenarios are a threat to the computer.

No it's not.

The error occurs when an application tries to access a protected memory address, and whilst that may be due to a viral infection it isn't the only reason it could happen---faulty or failing hardware, a bad Windows configuration, a bad application configuration, sloppy programming...…and so on are all as likely to be the culprit.
DEP has been highlighted as possible cause, and as many will be running systems with components that support hardware DEP it isn't as easy to turn off as software based protection, and is an ON/OFF system wide setting applied from the command prompt rather than the software based version in which you can exempt chosen programs.

Traveller54 wrote:After TS2019 was launched and I couldn't launch the 64bit version I bit the bullet and updated the Motherboard, CPU, a new SSD and memory. Steam was reinstalled, over the top of the original but leaving the Railworks files alone, now TS will not run at all!

LATER....SORTED but the 64bit will still not run!!

EVEN LATER: After a good cleanup after my upgrade/reinstall and, vóila, the 64bit now works! Onwards...... !

Cheers, Trav.

Good news Trav!

Interesting. Ran a scenario on the WCML5.1 immediately after running one on the Weardale and Teesdale and it started happily, albeit with very low frame rates. Decided to restart TS2019 to see whether it would improve them and now it crashed with an Access Violation.

Hi Guys

I must admit to not understanding all this confusion over "Access Violation" messages, and am certainly NOT up to fixing things on my own !

But my first incident of it has just occurred, whilst running a scenario on the Chiltern Mainline, which was a "standard" one, and involved driving a Class 168 Non stop from Bicester Parkway to Marylebone. All was going ok and I was about half way through the 50 min scenario, when without warning, and at high speed, I got the "Access violation" message and the game crashed to desktop !!

What I thought I DID understand from reading messages on here, was that I would only get this message at the START of a scenario...not when in the middle of it ?

Can anyone confirm that this WILL EVENTUALLY be fixed by DTG, and that I will not have to do anything myself to fix it ? Because if this sort of thing is going to happen in the middle of a lengthy scenario, I am likely to lose interest in Train Simulator very quickly, and I have had tremendous enjoyment out of it for several years !

Thanks

Derek

Derek

Can anyone confirm that this WILL EVENTUALLY be fixed by DTG, and that I will not have to do anything myself to fix it ? Because if this sort of thing is going to happen in the middle of a lengthy scenario, I am likely to lose interest in Train Simulator very quickly, and I have had tremendous enjoyment out of it for several years

Why would they? This is a Just Trains product and DTG don't guarantee that it will work? Its quite a laggy route - I ran this scenario and experienced over 30 stutters mainly approaching bridges, low frame rates overall and a peak RAM usage of 6GB (plus 2.6GB for win 10). It finished OK in 64-bit, but did crash at around the halfway mark when running under 32-bit.
So a delicate question were you definitely running TS 2109 in 64-bit mode?
How much RAM do have installed?
Have you contacted Just Trains?

Access violations can occur anywhere any time - there is no set pattern if there is a memory violation it can occur randomly in some cases. It may be due to the scenario and/or the route, what you ran before starting TS, AV, Firewall, etc Settings and so on. It is a complex problem that may take time to resolve.

regards
pH

shinymac wrote:Can anyone confirm that this WILL EVENTUALLY be fixed by DTG,

As Peter has written the "access violation" isn't necessarily down to the core of TS, so, in my view at least, the onus is on scenario writers to create scenarios that work--and work within the framework of the game. Has anyone else had bother with scenarios (under 32 or 64bit) that when under close scrutiny and editing are fixed by simple giving services *proper* "Final Destination" instruction rather than just a "last instruction in the list"? ---things like that, which might work 95% of the time but sit outside of the accepted (as far as I'm aware anyway) way of doing it, are a big contributory factor. There are more and more scenarios written like appearing, one in particular mentioning "unknown issues" and "bugs" in the documentation but after 20 minutes in the editor (and don't forget I'm very much an amateur scenario writer) those "issues" and "bugs" go away.
So far all everybody's done is run round in circles looking for an *official* scapegoat to blame rather than drilling down through the waffle in here and other forums and investigating what the game is actually being instructed to do when the error occurs. GIGO is an acronym that still holds!!

There are a LOT of people who pay good money to sit back and play Train Simulator without having to write scenarios, create routes or fix third party creations. If, like Shinymac, they cannot cope with the continuous "Access Violations" they will just quit TS2019 and go on to something else.

Its no skin off our noses except for the money we have already spent, but I'm sure DTG and their dependants will find it becomes a big hole in their wallets.

Mike.

Continuous??.....he's just suffered his first one!

How many are getting access violations on default scenarios?

Never ever had an access violation under 32 but, this is an event brought about by 64 bit. Obviously, it is a dtg problem since it has occurred with this new version of ts imo.

Only if it's happening in DTG scenarios Martin. If it's because the 64bit coding is less forgiving of *user error* then the users (creators) need to change.
Let's name and shame...somebody name an easily obtainable scenario that refuses to run without the violations; let's see what's what.