Search the Community

I don't recall a system for noise masking. It sounds like it'd be a good idea, but when you get into the details you realize it'd be complicated to implement. It's not only noise that that goes into it, I think. E.g., a high register can cut through even a loud but low register rumble. And it's not like the .wav file even has data on the register of what it's playing. So either you have to add meta-data (which is insane), or you have to have a system to literally check pitch on the .wav data and paramaterize it in time to know when it's going to cut through what other parameters from other sounds. For that matter, it doesn't even have the data on the loudness either, so you'd have to get that off the file too and time the peaks with the "simultaneous" moment at arbitrary places in every other sound file correctly. And then position is going to matter independently for each AI. So it's not like you can have one computation that works the same for all AI. You'd have to compute the masking level for each one, and then you get into the expense you're mentioning. I know there was a long discussion about it in the internal forums, and probably on the public subforums too, but it's been so long ago now I can't even remember the gist of them. Anyway the main issue is I don't know if you'll find a champion that wants to work on it. But if you're really curious to see how it might work, you could always try your hand at coding & implementing it. Nothing beats a good demo to test an idea in action. And there's no better way to learn how to code than a little project like that. I always encourage people to try to implement an idea they have, whether or not it may be a good idea, just because it shows the power of an open source game. We fans can try anything we want and see if it works!

Hey, Every time I've try to use the Full Editor when PM'ing someone, and every single time I get an error. Whoever is in charge of the forum, is it possible that this could be fixed? Thanks Neon

This is expected, the peek begins from the door center and goes outwards 90° from the door surface. The player view angles are only used to determine whether the peek goes forwards or backwards ("flipped"). So this suggests there's a problem with how either peekVector and/or playerViewVector get calculated. playerViewVector is much simpler and uses premade functions, so it's more likely the peekVector is at fault. You'll need to place debug lines to check the variables that are involved in its calculation, starting with "dimensions". Every time a variable gets changed you need to print its new value.

Yeah, I wrote these debug lines so that the script tells you what it's calculating. Please read the console output to check that the values are as expected:

Yeah, it looks like that line was deleted. It should be rotated before it gets normalized. In any case, the script isnt done yet. So far you know the center of the door and the direction you need to peek into. At this point it'd be wise to check the console output of the debug lines (sys.println...) to make sure the script is doing what you expect it to before adding more to the script. If you look into the direction you'd expect the peek to go, is: 1) peekVector and playerViewVector almost the same? 2) delta and magnitude of delta almost 0? 3) peekVector doesn't get flipped? Repeat with various other player view directions. Regarding the current end of the script, you can't use angToForward on peekVector because it's already a vector, not angles. You'll have to multiply the peekVector by half the door thickness (smallest component of "dimension") and add that to the door center so that the peekOrigin is on the surface of the door, not inside. Then you need to convert the peekVector to peekAngles and make $player1 look in that direction during the peek. Note that in DoomScript vectors and angles are both treated as "vector" variables.

No. The Aeden's staff optional objective is the hardest of the game. To point out directions here, though, is getting into an area of heavy-duty spoilers ... so I'm constrained in my response just as I was constrained in my responses to the "endless keyhunt" complaints because to show the rather simple direction would be a huge spoiler. So I had to bite my tongue and take it. Aeden's staff is different, though - harder. I've never tried a no-KO ghost playthrough. Because I'm clumsy and have slow reflexes. I think it might be possible to do a stealth no-alerts playthrough. Are you allowed to KO? I think I've gotten the staff a few times in my playthroughs without alerting the builders in that room. The only switchable lights in the FM are table lamps. The cylindrical style wall lamps aren't extinguishable. The other fire and gas wall lamps are extinguished by water. In the Ox all waiters and commoners in the common room and outside are friendlies - except for the waitress in the upper lounge which is filled with enemies. You need water arrows. Moss arrows. Rope arrows. I've never used a gas arrow in a playthrough of the FM but one would make things easier, for sure. I'm going to replay the area and check through the locations that you mentioned - the loop etc. - then if it's OK with you I'll PM you with some info, tho' I'll ask you if you want the info first. So's not to spoil it for others who get that far in the game (few and far between!). I find it almost impossible not to click the "reveal spoiler" tags and read the info ... and, y'know, spoilers do spoil the real deal.

I don't think this is going to let you use traces: the door surface may be uneven, so that the detected surface normal is different from the actual door surface normal. Another possible flaw is hitting the frame or handle. Using the direction of the shortest side of the door as the peek direction should be more reliable, but it won't work if the door was created diagonally. I think that's rare, though. Regarding what you've written so far, it looks good. I'd suggest adding comments to better indicate what's going on and changing some variable names: - "smallest" should be "dimensions" - "newVector" should be "peekVector". It can be created directly below "vector dimensions", then have either its x, y or z value changed to the corresponding value of "dimensions". For comparing orientations, one approach that should work is to convert the difference into a normalized vector and get its magnitude from 0 to 1, where 0 means no difference (same direction), 1 should mean maximum difference (opposite direction, 180° turn) and 0.5 should mean half difference (90° turn). You will actually need to keep peekVector as a vector and convert the player view angles into a forward vector with angToForward, input the difference into vecNormalize and use vecLength to get the magnitude of the normalized vector. When working with such calculations it's wise to insert debug lines like below so that you know what your script is doing and what numbers it's working with: sys.println( "peekVector is now: " + peekVector );

Better debug the test map with only func_static-s with "gui" spawnarg, find why the issue is happening, and fix the root cause

Wow, revisiting this thread… 2.5 years. Here are two Dockerfiles that build thedarkmod.x64. One for trunk, one for 2.10. An example of how to use for anyone who's interested: tag=tdm-docker:2.10 dockerfile=Dockerfile.2.10 docker build -t $tag -f ./$dockerfile . container=`docker run -d $tag` docker cp $container:/tdm/build/thedarkmod.x64.debug ./ docker rm -f $container My newest iteration is Dockerfile.ub2204.2.10 and that fixes the problem with linking as the last step in building against trunk. (I failed to carefully read COMPILING.txt and refer to the wiki). Dockerfile.svn Dockerfile.2.10 Dockerfile.ub2204.2.10

This is the new part in 2.11. This was always the case. The engine composes a virtual filesystem with a list of search paths. In fact, even if I wanted to load the file which is overridden, I simply could not do that: the two files have same path, and using it always yields the same file. Yes, it was always the case. And then FM takes precedence over core, and among them ordinary directories take precedence over pk4 (if I recall correctly). This was the case in 2.10. Right now you just get an error if there is such kind of conflict. Frankly speaking, why do you even want to silently have same decl in several files? How are you going to debug this? Just guessing that your decl does not work as intended because probably it is duplicated somewhere and running a search over all files in directories / pk4 files?

I'm using the version from kcghost. I just tested and I can't see any difference inside the inventory. On the stats itself it doesn't show the different loot types (still seen in the inventory), but instead gives more info on stealth score. Edit: I see Dragofer made an updated version of his script. I have to check that out. Edit2: That version works: https://forums.thedarkmod.com/applications/core/interface/file/attachment.php?id=21272&key=02755164a3bed10498683771fe9a0453

Regarding scissors: it will be fixed in 6099, but after 2.11. If you see some other problems (aside from cut headtops), you can leave a comment there. Regarding bindless textures, I hope they'll never be restored. Because in OpenGL they are completely unmanageable: you cannot debug it in any tool, and any error can crash the whole application (or driver). I've heard in Vulkan they did it in less barbaric way, so the their bindless textures are handled by various tools. Also you understand multidraw incorrectly. Rendering several copies of same geometry is called "instancing", and can only help when you know objects are the same... which is pretty rare I guess.

The ability to launch and control TDM from DarkRadiant via the Game Connection interface is very helpful. But at least on Linux (Manjaro / KDE Plasma in my case) it continues to be bugged by crashes and only work intermittently, and last night it suddenly stopped working for good. Hoping we can debug what must be happening before the next release. DR is 3.7.0 (Git commit d9145c3015d945014daeb829f22d8cdb94a2aa8f) while TDM is dev16650-10157. DR successfully contacts the engine each time and attempts to start it up, I can even see the mouse cursor temporarily disappear and the process briefly present in the system monitor. The issue is when the darkmod executable is launched by Radiant, it often crashes immediately after. This might thus be a problem in the TDM engine more than in DR. I'm dealing with two types of crashes so far: Until now it was a cooldown effect, I can't start TDM from DR more often than once every 3 or so minutes. If start it up too frequently I see a brief flash of the screen but the main menu doesn't get to open, about 10 seconds later DR gives me the error "Timeout when connecting to just started TheDarkMod process". I have no idea where the information on how frequently I'm starting it is even stored: I can shut down both DR and TDM to ensure neither have open processes running, yet even if I start DR up again and launch TDM from the Game Connection menu too soon it remembers and throws this error. Since yesterday on top of that, the process now permanently fails with another error. In its case I even see the main menu for a split second before TDM instantly closes. DR throws the error "Game restart failed: Connection lost unexpectedly". I even tried with fresh settings for both DR and TDM as well as restarting the machine, but despite not updating anything not even any new OS package updates nor changing firewall settings, this suddenly appeared and continues to occur.

@MirceaKitsune Here's how I compile on Pop OS 22.04 (Ubuntu 22.04). Something to compare against. Maybe it will help? $ sudo apt install \ udev \ build-essential \ cmake \ libsdl2-dev \ libopenal-dev \ libvorbis-dev \ mesa-common-dev \ libxxf86vm-dev \ libxext-dev $ cd ~/code $ ls darkmod_src/ $ mkdir build darkmod $ ls build/ darkmod/ darkmod_src/ $ cd build $ cmake -DCMAKE_BUILD_TYPE='Release' ../darkmod_src $ make -j$(nproc) $ cd ../darkmod $ ls glprogs/ thedarkmod.x64 thedarkmod.x64.debug To clean: rm -r build darkmod

Strange: With 10211 SVN engine I'm getting extremely low FPS all of a sudden, 20 FPS where I normally had 80 FPS. TDM 2.11 Beta 2 engine doesn't do it so it must be the new changes. It's not the debug engine, running thedarkmod.x64. Not shadow samples this time either, does it with both maps / stencil and soft shadows disabled. No improvement if I use a fresh Darkmod.conf or remove the generated glprogs directory.

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!