Jump to content
The Dark Mod Forums

Compiling TDM 2.04 Under Linux


NightStalker

Recommended Posts

Crinkelite: If you have not already done so:

duzenko: When you return:

 

I would encourage you both to take a look at Hamlet's patches, specifically the 'pugi_strings.patch.txt' patch. I think it will further your compilation attempts under Ubuntu 16.10.

 

I would be interested to hear your results if you get a chance to try it.

Link to comment
Share on other sites

If may be of help...

 

I felt my virility diminished by the fact that Ubuntu uses GCC 6.2 and I do not, so I installed the latter and now my psychic balance is restored.

Compilation by GCC 6.2.0 of The Dark Mod with a set of patches that worked with GCC 5.4 went fairly well, except for one point. After all, you cant reasonably expect to get away with redefine'ing private into public.

I am attaching a patch (gcc6-TypeInfo.patch.txt) that addresses the specific problem I encountered by including the "problematic" header before that redefinition happens. If other libraries (on any compiler) trigger the same problem in TypeInfo.cpp, the same approach can be used.

Edited by Hamlet
  • Like 3
Link to comment
Share on other sites

Crinkelite: If you have not already done so:

duzenko: When you return:

 

I would encourage you both to take a look at Hamlet's patches, specifically the 'pugi_strings.patch.txt' patch. I think it will further your compilation attempts under Ubuntu 16.10.

 

I would be interested to hear your results if you get a chance to try it.

Pugxml has stopped complaining with that patch. It's good to be applied to trunk IMHO.

Now I have this access redeclaration error. AFAIR it was mentioned somewhere already but can't remember where and whether it has been sorted out.

P.S. Great job so far, Hamlet, NightStalker :)

allout.txt

  • Like 1
Link to comment
Share on other sites

Pugxml has stopped complaining with that patch. It's good to be applied to trunk IMHO.

Please give me a bit of time to add the patch and test with it before anyone checks it into SVN. Even though I don't really need the patch, I'd like to test with it in place to ensure that nothing bad happens. (Not that I'm expecting that, I just want to be thorough).

 

I'm deep into debugging the Linux crashes that Baal was seeing, so it might take me another day or two to test the 'pugxml' patch. After that, I will report back and then either you or I should probably check it into SVN.

Now I have this access redeclaration error. AFAIR it was mentioned somewhere already but can't remember where and whether it has been sorted out.

Actually, I believe that Hamlet's patch in the post immediately above yours will help. I've seen it, but not yet applied it, because, like the one mentioned above, Slackware 14.2 (GCC 5.3.0) doesn't need it to compile TDM. But I will also apply that one and test, in due time.

  • Like 1
Link to comment
Share on other sites

Actually, I believe that Hamlet's patch in the post immediately above yours will help.

Oops, that hurt :).

It kinda compiles for me now :awesome:. Didn't test how it runs because I'm on a VM and you guys run it on real hardware.

Here's my svn patch that combines the changes from multiple Hamlet's patches.

I think we're at the point where it should be applied to trunk.

 

 

Index: game/gamesys/TypeInfo.cpp
===================================================================
--- game/gamesys/TypeInfo.cpp    (revision 6735)
+++ game/gamesys/TypeInfo.cpp    (working copy)
@@ -17,6 +17,29 @@
 
 ******************************************************************************/
 
+// As stated below, the trick of defining "private" and "protected" is pure evil.
+// We pay for it in class definitions that implicitly declare private members
+// without using the (default) private visibility declaration.
+// This becomes a real problem in code like the one found in GCC 6.2, along the lines:
+//     
+//     class Class {
+//       struct PrivateStruct; // forward declaration
+//       // ...
+//         private:
+//       struct PrivateStruct {}; // actual definition
+//     };
+//
+// In this case, PrivateStruct is implicitly declared private, and then defined as
+// "private", that after our trick becomes "public". Joy ensues.
+// We import all the things like that before the trick takes places.
+// We loose access to some variable inspection, but we gain in compilability
+// (and a bit in sanity).
+#if defined(__GNUC__) && (__GNUC__ == 6)
+// these were observed in GNU GCC 6.2.0 (not in 5.4.0):
+#include <sstream>
+ #endif // if GCC 6+
+
+
 // This is real evil but allows the code to inspect arbitrary class variables.
 #define private        public
 #define protected    public
Index: game/pugixml/pugixml.hpp
===================================================================
--- game/pugixml/pugixml.hpp    (revision 6735)
+++ game/pugixml/pugixml.hpp    (working copy)
@@ -17,6 +17,9 @@
 #include "pugiconfig.hpp"
 
 #ifndef PUGIXML_NO_STL
+#if defined(__clang__) || defined(__GNUC__)
+#include <string>
+#else
 namespace std
 {
     struct bidirectional_iterator_tag;
@@ -43,6 +46,7 @@
     template <> class char_traits<char>;
 #endif
 }
+#endif // if not clang nor GCC
 #endif
 
 // Macro for deprecated features
Index: idlib/geometry/RenderMatrix.cpp
===================================================================
--- idlib/geometry/RenderMatrix.cpp    (revision 6735)
+++ idlib/geometry/RenderMatrix.cpp    (working copy)
@@ -40,11 +40,13 @@
 #include "../bv/Bounds.h"
 #include "RenderMatrix.h"
 
-//anon begin -- just comment this out to disable intrinsics
-#define USE_INTRINSICS
-#include <intrin.h>
-#include "sys_intrinsics.h"
-//anon end
+//anon begin -- just comment this out to disable intrinsics
+#ifdef _MSC_VER
+#define USE_INTRINSICS
+#include <intrin.h>
+#include "sys_intrinsics.h"
+#endif // if MicroSoft Compiler
+//anon end
 
 // FIXME:    it would be nice if all render matrices were 16-byte aligned
 //            so there is no need for unaligned loads and stores everywhere
Index: include/devil/IL/devil_internal_exports.h
===================================================================
--- include/devil/IL/devil_internal_exports.h    (revision 6735)
+++ include/devil/IL/devil_internal_exports.h    (working copy)
@@ -24,7 +24,7 @@
 #ifndef NOINLINE
 #ifndef INLINE
 #if defined(__GNUC__)
-    #define INLINE extern inline
+    #define INLINE /* extern */ inline
 #elif defined(_MSC_VER)
     #define NOINLINE
     #define INLINE
Index: include/devil/il_bmp.h
===================================================================
--- include/devil/il_bmp.h    (revision 6735)
+++ include/devil/il_bmp.h    (working copy)
@@ -71,11 +71,11 @@
 ILboolean    ilReadRLE4Bmp(BMPHEAD *Info);
 ILboolean    iGetOS2Bmp(OS2_HEAD *Header);
 
-#ifdef IL_BMP_C
+/*#ifdef IL_BMP_C
 #undef NOINLINE
 #undef INLINE
 #define INLINE
-#endif
+#endif*/
 
 #ifndef NOINLINE
 INLINE ILvoid GetShiftFromMask(const ILuint Mask, ILuint * CONST_RESTRICT ShiftLeft, ILuint * CONST_RESTRICT ShiftRight) {
Index: include/devil/il_endian.h
===================================================================
--- include/devil/il_endian.h    (revision 6735)
+++ include/devil/il_endian.h    (working copy)
@@ -56,36 +56,36 @@
     #define BigDouble(d) iSwapDouble(d)
 #endif
 
-ILvoid   iSwapUShort(ILushort *s);
-ILvoid   iSwapShort(ILshort *s);
-ILvoid   iSwapUInt(ILuint *i);
-ILvoid   iSwapInt(ILint *i);
-ILvoid   iSwapFloat(ILfloat *f);
-ILvoid   iSwapDouble(ILdouble *d);
-ILushort GetLittleUShort();
-ILshort  GetLittleShort();
-ILuint   GetLittleUInt();
-ILint    GetLittleInt();
-ILfloat  GetLittleFloat();
-ILdouble GetLittleDouble();
-ILushort GetBigUShort();
-ILshort  GetBigShort();
-ILuint   GetBigUInt();
-ILint    GetBigInt();
-ILfloat  GetBigFloat();
-ILdouble GetBigDouble();
-ILubyte SaveLittleUShort(ILushort s);
-ILubyte SaveLittleShort(ILshort s);
-ILubyte SaveLittleUInt(ILuint i);
-ILubyte SaveLittleInt(ILint i);
-ILubyte SaveLittleFloat(ILfloat f);
-ILubyte SaveLittleDouble(ILdouble d);
-ILubyte SaveBigUShort(ILushort s);
-ILubyte SaveBigShort(ILshort s);
-ILubyte SaveBigUInt(ILuint i);
-ILubyte SaveBigInt(ILint i);
-ILubyte SaveBigFloat(ILfloat f);
-ILubyte SaveBigDouble(ILdouble d);
+inline ILvoid   iSwapUShort(ILushort *s);
+inline ILvoid   iSwapShort(ILshort *s);
+inline ILvoid   iSwapUInt(ILuint *i);
+inline ILvoid   iSwapInt(ILint *i);
+inline ILvoid   iSwapFloat(ILfloat *f);
+inline ILvoid   iSwapDouble(ILdouble *d);
+inline ILushort GetLittleUShort();
+inline ILshort  GetLittleShort();
+inline ILuint   GetLittleUInt();
+inline ILint    GetLittleInt();
+inline ILfloat  GetLittleFloat();
+inline ILdouble GetLittleDouble();
+inline ILushort GetBigUShort();
+inline ILshort  GetBigShort();
+inline ILuint   GetBigUInt();
+inline ILint    GetBigInt();
+inline ILfloat  GetBigFloat();
+inline ILdouble GetBigDouble();
+inline ILubyte SaveLittleUShort(ILushort s);
+inline ILubyte SaveLittleShort(ILshort s);
+inline ILubyte SaveLittleUInt(ILuint i);
+inline ILubyte SaveLittleInt(ILint i);
+inline ILubyte SaveLittleFloat(ILfloat f);
+inline ILubyte SaveLittleDouble(ILdouble d);
+inline ILubyte SaveBigUShort(ILushort s);
+inline ILubyte SaveBigShort(ILshort s);
+inline ILubyte SaveBigUInt(ILuint i);
+inline ILubyte SaveBigInt(ILint i);
+inline ILubyte SaveBigFloat(ILfloat f);
+inline ILubyte SaveBigDouble(ILdouble d);
 
 #ifdef IL_ENDIAN_C
 #undef NOINLINE

 

 

Link to comment
Share on other sites

I am build trunk right now with your combined patch applied as i dont have access to 2.05 yet. Ill keep you updated how it runs once i am done building.

 

EDIT

 

Okay i get following error while building tdm:

 

 

scons: *** [build/debug/game/sys/scons/libgame.so] Implicit dependency `/usr/lib32/libboost_filesystem.so' not found, needed by target `build/debug/game/sys/scons/libgame.so'.
scons: building terminated because of errors.

 

I obviously dont have that directory, just /usr/lib/ and /usr/lib64. I have the missing libboost_filesystem.so which is a symlink to the versioned file of my distribution in /usr/lib64. Boost is installed as 32bit and 64bit package.

Edited by damiel
Link to comment
Share on other sites

Here's my svn patch that combines the changes from multiple Hamlet's patches. I think we're at the point where it should be applied to trunk.

Very glad to hear of your compilation progress!

 

As for checking things into SVN, I really must beg a bit more patience, folks. Maybe I'm missing some relevant discussion on the "developers'" sub-forum (assuming there is one), but I really want to check these patches out a bit more and I think I like one of my patches better than (EDIT: part of) the one you're about to commit to SVN. But time is lacking ATM because I'm very deeply into the Baal crashes and this is not a simple issue (trust me!).

 

I really don't want us to be checking something into SVN only to have to adjust again later. All that does it is create SVN "churn", which makes a hard job (figuring out what's going on, especially for newcomers like myself with no project history) even harder. So, please, just a bit more patience. Today is going to be a very busy day for me, but I still hope to find more time to work the "Baal crash" issue. If that goes well then tomorrow I'd like to apply some of these patches and test.

I obviously dont have that directory, just /usr/lib/ and /usr/lib64. I have the missing libboost_filesystem.so which is a symlink to the versioned file of my distribution in /usr/lib64. Boost is installed as 32bit and 64bit package.

I'm very glad to hear that Hamlet's patches are helping both of you -- I suspected that they would. As for the "/usr/lib32" issue you mention, I implore you to go back and carefully re-read Hamlet's excellent, detailed post. He specifically mentions "(note the "/usr/lib32/" path in two places)". What he's saying there is that you need to adjust his command according to your system. Do that properly and please let us know if that works.

Edited by NightStalker
  • Like 3
Link to comment
Share on other sites

As for the "/usr/lib32" issue you mention, I implore you to go back and carefully re-read Hamlet's excellent, detailed post. He specifically mentions "(note the "/usr/lib32/" path in two places)". What he's saying there is that you need to adjust his command according to your system. Do that properly and please let us know if that works.

If this project is really considering to require the compiling users to provide Boost (32 bits) from their own system, then it's probably time for me to scratch my head and my search engine to find a good Boost installation macro for AutoConf.

The one you ship failed miserably on my system, and there might be some better ones. Also I suppose that Windows and OSX users already pick Boost from the system?

Anyway, let me know.

 

Note that the first word in my statement is a true if. This project may decide that it's too much to ask to the users, or that it's too much of a burden to suddenly have to cope with the less-than-stable Boost interface in the wild.

My personal opinion is that it's worth, but I might even be... wow, wrong!

 

Last word for NightStalker: we all have a real life, we all take our time. I don't think you'll be blamed for that, and I am sure you shouldn't be. Newcomers (that is me!) typically have a burst of enthusiasm... I am sure I'll calm down soon.

(also I am not going to commit anything, and thrice-especially not on trunk).

Link to comment
Share on other sites

I'm very glad to hear that Hamlet's patches are helping both of you -- I suspected that they would. As for the "/usr/lib32" issue you mention, I implore you to go back and carefully re-read Hamlet's excellent, detailed post. He specifically mentions "(note the "/usr/lib32/" path in two places)". What he's saying there is that you need to adjust his command according to your system. Do that properly and please let us know if that works.

 

Thank you for the hint, i missed that little detail, it's kinda getting hard to follow every discussion with so many being around now! :)

 

Using the combined patch and hardcoding the path to the system copy of boost, makes everything compile just fine. After that i encountered the invisible man problem but luckily that one was resolved by using the missing pak file. I started a couple of missions now and everything seems to be fine, no crashes or other oddities.

 

So for me at this point there are only two concerns left now:

 

1. patch review

 

2. handling of boost libs and possibly other improvements to the build process for linux.

Edited by damiel
Link to comment
Share on other sites

If this project is really considering to require the compiling users to provide Boost (32 bits) from their own system, [...]

Personally, I'm all for TDM not including all these headers and libraries in the source code distribution and/or the libraries in the run-time distribution. If the Windows users want and/or need that, that's fine with me. But that's just not "the Linux way" and is a path of slowly increasing pain.

 

But there are just too many things wrong with TDM (IMHO) at the moment that deserve more attention, so that's where my time will be directed, initially. I'd like to help grayman get 2.05 settled and "out the door" before I assault him or anyone else with potentially controversial ideas. :)

 

But, Hamlet, I think we are of one mind on the Boost stuff. And, if I'm still sane later on, I eventually plan to gently "campaign" for some improvements in that area.

Using the combined patch and hardcoding the path to the system copy of boost, makes everything compile just fine.

Excellent! Very glad to hear that, damiel -- thanks for the report! I plan to test the various outstanding patches within the next couple of days so that (hopefully) we will all soon agree on their "SVN-worthiness". Then, in theory, we'll all be able to simply pull from "latest SVN" with no extra hassle.

 

And, as I said to Hamlet, above, I foresee Linux build improvements (both small, uncontroversial ones and, hopefully, some larger ones), but it will take some time.

 

I hope both you guys hang around. I really appreciate all your inputs!

Link to comment
Share on other sites

As for checking things into SVN, I really must beg a bit more patience, folks. Maybe I'm missing some relevant discussion on the "developers'" sub-forum (assuming there is one), but I really want to check these patches out a bit more and I think I like one of my patches better than (EDIT: part of) the one you're about to commit to SVN. But time is lacking ATM because I'm very deeply into the Baal crashes and this is not a simple issue (trust me!).

I've finally taken the time (sorry for the excessive delay, all!) to carefully check all of the patches that I think we're all wanting in SVN HEAD.

 

I've successfully test-compiled (and run) the TDM build under both 32-bit Slackware 14.2 with GCC 5.3.0 (my current, preferred setup) and under 32-bit Slackware 13.1 with GCC 4.4.4 (which is the closest I can reasonably come to grayman's GCC 4.4.3 setup).

 

This is the patchset I used:

 

 

Index: game/gamesys/TypeInfo.cpp
===================================================================
--- game/gamesys/TypeInfo.cpp	(revision 6737)
+++ game/gamesys/TypeInfo.cpp	(working copy)
@@ -17,6 +17,29 @@
  
 ******************************************************************************/
 
+// As stated below, the trick of defining "private" and "protected" is pure evil.
+// We pay for it in class definitions that implicitly declare private members
+// without using the (default) private visibility declaration.
+// This becomes a real problem in code like the one found in GCC 6.2, along the lines:
+//     
+//     class Class {
+//       struct PrivateStruct; // forward declaration
+//       // ...
+//         private:
+//       struct PrivateStruct {}; // actual definition
+//     };
+//
+// In this case, PrivateStruct is implicitly declared private, and then defined as
+// "private", that after our trick becomes "public". Joy ensues.
+// We import all the things like that before the trick takes places.
+// We lose access to some variable inspection, but we gain in compilability
+// (and a bit in sanity).
+#if defined(__GNUC__) && (__GNUC__ == 6)
+// these were observed in GNU GCC 6.2.0 (not in 5.4.0):
+#include <sstream>
+ #endif // if GCC 6+
+
+
 // This is real evil but allows the code to inspect arbitrary class variables.
 #define private		public
 #define protected	public
Index: game/pugixml/pugixml.hpp
===================================================================
--- game/pugixml/pugixml.hpp	(revision 6737)
+++ game/pugixml/pugixml.hpp	(working copy)
@@ -17,6 +17,9 @@
 #include "pugiconfig.hpp"
 
 #ifndef PUGIXML_NO_STL
+#if defined(__clang__) || defined(__GNUC__)
+#include <string>
+#else
 namespace std
 {
 	struct bidirectional_iterator_tag;
@@ -43,6 +46,7 @@
 	template <> class char_traits<char>;
 #endif
 }
+#endif // if not clang nor GCC
 #endif
 
 // Macro for deprecated features
Index: idlib/geometry/RenderMatrix.cpp
===================================================================
--- idlib/geometry/RenderMatrix.cpp	(revision 6737)
+++ idlib/geometry/RenderMatrix.cpp	(working copy)
@@ -41,9 +41,11 @@
 #include "RenderMatrix.h"
 
 //anon begin -- just comment this out to disable intrinsics
+#ifdef _MSC_VER
 #define USE_INTRINSICS
 #include <intrin.h>
 #include "sys_intrinsics.h"
+#endif // if MicroSoft Compiler
 //anon end
 
 // FIXME:	it would be nice if all render matrices were 16-byte aligned
Index: include/devil/IL/devil_internal_exports.h
===================================================================
--- include/devil/IL/devil_internal_exports.h	(revision 6737)
+++ include/devil/IL/devil_internal_exports.h	(working copy)
@@ -24,7 +24,7 @@
 #ifndef NOINLINE
 #ifndef INLINE
 #if defined(__GNUC__)
-	#define INLINE extern inline
+	#define INLINE static inline
 #elif defined(_MSC_VER)
 	#define NOINLINE
 	#define INLINE
Index: include/devil/il_endian.h
===================================================================
--- include/devil/il_endian.h	(revision 6737)
+++ include/devil/il_endian.h	(working copy)
@@ -56,6 +56,7 @@
 	#define BigDouble(d) iSwapDouble(d)
 #endif
 
+#ifdef NOINLINE
 ILvoid   iSwapUShort(ILushort *s);
 ILvoid   iSwapShort(ILshort *s);
 ILvoid   iSwapUInt(ILuint *i);
@@ -86,6 +87,7 @@
 ILubyte SaveBigInt(ILint i);
 ILubyte SaveBigFloat(ILfloat f);
 ILubyte SaveBigDouble(ILdouble d);
+#endif
 
 #ifdef IL_ENDIAN_C
 #undef NOINLINE

 

 

The first 2 files patched are essentially Hamlet's patches ('gcc6-TypeInfo.patch' & 'pugi_strings.patch'), as-is, with 1 minor comment spelling error fixed ("loose" -> "lose") in the 1st file's patch.

 

The 3rd file is the portion of Hamlet's 'RenderMatrix_in_Linux.patch' that grayman has not already committed to SVN HEAD.

 

The last 2 files are a patch I submitted back on Dec 10th for what is essentially the same issue that Hamlet addressed with his 'inline.patch'. This is the only case where I preferred my patch over Hamlet's, simply because I think mine follows the latest direction of the DevIL library's header files a bit more closely (and I've been using it since even before Dec 10th, so it's reasonably well tested under Linux, with 2 versions of GCC).

 

Feel free to question or even outright disagree with anything I've asserted above, though, folks. I may have missed something and would appreciate a gentle knock on the head if so! :)

 

I have no way to compile under Windows, though. So if anyone who has that capability could make sure that nothing breaks under Windows (compile-wise at least and, ideally, run-time-wise) that would be very much appreciated.

 

If there are no objections within the next 3 days, my plan is to commit all of those patches to SVN HEAD, so that regardless of which version of GCC one is using (4.4.3 [grayman], 4.4.4 [NightStalker, simulating grayman], 5.3.0 [NightStalker], 5.4.0 [Hamlet], 6.2.0 [Hamlet, duzenko, Crinkelite, damiel]), we should all be able to successfully compile SVN HEAD. :awesome:

 

When the time comes, I plan to commit the changes to these 5 files in 4 pieces, so that they are added and can be removed (if needed) atomically.

 

Thanks to all for being patient with me on this!

  • Like 1
Link to comment
Share on other sites

I have no way to compile under Windows, though. So if anyone who has that capability could make sure that nothing breaks under Windows (compile-wise at least and, ideally, run-time-wise) that would be very much appreciated.

Compiles to me in vs2013 with your patch.

TRUNK! TRUNK! TRUNK!

Link to comment
Share on other sites

Why not to push it in a branch now?

That would give willing people the chance to test it easily without compromising trunk, and after it's proven that it compiles in the other supported platforms, you can merge it to trunk.

I don't disagree with your logic one bit. The only impediments are (1) I'm very rusty with SVN and would not be comfortable trying to create a branch with my newly-minted SVN write privileges lest I mess something up! and (2) I don't even know if I could create a branch that would be readable to the public. I thought the patchset I supplied would be easy enough for people to merge into their local trees, but maybe I'm missing something?

Compiles to me in vs2013 with your patch.

TRUNK! TRUNK! TRUNK!

:laugh: Excellent! Many thanks for doing that test. The only reason I'm seeming to "drag my heels" on this is that I like to give everyone time to test and/or comment and I don't expect that all the Linux-compiling people read the forum as regularly as I have lately. But if the way I'm approaching this is an impediment, and since I'm too scared to try to create a public branch just now, I could commit that patchset later today if you guys think that's better.

Link to comment
Share on other sites

i did gave your patch a run now, it compiles fine and the game is running without any noticable errors, so consider 64bit linux as tested. :)

Excellent... many thanks for testing this, damiel!

 

@all: I'm getting quite mixed up as to where things have been discussed and I posted about committing all those patches to SVN in a different thread. Apologies for the confusion. Suffice it to say that I think we can all compile from SVN trunk now.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Recent Status Updates

    • Petike the Taffer  »  DeTeEff

      I've updated the articles for your FMs and your author category at the wiki. Your newer nickname (DeTeEff) now comes first, and the one in parentheses is your older nickname (Fieldmedic). Just to avoid confusing people who played your FMs years ago and remember your older nickname. I've added a wiki article for your latest FM, Who Watches the Watcher?, as part of my current updating efforts. Unless I overlooked something, you have five different FMs so far.
      · 0 replies
    • Petike the Taffer

      I've finally managed to log in to The Dark Mod Wiki. I'm back in the saddle and before the holidays start in full, I'll be adding a few new FM articles and doing other updates. Written in Stone is already done.
      · 4 replies
    • nbohr1more

      TDM 15th Anniversary Contest is now active! Please declare your participation: https://forums.thedarkmod.com/index.php?/topic/22413-the-dark-mod-15th-anniversary-contest-entry-thread/
       
      · 0 replies
    • JackFarmer

      @TheUnbeholden
      You cannot receive PMs. Could you please be so kind and check your mailbox if it is full (or maybe you switched off the function)?
      · 1 reply
    • OrbWeaver

      I like the new frob highlight but it would nice if it was less "flickery" while moving over objects (especially barred metal doors).
      · 4 replies
×
×
  • Create New...