Search the Community

Hi, first of course thanks for all the work. I updated from 2.12 to 2.13 and now no weapon will show. I reverted to 2.12 and the problem persists, so I don't think it's a 2.13 issue. I don't see a setting; am I blindly or stupidly missing something?

Alright, I've done it. And then probably went overboard. I was able to disconnect all of the volta-named bits from the entities and rename or repoint everything to assets that ship with TDM. The results don't look quite as cool, but I still was able to make a destructable crate with flindery bits, particle effects, and smashing sounds. Hooray! I then discovered that changing the model required whatever new model I chose to also have a clip model. So there was no way to get around making clip models in darkRadiant for whatever things I wanted to be smashable. I went ahead and made really basic (cubes or 6-sided prism) clip models for all the junky broken down wooden objects I could find in the TDM assets, most of which were missing, and used those to create breakable versions of those models. Funny enough, this approach worked for everything except the original door that I wanted to make breakable in the first screenshot of this post! There is something funny about the collision geometry of models/darkmod/architecture/doors/oversized/old_door_02.lwo . If I used it as an entity model, the map complained about not having a collision model. But if I added a simple box as a collision model, the box didn't get used! I was able to shoot arrows and walk straight through this broken down "door". So my original chain-of-random-entities solution that doesn't make flinders is probably as good as we'll be able to get from the door. I also used this solution to try to recreate breakable banners from TG and T2, and they work pretty well. They should probably have a "torn" version that hangs from the banner rod instead of the whole banner and rod disappearing entirely, but they will serve the gameplay purpose of being able to hide safes/secret passages behind banners well enough for me. Coming back to flinderable entities, I realized I could probably tweak the entity definition to also make breakable ceramic pots, so I made some of those too. I ended up with ~25 prefab objects that you can smash with the sword or detonate with fire arrows - some are small enough to be picked up, but the bigger ones can only be pushed or are completely stationary. I tried to pick reasonable health values for them based on their size and apparent sturdiness. All of these can be used as obstacles to block doors or secrets. I've uploaded a .pk4 that contains a simple test map, the entity definitions, and the prefabs. Feel free to download, rip 'em out, and use 'em! If there are any good candidates for smashable-looking crap that I missed or any feedback on how I could make these better, let me know. If @kingsalis cool with it (...because I basically copied his homework for the scripting), I would also support making these entity definitions, collision models, and prefabs part of TDM's core, and would be willing to make whatever tweaks we think are good to help make that happen. breakable_prefabs.pk4

Hi all, Thanks for the replies. I'm not sure if it's just my setup, but it should be quite apparent if you load up any original Doom 3 map in DarkRadiant (unless it's only me having issues ofc). The mod folder doesn't seem to make a difference, but I do currently run the dhewm3 source port, so I should maybe run a clean installation on the side just to make sure and rule that out. Here are two screenshots, one from darkradiant and one from d3-editor from the same location on a map. The model appears green when it is connected with a light. I believe default keys are shift + k in D3 Edit to achieve it. And just to explain, the light on the right is essentially just brushwork and then a light sitting below it (not visible in the screenshots), while the left one is a light with the model property assigned, and the model can just be a func_static but that just doesn't seem to work in DarkRadiant for me. Caverns2 shows this off in the first room below the elevator pretty well.

Thank you! I'd say there are still a few things missing. Some items still need to be implemented, like the spyglass, keys, readables, and the newly added gasmine. I'm also considering adding interaction animations for things like opening doors or grabbing loot, but that's not a priority right now and it might not work well, so we'll see. Lastly, I think it could be cool to show animations for climbing ropes or mantling, but making that look good might be impossible. It's really just an idea for now.

This sounds more like a case of no good feedback in beta testing. Placing a few guards is not that difficult, or a lot of work.

It depends really. But, yes, missions like these show a great team effort. TDM still is in dire need of a good "official" campaign though. I know, a lot of work and time involved. But, imagine something like The Black Parade for TDM.

It seems that missions are better when more people work on them. This is a great example.

Hey we can dream cant we . on a more serious note i actually ment it when i said 12gb should be the bare minimum these days, but im not holding my breath on them actually following it. planned obsolescense is the current MO, spurred by people clinging to old hardware because it was viable for far longer than anticipated. Supply chains getting ruined by agressive parties. Inflation corona scalpers and just about any of the shitstorms of bad news the world has had in the last decade. the resurgence of ai not to be forgotten, and with only a few developers of gaming capable hardware -> nvidia amd and intel who all want a piece of the ai pie it seems they kinda forgot about the folks who got them to be in this line of work to begin with (kinda sucks when things get mixed up eh ?).

Yes, they have two separate, compounding issues: CPU overhead, and an inability to work well without resizable BAR support. Old CPUs/mobos can take a severe hit from one or both. It would presumably be a 75W GPU, so not intended for very high performance. But they could make obvious improvements such as including 8 GB of VRAM instead of the 6 GB of the A380.

Make all included filters editable. Currently you can only add your own and eddit those. Also, DR includes most of it's filters for other idtech4 games, although the paths might be different and therefore they might not work. I just really don't understand why you would want to block modders from changing the filters in their DR install.

Oh never knew Doom 3 editor lacked prefab ability, one reason DR got so popular then, prefabs are awesome. I never used inhouse Doom3 editor, besides trying it for a few minutes but DR felt better to me, so I used that. Custom DR prefabs, do work in Doom 3, obviously TDM ones will not. I did used prefabs in Doom 3 for some things, like wall lamps and such, where I connected a model, a light and a particle effect for example. Never looked at the DR source code, but behind the scenes I bet the entities are just being bound to each other and that Doom 3 supports fine. About the topic, I would love to help the person but like i said, I never used inhouse Doom3 editor, so I can't really compare behaviors between the editors. And what you said sounds totally reasonable.

Are you talking about the prefabs? If yes, afaik DR supports prefabs well, so if you are getting issues with that, could be because you are importing the model/entity not the prefab itself? To use prefabs (pre-fabricated complex group of entities) you need to right click on a 2D view and click on "insert prefab". If you are already doing that and it still doesn't work, then is probably some prefab that got outdated/broken, if so, please do a bug report for it. https://bugs.thedarkmod.com/my_view_page.php

Hi, This is just me being a bit curious. I've grown quite fond of DarkRadiant, so I tend to use it over the built-in d3-editor when mapping for Doom as well. However, there is one thing that doesn't work well, and It's when you have a specified model for the lights. So if you open up any map, you'll see the box with a question-mark instead. This is usually when there is special things going on like breakable lights etc. Is that just functionality that was never needed for the Darkmod/DarkRadiant or is there something else going on ? I tend to use d3-editor just for those special cases.

I think it's too late for them to come up with a higher-end RDNA4 die. We would have heard about it by now. I'll tell you this though. MLID is promising that FSR4 will come to RDNA3 and RDNA3.5. And it's kind of essential for that to happen, since all of AMD's handheld/mobile products will be using those for the next year, at least. I believe low power devices are the killer application for AI/ML-based upscaling, because they are the gaming devices facing the tightest constraints. Upscaling 4K to 8K is easy because there's so much detail in the first place. Upscaling 540p to 1080p is hard because there's little to work with. That's why DLSS is an important feature for the Nintendo Switch 2, and why FSR4 must come to RDNA3/3.5 handhelds like ROG Ally. The RDNA2-based Steam Deck will unfortunately be left in the cold, but it has held its own pretty well over its lifetime.

Man, these crashes are getting out of hand, I am in the finale of act 2 and it keeps crashing on me... It's so annoying that I am thinking about quitting, although I really enjoy the game and I am so close to the finish-line. It's a huge bummer! Some people reported that switching to DX11 renderer would help with the constant crashes, but it didn't work for me. I tried various ini tweaks etc. Just now I even tried disabling DLSS and setting everything to low. Still crashes eventually. It seems to dependent on the area, as I had sections of the game without any crashes for a whole evening. Then again, there were sessions were I had 10 crashes. I eventually created a "kill and restart" batch so that I at least could quickly get back into the game. By the way, it turns out that those LOD issues were due to me using the DX11 renderer.

I have Act 3 almost done, it is very very far along. It's been through many iterations, but so far this year I haven't had much personal free time to work on my map which is why it's so delayed. My hope was to have it already released, but yeah life has a way of distracting us. I'm going to be buying a laptop next month, and I will rent a hotel room and lock myself in it, away from the distractions of the world to get this done! Act 4 is also very far along too, so if I can get some free time after act 3 is out, I am hoping to get them out relatively close together. And just as a very special treat... here's the briefing video for act 3 (but shhh don't tell anyone!) Hehe thanks mate! I do the same thing whenever looking for stuff, it's no worries

Welcome! Your ambient work is very cool and I'm excited to see what you make for TDM.

Uh. I never figured out how powder kegs were supposed to work... until today. Such a fool I am.

Now this is the kind of spicy pepper that I enjoy biting into. I feel like this would be simplest to solve by adding some prefabs to tdm_prefabs01.pk4, with sensible defaults but some obvious exposed customizable bits, and maybe a tiny wiki article to document what can be done with them. No idea what it takes to make something(s?) part of the core package of TDM prefabs, but I'm willing to put in work to make it happen. When I revisit this (which will probably be a couple weeks), I'll upload whatever solution I end up with as prefab .map files to this thread and I suppose we can test/bikeshed from there. How to make it work well with the AI would be my big open question. I imagine kicking down a door/crate/exploding barrel should alert hostile NPCs and make neutral ones hostile, and should probably do so in a large radius. It sure feels like the kind of thing that should be a last resort with significant downsides in a Thief-y open source im-sim game. The breaking doors I was trying to get to work are in an area with no NPCs, so I haven't even tried to solve or test its effect on nearby AIs.

I don't think idDebris will work in TDM. Its mentioned a couple times in the source code related to projectiles and there is a defunct def of it in d3_junk.def. AFAIK - we need to use the flinder objects which I know grayman did some work on back in probable 2.7 or 2.8 to make them usable. Unfortunately I couldn't get them to ignore their own collision, maybe there is a spawn arg I'm missing. Another issue is if you break a crate by an elevator or by a door, the flinder objects could potentially stop the elevator or door from moving. So I could either have them disappear after a time OR make them grabbable so the player can move them out of the way. I opted for the later because it made more sense.

Coming in late in this discussion, but I've made some breakable crates for Volta 3 that work pretty well. It is a real pain to get the flinders to spawn at the right place since they need to spawn a few units away from each other or their clip models will get stuck and they'll float in the air. If its helpful, you can check them out in volta_breakable_crate.def. Breakable doors would be pretty cool, I wonder how AI will react to them?

Thank you. If you want, you can also share your post in this music resource thread I started a while back. I think it would fit nicely.

as for dxvk it is a marvelous tool for linux allowing most directx games to run flawless on linux by porting the directx calls to vulkan, it can be linked with the renderer so it can be turned off for comparison between the original directx and the vulkan renderer. you usually loose a few fps using it but older directx 8/9 games with non standard render paths like call of cthulhu dark corners of the earth run pretty well with it especially since dxvk allows alt tabbing which the original renderer could not handle. proton is a directx 12 wrapper much like microsofts but it does not use directx instead it ports directx 12 calls to vulkan and is sometimes used in conjunction with dxvk but the overhead is quite large so you need a beefy gfx card. proton supports raytracing as well but with said overhead it becomes somewhat undesirable to run dx12 calls through it. just try running horizon forbidden west through it and you get the idea. and hfw runs pretty well nomally. proton is mostly for linux users to allow directx 12 games to work, but with raytracing on it drops fps considerably. EDIT: the overhead is actually worse than i thought, on linux many dx12 titles tank completely with raytracing on sometimes seing drops as bad as 30 to 50 % on nvidia cards. unfortunatly with the drivers being closed source a fix might newer come.

Moved to this thread. There are lots of complaints about UE5 performance. Oblivion Remastered may be a worse example than usual (there is another title that did a UE5 on top of other engine approach, but I forgot what it is), but it's only the latest. Budget PC gamers have benefited from industry hardware/software stagnation (PS4 era games became trivial to run). We are still a far cry from the fast-paced 90s when your shiny new 3D accelerator could be completely obsolete within a year or two, but things are picking up a little. What we're learning is that we tend to need moar than 8 GB of VRAM, with 16 GB presumably having no issues given that current-gen consoles are locked in at 16 GB GDDR6 max. We can blame lazy developers for this if we are being uncharitable. Aside from that, you can't count on being able to do 4K or ray tracing (on low-end like 7600 XT 16 GB), but if you have little interest in newer games, that's probably fine. AMD is bringing some heat with several 16 GB options, but hasn't bothered with a 192-bit die, and won't be able to do some of the exotic memory configurations Nvidia can using 3 GB GDDR7 modules (GDDR6 is limited to 2 GB). Intel's 10-12 GB Battlemage cards are a no-show. AMD's 9060 XT 16 GB could be impacted by tariffs. We'll be lucky to see it under $350. I think next-gen could be more interesting with hopefully better market conditions, Nvidia using a new node (Blackwell 4nm = Lovelace 4nm), and all competitors using GDDR7, allowing 12 GB on 128-bit, 18 GB on 192-bit, etc. APUs are becoming a good option, giving you "unlimited VRAM" and decent performance. AMD only has Phoenix APUs on the desktop socket but might launch Strix Point by the end of the year. These should be generally sufficient for 1080p. Mobile-on-desktop soldered products are looking good and coming out long before the desktop APUs. AMD's Strix Halo is theoretically interesting, but in practice it's expensive and positioned more for AI than gaming. It just doesn't matter to the budget-conscious right now. If you don't care about the latest games, you're good to go. I've hardly played anything other than Thief and TDM lately. I do want to push TDM to higher resolutions though, and perhaps see ray tracing land in the engine in the future.

"Frontend acceleration" is the user-side name of cvar r_useParallelAddModels, which controls job-based parallelism inside frontend. And cvar com_smp controls the original two-thread parallelization which was present in Doom 3. We used to have a troubleshooting switch for it in the menu, but later we deleted it because this parallelism seemed stable enough. If you are interested, it is described here: https://wiki.thedarkmod.com/index.php?title=Tracy:_timeline_profiler#Gameplay