Page 3 of 4

Re: Pre-Release Candidate 4.0 build

Posted: Sun Jun 23, 2019 10:03 pm
by Razer
I will wait for a next early release that will work without any errors on Win 7.

Re: Pre-Release Candidate 4.0 build

Posted: Mon Jun 24, 2019 1:48 am
by 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?

Re: Pre-Release Candidate 4.0 build

Posted: Mon Jun 24, 2019 4:13 am
by 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.

Re: Pre-Release Candidate 4.0 build

Posted: Tue Jun 25, 2019 6:02 pm
by 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.

Re: Pre-Release Candidate 4.0 build

Posted: Tue Jun 25, 2019 11:44 pm
by 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";

Re: Pre-Release Candidate 4.0 build

Posted: Tue Jun 25, 2019 11:49 pm
by 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

Re: Pre-Release Candidate 4.0 build

Posted: Wed Jun 26, 2019 12:32 am
by 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. :]

Re: Pre-Release Candidate 4.0 build

Posted: Thu Jun 27, 2019 10:04 am
by 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

Re: Pre-Release Candidate 4.0 build

Posted: Thu Jun 27, 2019 2:57 pm
by 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

Re: Pre-Release Candidate 4.0 build

Posted: Thu Jun 27, 2019 3:00 pm
by 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