Search the Community

Awesome! Post is up! https://forums.thedarkmod.com/index.php?/topic/22200-beta-testing-the-house-of-delisle/#comment-487365 Thanks!

Cheers. Initially I was thinking of this for lights... later thought to include animated models too, mesh deformation isn't that expensive so I can see why there's little benefit. Especially as I realized per-pixel lighting would still be recalculated each frame, specularity also depends on camera angle not just model movement... technically we could frameskip that too but I'm getting way ahead of myself for what would likely be a tiny benefit Could this still work for lights though? Recalculating shadows when something moves in radius of a light is a big cost, even if it's gotten much better with the latest changes. A shadow recalculation LOD may give a nice boost. We could test the benefit with an even simpler change: A setting to cap all shadow updates to a fixed FPS. This would probably be a few lines of code so if you can give me a pointer I may be able to modify my local engine clone to try it. If it offers a benefit it can be made distance-based later. Another way would be to make a light's number of samples slowly decrease with distance, the furthest lights dropping to just one sample like sharp / stencil shadows: Shadow samples also have a big impact. What do you think of this solution as a form of light LOD, maybe mixed with just a shadow update LOD? These actually sound like they make sense; If you think it's worth it I can post those two on the tracker so they're not forgotten.

Example—be able to add oil to arrows then set flame to them using any of the game's fire sources. Food needs, being hungry will reduce movement speed, and make bow aiming more wonky, and have less time to nock the arrow before tiring. Player can buy food before a mission or scavenge it from the map. Could also kill any small animals like rats and eat them raw (risking disease) or make fire to cook them. Player will need to harvest firewood or make use of in game stoves. Injuries: if player if takes a heavy blow in combat, have injuries such as limping, injured weapon hand makes sword swing weaker, and bow wonky. Player can heal by health potions, or injury would naturally heal over a significantly longer time. Sword can also be knocked out of the players hand, if so they are without weapon, they can pick up an enemies sword or craft a melee weapon.

I was just reading a post over on TTLG about Thirith's experience playing Sable when he realized the game played significantly more smoothly, and the movement control was less wonky, at 30 fps than 60 fps, and then I see your post explaining just that. Edit: I should have double checked the date. I didn't realize when I clicked the thread that it didn't take me to the latest page but evidently to the last point I had read up to, which was more than 2 months ago. Sorry about that. Well it's still an interesting thing to point out anyway.

I've never actually seen the insides of an elevator but from what I know about electronics in similar settings from a few friends who did some work in the field, my guess is that it's an ARM system on a chip and it's quite possible that it runs Linux. And it's highly likely that it's separated from a chip that's taking care of the actual elevator movement, so you probably couldn't use the buttons for input. The reason for this being that ARM SoCs able to run linux are really not that expensive nowadays, whereas developing custom systems outputting graphics with a cheaper weaker chip has a large upfront cost. And if you're using a universal OS like Linux, you can keep the software side the same if the ARM chip you're using goes out of production and you need to switch to a new one. If these assumptions are true, running Doom on it would be easy provided there's some input method.

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.

The *DOOM3* shaders are ARB2 ('cause of old GeForce support) carmack plan + arb2 - OpenGL / OpenGL: Advanced Coding - Khronos Forums

Thanks, I can also recommend gog galaxy. The idea of the custom tags is really nice, I'll have to try this out too!

Keep in mind also that mission size, and complexity have increased dramatically since the beginning. For a lot of veteran mappers, it can take over a year to get a map made and released. The last dozen missions have for the most part been pretty massive, with new textures, sounds, scripts, models etc. We seem to be long past the point of people loading up the tools, and banging out a mission in a few weeks that's very barebones. We still do see some of those, but I noticed in the beta mapper forums and on Discord, that mappers seem to make these maps, but don't release them, and instead use the knowledge gained to make something even better. Could just be bias on my part scrolling through the forums and discord server though.

YOU TAFFERS! Happy new year! Deadeye is a small/tiny assassination mission recommended for TDM newcomers and veterans alike. Briefing: Download link: https://drive.google.com/file/d/1JWslTAC3Ai9kkl1VCvJb14ZlVxWMmkUj/view?usp=sharing Enjoy! EDIT: I promised to someone to write something about the design of the map. This is in spoiler tags below. Possibly useful to new mappers or players interested in developer commentary.

I have a safe door with a bar on it. I'd like the bar part to slide over when the door is opened, and slide back after it's closed. How do I accomplish this? I had it set to be a door at one point, which sort of worked. But that causes a weird problem where an AI tries to open it even though his path doesn't take him anywhere near it. To solve the problem I need it not to be a door entity. Isn't there any other kind of entity that a door can target that will cause it to move when the door is opened?

I just tried HL2: VR yesterday and got blown away by the level of quality. Got curious again how this mod is progressing, and imagine my shock - it's the same developer. Now I'm even more hyped for TDM VR. It have the potential to become one of the best VR games. The only other Thief- style game I know is Unknightly. But, ironically, it was abandoned by developer in alpha stage in a completely un-knightly manner. Adding full VR inventory and interactions to TDM will be perfect: - Stealth, horror and atmosphere aspects are greatly enhanced in VR (judging by my recent experience playing Into The Radius, which has all these elements, but is not focused on stealth as much). - This is a popular mod that gets constant updates and improvements with a modern version of Doom engine. So basically, "free" updates. - Constant stream of new missions to play. - Robust, accurate physics engine should be perfect for VR interactions (picking up stuff and bodies). One of the challenges would probably be making sure that the player has full control over his movement and the amount of noise he makes. With keyboard and mouse, it's easy to do precise movements which are needed in missions when you're in a tight spot. With VR, there's issues, like if you physically lean forward, most games will just move invisible player capsule forward (the capsule itself stays upright at all times) and then suddenly your view gets higher as the game registers your movement as if you stepped up on a table. But you want to lean over it. Anyway, it's just a speculation on my part. I'm a game dev myself, but haven't worked on actual VR game yet (too lazy, I guess). Maybe I should get my hands dirty at some point... I have some experience with C++, but not with Doom 3 engine.

Hello! I'm working on a few extra player movement sounds as an experiment in my next FM. A couple questions: Is there any way to add a player jump sound for when the player begins the jump?It looks like there is some setup for a player swimming sound, but it only seems to do exit/ enter splash sounds. Is this broken/ known issue? Is there anyway to hotfix this?Is there a setup for playing a sound when the player is moving above a certain speed? Likely a script that says play sound shader when player velocity is above a certain value. Think of a wind rushing sound..Lastly, is there a way to fade in and out a sounds using scripts? Something like adjust volume over time.

Seems to confirm: https://bugs.thedarkmod.com/view.php?id=5718 does it happen in the latest dev build: https://forums.thedarkmod.com/index.php?/topic/20824-public-access-to-development-versions/

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.

TTLG? That's Through the Looking Glass Forums. A looking glass fan community. Has been around for a long, long time. https://www.ttlg.com/forums/

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 read@motorsep Discovered that you are able to create a brush, then select it and right click "create light". Now you have a light that ha the radius of the former brush. Just read it on discord and thought it may be of use for some people in the forums here too.