Compiling TSRE

[eric]

Also glad that Goku has appeared here and provided some input and merged PRs

Indeed. Hopefully he can continue to provide some guidance. Absent a design document, it's hard to get into another programmer's code and not understand how things are structured and why.

[eric]

I figured out how to make the command console disappear when running the executable file outside the IDE --- remove the CONFIG+=console definition above

That comes in with the project settings, and is probably useful for debugging, but can be a risk when running the app because if you close the console, it takes the rest of the app with it and no opportunity to save unfinished work.

[kapitaen]

Available to try here ---> Github

Hello Eric,
I have tried to install the programme according to the instructions. Unfortunately, I did not succeed.

At first, the missing OpenAL32.dll was criticised.

Screen Shot 01-19-24 at 08.25 AM.jpg

After copying the DLL the following error message appeared


Screen Shot 01-19-24 at 08.25 AM 001.jpg

Copying the files into the TSRE5_v0.7.012 installation resulted in the same error.
Google gives possible causes for the error message 0xc000007b and so I ran the netfxrepairtool.exe on my WIN11 computer and restarted the computer. Unfortunately, the error cannot be rectified in this way.
What else could I try?

[GokuMK]

I've already pushed one change back to the master which Goku approved as a pull. That was a pretty straight forward change that shouldn't need a bunch of testing.

Yes, it was an easy change.
Don't expect accepting more conplex changes without proof of good testing and documentation. I can't do any tests myself. All I can do, is just review and accept it on my smartphone.

Better to use your fork for untested changes.

[eric]

Google gives possible causes for the error message 0xc000007b and so I ran the netfxrepairtool.exe on my WIN11 computer and restarted the computer. Unfortunately, the error cannot be rectified in this way.
What else could I try?

Not sure. I'll try running on a non gaming setup later today. My guess is there is a missing dll or runtime component missing. Does 8.002 run?

[kapitaen]

Does 8.002 run?

No, unfortunately not. It is the same error message.
The installation of VC_redist.x64.exe is also cancelled as a downgrade.

Screen Shot 01-19-24 at 05.26 PM.jpg

[08EC:16A4][2024-01-19T17:28:18]e000: Error 0x80070666: Cannot install a product when a newer version is installed.

[GokuMK]

QT doesn't use VC.
Try executing TSRE EXE from console to see more info.
That is why I use a static build. Makes sure that it works for everyone.

[eric]

It's failing on my non-gaming PC, so it's not your installation, Johann.

Goku, I'll look again at the static build --- the instructions I found weren't exactly helpful and they were for later versions of QT. If you can recall what steps were needed, that might help.

[eric]

GokuMK does this procedure look correct?

https://wiki.qt.io/Building_a_static_Qt_for_Windows_using_MinGW

[PerryPlatypus]

MSTS / Open Rails users usually don't have RTX GPUs with 16 GB of VRAM. Painted terrain takes a lot of memory. 512 pixel size limit is made on purpose.

The behavior is currently inconsistent, as this forced down-sizing does not happen except when painting on rotated or mirrored terrain patches. (Thank goodness this DOESN'T happen with non-rotated/mirrored patches!)

Believe it or not, we have successfully released payware routes that make use of thousands of 1024x1024 painted textures - but doing so requires a lot of needless extra effort to avoid rotating or mirroring any patches before painting. ORTS is capable of loading a very high number of custom terrain patches at once, and it doesn't require a supercomputer.

It should be up to content developers to make use of whatever terrain texture resolution they see fit, especially if we want to keep pushing the envelope on graphics quality for ORTS. If a particular route builder feels the need to limit themselves to 512x512, then they can choose to use exclusively 512x512 "base" textures. If a route builder wishes to use 1024x1024 or even higher resolution (like for example in a very limited number of terrain patches for a small high-detail scene) then they should be free to do so.

Don't get me wrong, custom terrain painting is by far one of the greatest improvements we've seen since the old MSTS RE, and we have you to thank for that. I just don't see a reason to try to force the use of lower resolution terrtexes. Thus why I'm hoping Eric or whomever can make the tweak to change this

[eric]

No promises... I can't get this to execute off my own PC yet, so that's the priority.

[eric]

Compiling TSRE from Goku's repository gets the same result as the fork repository for me. Not sure if it's my setup or what.

yellowdog can you zip up one of your executables and attach? Wondering if it's something in my configuration for NetBeans + MinGW or not...

[yellowdog]

This is from my build. I haven't been digging around in it as much as you have yours, so there may be bugs I'm not aware of.

[muskokaandtahoe]

Some thoughts:

1. Is there an executable of this available anywhere for us to play with?
2. Please put as many hardcoded values into the settings file that plausibly might be edited by the end user.
3. Can the tool windows be converted to resized both vertically and horizontally? Today, long shape file names get truncated.
4. Vertical camera movement please.
5. Rebuild .rdb, .tdb

[eric]

I can't run that build either.

If I remove all the DLL's, and replace Gui, Core and Network as asked for, it then asks for Websockets and dies.

If I leave Websockets, and restore Core and Gui, it dies with just those three are present.

That makes me wonder if the webserver components might be to blame here...