I’ve just tried to compile the engine source under GNU/Linux (Distribution is sidux based on Debian Sid).
Unfortunatelly the process is terminated because of errors.
Due to the “readme.txt” shipped with the engine source I’ve used scons starting in the src subdirectory.
Has anyone already compiled the source under Windows, Mac or GNU/Linux?
Any help much appreciated.
Yes i have it tried. You must have some Headers Files and Libs of the DirectX Sdk:
dinput8.lib or was is dinput.lib ?!
dsound.h
dinput.h
Yes, you must insert some headerfiles/libs from directX sdk.
Speaking of these headerfiles and the libs they declare. Did anyone tried a newer headerfile/lib then the one from directX 9.0. Because i could imagine newer directX versions and headerfiles not work. Just interested
Yes, you must insert some headerfiles/libs from directX sdk.
Speaking of these headerfiles and the libs they declare. Did anyone tried a newer headerfile/lib then the one from directX 9.0. Because i could imagine newer directX versions and headerfiles not work. Just interested
i have use directX Sck August 2006 
Its working
But how we can write a 2.60b Et? I have when i compile a 2.60d Et…
In these File qcommon/qcommon.h you can find these Code:
#ifndef PRE_RELEASE_DEMO
// 2.56 - protocol 83
// 2.4 - protocol 80
// 1.33 - protocol 59
// 1.4 - protocol 60
#define PROTOCOL_VERSION 84
#else
// the demo uses a different protocol version for independant browsing
#define PROTOCOL_VERSION 72
#endif
I have tried to change it to 84 but i have ingame Version 2.60d…
[QUOTE=Scennative;236118]
I have tried to change it to 84 but i have ingame Version 2.60d…[/QUOTE]
are you expecting Q3_VERSION to be magically updated when you change PROTOCOL_VERSION?
Good to hear.
As Debian Sid has newer versions of programs that might be a problem.
May be I haven’t installed all the needed programs/packages.
[QUOTE=Scennative;236106]Yes i have it tried. You must have some Headers Files and Libs of the DirectX Sdk:
dinput8.lib or was is dinput.lib ?!
dsound.h
dinput.h
:)[/QUOTE]Does the code really depend on this, i.e. does it use types declared in those files in a lot of places around the Linux code?
If not, couldn’t the first community-fix be to remove this awkward dependency?
BTW: maybe github can be nice to use for such community efforts.
I suppose those files are only used under windows, linux has nothing to do with directx
EDIT : compiles fine with Visual C++ 8.0 EE and DirectX SDK June 2010 ( latest available ), loaded them and they works fine, console version is 2.60d
It compiles okay on 64-bit Ubuntu after installing the 32-bit packages of :
[ul]
[li]libXxf86dga[/li][li]libXxf86vm[/li][/ul]
with getlibs, then changing lines 247 / 248 of SConscript.core to ‘/usr/lib32’ to use them.
ETPro doesn’t want to play with the new build however.
Firstly, it requires “version” to match exactly “ET2.60b” + “May 8 2006”, but simply changing Q3_VERSION to “2.60b” and line 2886 of qcommon.c to
s = va( "%s %s %s", Q3_VERSION, CPUSTRING, "May 8 2006" );
to give it the string it wants, results in a segfault.
It’s handled by ETPro…
LOADING… - game media done
LOADING… flamechunks
LOADING… clients
-------- UNRECOVERABLE ERROR --------
This may be due to a bug in etpro
Information to be used in a bug report is being generated:
------------- CUT HERE --------------
Version: etpro 3.2.6
Platform: Linux
Build: Sep 16 2006 18:02:39
Signal: Segmentation violation (11)
Signal code: 1
fault address: 0x7200720
Load addresses:
0xf7764000 /lib32/libdl.so.2
0xf7647000 /usr/lib32/libX11.so.6
0xf7636000 /usr/lib32/libXext.so.6
0xf7610000 /lib32/libm.so.6
0xf74b6000 /lib32/libc.so.6
0xf7791000 /lib/ld-linux.so.2
0xf749c000 /usr/lib32/libxcb.so.1
0xf7498000 /usr/lib32/libXau.so.6
0xf7491000 /usr/lib32/libXdmcp.so.6
0xf23df000 /lib32/libnss_compat.so.2
0xf23c8000 /lib32/libnsl.so.1
0xf7769000 /lib32/libnss_nis.so.2
0xf23bc000 /lib32/libnss_files.so.2
0xf0af0000 /usr/lib32/nvidia-current/libGL.so.1
0xf0aee000 /usr/lib32/nvidia-current/tls/libnvidia-tls.so.256.44
0xef5be000 /usr/lib32/nvidia-current/libnvidia-glcore.so.256.44
0xef0f7000 /usr/lib32/libXcursor.so.1
0xef0ed000 /usr/lib32/libXrender.so.1
0xef0e7000 /usr/lib32/libXfixes.so.3
0xef021000 /usr/lib32/libnss_mdns4_minimal.so.2
0xef01b000 /lib32/libnss_dns.so.2
0xef007000 /lib32/libresolv.so.2
0xec574000 /home/valkyr/.etwolf/etpro/ui.mp.i386.so
0xe6327000 /home/valkyr/.etwolf/etpro/cgame.mp.i386.so
EIP: e6335c4c
edi:e8cd6407 esi:07200720 ebp:e6403220 esp:ff8ece00
eax:e8cd6407 ebx:e64019d4 ecx:00000078 edx:00000000
stack:
e6401c20 e8cd6407 f47913e0 33504449 00000000 00000002 e6335c09 e64019d4
e6432ba0 08fbf0e7 e63edb59 e6335e7a 00000000 e8dfa724 f280e6a8 65646f6d
6d2f736c 69746c75 79616c70 732f7265 6c707075 2f736569 6c616568 6f626874
6d775f78 33646d2e 00003300 e6370033 00000030 00000001 e8d56760 00000000
code:
8b 0e 89 0c 24 e8 0a 5b 09 00 85 c0 75 2e ff 44 24 14 83 c5 10 81 7c 24 14 8f
00 00 00 76 c5 8b 74 24 10 85 f6 74 0d 8b ab 3c f7 ff ff 81 4d 00 00 00 00 40
Stack trace:
1 entries
/home/valkyr/.etwolf/etpro/cgame.mp.i386.so(+0x1df22)[0xe6344f22]
------------- CUT HERE --------------
Trying to clean up…
Received signal 11, exiting…
Shutdown tty console
Segmentation fault
That’s when connecting to a standard ETPro3.2.6 / ET2.60b server. Connecting to etmain works OK.
sounds like a 2.60 install instead of 2.60b, ETPro 3.2.6 won’t work without the 2.60b patch
Apparently ETPro 3.2.6 does some sort of hard-coded low-level ET executable check and requires the exact 2.60b executable.
Which is obviously a major problem for any new engine hoping to be backwards compatible with existing mod’s. NQ works with 32-bit engine builds, but 64-bit engine builds will (obviously) need mod’s that are also compiled for 64-bit.
Necro-post to be sure, but doesn’t ETPro do some run time memory patching? Or did that stop after the 2.60 release?