Compiling TSRE

[TrainSimJack]

That's your problem. Take the one in the response above and drop it in your original TSRE folder. Then run the process from the start.

Thanks yellowdog!

I'm a bit unclear - I downloaded OpenAL32.dll from Koniec.org
I copied it to the same folder as the TSRE5.exe that was built - are you saying it needs to go somewhere else pre-build, and then once it's there, I build the whole thing again?
If so what exact folder am I putting it in?

Thanks again!

[yellowdog]

Yes, I'm saying it needs to go in your prebuild TSRE folder. This is a partial view of my pre-build TSRE folder content. Not sure why you didn't have it to start. Maybe it accidentally got deleted somewhere along the way? At any rate, once it's there, you'll have to redo the build from scratch.

[TrainSimJack]

I'm still not following - are you saying you first installed the version of TSRE5 into c:\TSRE - this was long before you tried to compile the source, and you have a copy of that DLL in that folder?

And the thought is that by having it there, it would help out the version we're compiling in netbeans (the one that ends up in the folder with the source code we downloaded from github)

I'm trying this now!

Edit: Might be worth mentioning, I've been doing this testing on a VM, with a clean image - this way we'll all know if we've got the dependencies down.

[eric]

I tried the "drop it in the folder" and that works at runtime, but not for build/debug. I'm guessing it expects it in the Windows system directories.

Running the OpenAL installer did the trick --- it's adding it in the appropriate directories under Windows and probably registering it as well.

It's now in our library: 88523

[TrainSimJack]

Edit - some posts crossed, My reply was sent before I saw Eric's comment about the OpenAL installer.

Eric I just ran the installer, tried it and it worked!

I'm getting a few other errors so I'm recompiling now to see if that helps, but for the first time ever, I've gotten the version I compiled to show up on screen!

Thanks for your help!

[yellowdog]

At this point, I would just go with what Eric said.

I didn't have to do that, though. So I'm not sure what the difference is. Although I can confirm I've had OpenAL32.dll in my original TSRE folder for quite some time, because it also exists in a couple of different backup locations that I haven't touched for several months. I was under the impression that the code used in Step 6 manipulated the original, but that's just a guess.

cd C:\openal-soft-1.18.2-bin\libs\Win64
C:\MinGW\bin\dlltool -d OpenAL32.def -D OpenAL32.dll -k -a -l libopenal32.a -v

At any rate, it looks like we may not have a completely replicable process.... But at least there are various solutions to our different problems!

[eric]

I deleted the clone of Goku's repository, and linked it to the fork I created in GitHub. Doing that wiped out all the settings from Step 7, which I was able to repeat and get up and running in a matter of a few minutes.

That meant it was time to get down to some tweaks I really wanted for a while.

First up was reinstating the StaticDetailLevel for signals. The next tweak is reconfigured yellow TSection lines... This is currently hardcoded to 6.7m, which is clearance height on the UP and could be catenary height for some routes. This way, I know in the editor if my bridges are set right without a test fit.

Currently it's hardcoded in tdb.cpp, but I will eventually figure out how to grab it from Settings.txt so that it's configurable. The other option is to grab it from the Route.TRK file, as that variable appears to be already available in other modules.



This fork is really for my own experimentation right now, but if anyone wants to try out the executable, it's uploaded at https://github.com/Lanehog/TSRE-TS-Fork-Executable

No guarantees that it won't slag your route, as our friend Vince would say.... so be careful. Backup, backup, backup....

[TrainSimJack]

At this point, I would just go with what Eric said.

I didn't have to do that, though. So I'm not sure what the difference is. Although I can confirm I've had OpenAL32.dll in my original TSRE folder for quite some time, because it also exists in a couple of different backup locations that I haven't touched for several months. I was under the impression that the code used in Step 6 manipulated the original, but that's just a guess.

cd C:\openal-soft-1.18.2-bin\libs\Win64
C:\MinGW\bin\dlltool -d OpenAL32.def -D OpenAL32.dll -k -a -l libopenal32.a -v

At any rate, it looks like we may not have a completely replicable process.... But at least there are various solutions to our different problems!

Thanks again for all your help yellowdog - the last post of mine was written at the same time Eric posted his - I didn't see his reply when I submitted that post.
It looks like installing the openal installer helped!

I've made it this far, I'll take a look at the errors in the cmd window and see if it's anything I did.

[TrainSimJack]

Eric / Pete,

I think the creative OpenAL installer added the two copies with green checkmarks below:
(Purple was the one I downloaded from Koniec.org)



I suspect running the OpenAL installer in the file library (88523) is a requirement/prerequisite.

[eric]

Yep, we're on to something here. Compiling the code was the easy part.

Now the fun begins.... Changes.


Right after I uploaded my copy of the executable with changes, it's dumping on one of my more complex routes, yet 0.7.012 doesn't....

Here's the output from the debugger:

[E] QObject::~QObject: Timers cannot be stopped from another thread
terminate called after throwing an instance of 'std::bad_alloc'
  what():  std::bad_alloc
terminate called recursively
terminate called recursively
terminate called recursively
terminate called recursively​

Nothing I've touched involves timers, and I've seen that error before with regard to high memory usage, so perhaps there's a leak somewhere?


Update: Not necessarily a leak.

Make sure TileLOD = 1 if you have terrain of any significance...

The settings file that comes with the GitHub package has TileLOD set to 2, which means instead of loading 9 tiles of terrain (the way MSTS used to do it was a 3x3 grid), it was loading a 5x5 grid of 25 tiles... which I'm guessing overloaded memory.

That might explains why my version worked great on the CNW Chicago route, but blew up in the Arizona mountains....

As soon as I pushed that setting down, the newly compiled code worked.

[GokuMK]

I'm sure GOKU is somewhere laughing at us thinking "It only took them 6+ years to figure it out"

Many people from Europe and especially Russia, were always able to build TSRE using my tutorial I posted years ago without any issues. Someone even made an Apple macOS build. I don't know why you weren't able to follow these steps but I am happy that you were able to find your own way. A little complicated but if it works ..

Some people here should ask Google more and read more, instead of wasting time on rude posts suggesting that my GitHub repo is a SCAM. Asking "How to build C++ apps using Netbeans" first, would save you a lot of wasted time struggling with plugin installation. Reading about the tools you want to use is necessary if you want to go anywhere.

TSRE uses QT 5.7.1, so you should use at least this version. And I think that MinGW 7.3.0 is used now.

My build of TSRE doesn't require these QT dlls because I build it using QT static build. Making a static QT takes a lot of time. One example of static build is uploaded on my website and linked in my tutorial.

On linux I use default dynamic QT system libs and TSRE works fine with latest version of QT5 - 5.15.
On Windows, QT > 5.7 requires MinGW version higher than 8 and I couldn't make a good quality build using it.

[pwillard]

I think there is a big assumption that you have a WORKING TSRE5 application before you even try to compile the repository code... It's assumed that has been done so there is no mention of the OpenAl installer anywhere in the build docs.

And Goku... It's probably pretty clear that *those of us interested* are really not programmers and that the programmers we do/did have have either left or have been unwilling to help us out... until now.

For example, everyone working on OPENRAILS claims that they only work in C# and have no interest in C++ coding.

[eric]

GokuMK thanks for having the code available even though it's been a challenge to figure out the cross platform environment settings. One tiny assumption or not completely communicated step (the DLL build for OpenAL ) had us completely blocked.

Regardless, we are moving forward. There's a working process, and it will be formalized as a tutorial.

More importantly, we are no longer locked down on extending our ability to create content while awaiting action that the Open Rails team hasn't taken over the last 10 years.

[pwillard]

So my question now is... what have the Russian and Polish coders already done with TSRE5 that we English speakers might be interested in?

[yellowdog]

We always needed to have an OPENAL dll in the same folder as TSRE even with the released version of TSRE from GOKU, if I recall correctly.

I just want to go back and highlight this, as I think it's true. Having this in place prior to starting this process may alleviate some of the problems being encountered.