Search the Community

There is no download link yet, but either biker or myself will post one soon Whoops, I stand corrected. Biker already posted the link

I personally still feel it's now a lost cause without first getting clarification over the licence for the def and script files from the original Doom 3, which is why, until such clarification is officially made I'm not doing anything further towards it. I believe that while currently Microsoft may turn a blind eye to copy and pasted text from these files in TDM due to its' non-commercial nature, the moment it were to become Libre then the ability to use it commercially could lead to problems. However to answer your question (bearing in mind I have a very limited knowledge of Doom 3/TDM modding other than what I learnt attempting to get a compiled cut-down version running). In terms of the game scripts the following are the only non-GPL header game scripts and you can comment them out from being loaded in source code: tdm_grandfather_clock.script tdm_turret.script tdm_audiograph.script tdm_camgoyle.script tdm_safe_lock.script tdm_safe.script Also Grayman put the values as comments in code for these two files so they can be easily created: tdm_soundprop.def tdm_ai_base.def It would be easier to seek out Greebo and Springheel and ask them to GPL their work since that would open up all the base def files without the task of re-creating them. I suspect that it would take a very long time to recreate all the def files, also bear in mind that some functionality is copy/paste from Doom 3 eula protected files (func_static for example). As regards the work done by Grayman, that would always remain NC-BY, however access to the SVN commits would allow you to diff remove his non-GPL edits from the .def files. The UI function calls for TDM are all within the GPL source code, and as the UI is all a text based language it probably wouldn't take more than a couple of days to re-create a basic (though not pretty) UI. There are many comments within the source code relating to the UI string references, so a relatively complete UI string language file can be re-created as well.

Really? Quake 4 used megatexturing?! If that is true, afaik they never talked about it in the game promocional material. I always thought Quake Wars was the first idTech game to ever use them. Despite the feature existing hidden in the engine, since Doom 3. And yes in Doom 3, a single 8k terrain megatexture is a couple of gigabytes (thou today games are reaching 200+ GB already...). Also I wonder why JC didn't supported tga RLE compression feature for the MT, when the engine can already use it for basic textures, it wouldn't be as good as the later compression system they used but would still take out a few megas from the size. Perhaps the tga decompression, just took to long for the MT streaming feature?

hmm experimented with upping the limit to 16gb and it does work atleast untill i hit the ceiling with a texture bigger than 12 gb (my 2080 ti only has 11gb). the biggest concern is loading time which quadruples and in some instances even hits 8 times slower loading . is this one of the reasons besides avoiding loading screens that modern engines adopted streaming ?. while pretty annoying with the long loading times it sure as hell is visible in the detail level wow!. so the question would be if it would be feasible with a setting which would allow upping texture memory instead of the static define it uses now ?. theres also the problem with the engine only supporting power of two texture sizes (there is texture loader code that allows using any texture dimension but i wonder what the backside is).

Double topic. See also topic: https://forums.thedarkmod.com/index.php?/topic/22754-thief-vr-legacy-of-shadow-announcement/

i am having a hard time searching for specific keyword in bug tracker so i decided to wade into google search and found similar thread with similar issue : https://forums.thedarkmod.com/index.php?/topic/13723-key-drop-melee-animation-glitch/

I edited my video description, I included a link to your bug report post for training missions as well

I wish all the cult classic franchises were never released as VR exclusives, because it's pretty much like a spit in the face of all the fans of such games, especially if they didn't have sequels for a long time. I had the same feeling when they released Medal of Honor: Above and Beyond and though I didn't care about HL: Alyx but I'm sure other people also felt betrayed when it was released.

Ooooof, I missed this post before I tossed up an announcement thread of my own. Yeah, I'm pretty excited. Totally not what I expected on my bingo card for today.

The system requirements are vague as hell on the Steam page. But releasing this year is nice, so hoping for more details before too long. I just want to hear more Stephen Russell! A level editor would be cool, but I’m not holding my breath.

There are multiple mappers and active users using Linux. You want less missions? Also: Windows costs money. You ask people to buy Windows for a backup pc, while TDM is in fact multiplatform. I don't know how long tdm is multiplatform, but it must be a while. Listen Valve, Wesp says: Linux gamers are not normal gamers. Why is this relevant?

From an earlier post:

Just to complicate your life, there are 3 additional aspects to consider about the circa-2014 Mason files, and subsequent circa-2017 improvements to the 'english' version perhaps applicable to your work. (These issues are covered in the wiki "Mason Font" article, with a bit more in my "Analysis of 2.12 TDM Fonts", https://forums.thedarkmod.com/index.php?/topic/22427-analysis-of-212-tdm-fonts/. The 2017 changes can be seen in the *current* 2.13 TDM English Mason files.) 1) Need for custom DAT-scaling on certain Mason characters The source TTF had upper-case and lower-case characters that were early-on considered too similar to size. So (before 2014) in the DAT, selective per-character scaling was used to differentiate them. See https://wiki.thedarkmod.com/index.php?title=Font_Metrics_%26_DAT_File_Format#Per-Character_Font_Scaling for details. As you add new characters, you should do likewise (relatively easy with refont). 2) Creating the "glow" of mason_glow How Tels created the glow (for 'english' carleton & mason) is discussed in reasonable detail here: https://forums.thedarkmod.com/index.php?/topic/12863-translating-the-tdm-gui/page/5/#findComment-262661 That could be done for Russian too, which I recall currently fakes a glow, and possibly would require a minor GUI or engine code change to use. Note: To best accommodate glow and retain GIMP-visualization-alignment between base and glow characters, Tels moved some base characters within their bitmap, to keep their glyphs 2-3 pixels away from any bitmap edge. You should consider this when placing new base glyphs. Note: For the 3 mason bitmaps doubled in size circa-2017 as discussed next, the mason_glow bitmaps were also doubled. 3) Extensive bitmap editing to solve main menu character jaggedness. On Oct. 5, 2017, @Springheel in https://forums.thedarkmod.com/index.php?/topic/19129-menu-update/#findComment-412921 said: "Looking at the Mason fonts, it looks like they were super low res to begin with, and were then just resized [presumably referring to per-character scaling], making them even worse. I'll see what I can do." [Further on, referring to fonts in the TDM menu system:] "It appears that resizing the dds file to make it higher res is possible, so I'll proceed." Later, on Oct 13, 2017, he concluded within a "More detailed list of changes: "Updated the menu fonts, which were surprisingly bad before" Unfortunately, I couldn't find details on how this work was actually done. I assume the bitmap editing was all done in GIMP. It started with doubling the size of certain bitmaps from 256x256 to 512x512. This was done for the first 3 bitmaps (i.e., those with ASCII, some Latin-1). Then characters were made more crisp and smooth-edged. How? Dunno. Also, some odd but harmless artifacts happened within GIMP (noted in https://forums.thedarkmod.com/index.php?/topic/22427-analysis-of-212-tdm-fonts/page/3/#findComment-499660)

I'm afraid it doesn't work that way. If agent A publishes a work W under a license L1 that allows agent B to build on the work as long as B publishes the derivative work under L1, then if A later decide to also offer W under another licence L2 (with similar stipulations about publishing derivative works under L2) then B can choose if their additions to W should be licenced under L1 or L2 or both. However, if the scrips in question were released as GPL then it would significantly reduce the risk of publishing derivative works based on them.

The proposal for a TDM libre is not about inclusion in a specific repository, or publication. I provided two just as examples. My hypothesis is this: A TDM libre will cater to a different audience than TDM regular. If a TDM libre can be provided in addition to TDM regular then the reach will be greater and the total audience will be larger. A larger audience will drive recruitment of contributors, to both versions. More contributors will drive quantity and quality of content, which in turn will further increase reach and audience in a positive spiral. As I understand it, if a software is included in a libre project (e.g. Debian), and they fix a defect in it that one of their users reported to them (because it is part of their distro), they will provide patches upstream to us which will then benefit all users, regardless of operating system. All contributions to TDM libre can be added to TDM regular. I also see TDM libre as a product associated with lower risks long term.

Any time you can spare would be greatly appreciated. Thank you both. I've created a post with more detailed information in the Beta Testing forum here:

May I ask why a libre version is necessary in the first place? Right now TDM already is a free standalone game. According to the first post the advantage would only be to add it to some repositories that I never even heard before. Would this be worth the effort?

Or, just get in contact with the owners of the IP and ask them since just because an IP lawyer in one jurisdiction says it would be okay, doesn't mean it would be okay globally. There are several packs out there of scripts/definition files which are licenced under free licences (CC0 and WTFPL mostly) and claim their freedom by recreating them using "clean-room way". In fact, I used them in getting TDM running with mostly free licenced files by selectively choosing which had clearly been written from scratch albeit with reference to the originals, and which were just direct copy and paste with claimed free licences (I didn't use them). Then it was a case of finding/replacing the core engine textures, sounds, etc. the engine required to launch with free alternatives (again checking the packs since some were just copied direct from the game files and claiming to be free). In the end, the only non-free licenced files that were still required were those from TDM itself. The result of this TDM version is the screenshot I posted some posts ago here: https://forums.thedarkmod.com/index.php?/topic/22346-libre-version-of-tdm/page/3/#findComment-500642 However, you will notice the giant cursor on the screen in the screenshot, why? because the only reference to hiding the cursor is within the UI files which come under the game eula, so I didn't add in the command to hide it in game. In the case of the script/def files, this "clean-room" approach has stood up in a court of law when I looked online, however you wouldn't really want to end up being in the position of ending up in court defending yourself in the first place. The flaw in the def/scripts that were recreated are that they all wrote their files using the originals as reference. So if the originals are under the game eula, and if the information contained is in some way protected, then all these "clean-room" files revert to the original game eula, as the authors didn't have the right to change the licence. I believe (with a pinch of salt )that if the core scripts/files were made GPL by idSoftware/Microsoft then as files based off of or using them as parents (basically all TDM scripts/defs as far as I can make out) then all of the TDM scripts and def files would automatically become GPL as their authors could also not claim their work was NC-BY since it was then based on GPL work.

Sad, but thanks for trying! I appreciate it! Would it be feasible to re-write them? I don't see why the original files can't be used as references (and stubs) during such a work. As long as they are not outright copied.

Ya I saw that state class and wasn't sure what exactly the canonical way to interact with it was. I imagine there must be a better way - maybe dynamic_pointer_cast<BlindState>(GetMind()->GetState()); would be a better check? But I figured that was best left to the dev who ends up having to compile and implement the change. I wrote it that way just to illustrate the point. If I end up drafting the actual PR instead of just a forum post, I'll try to do better than string comparison haha - or at least extract the magic string from the class instead of just hard coding it in to the AI code. Not sure about the animation loop or the timer, but the bizarre hit detection is probably caused somewhere in https://github.com/stgatilov/darkmod_src/blob/trunk/game/ai/States/State.cpp#L489-L515 . In TDM, it looks like instead of dropping a flashbomb near-ish the AI, you have to drop it inside their vision cone in order for it to be effective, and they also have to pass a line of sight check to the bomb. That... might be too finicky or elaborate for the gameplay purpose of the flashbomb? Maybe it should be simplified to a radius or have more generous vision checks or something - there appears to be an else branch trying to do this in some cases. Or maybe there's a subtle math bug in one of those FOV checks or something?

Regarding the existing Russian version of TDM's MasonAlternative font, this had a different origin than those Russian fonts processed by Riff_Keeper. Tels created this in 2012. He started from bitmaps of an ASCII Mason font, then used his Perl patch program to copy selected ASCII glyphs (that resemble in some way Cyrillic) to new font "MasonAlternative". See https://forums.thedarkmod.com/index.php?/topic/12863-translating-the-tdm-gui/page/15/#findComment-274617 In GIMP, he flipped or otherwise hand-edited to make them Cyrillic. He said, "There are still a few dozen missing, but this is enough to render the two headlines we have (New Mission and Setting)" https://forums.thedarkmod.com/index.php?/topic/12863-translating-the-tdm-gui/page/15/#findComment-274623 This accounts for the incomplete coverage. Speculatively, he took this approach because it couldn't find a Mason-style TTF font with both Russian characters and an acceptable license (e.g., public domain, or at the least freely redistributable for non-commercial use). @kalinovka,I wonder what the licensing is for your masonchronicles3.ttf.

Evidently a significant portion of the Cyrillic work was done by Keeper_Riff (in conjunction with Tels) back in 2011. These folks are not active in TDM these days. Keeper_Riff outlined a workflow, starting with FontLab to edit TTF files... https://forums.thedarkmod.com/index.php?/topic/12863-translating-the-tdm-gui/page/12/#findComment-271548 Specifically Carleton: https://forums.thedarkmod.com/index.php?/topic/12863-translating-the-tdm-gui/page/4/#findComment-262135

@kalinovka, I'm assuming your TTF font codepoints are those of Unicode. A conversion to Win1251 would use this map: https://www.unicode.org/Public/MAPPINGS/VENDORS/MICSFT/WINDOWS/CP1251.TXT The lower 128 are just ASCII, where Unicode and Win1251 use the same number. The upper 128 contain both the 90 codepoints you mentioned (starting with 1025 aka 0x0401), interposed with other characters. A proper rendering for TDM would include all these characters. It is possible that some old-school font editor already has an export profile for Win1251. As for hacking up a variant of ExportFontDoom3All256, you'd need to write a static array, holding Unicode values from CP1251.TXT. You could just do the upper 128 if you want, as shown next. Example: const static unsigned long UnicodeFor1251::array[] = { 0x0402, // 0x80 CYRILLIC CAPITAL LETTER DJE 0x0403, // 0x81 CYRILLIC CAPITAL LETTER GJE ... // more tedious or fancy editing here } Then the code loop would be something like [NOT TESTED]: // Export all characters. unsigned long sourceCharacterCode; for (int outputCharacterCode = 0; outputCharacterCode < Font::numCharactersToExport; outputCharacterCode++) { if(outputCharacterCode < 128) sourceCharacterCode = outputCharacterCode; else sourceCharacterCode = UnicodeFor1251[outputCharacterCode - 128]; bool okay = exportCharacter(sourceCharacterCode, outputCharacterCode); if (!okay) { std::cerr << "Error: Unable to export character " << getCharacterCodeString(characterCode) << "." << std::endl; return false; } } ... Further down in FontExporter.cpp, more changes... bool FontExporter::exportCharacter(unsigned long sourceCharacterCode, outputCharacterCode) // WAS single parameter characterCode { Doom3GlyphDescriptor* doom3GlyphDescriptor = 0; // Get the index of the glyph that represents this character. int glyphIndex = self.font->getGlyphIndexForCharacterCode(sourceCharacterCode); // WAS characterCode ... // Create a descriptor for the current glyph. doom3GlyphDescriptor = &self.doom3GlyphDescriptors[outputCharacterCode]; // WAS characterCode ... } After a successul export, there's still lots more testing and tweaking to be done, e.g., with datBounds, refont, if you want best character spacing and presentation. Also, TDM treats codepoint 0xFF specially, as mentioned in https://wiki.thedarkmod.com/index.php?title=I18N_-_Charset

Nvidia could have designed their low-end die (GB206 is used in both the 5060 and 5060 Ti) to have a higher maximum bus width, e.g. 192-bit for 12 GB or 160-bit for 10 GB. But the trivial thing for them to do would be to use the 3 GB (24 Gb) GDDR7 modules to reach 12 GB on 128-bit. These are already available (used in 5090 Laptop) but could be in short supply. The way to handle that is to simply delay the release of 60-class cards, and Nvidia is no stranger to releasing the top SKUs long before the bottom SKUs. I think there would be no problem with having 12 GB 5060 and 12/16 GB 5060 Ti options, but the upsell/scamming potential is worse for Nvidia in that scenario. As it stands, leakers have repeatedly pointed to the release of 5080 Super 24 GB and 5070 Super 18 GB cards using 3 GB GDDR7 sometime in the future. Nothing below that is confirmed. Intel Arc B770 reportedly still set for release, expected in the fourth quarter of the year

Oh shoot, this post fell under the radar, sorry @BenJ. I can take a look at this issue, but can you replicate it? Mind offering up a few more details? It would also be good to know if you are playing with any additional mods or add-ons