Public Beta Build 76.3a

Armstrong Power House Class 68 Enhancement Pack you use the Keys Shift + W to turn it on but this doesn't in the new beta. Whether it is a DTG or AP problem to fix I don't know.

 

Regarding the above... stating there is a crash when just looking at trains but not placing them.
There used to be an issue, I ran into it a lot, with moving trains. The causes are a bit arcane, I created a free roam for Canadian Mountain Passes with 40 proper long stationary AI trains in one go, and yet upon trying to fine tune the position of just one train in a fresh, empty scenario, moving it a few times to place it at the edge of the track, it would very often crash. Whether it allocates too much memory and then takes too long to free it, no idea. I had epic struggles filling a Castle Rock yard with 4x10 gondolas. Sometimes the crash would occur when selecting the consist (in order to set it loaded).

I recall it happened as recently as about a year ago, when I last edited a scenario. In that case, it was Donner Pass.

So the test case is as simple as place a moderate string of wagons, and just keep moving them a little.

 

This is on a fresh install of Train Sim Classic, with only the required Third Party Content installed from Armstrong Powerhouse.

By "load up", I meant to Play from the Drive menu, however the same error occurs when trying to load up in the Scenario Editor.

Also which log were you on about, the longer log ts-2023-12-13-18-06-33 (910kbs), or the shorter log ts-2023-12-13-18-17-05.log (95kbs)?

 

Again, which Scenario are you trying?

 

One which is private, one which is released. The released one linked below is what produced log ts-2023-12-13-18-06-33.log (910kbs).

https://www.trainsimcommunity.com/m...3730-1z41-0751-london-waterloo-to-bournemouth

 

Ok, can't test this as I'm missing some of the requirements. Seems to be a demanding one, saw it requires a bat file to be run.

 

The bat file was originally a way to get around the out of memory errors, however even with doing all the steps involved with the bat file, it still comes up with out of memory errors. It even has out of memory errors on what's meant to be the less memory intensive version of the scenario.

 

I was having this issue after deleting and rebuilding my PlayerProfiles.bin file. Reset to run borderless. solved the issue.

 

This is an excellent tool to clear the cache at anytime in or out of the game via a shortcut on your desktop. https://steamcommunity.com/sharedfiles/filedetails/?id=465303891&searchtext=delete+cache

 

I'm running borderless and I'm still running into this issue. The error message says that the issue is with the despatcher. It seems to be worse in large stations where there are a few AI trains coming and going in and out of the station and across the various junctions in the station throat - I've had the issue in Piccadilly and Lime Street on the "Liverpool-Manchester Revamped" workshop route. It seems that if you move the AI driver/instructions to a train on the adjacent platform that doesn't have a route to the original destination because there is no valid routing, wrong directionality or no electrification, the game is crashing rather than just giving the usual error symbol in the timetable editor.

 

That's another issue.

I've had crashes in the editor when just adding a driver icon to a train (only DTG content used). There is still a bug somewhere in the code - or what would be worse, in one of the DTG assets (hard to find out.)

I've made a quick separate installation (just copying the core files and London-Faversham route /assets there), and ran into these issues. Much switching between editor and play mode involved.

And this new issue which came apparent on the SFSJ UP Mission Bay hauler, the dispatcher module crashing when selecting an invalid destination (it should just display the instruction as red), is worrysome although Steve mentioned it being a content not a core issue...

 

Hola,
En mi caso me pasa lo siguiente. Teniendo la beta la versión DXT12 no me funciona, y si estoy jugando, si me salgo al escritorio de mi ordenador y vuelvo me da error "OUT OF MEMORY" (Adjunto foto). He visto que siempre me pasa eso ultimo.

Tambien, hay ocasiones en las ejecuto el juego (desde steam), aparece el icono en la barra de tareas (icono de TSC) pero no carga, llega un momento donde se cierra solo.

 

Hey, this is an English-speaking forum.

 

Hey, try to be a bit nicer on Christmas Eve

 

Post from gonla using Google Translate:
Hello,
In my case the following happens to me. Having the beta version DXT12 does not work for me, and if I am playing, if I go out to my computer's desktop and come back I get an "OUT OF MEMORY" error (photo attached). I have seen that the latter always happens to me.

Also, there are times when I run the game (from Steam), the icon appears in the taskbar (TSC icon) but it does not load, there comes a time where it closes by itself.
Solution: Use borderless, and do not use DX12 and see if that helps.

 

I get the 'OUT OF MEMORY' error, Fatal error in mode 'FRONT END'.

This occurs in the standard 64bit edition. Logs attached.

 

There seems to be more than just a few corrupt assets that are lying around in peoples installs. They have probably been there for ages.
Its all the Core fixes that are bringing badly configured content out of hiding, which is a good thing, because most of it can probably be repaired.

I was thinking of creating tools to look for faulty assets in peoples installs.

 

Sadge.
Start game (takes two minutes).
Open Settle-Carlisle scenario in build.
Delete the Class 47.
Ctrl-X the Class 158 set. (With that, there are no trains remaining.)
Press 2D Map.
Crash.

Completely reproducible. Attached.

 

If it takes two minutes for the game to load you have some serious issues to begin with. Any idea why so long?

 

Just checking all scenarios.
I have too many installed and it's too clumsy to juggle.

 

Bug report - Error in module DISPATCHER

I'm still puzzled by the CalTrain "UP Mission Bay Hauler" scenario which crashes under the new core. Though I have submitted a fixed version to TrainSim-Steve I still wonder why the scenario crashes at all.

Now, I've encountered the same issue. Selecting an - for whatever reason - invalid destination causes the editor to crash out, instead of just displaying the !!:!!:!! timings as it does in v72.3b (old core).

Stumbled across this one:

Route: Longhai Railway (Official DLC, developer: SimtechVision)

Reproduce the bug:
- Create a new Standard scenario at Lingbao
- Place a train at Lingbao Platform 2, facing east
- Add a driver and select Minchai Platform 1 as Final Destination
- Add first instruction "Pick Up Passengers" at Lingbao Platform 2
- Now add second instruction "Pick Up Passengers" and select Sammenxiaxi Platform 3
The editor will crash.

View attachment 143359

I have attached the LogMate log. It shows troubles with a network ribbon and crashes in LandscapeTextureManager.cpp

So if this is a content issue - can we have the core catch these as it did before?

 

Part 2.

The reason is that Sammenxiaxi P3 is (partially) westbound only. This should not crash the dispatcher!

 

The more scenarios installed, the longer it takes. Also Workshop content gets synced at start, the more you have the longer it takes (there's ways to avoid this by copying WS stuff manually from its Steam folder to TSC, then unsubscribe it - so it doesn't get tagged as WS content.)

The biggest time-eater is the processing of the scenario database into a format that the old ShockwaveFlash-based Drive menu can handle.

 

I have 214 routes and forty one pages of locos in the QD menu not to mention those not QD capable not nearly as sexy a setup as you have and it takes about 15-20 seconds to load to the main menu and another 15-20 seconds to get to the scenario start page.

 

Which is fine, but again it depends more on the total number of scenarios and the amount of subscribed content.
Then it depends on storage speed.
Finally, processing the scenario database speed also depends on your CPU.

 

BUG REPORT

Again, a DLC scenario does not work with the new core. Instant crash (DISPATCHER).

Exe: RailWorks64.exe v76.3a
DLC: Longhai Railway - Lingbao to Mianchi
Developer: Simtech Vision
Scenario: 3. [HXD1] Heavy Freight Service and Passenger Train

Confirmed to be working in RailWorks64.exe v72.3b



Interesting correlation:
Just finished this scenario in v72.3b - it's not giving you a checkmark or star upon completion.

Now I've opened this one in the editor (v72.3b):

It shows duplicate vehicle IDs - definitely a content bug. Can this be caught by a checking routine instead of crashing the sim? I'm sure there's some old RailSimulator scenarios that have duplicate vehicle IDs, will check what happens there.

The vehicle IDs here are probably the result of copy-pasting - The HXD1 A and B units have the same number here. As they are involved in uncoupling instructions later, they probably cause the crash due to the internal consist list pointers (speculating)

So the issue with this one is you have two A units with the same ID, then two B units also sharing the ID, instead of ABAB or ABBA with four unique IDs.

 

"you CPU" . Don't call me a CPU. LOL.

 

"DPU" would be more appropriate I guess?

 

TrainSim-Steve Smokebox

A happy new year - but Houston we have a problem.

Just playing Saluda Grade - The Rouster Job to find it too has become incompatible and instantly crashes. (Clean test installation, RailWorks64.exe)


Full Logmate report: (unfortunately the vehicle name is not given... are vehicles processed in the order they appear in scenario.bin?)

Code:

2024.01.03 12:25:51.386 - [RunTimeError] - Error - Collision will go through the ground for railvehicle (Collision centre < half of collision height)
2024.01.03 12:25:51.389 - [RunTimeError] -
2024.01.03 12:25:51.389 - [RunTimeError] - ASSERT(rvbp.getCollisionHeight() / 2 < rvbp.getCollisionCentreY());
2024.01.03 12:25:51.389 - [RunTimeError] -
2024.01.03 12:25:51.389 - [RunTimeError] - ConsistCreateInfoBuilder::setupVehicleInfo()
2024.01.03 12:25:51.389 - [RunTimeError] -
2024.01.03 12:25:51.389 - [RunTimeError] - D:\RGBuild\CoreRelease\Code\DLLs\PhysicsManager\ConsistCreateInfoBuilder.cpp : 254
2024.01.03 12:25:51.389 - [Content] - Trace D:\RGBuild\CoreRelease\Code\DLLs\SoundSystem\cRailSimSoundSystem.cpp : 536 = Sample HIS\Saluda\Audio\RailVehicles\Diesel\GP35\Engine\Engine\pump.dav has a 'smpl' chunk defined in the wave file but no sample loops defined.
This is not an error, but is it as intended?
2024.01.03 12:25:51.389 - [Content] - Trace D:\RGBuild\CoreRelease\Code\DLLs\SoundSystem\cRailSim

Already preparing a fix - it is a content issue that was ignored in older versions. TSC now rightfully calls this out. Though I'm questioning the purpose of a vertical collision check at all, but enlighten me please.

Browsing the cars, I found the centerbeam to have the collision box touch the ground. (3.62 / 2 - 1.81 = 0)


There's some things to consider. I've just opened a Centerbeam blueprint by Milepost's Peace River DLC. It has the same parameters - so this should now also crash.

Do we need to rework all assets or can we remove the check from the code - what is the purpose for testing vertical collision? (Edit: other than camera clipping?)

 

Generally speaking, I feel that TS is quite lacking log-wise. Most of the time when you use LogMate, you're left with a log that randomly ends, sometimes in the middle of a line... (there must be some kind of parallelism between the core execution and log writing)
So I am ready to understand that all remaining OOMs would be caused by faulty assets, but we definitely need better logs to help tackle that!

 

I've fixed the Centerbeam collision box, but the next issue causing a crash follows: (Still testing "The Rouster Job" scenario)

Code:

2024.01.03 13:03:12.802 - [RunTimeError] - Tile 14, -11 has no recordset, refcount: 1
2024.01.03 13:03:12.802 - [RunTimeError] -
2024.01.03 13:03:12.802 - [RunTimeError] - ASSERT(0);
2024.01.03 13:03:12.802 - [RunTimeError] -
2024.01.03 13:03:12.802 - [RunTimeError] - cHeightFieldManager::moveViewPointBy()
2024.01.03 13:03:12.802 - [RunTimeError] -
2024.01.03 13:03:12.802 - [RunTimeError] - D:\RGBuild\CoreRelease\Code\DLLs\Engine\theTerrainManager\cHeightFieldManager.cpp : 645
2024.01.03 13:03:17.881 - [Content] - Trace D:\RGBuild\CoreRelease\Code\DLLs\SoundSystem\cRailSimSoundSystem.cpp : 536 = Sample HIS\Saluda\Audio\RailVehicles\Diesel\GP35\Engine\Engine\pump.dav has a 'smpl' chunk defined in the wave file but no sample loops defined.
This is not an error, but is it as intended?
2024.01.03 13:03:17.881 - [Content] - Trace D:\RGBuild\CoreRelease\Code\DLLs\SoundSystem\cRailSimSoundSystem.cpp : 536 = Sample HIS\Saluda\Audio\RailVehicles\Diesel\GP35\Engine\Engine\pump_start.dav has a 'smpl' chunk de

 

Being on a bridge above or beyond another train.

I mean an assumption can be made that vertical collision will never be valid - you would hit the rails and the bridge / embankment, but if it's a generic engine just intersecting boxes, it needs that info.

While I don't know about any X sections where the train would have any significant difference, a BR 323 might casually fit under a US autorack, would have to check what the vertical difference is in their case. Otherwise, the checking can be simplified from 3D to 2D - if the height difference is lower than a constant value, it intersects the 2D.

In theory the trains can also get stuck on a changing grade, similar to trucks in crossing.
Ideally the trucks and the wheels shouldn't be part of a collision box for this purpose.

By the way the assertion is wrong. 3.82 / 2 < 1.91 is false, since they are equal. Either binary math lack of precision issue, or it is coded as "not greater".

 

The assertion is not wrong. It needs CollisionHeight/2 to be less than CollisionCentreY. As they are equal the assertion is not TRUE and thus an error is generated, rightfully, as the box touches the ground which will trigger a collision.

I don't understand your bridges example, sorry. The collision box height is only needed for the boom camera to prevent clipping, not for any sort of physics as we don't stack trains over each other and there's no need to simulate tunnel entry collisions which just don't happen, as opposed to lorries getting stuck under too low bridges.

 

ASSERT(rvbp.getCollisionHeight() / 2 < rvbp.getCollisionCentreY());
When they are equal, the collision box is exactly on the rails / ground. Apparently there is content like that.
The message reads: Collision centre < half of collision height.
So the equality case is not covered by the messages. It might be pedancy, or it might uncover the error - since you actually discovered that it used to work. One must always clarify end test all edge cases.

Isn't it used for train-train collisions? How does that work, different parameters?
Easy example, that notorious NS Coal District scenario with the loco in the way that you gently push.
But I've also managed to exit a siding slightly blocked, scratching and slightly lift-tilting my entire train against the other.

 

No, the assertion needs the box to NOT touch the ground by asking for SMALLER THAN. And as the result is zero, meaning EQUAL, a FALSE is triggered. EQUAL already triggers collision code, which is logically correct as the distance between the ground and the object is zero which is exactly - a collision.

Most cars have the collision box at least 60 cm over the ground. The Centerbeam is the only vehicle in the DLC that's not, it's a copy paste blueprint, it was forgotten to raise the Y centre, and the bug is older. Apparently, the vertical collision was never tested before by the game and was added to the code in good intention, and I'm questioning if that code is useful if it's not adding anything but makes reworking a lot of assets necessary (maybe it's really only that centerbeam, but it gets used in a lot of DLC, which would require pushing a lot of Steam updates.)

Train collisions happen on the horizontal plane, not the vertical, so CollisionLength/Width are the important values for testing a collision. (Width is important for curve radii)

First example: basic collision by movement, CollisionLength triggers, second: corner collision in tight curves -> both Length and Width trigger


Though the full collision box is used to not make the "2" camera enter the roof and clip through the vehicle. Still, an overdimensioned box would not be a problem for the game.

It's a design decision - shall we be strict, for possible future features, or do we really need the vertical check? Maybe there is an occasion where a derailment was triggered due to an oversized collision box (there was, the GP40Pack for example, but again this was a CollisionLength issue. There is no simple way to check for correct values here by the game, as the only thing that's always there is the ground which is in the vertical plane..

So far, I have not tested all DLC on the new core. But I'm afraid as I had two hits in one day (Longhai and Saluda), there's more to discover that's not working due to the dispatcher crash when selecting invalid track destinations and the collision check.

So, to be pedantic: Yes - this sudden change of grade could require a height collision check (if the couplings allowed this)

 

How do you distinguish this from hitting the side of another train in a diamond?

I was looking for a famous pic, this is the best I found:

On both occasions, the vertical check is required. The assert, maybe not. Specific numbers, also not / either they're on the same level or significantly elevated.

 

Still can't see the point. The invisible collision box could be of arbitrary height - you are confusing the collision box with the position of the vehicle itself on the rails, which is built upon the bogie blueprint. I don't see a need to check for the collision height of a car here. We don't want to check if we're touching catenary or bridges, as that'll never happen in railroading unless an infrastructural accident happened. Irrelevant for the game.

The Collision height would be useful if we could crawl beneath the train, or climb a tanker. We can't, so we don't need to tell the game where bottom and top is. The visible 3D model is sufficient.

I could make a loco with a tiny cube inside as collision box - you wouldn't notice that other than the 2 camera would clip through the loco when panning around. Coupling uses the coupler pivot coordinates as a reference.

 

I have hit the same crash error message (though possibly not the same error) in two of my favourite scenarios in the current version - I haven't changed them and they worked before. I wil check if this assert is a factor for mine too - brilliant if it is and I can fix it - thanks for the detective work.
And agreed - better info in logmate is definitely required!

 

Any info on those scenarios? Or which assets they're using?

Still, I can't figure out the second error (Tile 14,-11 has no record). Both terrain and scenery tiles do have a RecordSet, and the route itself is ok.

I've moved Saluda Grade over to my v72.3 installation for the time being.

 

Sorry - I won't get to test this out for a few days. I'll shout when I get more info.

Re your tile issue - does the error go away if you remove the tile? Could it be a procedural tile issue where a linear asset runs over onto an adjoining tile?

 

Does anyone remember this?
"Hello everyone, I'm posting this early so you have a chance to read this before the update rolls out at around 1pm UTC/GMT today. Please post your feedback relating only to the build version 76.3a here. If you wish to discuss things not relating to this beta, please use the other forums."
Steve

 

Mr Policeman, the reports are here because the newest versions cannot load content that the previous versions could.
There are two ways out of this: either like Microsoft, ensure that bogus content still loads (actually handling the exceptions), or sitting down and fixing all content errors, at least on Steam. The latter can be done by the community as long as DTG is willing to accept the proposed changes and publish them. Mind you they cannot afford to test them, it's part of the situation and the beauty: the content is already broken, so an update cannot make it worse. Since they apparently stopped producing content, I don't see why they couldn't focus on being product managers instead of being developers. (Maybe this alpha testing is a prelude to it.)

 

As triznya.andras has said - these things were working in the beta (up to a point) but don't work now that the beta is live. So the problem is that somewhere in the rollout of the beta into live something seems to have gone wrong. I will also post my issue in the main technical reports section once I've checked out Spikee's suggestion.

As for fixing or hiding the issues: - Since many/most of the issues are likely to be in 3rd-party content my own preference would be for the game/logmate to provide enough information to identify a culprit asset/tile/thing so we can go in and find out what is wrong and come up with a fix which can be publicised/fixed versions of stuff provided to the community. Obvs if DTG own some of the broken stuff then I would hope they will fix that. I would rather not handle/hide any of these since they may have other hidden effects that cause more subtle problems (and may have been doing this since time began).

This thread seems to have identified at least three seperate issues (Correct me if I'm wrong):

1. scenario/editor crash - maybe due to use of duplicated rollingstock numbers in moving AI consists (duplicates in statics don't seem to be an issue)
2. load crash due to an unknown tile-related issue (perhaps)
3. scenario/editor crash caused by a newly-illegal collision box error in an old blueprint

I am looking at nbr 3 on my own route and will report back.

 

Ok - so one of my two scenario crashes (OOM - fatal error in mode LOAD_SCENARIO during update within DISPATCHER) is now resolved. This error occurred in both Drive and Edit modes which made direct assessment difficult.
The problem was an AI consist (Light engine) which trundled about 50 yards in the yard to provide mild interest. The last bit of logmate showed this (but didn't identify the culprit):

2024/01/06 11:38:42.306 - [RunTimeError] - Verify failed:
2024/01/06 11:38:42.306 - [RunTimeError] -
2024/01/06 11:38:42.306 - [RunTimeError] - D:\RGBuild\CoreRelease\Code\DLLs\Dispatcher\DispatcherV1\cPathOccupationScheduler.cpp : 1403
2024/01/06 11:38:42.306 - [RunTimeError] -
2024/01/06 11:38:42.306 - [RunTimeError] - Expression: mStackCurrentPtr != mOccupancyStack.end() || node == mSearchPath->GetTailSearchPathNode()
2024/01/06 11:38:42.306 - [RunTimeError] -
2024/01/06 11:38:42.306 - [RunTimeError] - Occupation stack overflow
2024/01/06 11:38:42.306 - [RunTimeError] - Verify failed:
2024/01/06 11:38:42.306 - [RunTimeError] -
2024/01/06 11:38:42.306 - [RunTimeError] - D:\RGBuild\CoreRelease\Code\DLLs\Dispatcher\DispatcherV1\cPathOccupationScheduler.cpp : 1403
2024/01/06 11:38:42.306 - [RunTimeError] -
2024/01/06 11:38:42.306 - [RunTimeError] - Expression: mStackCurrentPtr != mOccupancyStack.end() || node == mSearchPath->GetTailSearchPathNode()
2024/01/06 11:38:42.306 - [RunTimeError] -
2024/01/06 11:38:42.306 - [RunTimeError] - Occupation stack overflow

I worked back up the logmate to identify which consist was the likely culprit and discovered this gem in the first 'pathing' phase of the scenario load:

2024/01/06 11:38:13.906 - [Pathing] - Trace D:\RGBuild\CoreRelease\Code\DLLs\DriverManager\cDriver.cpp : 3088 = Train length: 27.584999
2024/01/06 11:38:13.906 - [Pathing] - Trace D:\RGBuild\CoreRelease\Code\DLLs\DriverManager\cDriver.cpp : 3088 = Train length: 27.584999
2024/01/06 11:38:13.906 - [Pathing] - Trace D:\RGBuild\CoreRelease\Code\DLLs\DriverManager\cDriver.cpp : 3088 = Train length: 27.584999
2024/01/06 11:38:13.906 - [Pathing] - Trace D:\RGBuild\CoreRelease\Code\DLLs\DriverManager\DriverInstructions\cConsistOperations.cpp : 140 = Consist operation for target 0
2024/01/06 11:38:13.907 - [Pathing] - Trace D:\RGBuild\CoreRelease\Code\DLLs\DriverManager\DriverInstructions\cConsistOperations.cpp : 149 = Length delta for: 999999 is: 5.961000
2024/01/06 11:38:13.907 - [Pathing] - Trace D:\RGBuild\CoreRelease\Code\DLLs\DriverManager\DriverInstructions\cConsistOperations.cpp : 149 = Length delta for: 6541731a is: 8.165939
2024/01/06 11:38:13.907 - [Pathing] - Trace D:\RGBuild\CoreRelease\Code\DLLs\DriverManager\DriverInstructions\cConsistOperations.cpp : 167 = Length delta total: 14.126940

This suggested that the game thought the consist was longer than it actually was (or something). I identified the consist (see below) and deleting it via RWtools brought the scenario to half-life - it would run and could be edited. (I will describe the second error in a following post to try to avoid confusion).

Learning points:

The current logmate info has an initial section of 'pathing' where it lists all consists in a fixed order (of some sort) where it names them and checks their length:

2024/01/06 11:38:13.906 - [Pathing] - Trace D:\RGBuild\CoreRelease\Code\DLLs\DriverManager\cDriver.cpp : 3088 = Train length: 10.165000
2024/01/06 11:38:13.906 - [Pathing] - Trace D:\RGBuild\CoreRelease\Code\DLLs\DriverManager\cDriver.cpp : 3088 = Train length: 10.165000
2024/01/06 11:38:13.906 - [Pathing] - Trace D:\RGBuild\CoreRelease\Code\DLLs\Dispatcher\DispatcherV1\cDispatcher.cpp : 320 = Path request added:ALC_J50_Hitchin_Shed_Yard_Spotter priority : 1.000000
2024/01/06 11:38:13.906 - [Pathing] - Trace D:\RGBuild\CoreRelease\Code\DLLs\Dispatcher\DispatcherV1\cDispatcher.cpp : 321 = Train type: Special Non-Electric
2024/01/06 11:38:13.906 - [Pathing] - Trace D:\RGBuild\CoreRelease\Code\DLLs\Dispatcher\DispatcherV1\cDispatcher.cpp : 331 = Segment 0 destination: ALC Hitchin Shed Road 1 Scenario
2024/01/06 11:38:13.906 - [Pathing] - Trace D:\RGBuild\CoreRelease\Code\DLLs\Dispatcher\DispatcherV1\cDispatcher.cpp : 331 = Segment 1 destination: ALC Hitchin Shed Entry/Exit

This is useful because when it subsequently checks that path is valid it does so in the same order with each entry ending in "2304 = Pathing succeeded/failed: <name of consist>":

2024/01/06 11:38:42.306 - [Pathing] - Trace D:\RGBuild\CoreRelease\Code\DLLs\Dispatcher\DispatcherV1\cPathingReport.cpp : 125 =
2024/01/06 11:38:42.306 - [Pathing] - Path requester: Pathing state: PATHING_SUCCEEDED Cost - time: 0.0008 secs Cost - steps: 749 Segments completed: 2 of 2 --- ALC Hitchin Shed Road 1 Scenario --- ALC Hitchin Shed Entry/ExitSegment: 0, --- ALC Hitchin Shed Road 1 Scenario State: PATHING_SUCCEEDED- A* pathing: State: PATHING_SUCCEEDED Length: 311.43 Nodes: 0- Scheduling: State: PATHING_SUCCEEDED Estimate: 5220.30 Schedule: 3480.20 Waiting for: N/A Blocked by: N/ASegment: 1, ALC Hitchin Shed Road 1 Scenario --- ALC Hitchin Shed Entry/Exit State: PATHING_SUCCEEDED- A* pathing: State: PATHING_SUCCEEDED Length: 242.78 Nodes: 0- Scheduling: State: PATHING_SUCCEEDED Estimate: 78.36 Schedule: 52.24 Waiting for: N/A Blocked by: N/A
2024/01/06 11:38:42.306 - [Pathing] -
2024/01/06 11:38:42.306 - [Pathing] - Trace D:\RGBuild\CoreRelease\Code\DLLs\DriverManager\cDriver.cpp : 2304 = Pathing succeeded: ALC_J50_Hitchin_Shed_Yard_Spotter

So if the next consist causes a fatal error then you can identify it by checking the last successful consist and finding what came next in the first pashe of the pathing process.
Hope this helps.

 

The second (new) error in the scenario was trapped in the conventional way in the scenario load with a 'scenario failed to load' dialog with the problem listed inside it. In this case the problem was a 'missing marker'. Now this scenario (and the marker being used) had both existed (and run ok) for some years - so my assumption is that the new regime of better regulated coding exposed a previously 'fudged/ignored' issue. I edited the consist instructions (deleted the bad instruction and added a new stopat) and the scenario then run as it had pre-upgrade.

Interestingly my first attempt in the editor caused a crash when I attempted to look directly at the failing instruction by selecting it for edit. I could delete it but not look inside it. Hmmm.

 

cunningn#3154 (or anyone really) a little forum tip.

If you click on the + you'll get a dropdown additional menu one of those options being code insertion.. (code tags in basic BB3 form)



So then your log would then appear a lot more friendlier as this...

Code:

2024/01/06 11:38:42.306 - [RunTimeError] - Verify failed:
2024/01/06 11:38:42.306 - [RunTimeError] -
2024/01/06 11:38:42.306 - [RunTimeError] - D:\RGBuild\CoreRelease\Code\DLLs\Dispatcher\DispatcherV1\cPathOccupationScheduler.cpp : 1403
2024/01/06 11:38:42.306 - [RunTimeError] -
2024/01/06 11:38:42.306 - [RunTimeError] - Expression: mStackCurrentPtr != mOccupancyStack.end() || node == mSearchPath->GetTailSearchPathNode()
2024/01/06 11:38:42.306 - [RunTimeError] -
2024/01/06 11:38:42.306 - [RunTimeError] - Occupation stack overflow
2024/01/06 11:38:42.306 - [RunTimeError] - Verify failed:
2024/01/06 11:38:42.306 - [RunTimeError] -
2024/01/06 11:38:42.306 - [RunTimeError] - D:\RGBuild\CoreRelease\Code\DLLs\Dispatcher\DispatcherV1\cPathOccupationScheduler.cpp : 1403
2024/01/06 11:38:42.306 - [RunTimeError] -
2024/01/06 11:38:42.306 - [RunTimeError] - Expression: mStackCurrentPtr != mOccupancyStack.end() || node == mSearchPath->GetTailSearchPathNode()
2024/01/06 11:38:42.306 - [RunTimeError] -
2024/01/06 11:38:42.306 - [RunTimeError] - Occupation stack overflow

I worked back up the logmate to identify which consist was the likely culprit and discovered this gem in the first 'pathing' phase of the scenario load:

2024/01/06 11:38:13.906 - [Pathing] - Trace D:\RGBuild\CoreRelease\Code\DLLs\DriverManager\cDriver.cpp : 3088 = Train length: 27.584999
2024/01/06 11:38:13.906 - [Pathing] - Trace D:\RGBuild\CoreRelease\Code\DLLs\DriverManager\cDriver.cpp : 3088 = Train length: 27.584999
2024/01/06 11:38:13.906 - [Pathing] - Trace D:\RGBuild\CoreRelease\Code\DLLs\DriverManager\cDriver.cpp : 3088 = Train length: 27.584999
2024/01/06 11:38:13.906 - [Pathing] - Trace D:\RGBuild\CoreRelease\Code\DLLs\DriverManager\DriverInstructions\cConsistOperations.cpp : 140 = Consist operation for target 0
2024/01/06 11:38:13.907 - [Pathing] - Trace D:\RGBuild\CoreRelease\Code\DLLs\DriverManager\DriverInstructions\cConsistOperations.cpp : 149 = Length delta for: 999999 is: 5.961000
2024/01/06 11:38:13.907 - [Pathing] - Trace D:\RGBuild\CoreRelease\Code\DLLs\DriverManager\DriverInstructions\cConsistOperations.cpp : 149 = Length delta for: 6541731a is: 8.165939
2024/01/06 11:38:13.907 - [Pathing] - Trace D:\RGBuild\CoreRelease\Code\DLLs\DriverManager\DriverInstructions\cConsistOperations.cpp : 167 = Length delta total: 14.126940

 

... which is the reason I had to remove one car from the Caltrain "[GP38-2] UP Mission Bay Hauler" Career scenario to make it work. It refused to path me through otherwise - which it did in v72.3.

 

Adding a turntable to a route and connect it to existing track network in 76.3a makes the sim crash when driving a loco onto it.
Works fine if you add new tracks to it that isn't connected to existing track network in a route.
There are no problems when rolling back to version 75.8a.

I've tested with several turntables and routes.

From the log these are the errors that doesn't appear in 75.8a.

Code:

2024.01.07 00:42:34.380 - [Pathing] - Trace D:\RGBuild\CoreRelease\Code\DLLs\Dispatcher\DispatcherV1\cSearchPath.cpp : 430 = Found deleted node while traversing path.
2024.01.07 00:42:34.380 - [Pathing] - Trace D:\RGBuild\CoreRelease\Code\DLLs\Dispatcher\DispatcherV1\cSearchPath.cpp : 430 = Found deleted node while traversing path.
2024.01.07 00:42:34.380 - [Pathing] - Trace D:\RGBuild\CoreRelease\Code\DLLs\Dispatcher\DispatcherV1\cSearchPath.cpp : 430 = Found deleted node while traversing path.
2024.01.07 00:42:34.380 - [Pathing] - Trace D:\RGBuild\CoreRelease\Code\DLLs\Dispatcher\DispatcherV1\cSearchPath.cpp : 430 = Found deleted node while traversing path.
2024.01.07 00:42:34.380 - [Pathing] - Trace D:\RGBuild\CoreRelease\Code\DLLs\Dispatcher\DispatcherV1\cSearchPath.cpp : 430 = Found deleted node while traversing path.
2024.01.07 00:42:34.380 - [Pathing] - Trace D:\RGBuild\CoreRelease\Code\DLLs\Dispatcher\DispatcherV1\cSearchPath.cpp : 430 = Found deleted node while traversing path.
2024.01.07 00:42:34.380 - [Pathing] - Trace D:\RGBuild\CoreRelease\Code\DLLs\Dispatcher\DispatcherV1\cSearchPath.cpp : 430 = Found deleted node while traversing path.
2024.01.07 00:42:34.380 - [Pathing] - Trace D:\RGBuild\CoreRelease\Code\DLLs\Dispatcher\DispatcherV1\cSearchPath.cpp : 430 = Found deleted node while traversing path.
2024.01.07 00:42:34.380 - [Pathing] - Trace D:\RGBuild\CoreRelease\Code\DLLs\Dispatcher\DispatcherV1\cSearchPath.cpp : 430 = Found deleted node while traversing path.
2024.01.07 00:42:34.380 - [Pathing] - Trace D:\RGBuild\CoreRelease\Code\DLLs\Dispatcher\DispatcherV1\cSearchPath.cpp : 430 = Found deleted node while traversing path.
2024.01.07 00:42:34.380 - [Pathing] - Trace D:\RGBuild\CoreRelease\Code\DLLs\Dispatcher\DispatcherV1\cSearchPath.cpp : 430 = Found deleted node while traversing path.
2024.01.07 00:42:34.380 - [Pathing] - Trace D:\RGBuild\CoreRelease\Code\DLLs\Dispatcher\DispatcherV1\cSearchPath.cpp : 430 = Found deleted node while traversing path.
2024.01.07 00:42:34.380 - [Pathing] - Trace D:\RGBuild\CoreRelease\Code\DLLs\Dispatcher\DispatcherV1\cSearchPath.cpp : 430 = Found deleted node while traversing path.
2024.01.07 00:42:34.380 - [Pathing] - Trace D:\RGBuild\CoreRelease\Code\DLLs\Dispatcher\DispatcherV1\cSearchPath.cpp : 430 = Found deleted node while traversing path.
2024.01.07 00:42:34.380 - [Pathing] - Trace D:\RGBuild\CoreRelease\Code\DLLs\Dispatcher\DispatcherV1\cSearchPath.cpp : 430 = Found deleted node while traversing path.
2024.01.07 00:42:34.380 - [Pathing] - Trace D:\RGBuild\CoreRelease\Code\DLLs\Dispatcher\DispatcherV1\cSearchPath.cpp : 430 = Found deleted node while traversing path.
2024.01.07 00:42:34.380 - [Pathing] - Trace D:\RGBuild\CoreRelease\Code\DLLs\Dispatcher\DispatcherV1\cSearchPath.cpp : 430 = Found deleted node while traversing path.

CrashRpt-Log-20240107-004234-{700542dc-5f27-4904-952a-295ce0dcf633}

 

Hi everyone!

i have a bug only with "Tehachapi Pass: Mojave - Bakersfield Route Add-On" on the last public beta
I give you the log, and the screen shot of the crash

(32Go ram @3.2Ghz,CPU : AMD R7 2700,GPU AMD RX 6700XT, MB: Aorus X470)
______


Salut a tous!

j'ai un bug uniquement avec "Tehachapi Pass: Mojave - Bakersfield Route Add-On" sur la derniere beta public
je vous donne les log, et le screen shot du crash