stgatilov

You need to pass +set com_allowConsole 1 as command line parameter. You can create shortcut of batch/shell file for that. Changelog is at the top of this thread, as usual.

Ok, it seems that while using EXE as DLL is possible, some pretty artificial issues make this path very hacky: https://www.codeproject.com/Articles/1045674/Load-EXE-as-DLL-Mission-Possible And adding optional build with DLLs but deploying fully static build would mean that you'll have to distribute this DLL yourself, i.e. you cannot load this DLL from user's TDM installation.

One of the problems with DLL-based build is having to use dynamic CRT (recall the nightmare of two separate CRTs when Doom 3 was closed source). In this case we have to do one of: Put CRT dlls into game directory. This was not an option before 32-bit deprecation because it did not allow 32-bit and 64-bit executables to coexist in the same directory. And changing paths conventions in TDM is something I'd better not attempt Run VCRedist installer on player's machine. I tried doing that but it did not work well... Maybe because I wanted to avoid running the installer when it's already installed, and I did not manage to properly check if compatible version is installed. Anyway, there were a lot of complaints about this thing, so I simply returned full-static build. Maybe it is possible to have an option (CMake-only) to build something dynamic, but that option would probably get broken regularly, because everyone would forget about it. Yes, it makes sense to keep interface pure-C. You won't be able to dynamically load exported C++ function because of name mangling anyway. But are you sure you will be able to expose much stuff without using complex types? By the way, it is not necessary to create any kind of DLL to do that. In principle, DarkRadiant can import the EXE file as module and use its exported functions! After all, entry point is the only difference between DLL and EXE. Of course, doing so would mean mapping 18 MB file onto DR's virtual memory, but I don't think it is a big problem (well, maybe code cache would suffer because relevant TDM functions would be less localized). Running dmap is now available with the "game connection" feature. Of course, it is more messy and fragile than DLL call, but "game connection" needs to exist anyway (and dmapping in game connection is a bit faster). Ehm... To be honest... we discussed that we should probably reimplement most of this system But I agree that it would be very hard to force myself doing that It seems that writing English full-text in translation files instead of relying on these #str_XXX keywords would be more comfortable for mappers in 99% of the cases, and additional "labels" added to the original text would resolve ambiguity in the rest 1%.

I think dmap uses materials/decls/images only because materials are assigned to geometry. In fact, it does not need actual images, it only needs material flags to determine if material is opaque or not. Of course, you will have to drag along the whole idlib, and probably all the common/sys classes as well: idList-s are now all over the place, and various common->Printf/Warning are used a lot too. By the way, recently I merged idlib code into TDM project... and most likely it has to be extracted back in order to be used in DarkRadiant. On the other hand, won't moving dmap to DarkRadiant cause more problems than if would solve? For instance, dmap sometimes is changed. One such change during 2.08 was quite breaking. Dmap from TDM is not compatible with dmap from Doom 3 and vice versa (a map which compiles on one game can fail with leak on the other one). How would mappers understand which version they use? What if dmap changes are tied to the changes in the rest of the game? Extracting renderer frontend would be much harder I suppose. Without it, you can just read .proc files and implement your own areas/portals pruning code.

Created and fixed: 5928 After inspecting this savegame and finding the most likely cause, I found a reliable way to reproduce it. It only happens if you load the game in a fresh TDM process, and if you saved game while holding/stringing the bow. Hopefully, this won't happen in future dev builds and in 2.11. Also, there is a minor probability that this change will fix crashes too, if they happened due to thread-unsafety of cvars system.

Putting a kid into luggage indeed saves from a lot of headache Maybe I'll ask someone to ship my PC to me, but this is rather unlikely.

dev16481-9881 is available. There are two reasons for this dev build: major update of compiler and third parties releasing all the changes which happened during 2.10 beta but did not get into release

Relocation. The only way to take the desktop PC is to take it along with me on the flight (as luggage), but I'm pretty sure there would be a lot of other things to carry.

Did you mean discrete graphics card?

Post the savefile. Of course, that would only help if it is reproducible from a clean TDM run. UPDATE: Also, you can record crashdump, upload it somewhere, and share the link.

I will probably have to get rid of my desktop PC, and I'm worried about how to work on TDM without it. Obviously, I need a laptop, but: Laptops without discrete GPU will probably run TDM too slowly. Can anyone share positive experience about that? Laptops with discrete GPU (gaming laptops) are often unreliable. I'm worried that they die too quickly...

Sounds like a partly updated mirror?...

If someone is eager to improve dhewm3 by taking changes from TDM, I can review what I personally did, and provide a list of bugtracker issues and probably commits which are worth porting. But I won't spend my time on actually cherry-picking them. One issue is that goal of dhewm3 is preservation of Doom 3 game. I recall a few changes, which make perfect sense or fix plain bugs, but can actually break maps, and such changes probably won't fit dhewm3 at all.

Yes, resumable downloads are not implemented yet. The main problem is that if you kill tdm_installer with task manager, you will have corrupted data on disk. Trying to use this data on future run will cause unavoidable errors. Aside from that, I'm not sure these __download__XXX.pk4 files are valid zip archives when they are saved, which means that some more code has to be added to support loading them. And yes, leaving all these weird files after cancelled installation might confuse user too. I think the main problem here is that tdm_installer fails after downloading data. Normally, this should not happen unless mirrors are screwed, or you have software/hardware problems. And I think it happened very rarely in the past, but there were several reports of such errors lately. I could not reproduce the error, and thus far nobody has even shared a log file of such an error.

Someone should finally capture full memory dump at the moment of crash. Here are instructions on Windows: https://wiki.thedarkmod.com/index.php?title=Save_a_Memory_Dump_for_debugging_Crashes It is also possible on Linux, but we don't have description anywhere, and investigating such dumps is known to be painful sometimes... but it is indeed possible.

I played Cry of Fear, and it is great horror... in its own sense. It is scary in a very different way than e.g. Amnesia. And it is very tiresome to play... I could not play for long time without break, especially when I started. Jump scares are plenty, and probably the worst one is almost at the beginning As for Afraid of Monsters, I only watched someone playing it, and it looked very similar to old-style survival horrors in a bad way: you have no idea where to go and have no resources to survive, which becomes annoying after 10-20 deaths.

Glad you managed to fix that. If the error happens on the very first page during "Analyzing XXX", then removing the culprit file is the best thing to do. Replacing it with the same file from different installation is also OK.

Thank you for finding and testing this change! I have committed it at svn rev 9879.

Yes, this is known problem: 5852

I have updated my torrent file above with these trackers. I don't like your torrent file, since it shares a lot of unnecessary stuff, like already unpacked files, config files, zipsync directory, logs, etc.

I think headshot to unaware enemy kills instantly. If you hit another part or guard is already alert or he wears a face grill, then it won't work. Undead don't have any brain left, why would headshot do anything special? Basically, you should not try to "kill" undead.

If you update from 2.09 using tdm_installer, download should be at most 100 MB. You can see exact number in the page just before installation starts: it shows how much data is going to be downloaded.

This is OK for a forum FAQ, and has nothing to do with the game.

The tdm_installer mirrors are all different from this one. TDM does not create registry entries. I'm open for tracker suggestions. I believe it is not possible to have P2P sharing without tracker, at least I did not managed to do it.

It is not only technical issue, it is also an artistic one. The current visual style ("parchments") is spread across core files of main menu and custom GUI in missions (briefing, messages, etc.). If we change the core files to other visual style, that would result in inconsistent visual style in many missions. The end result would be uglier in general. That would be a terrible approach at the time when the training mission was started. For a native speaker, speech feels more natural, but for a non-native one, text is much easier to understand than speech. Of course, this is not an issue now with subtitles.