Search the Community

https://github.com/HansKristian-Work/vkd3d-proton/tags <- directx 12 wrapper for dxvk https://github.com/doitsujin/dxvk/tags <- directx to vulkan wrappers D3D 9 to 11 eg. dxvk if you want to try it with horizon zero dawn you need to copy out dxcompiler.dll from Tools\ShaderCompiler\PC\1.0.2595\x64 and bink2w64.dll from Tools\bin and place them next to HorizonZeroDawn.exe. then copy over dxgi.dll from dxvk and d3d12.dll from vkd3d and place them next to it to. now fire up the game and let the shaders recompile -> profit.

I think the reason the dev forums exist is to provide a place where the implementation of features can be discussed without getting mixed up with other debates when someone believes what the devs are doing is wrong. We often post public discussion threads for features with subjective elements like the frob outline, because community feedback is very important. But there will always be vocal defenders with strong views for or against certain features, or how exactly it should be implemented in their opinion. At some point a decision has to be made and be carried through, which is what the dev forums are for. Almost all of the threads are very technical, basically explaining and discussing recent or potential code changes with other devs. Its hard to say. Its a hobby the devs do in their spare time, so people come and go when they're in the mood and when they have the time. The team page is mostly accurate except for some relatively newer additions like myself.

I just found this thread on ttlg listing Immersive Sims: https://www.ttlg.com/forums/showthread.php?t=151176

Yes, but unfortunately I often lose debug settings either after config wipe of because I was checking performance and thought that debug context might affect it (although I'm not sure debug context has any performance consequences). I hope you see these messages on 2.09a or latest dev build, but not on the latest code SVN?

@stgatilov I've updated to 2.11 final and the issue is still there. How can I debug this issue?

The build succeeds now with the latest. Yea! However, evidently the directory structure is not quite right for debug to work. I followed what the compile guide said (I think), with these 2 directories: ...Games/tdm11dev/darkmod_src/trunk/TheDarkMod.sln (etc.) [using TortoiseSVN] ...Games/tdm11dev/darkmod/TheDarkModx64.exe (& all the .pk4s, etc) [using tdm_installer] It appears that the build process puts the results in ...Games/tdm11dev/darkmod_src/darkmod/ I tried changing adding a "." to the project output location to move the directory up one, i.e., DarkModTools property sheet, for the debug x64 configuration: Configuration Properties; General; Output Directory [changed from] $(SolutionDir)..\darkmod\ [to] $(SolutionDir)...\darkmod\ But that seemed to generate build errors subsequently, so reverted. I can probably munge this up so it works, but thought I'd ask your suggestions first.

Recently revisiting the forums after a longer period of time I wanted to check the unread content. I don't know if I am doing this wrong since.. ever... but on mobile (visiting the unread content page on my smartphone) you have to click on that tiny speech bubble to go to the most recent post in a thread. If you don't click correctly you'll hit the headline and end up at post 1 in the beginning of the thread. It's terrible on mobile, since not only the speech bubble is really small and was to miss. But also the thread headline is just millimeters away from it so you go right to the first post that was ever made instead of the most recent ones. Am I doing it wrong? I just want to go through u read content a d the to the newest post from that topic.

Are you running a debug build? I don't get notifications in console for AI sustained damage.

I guess I can do that. Note: This code is not complete. I'm not sure if this patch will apply correctly these days, since it's based on an old revision. There are my debug print statements in this work-in-progress patch that should be removed if it was complete. There's a cvar used for tracking whether or not the main menu is open. I didn't like this and wanted to find an alternative. There's this block of code used to identify readables, etc. I wanted to find a more explicit way of identification. guiFileStr.find("invgrid") != std::string::npos || guiFileStr.find("objectives") != std::string::npos || guiFileStr.find("map") != std::string::npos || guiFileStr.find("readable") != std::string::npos; Again, I got better luck just editing the image files themselves. But maybe there's something good in the patch that can be salvaged for later. Attaching here for you @datiswous and others who are curious. wip-ui-brightness.diff

A@datiswous Ah yeah, well sorry, I was quiet busy and only visiting discord. First time here on the forums since months now I think.. Thank you for the subtitles. I encourage everyone who is interested in using them to download it from here as I'm not sure when I'll be able to implement them myself into the mission. Again, thank you for your work.

For a particular reason yes, it probably can be added, but "for some reason"?... What exactly is the typical problem? Syntax errors of .srt of .subs files not reported? The engine has debug command com_showSoundDecoders, which displays all currently playing sounds on screen. It should be easy to add a small tag here showing which sounds have subtitles and which not.

I must admit I'm rather nooby in Linux development I looked into the dump, but could not get meaningful stack traces. It seems that TDM is killed by SIGABRT, and it seems that core dump contains state after handling the signal. This is quite strange because manuals say that gdb breaks on it by default. Maybe you could try again, but please execute "handle SIGABRT stop" in gdb before executing "run" ? Another approach is to get stack trace on your machine. Download debug symbols: get and unpack thedarkmod.x64.debug, put it just near thedarkmod.x64. Then run gdb ./thedarkmod.x64: you should see a message like this: Reading symbols from /mnt/hgfs/thedarkmod/darkmod_209/thedarkmod.x64.debug...done. Then execute "run" and reproduce the crash. After then execute "bt" in gdb: it should print meaningful stack trace. You can also switch between threads using "info threads" and "thread 1" / "thread 2" / ..., but I hope it won't be necessary.

I was able to install, launch, and watch the opening videos of TDM 2.10 on a Pi 4b via Box86 by setting the environment variable MESA_GL_VERSION_OVERRIDE=3.3 first. However, it froze after a frame or two of gameplay. I haven't tried to debug that yet. Note that TDM 2.08 and earlier use GL3.1+extensions (but still probably require 3.3-compliant hardware unless you're up for some hacking) and 1.08 and earlier are judt Doom 3 mods (but incompatible with Dhewm3).

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!

Ignoring is somewhat inadequate as you still see other members engaging in a discussion with the problematic user, and as Wellingtoncrab says such discussions displace all other content within that channel. Moderation is also imperfect as being unpleasant to engage with is not in itself banworthy, so there is nothing more to do if such people return to their old behaviour after a moderator had a talk with them, except live with it or move away. I'd be more willing to deal with it if it felt like there were more on-topic discussion, i.e. thoughts about recently played fan missions or mappers showcasing their progress, rather than a stream of consciousness about a meta topic that may or not have to do with TDM. I guess the forums already serve the desired purpose, or they just compartmentalise discussions better.

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.

My bet is NO But nobody tried to measure it yet. There is no need to disable debug information in full release build. In fact, it must be retained if you want to analyze crash/core dumps from users. There are many options affecting debug performance in Visual Studio: https://dirtyhandscoding.github.io/posts/fast-debug-in-visual-c.html

I think it is a good idea! Our ingame mission downloader and mission view has long been subject of multiple improvement suggestions. Due to the sheer mass of missions that have been released in the last 15 years, things got really cluttered and especially newcomers will have a hard time finding what they want. However, improving the ingame guis is quite a task, so a web-based application might really suit this scenario well. Maybe we could even add a linke to it from our ingame menus, so user can access it quicker. Some more things to think about Would users be able to add custom tags and downvote / upvote certain tags, much like the system of Steam? This would also allow to add tags like "beautiful", or "difficult". Actually, the more users can contribute to this system, the better, because it will be automatically maintained then. The browser should also contain a flag for whether the FM belongs to a connected series of FMs or not and have the capability to go to the previous or next FM in that series. There should also be a flag for fully fledges campaigns. Some might like a flag whether or not an FM is "ghostable".