### Pre-Release Candidate 4.0 build

This forum is for tracking and working on active issues that need to be resolved, as well as testing Pull Requests that are waiting to be integrated into Torque 3D.

#### Re: Pre-Release Candidate 4.0 build

Razer
Posts: 81
Joined: Tue Jan 10, 2017 11:29 am
I will wait for a next early release that will work without any errors on Win 7.

#### Re: Pre-Release Candidate 4.0 build

Azaezel
DEVGRU
Posts: 496
Joined: Tue Feb 03, 2015 9:50 pm

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?

#### Re: Pre-Release Candidate 4.0 build

JeffR
DEVGRU
Posts: 956
Joined: Tue Feb 03, 2015 9:49 pm

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

Code: Select all

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.

#### Re: Pre-Release Candidate 4.0 build

Happenstance
Posts: 104
Joined: Sat Apr 11, 2015 9:08 pm
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.

#### Re: Pre-Release Candidate 4.0 build

Azaezel
DEVGRU
Posts: 496
Joined: Tue Feb 03, 2015 9:50 pm

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";
Last edited by Azaezel on Tue Jun 25, 2019 11:50 pm, edited 1 time in total.

#### Re: Pre-Release Candidate 4.0 build

Steve_Yorkshire
Posts: 345
Joined: Tue Feb 03, 2015 10:30 pm

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

#### Re: Pre-Release Candidate 4.0 build

Happenstance
Posts: 104
Joined: Sat Apr 11, 2015 9:08 pm
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. :]

#### Re: Pre-Release Candidate 4.0 build

Timmy
Posts: 378
Joined: Thu Feb 05, 2015 3:20 am
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

#### Re: Pre-Release Candidate 4.0 build

Jason Campbell
Posts: 362
Joined: Fri Feb 13, 2015 2:51 am

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

Code: Select all

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.

#### Re: Pre-Release Candidate 4.0 build

Jason Campbell
Posts: 362
Joined: Fri Feb 13, 2015 2:51 am

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.