ConBuilder

[eric]

Yeah, I

Yes, it does unless you perform workarounds like you have described. But that defeats the purpose of using TSRE in the first place. At present there is no method to use TSRE like Conbuilder (Conbuilder allows the use of the mouse wheel scroll which is very handy and fast). I guess the default in TSRE should be to NEVER display a 3d model, unless doubled clicked etc to do so. But that kills the sexiness of TSRE. Should TSRE have this option, to not display UNLESS double clicked? I vote yes as a workaround to crashing.

First I've heard of an issue with TSRE not being able to handle the embedded ShapeViewer, but you can already disable by going to the View Menu and un-clicking "Eng View".

It's possible the 32 bit versions had different memory management issues, but I've not run into a memory overrun or crash since starting on the 64 bit builds seven months ago, but yes, there's a lot kept in memory vs. being flushed. If anyone has suggestions on how to address that in QT and C++, by all means speak up.

I'm already working on a few small issues for v8.005, and can add a switch to disable the ShapeViewer on startup if that's really desired.

[crstagg]

Charles,

Yes, it does unless you perform workarounds like you have described. But that defeats the purpose of using TSRE in the first place. At present there is no method to use TSRE like Conbuilder (Conbuilder allows the use of the mouse wheel scroll which is very handy and fast). I guess the default in TSRE should be to NEVER display a 3d model, unless doubled clicked etc to do so. But that kills the sexiness of TSRE. Should TSRE have this option, to not display UNLESS double clicked? I vote yes as a workaround to crashing.

I have read your workaround and it is very much what I tried some years back and I found that workflow cumbersome and fraught with errors by the user. The inability of TSRE to free up dynamic memory structures for most likely performance reasons is the cause of the crash. Once something is loaded into memory it is NEVER released, at least in the versions I used. BTW as a route editor, I found TSRE has the same problems with consumption of dynamic memory structures. Workarounds are/were to reduce the resolution of textures etc. But why should we have to do this in the year 2024bis with multiple gigabytes of system/gpu memory to work with? Even in the year 2024bis, memory management is still a thing. As a software developer whatever memory I allocate I have to take responsibility to free up. When it is not in use I should not play the "slot machine" that I did not consider the cases beyond the limited data set I tested with.
................
My point of view,
Steve

"Workaround" WTH are you referring to?

The method I used was what I thought would create the greatest burden on TSRE-CE displaying 4000 items while selecting 80 to place in the consist. That method required TSRE-CE to display ALL 4000 of my freight stock. NOT just the 80 selected. Using a mouse wheel or the scroll bar places less of a burden on the display.

If you have a method that places a greater burden on TSRE-CE please explain it.

You mention crashes using the Scroll wheel of the mouse. I repeated the test using the Mouse wheel, but this time I did not filter to just freight. The list was almost 10,000 items long. Selected the first item, turned the wheel, stopped, selected an item, repeated till I got to the end of the list. Had a weird looking consist of 134 items. NO CRASH!

FYI I did the testing described with the Initial view. NO TURNING OFF OF LISTS OR GRAPHIC VIEW. Initial View of Consist list, Trainset list, Selected item graphic view and Consist graphic view.

[EldoradoRailroad]

Yeah, I
It's possible the 32 bit versions had different memory management issues, but I've not run into a memory overrun or crash since starting on the 64 bit builds seven months ago, but yes, there's a lot kept in memory vs. being flushed. If anyone has suggestions on how to address that in QT and C++, by all means speak up.

I'm already working on a few small issues for v8.005, and can add a switch to disable the ShapeViewer on startup if that's really desired.

Eric,

Being rather obstinate here at times with new things until proven that bugs (the really destructive kind) are not on the horizon, I am well known for holding back and testing newer versions. If anything, I am guilty of omission, that yep, a 32 bit version was being used that caused all memory to be gobbled up.

Since I still often do things in a 32 bit world or restricted physical memory of 4 gb, I am not spared from finding weaknesses in memory management. Too many years in a 32 bit world have taught me to be careful. I am sorry to say that I do not know if 32 and 64 bit versions of TSRE are being compiled by you for the updated releases? In a 64 bit world, there is a bit of a devil may care attitude, if system memory is greater than 8 gb.

C++ has constructors and destructors. In your travels through the code you must have seen evidence of constructors for treating models that are loaded for instant view in the TSRE consist builder?? At some point, a destructor for that same model could be invoked? I know that QT is not "lifting up your skirt"..to paraphrase a line from the movie "True Lies", Charlton Heston with a menacing eye patch!!

Well, I vote for having the ShapeViewer disabled on startup, others might not even understand what we are talking about here.

Thanks for your reply,
Steve

[eric]

I have no plans to support 32 bit -- all of the updates in my fork have been for 64 bit.

v7.012 is the last version for 32 bit right now.

[ckawahara]

Did anyone PM Joe? Did you get a response?

[eric]

Joe hasn't been on the site in almost a year, so that might not be a workable option.