Jump to content
The Dark Mod Forums

Search the Community

Showing results for tags 'bug'.

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • General Discussion
    • News & Announcements
    • The Dark Mod
    • Fan Missions
    • Off-Topic
  • Feedback and Support
    • TDM Tech Support
    • DarkRadiant Feedback and Development
    • I want to Help
  • Editing and Design
    • TDM Editors Guild
    • Art Assets
    • Music & SFX

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


AIM


MSN


Website URL


ICQ


Yahoo


Jabber


Skype


Location


Interests

  1. Can someone reproduce? Make a mission fail. The screen with multiple options like restart mission appears. Hit quick load key. Let the reload end. Hit esc. See the mission failed screen again instead of main menu.
  2. Hello taffers, I'm currently attempting to ghost (supreme ghost if possible) the aforementioned mission on expert + hardcore settings, and upon trying to loot the spider lair in the sewers, it started to behave rather strangely, as though it was attracted to my general position no matter what: altitude lightgem level alert level. Also, could be a bug with the unofficial patch by @wesp5: rarely when it detects me, the stealth stats won't update when the spider attacks, it will settle to roaming immediately after I'm hidden or on high ground, this didn't happen on my vanilla installation. Since the unofficial patch "balances" some game mechanics, the root cause could be related. On vanilla TDM this is not an issue, or not that I had encountered on my previous normal and ghosting runs of this mission. If this is a core game bug and not something related to the mod, and can be reproduced consistently on vanilla TDM, I can create a bug report if needed. [edited] Thank you.
  3. Hello again TDM crew. I am running TDM 2.10 beta / 64 #9627 and the map is Chronicles of Skullduggery 3 (COS3) Sacricide. When I do the rats extermination side mission, I can kill the rats, but, I cannot frob and lift the bodies up into the drop bucket. I can frob and slide the bodies around the floor, but, they just seem to stay at floor level no matter what I do. This is not an issue in 2.09 release. I played both versions to verify the bug as it is easy to recreate. To quickly recreate: 1) start the mission standing in your "delivery" box. 2) immediately go North from spawn point into the alley to the side-job notes on the wall and read the one about the rats to gain the objective. 3) go south back to your start point. 4) go east in the to the opening in the ground leading to the rats in the basement. 5) shoot a rat with an arrow. 6) attempt to frob and lift it to the drop bucket but the rat stays at the floor. I could create a vid if requested. CVLW
  4. TDM 2.10/64 #9627 // Briarwood Manor Hello TDM crew. I think I have encountered a 2.10 bug. It appears to be intermittent. This is/was not an issue on 2.09. I am running Briarwood Manor on 2.10. I had just run this map multiple times on 2.09. One difference, though is the map shows "Briarwood Manor 1.81" in the title on 2.09 and just "Briarwood Manor" on 2.10. I have no idea what that might mean. At one point, I was at the Steward's room door attempting to pick the lock with the Triangle lockpick. The pick seemed to engage, start picking, then quickly disengage, repeatedly, without progressing the picking. I was crouched right up next to the door aimed at the door handle, so, I wasn't having a distance disengagement issue. Closing and reloading the game (to a save prior to the door) allowed the pick to work normally. Thus, I suspect this is intermittent which is, of course, simply the BEST type of bug to have! I managed to capture a video of the problem when it happened. The file is too large to send in this bug.
  5. There seems to be a limitation regarding controllers (2.09 release, Linux / X11). The engine appears to not detect special mouse keys: In the Settings - Controls menu, I cannot map actions to some mouse buttons, they aren't being sensed at all. Tilting the mouse wheel sideways seems to register (as "mouse4" and "mouse5") but the forward and backward navigation keys do not. I noticed this a while ago but I don't need those buttons. However I'm trying to introduce the game to someone close: He needs to use a mouse with special buttons for gaming due to medical reasons. If non-standard mouse keys can't be mapped, I'm afraid this is a game we won't be able to enjoy. For this reason I'd like to ask if others can confirm this limitation, and if so can the engine be patched to solve it please? Thank you.
  6. As the titles say the names of the mission are not showing up. This is also the latest version (2.09) so I have no clue how to fix this. Any ideas?
  7. https://bugs.thedarkmod.com/view.php?id=5068 Sometimes, when going underwater, the shader responsible for blurring the view will shrink the image to roughly 1/4 of the screen (1/2 both horizontally and vertically) and position it in the lower-left corner, while leaving a jumble of textures to display in the background. This only seems to happen on rare occasions; My latest test suggest it occurs if the player has taken any damage and the health bar is showing up on the HUD. I'm running TDM 2.07 x64 on Linux (openSUSE Tumbleweed) with the free video drivers (amdgpu).
  8. https://bugs.thedarkmod.com/view.php?id=5055 There seems to be an issue with shadow rendering in the engine: When enabling both Stencil Shadows and Soft Shadows, shadows get incorrectly mapped and are stretched across the screen in front of the camera. I have no issues when using Stencil Shadows without shadow softness, nor when using Map Shadows both with and without soft shadows. I'm running TDM 2.07 x64. My operating system is Linux openSUSE Tumbleweed x64. Kernel 5.2.14. Mesa 19.1.7 (amdgpu module). My video card is an AMD Radeon XFX R9 390. I attached two screenshots from the FM Full Moon Fever: The first shows stencil shadows without softness (normal results) and the second is stencil shadows with softness (corrupt shadows).
  9. I'm having lighting issues specifically on this mission. This is with soft shadows off, but I have similar problems with them turned on. Upon restart it seems to come up with different lighting issues each time. My settings. https://i.imgur.com/Z4AZLZ6.jpg https://i.imgur.com/wyjwrku.jpg Edit: It would appear my lighting, in general, is broken. I just started "Cleaning Up the Neighbourhood" and it also is broken. Will be posting this in a separate thread appropriately. Edit edit: Just happened in William Steele. My version of TDM seems broken. The lighting was perfectly functional yesterday but I just downloaded some new missions off the list. Is there any way that would have broken things?
  10. There's some sort of problem with the TDM updater whereby it won't create a proper 2.07 installation. Being on a slow Internet connection, my TDM installation/update procedure has always involved downloading just the latest update zip file (currently, 'tdm_update_2.06_to_2.07.zip') from the ModDB site and making that available to the updater locally, to avoid unreliable, slow downloads during the actual update. I followed the same procedure that I've always (successfully) done in the past: extract the huge, 2.3-GB 'THEDARKMODVersion2.0-StandaloneRelease.zip' file (downloaded once from ModDB and re-used many times over the years) change the permissions on all the PK4 files to be write-able (so that the updater can alter the content within, as needed) delete the existing, obsolete (2013-era), read-only 'tdm_update.log' file (which shouldn't be in the zip file to begin with) put a copy of all the 'tdm_update_2.0{x}_to_2.0{x+1}.zip' files amassed to date into that extracted directory download the latest version of the TDM updater app (from the TDM website) run the updater, with the options '--keep-update-packages --noselfupdate' On the 1st run, it proceeds in what appears to be normal fashion. There's no obvious indication that anything has gone amok. However, if you run the game, it comes up with the main menu showing "TDM 2.06", not the expected "TDM 2.07". Here's the TDM updater log file for this 1st run: tdm_update--run-1.log.txt Some analysis of the directory content and the updater's log file seems to indicate that the installation only made it to 2.06! As for the 'tdm_update_2.06_to_2.07.zip' file, I've verified the integrity ('zip -T'). I've also verified the filesize and checksum against the updater-downloaded 'tdm_version_info.txt' file: [UpdatePackage from 2.06 to 2.07] crc = 159677cb filesize = 427644498 package = tdm_update_2.06_to_2.07.zipSo I don't think there's anything wrong with that particular file. If I compare what the updater created as a "2.07" installation with an old, virgin 2.06 installation of mine, the only files that are different are ones that you'd expect to be: 'crc_info.txt', 'tdm_mirrors.txt', 'tdm_update.log', and 'tdm_version_info.txt'. If I run the updater a 2nd time (and all subsequent times) with the same options, it essentially does this: Applying differential update package... [=========================] 100.0% Adding: ExtLibs.dll [=========================] 100.0% Adding: ExtLibsx64.dll [=========================] 100.0% Adding: TheDarkModx64.exe [=========================] 100.0% Adding: thedarkmod.x64 [=========================] 100.0% Adding: vcredist_x64.exe [=========================] 100.0% Adding: vcredist_x86.exe [=========================] 100.0% Replacing: AUTHORS.txt [=========================] 100.0% Replacing: TheDarkMod.exe [=========================] 100.0% Replacing: tdm_update.exe [=========================] 100.0% Replacing: tdm_update.linux [=========================] 100.0% Replacing: thedarkmod.x86 [=========================] 100.0% File: Done applying the differential update.Due to website file upload limitations, the TDM updater log file for this 2nd run will be attached to a subsequent post. The updater log files on that 2nd and all subsequent runs are essentially identical, just with different timestamps and potentially use of a different mirror site. That's the repeatable scenario, the "crux of the matter", if you will. FWIW, I also dug more deeply into the problem. What I describe from here on is less thoroughly documented, but I'll mention what I did, in case it helps.... I tried removing all of the update zip files, hoping it would force the updater to update what is effectively a 2.06 installation but via a slow, painful download of that 408-MB 'tdm_update_2.06_to_2.07.zip'. But instead, it inexplicably wanted to download the 235-MB 'tdm_update_2.05_to_2.06.zip' file, so I aborted the update. Taking a different tack, I dug into the updater source code a bit and noticed this curious-looking snippet in '.../tdm_update/libtdm_update/Updater/UpdateController.cpp': //#4529 stgatilov: Since differential update does not uncompress unchanged OGG/ROQ files, //The hashes of pk4 files are now different from the ones on the server. //That's why we exit right away to avoid redoing the same differential update and redownloading the unchanged data. if (info.fromVersion == "2.05" && info.toVersion == "2.06") { TryToProceedTo(PostUpdateCleanup); break; }I played around with various changes to that code (both bumping the 2 version numbers and outright disabling the whole block), but to no avail. Although I'm running Linux (64-bit Slackware 14.2), I don't immediately see any reason why this would be OS-specific. This issue sounds different from the problem grayman had (running Windows), but I did get an "infinite updater loop" scenario when I hacked that code mentioned above, so maybe there's some correlation. I also noticed during some debugging that the installation I had was not being correctly recognized by the updater app as a valid 2.06 installation. When I looked into the updater's console output and log file, it seemed that every file about which the installer reported "SIZE MISMATCH" was one of the PK4 files that had embedded OGG files, although I did not check every case. I'm simply not able to figure out what's going on here, despite much effort, so I have to "punt" before my head explodes. Any input on this matter would be very much appreciated!
  11. http://bugs.thedarkmod.com/view.php?id=4893 I found a very problematic issue in the engine. I'm running TDM 2.06, 64bit executable, Linux version (openSUSE Tumbleweed x64). The issue is as follows: Previously, if a bad script or definition or missing asset error occurred, TDM would crash back to the main menu and the error would appear in the console. It seems this is no longer the case and something worse happens instead: Errors will now cause the process to freeze, shortly followed by a permanent black screen. The reason why this is annoying is because alt-tab switching still doesn't work. To recover the operating system, I need to hit Control + Alt + F1 to go to a different runlevel then use 'top' to find the TDM process followed by a 'kill -9 PID'. Can anyone else confirm this and fix the engine locking up on internal errors?
  12. Hey guys If i end a mission in the dark mod and i cant read the statistic. i see only 0 everywhere and i dont know why i get this bug in every Missions. Here is a screenshot of these bug Link: Google Drive I hope someone can help me to fix it Btw i installed already The dark Mod new but it doesnt help, i playend on 2.05 and 2.06 (64bit) Greetings PS: sorry for my bad english
  13. Once I was able to run my game thanks to my previous post, I immediately launched Training mission. Due to the controls confusion, I picked up first health potion, and instead of using it, accidentally dropped it. When I picked it up again, the text was "You picked 2 health potions, 8 more to go". It does not have any major impact, but as a programmer, unresolved issues BUG me (no pun intended).
  14. http://bugs.thedarkmod.com/view.php?id=4742 The latest DarkRadiant commit in https://github.com/codereader/DarkRadiant ( 2ad55e91df66e11c5385ba40cf3615f56f7d00e8 ) fails configuration. Oddly enough the console doesn't output the exact cause, it only complains that Makefile.in cannot be found. I use Linux openSUSE Tumbleweed 64bit. Below is a console log with the commands I ran and the respective output. mircea@linux-qz0r:~/Downloads/DarkRadiant> ./autogen.sh;./configure --prefix=/home/mircea/Downloads/DarkRadiant/install --enable-darkmod-plugins libtoolize: putting auxiliary files in '.'. libtoolize: copying file './ltmain.sh' libtoolize: putting macros in AC_CONFIG_MACRO_DIRS, 'm4'. libtoolize: copying file 'm4/libtool.m4' libtoolize: copying file 'm4/ltoptions.m4' libtoolize: copying file 'm4/ltsugar.m4' libtoolize: copying file 'm4/ltversion.m4' libtoolize: copying file 'm4/lt~obsolete.m4' configure.ac:24: installing './compile' configure.ac:2: installing './missing' configure.ac:336: error: required file 'plugins/eclasstree/Makefile.in' not found configure.ac:336: error: required file 'plugins/entitylist/Makefile.in' not found configure.ac:336: error: required file 'plugins/undo/Makefile.in' not found libs/ddslib/Makefile.am: installing './depcomp' configure: loading site script /usr/share/site/x86_64-unknown-linux-gnu checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for a thread-safe mkdir -p... /usr/bin/mkdir -p checking for gawk... gawk checking whether make sets $(MAKE)... yes checking whether make supports nested variables... yes checking whether make supports nested variables... (cached) yes checking build system type... x86_64-unknown-linux-gnu checking host system type... x86_64-unknown-linux-gnu checking for a sed that does not truncate output... /usr/bin/sed checking whether NLS is requested... yes checking for msgfmt... /usr/bin/msgfmt checking for gmsgfmt... /usr/bin/msgfmt checking for xgettext... /usr/bin/xgettext checking for msgmerge... /usr/bin/msgmerge checking for style of include used by make... GNU checking for gcc... gcc checking whether the C compiler works... yes checking for C compiler default output file name... a.out checking for suffix of executables... checking whether we are cross compiling... no checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed checking whether gcc understands -c and -o together... yes checking dependency style of gcc... gcc3 checking for ld used by GCC... /usr/x86_64-suse-linux/bin/ld checking if the linker (/usr/x86_64-suse-linux/bin/ld) is GNU ld... yes checking for shared library run path origin... done checking how to run the C preprocessor... gcc -E checking for grep that handles long lines and -e... /usr/bin/grep checking for egrep... /usr/bin/grep -E checking for CFPreferencesCopyAppValue... no checking for CFLocaleCopyCurrent... no checking for GNU gettext in libc... yes checking whether to use NLS... yes checking where the gettext function comes from... libc checking for msgfmt... yes checking for msgmerge... yes checking for xgettext... yes checking for g++... g++ checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes checking dependency style of g++... gcc3 checking how to print strings... printf checking for a sed that does not truncate output... (cached) /usr/bin/sed checking for fgrep... /usr/bin/grep -F checking for ld used by gcc... /usr/x86_64-suse-linux/bin/ld checking if the linker (/usr/x86_64-suse-linux/bin/ld) is GNU ld... yes checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B checking the name lister (/usr/bin/nm - interface... BSD nm checking whether ln -s works... yes checking the maximum length of command line arguments... 1572864 checking how to convert x86_64-unknown-linux-gnu file names to x86_64-unknown-linux-gnu format... func_convert_file_noop checking how to convert x86_64-unknown-linux-gnu file names to toolchain format... func_convert_file_noop checking for /usr/x86_64-suse-linux/bin/ld option to reload object files... -r checking for objdump... objdump checking how to recognize dependent libraries... pass_all checking for dlltool... no checking how to associate runtime and link libraries... printf %s\n checking for ar... ar checking for archiver @FILE support... @ checking for strip... strip checking for ranlib... ranlib checking command to parse /usr/bin/nm -B output from gcc object... ok checking for sysroot... no checking for a working dd... /usr/bin/dd checking how to truncate binary pipes... /usr/bin/dd bs=4096 count=1 checking for mt... mt checking if mt is a manifest tool... no checking for ANSI C header files... no checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking for dlfcn.h... yes checking for objdir... .libs checking if gcc supports -fno-rtti -fno-exceptions... no checking for gcc option to produce PIC... -fPIC -DPIC checking if gcc PIC flag -fPIC -DPIC works... yes checking if gcc static flag -static works... no checking if gcc supports -c -o file.o... yes checking if gcc supports -c -o file.o... (cached) yes checking whether the gcc linker (/usr/x86_64-suse-linux/bin/ld -m elf_x86_64) supports shared libraries... yes checking whether -lc should be explicitly linked in... no checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... no checking how to run the C++ preprocessor... g++ -E checking for ld used by g++... /usr/x86_64-suse-linux/bin/ld -m elf_x86_64 checking if the linker (/usr/x86_64-suse-linux/bin/ld -m elf_x86_64) is GNU ld... yes checking whether the g++ linker (/usr/x86_64-suse-linux/bin/ld -m elf_x86_64) supports shared libraries... yes checking for g++ option to produce PIC... -fPIC -DPIC checking if g++ PIC flag -fPIC -DPIC works... yes checking if g++ static flag -static works... no checking if g++ supports -c -o file.o... yes checking if g++ supports -c -o file.o... (cached) yes checking whether the g++ linker (/usr/x86_64-suse-linux/bin/ld -m elf_x86_64) supports shared libraries... yes checking dynamic linker characteristics... (cached) GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether g++ supports C++11 features by default... yes checking cstdint usability... yes checking cstdint presence... yes checking for cstdint... yes checking zlib.h usability... yes checking zlib.h presence... yes checking for zlib.h... yes checking for inflateEnd in -lz... yes checking jpeglib.h usability... yes checking jpeglib.h presence... yes checking for jpeglib.h... yes checking for jpeg_start_compress in -ljpeg... yes checking for wx-config... /usr/bin/wx-config checking for wxWidgets version >= 3.0.0... yes (version 3.0.3) checking for wxWidgets static library... no checking for pkg-config... /usr/bin/pkg-config checking pkg-config is at least version 0.9.0... yes checking for libxml-2.0... yes checking for sigc++-2.0... yes checking for libpng... yes checking for ftgl... yes checking GL/glew.h usability... yes checking GL/glew.h presence... yes checking for GL/glew.h... yes checking for main in -lGLEW... yes checking for main in -lGL... yes checking for gluBuild2DMipmaps in -lGLU... yes checking filesystem usability... no checking filesystem presence... no checking for filesystem... no checking experimental/filesystem usability... yes checking experimental/filesystem presence... yes checking for experimental/filesystem... yes configure: Will use std::filesystem instead of boost.filesystem checking for python-config... python-config configure: Checking for pybind11 headers... checking pybind11/pybind11.h usability... no checking pybind11/pybind11.h presence... no checking for pybind11/pybind11.h... no configure: Using the pybind11 headers shipped with the sources configure: Using the fmtlib headers shipped with the sources (header-only mode) checking for main in -ldl... yes checking AL/alut.h usability... yes checking AL/alut.h presence... yes checking for AL/alut.h... yes checking for ov_clear in -lvorbisfile... yes checking for alGetError in -lopenal... yes checking for main in -lalut... yes checking that generated files are newer than configure... done configure: creating ./config.status config.status: creating install/darkradiant.desktop config.status: creating install/i18n//Makefile.in config.status: error: cannot find input file: `Makefile.in' mircea@linux-qz0r:~/Downloads/DarkRadiant>
  15. I'm being affected by a strange issue in the latest Git master of DarkRadiant which makes using DR nearly impossible. I've already opened a bug report about it, but since progress is slow for several months I thought I'd also put this here in case anyone sees it and has some extra ideas. http://bugs.thedarkmod.com/view.php?id=4524 DarkRadiant does not sense any keyboard commands. I can however use the mouse and click on buttons just fine. I'm using openSUSE Tumbleweed x64 / KDE desktop. This seems to change if I have a menu opened, which implies it might be a focus detection issue. For instance: If I select a brush then press escape to deselect it, nothing happens... but if I select a brush, click on a toolbar entry such as "File" and leave the menu open, then press escape, the brush does get deselected. I additionally noticed that if I run DarkRadiant from a console, I get the following messages printed which seem to be relevant: (darkradiant:10061): Gtk-CRITICAL **: IA__gtk_check_menu_item_set_active: assertion 'GTK_IS_CHECK_MENU_ITEM (check_menu_item)' failed (darkradiant:10061): Gtk-CRITICAL **: IA__gtk_check_menu_item_set_active: assertion 'GTK_IS_CHECK_MENU_ITEM (check_menu_item)' failed (darkradiant:10061): Gtk-CRITICAL **: IA__gtk_check_menu_item_set_active: assertion 'GTK_IS_CHECK_MENU_ITEM (check_menu_item)' failed (darkradiant:10061): Gtk-CRITICAL **: IA__gtk_check_menu_item_set_active: assertion 'GTK_IS_CHECK_MENU_ITEM (check_menu_item)' failed
  16. It appears the latest version of DarkRadiant Git from Codereader is full of bugs and breakages, which affect at least the Linux version of the software. Since I just reported a whole list of problems, I decided to also make a thread here to hopefully bring more attention and testers who can confirm them: DarkRadiant doesn't sense keyboard inputsVarious windows won't openPanel sizes not persisted between startupsRecent maps menu becomes empty after useDarkRadiant crashes KWin when desktop compositing is enabled (KDE)
  17. Hate to beat a dead horse and all that jazz, but for some reason the letters are screwed again. Is it possible if in one of the updates something got changed? The last working thing is supposed to be here with "tdm_base01.pk4" https://drive.google...iew?usp=sharing Maybe something got messed up in 2.04 or 2.05? Or in the recent hotfixes? This tdm_base01.pk4 has the only working romanian character set that exists. What we have now messes up again ș, ț, ă. The updater downloads the wrong version of tdm_base01.pk4. Bug tracker listing: http://bugs.thedarkmod.com/view.php?id=4523
  18. While analysing the warnings emitted by GCC 6, I was pointed to this piece of code in renderer/Model_lwo.cpp (comment added): int sgetI1( unsigned char **bp ) { int i; if ( flen == FLEN_ERROR ) return 0; i = **bp; if ( i > 127 ) i -= 256; flen += 1; *bp++; // <== warning: unused value return i; } short sgetI2( unsigned char **bp ) { short i; if ( flen == FLEN_ERROR ) return 0; memcpy( &i, *bp, 2 ); BigRevBytes( &i, 2, 1 ); flen += 2; *bp += 2; return i; } Starting from the second function, sgetI2(), it appears that it receives as argument a pointer to an unsigned character, passed by reference in C style (that becomes a pointer to the pointer).It copies two bytes in a short, swap them as needed (handling little/big endian, I suppose), then it makes the pointer *bp point after the copied data and returns the value read. There is a sgetI4() which does the same with 4 byte data. Back to the first quoted, I was assuming sgetI1() would do the same. GCC complains that the statement *bpp++ produces an unused value. It turns out, the postfix increment operator (a++) has the highest priority among C and C++ operators, and it gets executed before the dereference operator. That means that I would expect the code to operate like (*bp)++, equivalent to *bp += 1, similarly to sgetI2(), but I get instead a *(bp++). This means that the local variable bp (unsigned char**) is increased (while the unsigned char* pointer *bp is not), and then the value it was pointing to before the increase is taken and ignored. All in all, it means that when it's called as sgetI1(&ptrToBuffer), it returns the value at the current value of ptrToBuffer and, on the next call, sgetI1(&ptrToBuffer), it returns again the same value, since ptrToBuffer is not increased. The same construct appears in sgetU1() and in add_clip() on nclips (a simple pointer int*), where it might have more serious consequences: *nclips++; clip->index = *nclips; since the an index is assigned from the cell of memory next to nclips (nclips is first increased).I can't find any place where the former two are used, while add_clip() is pulled in from LoadLWO() in renderer/Model.cpp (at which point I stopped tracking). I attach a trivial patch that removes these warnings by just doing the thing that would be usually expected (increase the pointed value) (it also removes the other instance of it, not mentioned in this text). Edit: discovered that syntax highlight for C/C++ works with code type "auto", even if it does not show in the preview. UnusedValue.patch.txt
  19. This is another report originating from a GCC warning, in this case the comparison of two different enumerators. This works by converting each of the two enumerators into a numeric value, and comparing them instead. In general, an enumerator is better used in a way that does not depend from its value at all. If the value is needed, constants are generally better suited. The relevant one of the two warnings comes from idAF::Load() in game/AF.cpp (line 910), where a variable of enumerator type declAFConstraintType_t from framework/DeclAF.h: typedef enum { DECLAF_CONSTRAINT_INVALID, DECLAF_CONSTRAINT_FIXED, DECLAF_CONSTRAINT_BALLANDSOCKETJOINT, DECLAF_CONSTRAINT_UNIVERSALJOINT, DECLAF_CONSTRAINT_HINGE, DECLAF_CONSTRAINT_SLIDER, DECLAF_CONSTRAINT_SPRING } declAFConstraintType_t;is compared with a variable of enumerator type constraintType_t from game/physics/Physics_AF.h: typedef enum { CONSTRAINT_INVALID, CONSTRAINT_FIXED, CONSTRAINT_BALLANDSOCKETJOINT, CONSTRAINT_UNIVERSALJOINT, CONSTRAINT_HINGE, CONSTRAINT_HINGESTEERING, CONSTRAINT_SLIDER, CONSTRAINT_CYLINDRICALJOINT, CONSTRAINT_LINE, CONSTRAINT_PLANE, CONSTRAINT_SPRING, CONSTRAINT_CONTACT, CONSTRAINT_FRICTION, CONSTRAINT_CONELIMIT, CONSTRAINT_PYRAMIDLIMIT, CONSTRAINT_SUSPENSION } constraintType_t;The comparison of values from two distinct enumerator types should be avoided because it requires the enumerator modifications to be synchronised, but it's very tempting to add an element to one forgetting about the other. If this comparison is really required, there should be a single enumerator type. Judging from the enumerator names, this departure from synchronisation has already happened (I would except a DECLAF_CONSTRAINT_SLIDER to be equivalent to a CONSTRAINT_SLIDER, and instead it's compared to a CONSTRAINT_HINGESTEERING). The two definitions are in different parts of the code and do not apparently share headers. But more to the point, for what I know these numerical values might be serialised, and changing them would break saved data. My recommended suggestions would be: if possible, manage to have a single enumerator for both usesif not, abandon direct comparison and use a slower multiple-choice comparison function.I provide a patch implementing the latter suggestion, which is expected not to break any serialised data, by not changing the enumerator values. Note that this function relies on the heuristic logic of my brain to match the elements from the two enumerators. Somebody with some understanding should cross check it. The patch also addresses the other enumerator comparison, which is more subtle and is caused by the fact that enumerators defined in a template class yield one different enumerator type for each template instantiation. enumCompare.patch.txt
  20. I have compiled The Dark Mod on Gentoo Linux (I detailed my experience in another post). I have a problem: the light gem is always completely dark. Guards will react to noise and to touch, but I could stand in front of them making faces and they will politely ignore my presence. I have bisected the commits and tracked back the problem to commit #4379. Reverting that single commit fixes my problem. Not surprisingly, I do not understand that commit. I can try things though. I should assume this does not happen on Windows. Is this material for a bug report?
  21. DarkRadiant stopped compiling after a series of system package updates in openSUSE Tumbleweed today. Oddly enough, I get an error related to boost again, although I compile DR with the same Boost version downloaded from the official website and compiled locally (was 1.54, now 1.59 but same issue). Core DR appears to compile, the error is in the filters plugin. Can anyone please take a look and fix this? make[2]: Entering directory '/home/mircea/Games/Quake/TheDarkMod/DarkRadiant_GIT/plugins/filters' CXX XMLFilter.lo CXX BasicFilterSystem.lo CXX filters.lo CXXLD filters.la libtool: warning: '/usr/lib64/gcc/x86_64-suse-linux/5/../../../../lib64/libxml2.la' seems to be moved .libs/XMLFilter.o: In function `boost::re_detail_106000::perl_matcher<__gnu_cxx::__normal_iterator<char const*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::allocator<boost::sub_match<__gnu_cxx::__normal_iterator<char const*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > > >, boost::regex_traits<char, boost::cpp_regex_traits<char> > >::unwind_extra_block(bool)': /usr/include/boost/regex/v4/perl_matcher_non_recursive.hpp:1250: undefined reference to `boost::re_detail_106000::put_mem_block(void*)' .libs/XMLFilter.o: In function `boost::cpp_regex_traits<char>::transform_primary(char const*, char const*) const': /usr/include/boost/regex/v4/cpp_regex_traits.hpp:966: undefined reference to `boost::re_detail_106000::cpp_regex_traits_implementation<char>::transform_primary(char const*, char const*) const' .libs/XMLFilter.o: In function `boost::cpp_regex_traits<char>::transform(char const*, char const*) const': /usr/include/boost/regex/v4/cpp_regex_traits.hpp:962: undefined reference to `boost::re_detail_106000::cpp_regex_traits_implementation<char>::transform(char const*, char const*) const' .libs/XMLFilter.o: In function `void boost::re_detail_106000::raise_error<boost::regex_traits_wrapper<boost::regex_traits<char, boost::cpp_regex_traits<char> > > >(boost::regex_traits_wrapper<boost::regex_traits<char, boost::cpp_regex_traits<char> > > const&, boost::regex_constants::error_type)': /usr/include/boost/regex/pattern_except.hpp:75: undefined reference to `boost::re_detail_106000::raise_runtime_error(std::runtime_error const&)' .libs/XMLFilter.o: In function `boost::re_detail_106000::cpp_regex_traits_implementation<char>::error_string(boost::regex_constants::error_type) const': /usr/include/boost/regex/v4/cpp_regex_traits.hpp:449: undefined reference to `boost::re_detail_106000::get_default_error_string(boost::regex_constants::error_type)' .libs/XMLFilter.o: In function `boost::re_detail_106000::perl_matcher<__gnu_cxx::__normal_iterator<char const*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::allocator<boost::sub_match<__gnu_cxx::__normal_iterator<char const*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > > >, boost::regex_traits<char, boost::cpp_regex_traits<char> > >::extend_stack()': /usr/include/boost/regex/v4/perl_matcher_non_recursive.hpp:217: undefined reference to `boost::re_detail_106000::get_mem_block()' .libs/XMLFilter.o: In function `boost::re_detail_106000::save_state_init::save_state_init(boost::re_detail_106000::saved_state**, boost::re_detail_106000::saved_state**)': /usr/include/boost/regex/v4/perl_matcher_non_recursive.hpp:107: undefined reference to `boost::re_detail_106000::get_mem_block()' .libs/XMLFilter.o: In function `boost::re_detail_106000::perl_matcher<__gnu_cxx::__normal_iterator<char const*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::allocator<boost::sub_match<__gnu_cxx::__normal_iterator<char const*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > > >, boost::regex_traits<char, boost::cpp_regex_traits<char> > >::match_imp()': /usr/include/boost/regex/v4/perl_matcher_common.hpp:214: undefined reference to `boost::re_detail_106000::verify_options(unsigned int, boost::regex_constants::_match_flags)' .libs/XMLFilter.o: In function `boost::re_detail_106000::save_state_init::~save_state_init()': /usr/include/boost/regex/v4/perl_matcher_non_recursive.hpp:115: undefined reference to `boost::re_detail_106000::put_mem_block(void*)' /usr/include/boost/regex/v4/perl_matcher_non_recursive.hpp:115: undefined reference to `boost::re_detail_106000::put_mem_block(void*)' .libs/XMLFilter.o: In function `boost::re_detail_106000::perl_matcher<__gnu_cxx::__normal_iterator<char const*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::allocator<boost::sub_match<__gnu_cxx::__normal_iterator<char const*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > > >, boost::regex_traits<char, boost::cpp_regex_traits<char> > >::perl_matcher(__gnu_cxx::__normal_iterator<char const*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >, __gnu_cxx::__normal_iterator<char const*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >, boost::match_results<__gnu_cxx::__normal_iterator<char const*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::allocator<boost::sub_match<__gnu_cxx::__normal_iterator<char const*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > > > >&, boost::basic_regex<char, boost::regex_traits<char, boost::cpp_regex_traits<char> > > const&, boost::regex_constants::_match_flags, __gnu_cxx::__normal_iterator<char const*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >)': /usr/include/boost/regex/v4/perl_matcher.hpp:382: undefined reference to `boost::re_detail_106000::perl_matcher<__gnu_cxx::__normal_iterator<char const*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::allocator<boost::sub_match<__gnu_cxx::__normal_iterator<char const*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > > >, boost::regex_traits<char, boost::cpp_regex_traits<char> > >::construct_init(boost::basic_regex<char, boost::regex_traits<char, boost::cpp_regex_traits<char> > > const&, boost::regex_constants::_match_flags)' collect2: error: ld returned 1 exit status Makefile:490: recipe for target 'filters.la' failed make[2]: *** [filters.la] Error 1 make[2]: Leaving directory '/home/mircea/Games/Quake/TheDarkMod/DarkRadiant_GIT/plugins/filters' Makefile:446: recipe for target 'install-recursive' failed make[1]: *** [install-recursive] Error 1 make[1]: Leaving directory '/home/mircea/Games/Quake/TheDarkMod/DarkRadiant_GIT/plugins' Makefile:752: recipe for target 'install-recursive' failed make: *** [install-recursive] Error 1
  22. Hey Guys, Big fan of TDM, been playing it for a while off and on over the last several years. Never had a technical issue I couldn't overcome until now. I recently rebuilt my rig, re-installed TDM, updated to 2.03, and now I can't load levels. I get through mission briefing/equipment purchase just fine, but as soon as I hit an actual load screen, the game locks up after loading about 1/5 of the bar (see attached images). This happens on every mission I've tried (including the included training mission). There's no error popup, and it doesn't crash, it just hangs forever. I've tried adjusting settings in the game itself (video quality, resolution, vsync, etc) to no avail. I'm stumped. Here's my system specs: - Windows 7 (64 bit) - Intel Core i7, 4.0GHz - 32 GB RAM - NVIDIA GeForce GTX 680 (updated to latest drivers) Any ideas or assistance would be greatly appreciated. Thanks in advance guys!
  23. I am trying to compile the latest SVN engine, on openSUSE Tumbleweed (via gcc 4.8). Compilation goes well until the end, when the process mysteriously fails for an unexplained reason. The only thing that seems to be printed is the name of the file and something called "Error 1". Anyone else running across this, and knows of a solution? Thanks. cm/CollisionModel_load.cpp: At global scope: cm/CollisionModel_load.cpp:42:13: warning: ‘versioned’ defined but not used [-Wunused-variable] static bool versioned = RegisterVersionedFile("$Id: CollisionModel_load.cpp 6551 2015-10-15 18:48:23Z stevel $"); ^ In file included from include/boost/filesystem/path_traits.hpp:23:0, from include/boost/filesystem/path.hpp:25, from include/boost/filesystem.hpp:16, from framework/../idlib/../idlib/Image.h:29, from framework/../idlib/../idlib/Lib.h:230, from framework/../idlib/precompiled.h:106, from framework/precompiled_engine.h:28: include/boost/system/error_code.hpp:221:36: warning: ‘boost::system::posix_category’ defined but not used [-Wunused-variable] static const error_category & posix_category = generic_category(); ^ include/boost/system/error_code.hpp:222:36: warning: ‘boost::system::errno_ecat’ defined but not used [-Wunused-variable] static const error_category & errno_ecat = generic_category(); ^ include/boost/system/error_code.hpp:223:36: warning: ‘boost::system::native_ecat’ defined but not used [-Wunused-variable] static const error_category & native_ecat = system_category(); ^ scons: *** [build/release/core/cm/CollisionModel_load.o] Error 1 scons: building terminated because of errors.
  24. When selecting a specific surround sound mode (I haven't been able to see the name of that specific mode), TDM crashes on my system (I'm running Linux Mint 17.1). It didn't even want to start again when I tried to start it immediately after I had made it crash, and I had to delete the file Darkmod.cnf before I could successfully start the game again. When diffing a version of Darkmod.cnf as it looks before I have changed the surround sound setting, and a version as it looks after I have changed the setting so that the game crashes, I see that the only difference is that the variable s_numberOfSpeakers is set to 8 in the version of the file that makes the game crash.
  25. All of a sudden I cannot save. When clicking the save game and assigning a name to it the the menu closes, but it doesn't actually save. Quicksave also brings no reaction. I tried starting a new game but it just won't save. What can be causing this?
×
×
  • Create New...