Search the Community

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.

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

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.

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 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!

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.

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?

Some more information after second session: Checking both colorModulate and colorAdd for NaN and resetting them if they are NaN seems to fix the issue. Fixing only one of these two parameters is not enough, although some glitches go away. The issue does not depend on gameplay modelling: timescale and g_stopTime does not stop or change flickering. The issue does not happen if one sets "r_useMultiDrawIndirect 0" on the new backend. The issue does not happen with "r_useMultiDrawIndirect 1" if I hardcode "maxBatchSize = 1" in DrawBatchExecutor::EnsureAvailableStorageInBuffers, but it happens if I hardcode "maxBatchSize = 2". Also, there is absolutely no possibility to put NaNs into the two considered uniforms in C++ code, only -1, 0, 1 values are set in all cases. But nobody can be totally sure that the complicated framework of new backend does not spoil the data somehow, or does not mess up the syncing. So the bottom line is: this issue is caused by "multi draw indirect" code path in the new backend, and only happens when you actually render several "draws" (at least 2) at once. UPDATE: Oh yeah, and the last point: 5. We did not manage to reproduce the problem on Debug With Inlines build, only on Release one. So I suppose it is timing-sensitive. Which means that it is hell even telling when it stops happening because it logically does not happen and when it stops happening simply because timings have changed. UPDATE: Of course, there is another possible reason for Debug vs Release difference. Perhaps we messed something up with memory (aka "undefined behavior"), and this only breaks things when several other factors contribute (like Windows 11 heap for example).

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.