[Razer]

I will wait for a next early release that will work without any errors on Win 7.

[Azaezel]

Only thing we've got thus far resembling a decent report thus far is:

When launching T3D 4.0 Test 2 (May 25 2019) this error appears. Did not occur with prior Test 1 (May 20 2019).

That'll translate to checking each commit on somebody with a win 7 box from Commits on May 19, 2019 to probably around Commits on May 24, 2019.

Any Takers?

[JeffR]

Hey, I've been attempting to compile the Pre-Release in Linux and so far have some case-sensitive problems. In customShaderFeature.cpp - line 23, it was CustomShaderFeature.h but was supposed to be customShaderFeature.h.

Damn case-sensitivity.

In meshREnderSystem.h, I changed, #include "core/util/SystemInterfaceList.h" to #include "core/util/systemInterfaceList.h"

There were some others too.


In renderProbeMgr.h, I had to change

Code: Select all

inline bool ProbeRenderInst::operator ==(const ProbeRenderInst& b) const

to

Code: Select all

inline bool operator ==(const ProbeRenderInst& b) const

I got it to compile without errors and the executable would only run from command line.

I used

Code: Select all

CMAKE_EXE_LINKER_FLAGS -no-pie

Code: Select all

CMAKE_EXE_LINKER_FLAGS_RELEASE -no-pie

re-compiled and the executable would run with a double click. I don't really know what -nopie means but I read it isn't the best practice.

When I enter a level, there are a ton of errors that I believe may stem from case-sensitivity in Linux.

I will check more into it.

Thanks

Good spots on all this, I'll make sure to get this rolled in.
On the no-pie thing, I did some reading and it seems like it's more just a "it's less secure this way because it doesn't get punted into random memory", but since it actually lets the thing run without any hoop-jumping, then unless something else crops up for why it's bad to use, I'm sorta inclined to have it be the default.

We could probably have that be an option in cmake so if someone wants that added security and is willing to juggle the extra headache of the security measures messing with stuff, they can.

[Happenstance]

Going to dig into this today (likely an issue on my end based on the feedback so far) but all of the builds fail to run on my system. They show the Torque3D splash screen and then immediately close. Console log seems normal, last line is 'sfxStartup...' but that's not particularly helpful.

This is on a Win10 machine with a 1060 3GB card.

[Azaezel]

Going to dig into this today (likely an issue on my end based on the feedback so far) but all of the builds fail to run on my system. They show the Torque3D splash screen and then immediately close. Console log seems normal, last line is 'sfxStartup...' but that's not particularly helpful.

This is on a Win10 machine with a 1060 3GB card.

Had you been keeping up with the development fork from time to time, or would this be a prior master to these forks as far as checking in goes? We shifted the backend to openal-soft a few months ago, so it may be something tripping there...

One way to doublecheck would be to go to your
C:\Users\<user>\Documents\<game name>\preferences\clientPrefs.cs and flip:
$pref::SFX::device = "OpenAL";
to
$pref::SFX::device = "NULL";

[Steve_Yorkshire]

If you don't have the openAl32.dll in your game directory you need to copy it over. If you can't find it on another project try here

[Happenstance]

Just got home and started looking into this. It was indeed failing to init the sound system (console log was actually helpful after all!). Up and running now. :]

[Timmy]

Should note the OpenAL end of things on mac was a bit of a hack that cost us the new reverb stuff on that platform. At some point we'll need to revisit that to sort out how to properly use the git-included library instead of the os framework to leverage the AL_ALEXT_PROTOTYPES extended functionality.

Fix is here , this also enables using the t3d supplied openal-soft version for linux as well, so all 3 platforms will now use the same openal-soft build. Should give @ practicing01 credit for the EFX fix, his original can be found here

[Jason Campbell]

Hey, I've been attempting to compile the Pre-Release in Linux and so far have some case-sensitive problems. In customShaderFeature.cpp - line 23, it was CustomShaderFeature.h but was supposed to be customShaderFeature.h.

Damn case-sensitivity.

In meshREnderSystem.h, I changed, #include "core/util/SystemInterfaceList.h" to #include "core/util/systemInterfaceList.h"

There were some others too.


In renderProbeMgr.h, I had to change

Code: Select all

inline bool ProbeRenderInst::operator ==(const ProbeRenderInst& b) const

to

Code: Select all

inline bool operator ==(const ProbeRenderInst& b) const

I got it to compile without errors and the executable would only run from command line.

I used

Code: Select all

CMAKE_EXE_LINKER_FLAGS -no-pie

Code: Select all

CMAKE_EXE_LINKER_FLAGS_RELEASE -no-pie

re-compiled and the executable would run with a double click. I don't really know what -nopie means but I read it isn't the best practice.

When I enter a level, there are a ton of errors that I believe may stem from case-sensitivity in Linux.

I will check more into it.

Thanks

Good spots on all this, I'll make sure to get this rolled in.
On the no-pie thing, I did some reading and it seems like it's more just a "it's less secure this way because it doesn't get punted into random memory", but since it actually lets the thing run without any hoop-jumping, then unless something else crops up for why it's bad to use, I'm sorta inclined to have it be the default.

We could probably have that be an option in cmake so if someone wants that added security and is willing to juggle the extra headache of the security measures messing with stuff, they can.

Thanks Jeff, I admit that I haven't had to much time to look into the actual script errors but I uploaded the "working" Linux friendly source if anyone wants to compile it.
https://drive.google.com/open?id=1KuEQK ... GbgxqYmoad

[Jason Campbell]

Good spots on all this, I'll make sure to get this rolled in.
On the no-pie thing, I did some reading and it seems like it's more just a "it's less secure this way because it doesn't get punted into random memory", but since it actually lets the thing run without any hoop-jumping, then unless something else crops up for why it's bad to use, I'm sorta inclined to have it be the default.

We could probably have that be an option in cmake so if someone wants that added security and is willing to juggle the extra headache of the security measures messing with stuff, they can.

Thanks Jeff, I admit that I haven't had to much time to look into the actual script errors but I uploaded the "working" Linux friendly source if anyone wants to compile it.
https://drive.google.com/open?id=1KuEQK ... GbgxqYmoad

reminder: you need to add these flags for executable in cmake

CMAKE_EXE_LINKER_FLAGS -no-pie
CMAKE_EXE_LINKER_FLAGS_RELEASE -no-pie