PDA

View Full Version : Errors Shown in Logmate Starting Route



boleyd
08-21-2009, 10:42 AM
The following appears in LogMate (excerpt) when starting a route. Appears harmless (runtime errors) but may lay a foundation for future problems.

Reported

[Content 10:45:11 AM] Trace C:\Dev\RailSim\Code\Libs\Heracles\Engine\Draw\DxCo mmon\cHcEffectDx.cpp : 134 = Creating effect TrainSpecEnvMask.fx
[Content 10:45:11 AM] Trace C:\Dev\RailSim\Code\Libs\Heracles\Engine\Draw\DxCo mmon\cHcEffectDx.cpp : 134 = Creating effect TrainGlass.fx
[Content 10:45:11 AM] Trace C:\Dev\RailSim\Code\Libs\Heracles\Engine\Draw\DxCo mmon\cHcEffectDx.cpp : 134 = Creating effect StencilShadow.fx
[Content 10:45:11 AM] Trace C:\Dev\RailSim\Code\Libs\Heracles\Engine\Draw\DxCo mmon\cHcEffectDx.cpp : 134 = Creating effect TrainBasicObjectSpecular.fx
[Content 10:45:11 AM] Trace C:\Dev\RailSim\Code\Libs\Heracles\Engine\Draw\DxCo mmon\cHcEffectDx.cpp : 134 = Creating effect TrainBumpSpec.fx
[Content 10:45:11 AM] Trace C:\Dev\RailSim\Code\Libs\Heracles\Engine\Draw\DxCo mmon\cHcEffectDx.cpp : 134 = Creating effect TrainBumpSpecEnvMask.fx
[Content 10:45:11 AM] Trace C:\Dev\RailSim\Code\Libs\Heracles\Engine\Draw\DxCo mmon\cHcEffectDx.cpp : 134 = Creating effect SkinDiffuse.fx
[RunTimeError 10:45:11 AM] Verify failed:
[RunTimeError 10:45:11 AM]
[RunTimeError 10:45:11 AM] C:\Dev\RailSim\Code\DLLs\RouteManager\cGPSMarkerSe t.cpp : 146
[RunTimeError 10:45:11 AM]
[RunTimeError 10:45:11 AM] Expression: namedMarkerEntityBlueprint != 0 && namedMarkerEntityBlueprint->QueryInterface ( entityBlueprint )
[RunTimeError 10:45:11 AM]
[RunTimeError 10:45:11 AM] Marker set's flag blueprint is not an entity blueprint - can't create flags
[Content 10:45:11 AM] Trace C:\Dev\RailSim\Code\Libs\Heracles\Engine\Draw\DxCo mmon\cHcEffectDx.cpp : 134 = Creating effect soar.fx

OTTODAD
08-21-2009, 11:29 AM
Hi Dick !

I can not help feeling that some of these many errors you get are self-induced, nobody else reporting similar to my knowledge, Sniper certainly not getting them ?

Unless there is a log which can record every key you press and what else you do when working in a RW scenario then there is little chance of RS.com being able to figure out what is happening ! :o

O t t o

sniper297
08-21-2009, 12:08 PM
Actually I do get them, I just don't pay much attention cuz I'm used to them from the MSTS route editor. Refresh my memory, who wrote the code for MSTS? :rolleyes: I agree that it IS self induced, we're not using the program the way it was intended, if you play the default free roams on the default routes without opening an editor you never get the errors on exit. Mine are standardized;

http://www.trainsim.com/vbts/attachment.php?attachmentid=19334&stc=1&d=1250870355

I get that one on exit when I use the scenario editor;

http://www.trainsim.com/vbts/attachment.php?attachmentid=19335&stc=1&d=1250870381

That one when I use the world editor, altho if I use both it don't give both messages since it gives preference to the scenario editor error. This one;

http://www.trainsim.com/vbts/attachment.php?attachmentid=19336&stc=1&d=1250870459

Is a variation I got from creating a new route and not laying any track in it, and this;

http://www.trainsim.com/vbts/attachment.php?attachmentid=19337&stc=1&d=1250870459

Is a promise of future patches. :cool:

boleyd
08-21-2009, 12:22 PM
Hi Dick !

I can not help feeling that some of these many errors you get are self-induced, nobody else reporting similar to my knowledge, Sniper certainly not getting them ?

Unless there is a log which can record every key you press and what else you do when working in a RW scenario then there is little chance of RS.com being able to figure out what is happening ! :o

O t t o

I do not agree with the keypress recording need. It is rare that you get to the need to that detail. Breakpoints placed in the program will usually be sufficient to tell the stimulus that begins the errored sequence.

Back to reporting more problems to kill the vendor's perception that all is well in the signaling arena and other areas.

Leaving lingering stuff like this around is not wise and Rail simulation should clean that up even if it is "harmless" and we have no proof it is or isn't.

Second, I was doing absolutely nothing that any customer might undertake. If there is some standard set of processes that are inviolate I have not seen that produced by Rail simulation. Customers have procedural workarounds to avoid some issues but the vendor cannot rely on them as any kind of fix.