Search the Community

This is basically "do include my work ASAP because I worked so hard, or else *sulk*". This is similar case: https://forums.thedarkmod.com/index.php?/topic/21679-beta-testing-211/page/10/#comment-482352 This is neither a commercial product, nor a phishing email. That sense of rush and pressure is artificial. These releases typically do take long, and even then, there are often many things broken by mistake or omission. Often there aren't enough people to test stuff, or they're not competent enough, etc, etc. There's little point in hurry.

Looking at the source code and the core pk4 asset files, I don't see any changes that would make a difference. Does this happen with a single FM? Does the FM pk4 file include an "autoexec.cfg" file? From the source code, here's the load order of config files. exec default.cfg exec Darkmod.cfg exec DarkmodKeyboard.cfg exec DarkmodPadbinds.cfg ==> exec autoexec.cfg <load language> <exec command-line arguments> <init input> <init sound> <init OpenGL> <init ui> <load DLL> <init session> ==> exec autocommands.cfg Details about the addition of "autocommands.cfg" are at https://bugs.thedarkmod.com/view.php?id=3199 I thought "autocommands.cfg" was the right way to do it, because that is what I've read on the forums. It seems that "autocommands.cfg" was originally designed for one use case: running "dmap". However, maybe over time "autocommands.cfg" became the de facto config file for user commands and "autoexec.cfg" became the config file for FM authors to use. I don't know. Does anyone know for a fact whether or not this is the case?

Several team members have expressed interest into evaluating PBR but there is no hard target for any progress because it would be a lot of work. If someone wanted to take some existing TDM assets and convert them for use in Doom 3 BFG ( RBDoom3BFG ) so that they can be evaluated, it might speed up the initial phase work. ( Eg, make a small test map with all the basic visual components; AI models, wood, metal, water, glass (textures), and lighting ) We won't even ask for anyone to start this work until we have more commitment on the time-tables but we won't say no to any submission like this if someone is really motivated to get things going. Going back to my previous post, it seems there is a workflow to convert PBR to Specular: https://marmoset.co/posts/pbr-texture-conversion/ but I can't find any automation that does it.

Not sure what the license is but if the Nvidia Remix tool has textures with a creative commons license then someone could extract them and use the texture replace tool in Dark Radiant to update a mission with them. The textures are most likely using a modern PBR format with metalness and roughness, so without PBR support in TDM they would need to be converted to a diffuse \ specular design ( I believe there are tools that automate going from legacy to PBR but I am not sure whether any texture author tool can do the reverse? ) There is a long term plan to evaluate whether allowing mixed legacy and PBR content the way that the "RBDoom3BFG" Doom 3 port does might be viable in TDM. If it turns out to be viable, then TDM would be able to use these "remix" textures natively without conversion ( again, as long as they are open CC assets and can be exported ). As far as I can tell, Nvidia are locking down all remix aspects so that modders can only use it for Nvidia's intended purpose of upgrading old fixed-function games to RTX. They aren't interested in shader based games or DX9+ because the change to Ray Tracing won't be as dramatic. Anything using light-mapping with probes is going to get a negligible upgrade from changing the lighting model since lightmaps are already raytraced. They want really impressive before \ after pictures to sell the technology. Even TDM probably looks too good in the "before" state to be of interest to Nvidia. ( That said, I would gladly accept a ray tracing patch for TDM if Nvidia ever decided to create one for us... )

So I think we can count 12 or 14 missions depending on our opinion of La Banque Bienveillante and Sneak and Destroy. If these two reissues are counted as new missions (as JarlFrank did here: https://www.ttlg.com/forums/showthread.php?t=152035), then we have 14 missions. If not, then 12. Personally, I don't consider them new missions, so 12 in my opinion. Have no problem with other opinion. In any case, last year was productive!

My dream is for forums.thedarkmod.com to link to thedarkmod.com

Purah also worked on Dishonored: https://www.ttlg.com/forums/showthread.php?t=136214 One of my neurons knew it started with a 'P'

We got TDM VR, for a start. https://forums.thedarkmod.com/index.php?/topic/20468-the-dark-mod-vr-210-alpha-is-now-available/

Yes, it does. Which makes it interesting that you yourself explicitly said that it's interesting nobody had complained here on the official forums: I did, which is why it stood out to me so much that even though you yourself had personally been involved you would reply claiming nobody had complained here on the official forums. I'm not colorblind at all. Does that make people pointing out that almost no modern games have proper colorblindness support hyperbole? Just because it doesn't affect you, or you choose not to pay attention to the discussion of something, doesn't make it hyperbole. Pick pretty much any modern FPS and you will find plenty of discussion about the near universal disregard for FOV and camera movement as accessibility issues. Denigrating those as hyperbole because you personally don't feel the affects is as bad of a look as demeaning people who bring up the importance of valid allergen warnings like gluten or colorblindness and deafness support.

I literally registered just to point out that people HAVE been raising this as a serious accessibility issue since as far back as 2008. It's been repeatedly brought up over and over and over again. And that is just here on the official forums. If you really mean what you've said I think you should find it genuinely concerning that one of the single most widely discussed accessibility issues in gaming has been repeatedly brought up for over a decade with your game and apparently this is the first you've heard of it... even though it's even been subject to multiple issues in your issue tracking system according to these threads and other google results.

here use this link and never miss again its my startpage https://forums.thedarkmod.com/index.php?/discover

You can find a test map here. Note that I remember not being too happy with it. https://forums.thedarkmod.com/index.php?/topic/19825-negative-spectrum/&do=findComment&comment=432949

This "free game" had an outside audit done on it to help make sure that the total conversion from Doom 3 and all of its assets were legally protected. So there is definitely heightened sensitivity around these issues and they should not be dismissed out of hand. https://www.newmediarights.org/taxonomy/term/421

Thanks! Dishonored is definitely a influence for these. So far everything is being done in substance designer using a base material I made. All of the height information is generated directly in the material (no high poly baking/no photo conversion) and comes from combining alpha elements sourced from the public domain (https://publicdomainvectors.org/, https://www.rawpixel.com/category/53/public-domain, etc), generators within substance designer, or alpha textures I just made myself which substance designer can bevel and extrude.

DarkRadiant 3.7.0 is ready for download. What's new: Feature: Skin Editor Improvement: Script Window usability improvements Fixed: Hitting escape while autosaving crashes to desktop Fixed: Def parsing problem in tdm_playertools_lockpicks.def Fixed: DR hangs if selecting a lot of entities with entity list open Fixed: Float Property Editor's entry box is sticking around after selecting a float key Fixed: Spline entities without model spawnarg are unselectable Fixed: Entity window resets interior sizing forcing resize each time it is opened Fixed: Spline curves should not be created with a model spawnarg Fixed: Newly appended curve control vertices aren't shown at first Fixed: Light entities are zoomed out in preview window Fixed: Entity inspector spawnarg fields not always updated by UI windows such as Model Chooser Feature: Skin Editor (see video) Windows and Mac Downloads are available on Github: https://github.com/codereader/DarkRadiant/releases/tag/3.7.0 and of course linked from the website https://www.darkradiant.net Thanks to all the awesome people who keep using DarkRadiant to create Fan Missions - they are the main reason for me to keep going. Please report any bugs or feature requests here in these forums, following these guidelines: Bugs (including steps for reproduction) can go directly on the tracker. When unsure about a bug/issue, feel free to ask. If you run into a crash, please record a crashdump: Crashdump Instructions Feature requests should be suggested (and possibly discussed) here in these forums before they may be added to the tracker. The list of changes can be found on the our bugtracker changelog. Keep on mapping!

Would it be at all possible to do this from the "main" website? I mean the one you first see when you look up "Dark Mod". Cuz it is a maze in these forums, goodies strewn about here and there but few resources that are intuitively accessible. Also @SeriousToni, what are you planning on uploading?

Originally the mug was created by @LordSoth https://forums.thedarkmod.com/index.php?/topic/13257-tdm-beginners-contest/&do=findComment&comment=287897

It seems that there is a reverse engineer group ( Amernime \ Nimez ) who are back-porting newer AMD drivers to older GPU versions. Terrascale 1 support is currently a "work in progress" : https://forums.guru3d.com/threads/amernime-zone-amd-software-adrenalin-pro-driver-release-nemesis-22-10-3-whql.436611/ If you are interested, they might have beta versions up on their terrascale discord. The downside is that these are community created drivers rather than official ones by AMD. Maybe AMD will release some sort of maintenance for terascale like they did for some of their other old GPU's.

id Studio did a poor job in defining its categorization of variable nomenclature, so in subsequent documentation and discussions there are divergent views (or just slop). In my series, I had to choose something, and went with what I thought would be clearest for the GUI programmer: Properties, which are either Registers (like true variables) Non-registers (like tags) User Variables (also true variables) I see that your view is more along these lines (which perhaps reflects C++ internals?): Flags (like my non-registers) Properties, which are either Built-in (like my registers) Custom (like user Variables) Also, elsewhere, you refer to "registers" as temporaries. I am willing to consider that there could be temporary registers during expression evaluation, but by my interpretation those would be in addition to named property registers. I'm not sure where to go next with this particular aspect, but at least can state it.

DarkRadiant 3.6.0 is ready for download. What's new: Feature: Selection Focus (Ctrl-F) Feature: Add Radiant.findEntityByName script method Feature: Media Browser shows a thumbnail preview when selecting folders Feature: Map is remembering layer visibilities between loads Fixed: ModelDefs are shown in T-pose Fixed: Patch vertices are the wrong colour Fixed: Shader Clipboard source gets cleared on 'copy shader' operation Fixed: Nodes of hidden layers are still visible after loading the map Fixed: Can't close properties window Fixed: Merge Action rendering is broken Fixed: After using ToggleMainControl_Camera, the center panel is grey after restart Fixed: When using ToggleMainControl_Camera, arrow keys cannot be used to move the viewer Fixed: Property Panel not remembering undocked/closed tabs Fixed: Texture Tool not updating during manipulation Fixed: Orthoview ignores filters for surfaces in models Fixed: Blue dot when selecting one face removed Tweak: Conversation Editor: double-click opens selected conversation Tweak: Preference option to disable drag select in camera view Tweak: ESC key should clear the resource tree view filter text Tweak: New layers function: tooltip popup getting in the way Feature: Selection Focus (see video) Windows and Mac Downloads are available on Github: https://github.com/codereader/DarkRadiant/releases/tag/3.6.0 and of course linked from the website https://www.darkradiant.net Thanks to all the awesome people who keep using DarkRadiant to create Fan Missions - they are the main reason for me to keep going. Please report any bugs or feature requests here in these forums, following these guidelines: Bugs (including steps for reproduction) can go directly on the tracker. When unsure about a bug/issue, feel free to ask. If you run into a crash, please record a crashdump: Crashdump Instructions Feature requests should be suggested (and possibly discussed) here in these forums before they may be added to the tracker. The list of changes can be found on the our bugtracker changelog. Have fun mapping!

@stgatilov, you said, RE string comparisons: I'm unclear if you are referring just to changes you made in 2.11. I think equality testing of two strings (one of which is "text") was working and is a good and expected capability, and should be supported. Including against an empty string. I noticed in your bug activities that you did remove some comparisons with ... == "". I see you also removed string concatenation with "\". No problem, but does that mean multiline macros are no longer a thing? (If so, I'll need to change some examples) BTW, the series so far hasn't really tried to cover the 2.11 changes, since I figured it's a work in progress. But since you did a great deal of GUI work in July, perhaps it's stable enough to try to consider it. I see the logs listed in bugtracker, but don't have access to the private forum threads mentioned there: https://forums.thedarkmod.com/index.php?/topic/20526-gui-refactoring/&do=findComment&comment=477179 https://forums.thedarkmod.com/index.php?/topic/21535-order-of-evaluation-in-expressions-materials-and-gui/ (Nor do I have SVN currently set up on my newer machine, for changelogs from there.) Any place else I should look?

-> https://forums.thedarkmod.com/index.php?/forum/13-music-sfx/

I mentioned this in the improvements thread - https://forums.thedarkmod.com/index.php?/topic/11058-things-that-could-be-improved/page/95/#comment-473534 Bright readables in a game that is 99% darkness literally burns my eyes.

@HMart, you took issue with me saying: This was my summary of what I thought you meant in these post fragments from a forum linked to by Ref 10 (namely, https://forums.thedarkmod.com/index.php?/topic/20100-idtech-4-gui-scripting/#comment-439778 )... I see I probably shouldn't have added the "[as float parameters]" to the ambiguous "as well" phrase, and perhaps "recommended TDM try" is too strong. Overall, would this be better? "In Ref 10, it is noted that in transition statements, a 4-value color vector must be either a literal or (less reliably) a definevec4. Using a #defined macro for the color vector won't work currently... an idea for a future improvement?" EDIT - I see that a broader revision was needed. So changed to this in https://wiki.thedarkmod.com/index.php?title=GUI_Scripting:_TDM_vs_Doom_3,_Quake_4 ====transition 4-6 parameters==== Often, transition statements have a pair of 4-value color vectors as their 2nd & 3rd parameters. As the discussion in [[GUI Scripting: References & Resources | Ref 10]] indicates, each vector is traditionally represented by a double-quoted literal: transition "matcolor" "1, 1, 1, 0" "1, 1, 1, 0.8" "300" This was id Studio's preferred method, but using a definevec4 user variable was a possible alternative. In addition, TDM can #define colors for transitions. Unfortunately, due to syntax differences, for a particular color, it is not possible to create a single #define that would work with both properties and transitions; thus: #define INACTIVE_COLOR 0,0,0,0.50 #define SINACTIVE_COLOR "0 0 0 0.50" See [[GUI Scripting: Preprocessor Directives]] for further examples. (Possible future improvement: Changing TDM's parsing to let a transition also accept color vectors with commas.) See also the discussion above about 4vect properties and _x, _y, _z, _w suffixes.