Search the Community

DarkRadiant 3.5.0 is ready for download. What's new: Feature: More customisable layout, all windows and panes can be dragged and arranged Layouts like Embedded, Regular and Splitpane are superseded and have been removed Tweak: The LayerControlPanel's tooltip popup is now less annoying Tweak: Clarify distinction between Shadow render mode and other render modes Fixed: Show/hide Light Volumes for combined entities inconsistent Fixed: Currently applied particleDef not selected in Particle Selector Fixed: Layer visibility checkbox not reacting to double-clicks Fixed: Cannot toggle visibility of layers in Linux Fixed: Drag-and-dropping layers is not working in Linux Feature: Customisable Layout (click to see the videos) Windows and Mac Downloads are available on Github: https://github.com/codereader/DarkRadiant/releases/tag/3.5.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!

1. If you want to use custom work (sound, models, textures) from released missions, best thing is to ask the author if he/she agrees. So far, Sotha is the only one who permits unlimited usage of his custom work (he expressed that here on the forums). He just wants to be credited. 2. If mission authors from released maps are not available anymore, then I do not know what to do. @Dragofer@nbohr1more: Any suggestions? I would say, that's the same situation as described above, just replace "released mission" with "abandoned work". As for my released work, feel free to use whatever you want.

I think it was a small part that I split off from the main map because NeonsStyle was only interested in a specific aspect. It should be ignored. Brush/patch/entity count is an interesting statistic to have, too.

Also, fllood isn't active on the forums a lot it seems, so maybe another person can give authorisation when @fllood isn't around? Just an idea. I guess I could pm this to fllood. Edit:

Would be interesting to also see a shot of the mission in DR too for mappers to get a better idea of how much there is and how dense (brush, patch and entity counts would be good too). @Baal Have you tried sending a PM to fllood? Simply pinging them with @ only gives them a notification when they log into the forums, while a PM will also get sent to their email.

If the monsterclip does not go up to the ceiling (touching the blocking brush up above) it can happen, that the pathfinding algorithm will consider the top of said monsterbrush as reachable by the ai, and will therefore add it to the aas. This can indeed cause odd behaviour, although I am not sure that it would explain what you are seeing. Usually the ai just tries awkward things like walking on top of a shelve or jittering up and down. There is an impulse one can bind to a key to inspect the aas areas in game which is pretty useful for finding such spots. But I forgot which on it was. Grayman once posted it iirc. Another thing worthwhile trying is to insert additional pathnodes. Is the pathnodes are far away from each other there may be things influencing the pathfinding which you then easely overlook. That's just an assumption, though. Let's hope that Biker is lucky.

What do you use to drag out a new brush?

I actually had a go at this myself once, but found it far too difficult. Personally I too hate the default input style, particularly the requirement to constantly hold down modifiers just to select things, but changing the defaults just breaks too much stuff because the selection system isn't designed to work that way. In order to allow "normal" selection rules, we would also need: A different method to create a new brush (since left-drag is now a selection or manipulation operation), for example something like Blender's Shift+A shortcut. A different way to resize brushes. Currently dragging anywhere outside the brush performs a resize, but if clicking/dragging on empty space is supposed to define a new selection, this will no longer work. So we would need something like traditional resize handles instead of the planar dragging approach. The selection system to decide what operation is being performed after the initial click or drag starts (as Greebo already mentioned). [Optional but almost certainly necessary] A system for setting up alternative keyboard profiles so people could choose between classic Radiant selection or the new system, since not everybody would agree with the changes.

Is this the proper way to create a trigger hurt with specific damage, in my case a 5 damage: 1) make intended brush 2) texture as trighurt 3) convert to entity trigger_hurt (not damage_triggerhurt_5) 4) set def_damage arg to damage_triggerhurt_5 From what I can tell, this works now.

triggerhurt question Hello TDM crew. I am having a bugger of a time trying to get a damage_triggerhurt_5 to do anything. I create a brush, give it trig hurt texture, right-click, convert to entity damage_triggerhurt_5. In sample tests, I make the brush bigger than the player to make sure the player is within the bounds. Nothing. So, I am missing something. Advice? Clint

Some textures are listed as no shadows, so if you apply that to a brush, it won't block light, something to keep in mind. If you see a texture that ends in _ns or noshadows, don't use it.

Hello! I just joined the forums to report an annoying bug. I don't know if it's specific to this map or just a game bug but I have played most of the other missions and this is a first for me. Before i picked up the key to the junkroom i tried to open the door and i got the "needs junkroom key" message on my screen... but that message never went away. I had to complete the mission with that on my screen the entire time, overlaying all the other messages that appear. a reload/restart didnt do anything to solve the problem. A few of the on-screen messages at the beginning didn't make sense to me and were kind of cryptic, like a riddle i didn't get. one of them was something about an alarm? otherwise i liked the mission, pretty challenging and I know i missed some spots. cheers

Thank you. I am mainly concerned about the grouping of portals and their shape. What happens if i deviate from the basic brush shape (90° angles) or when i join portals of different sizes instead of using one big portal to fit? Can that cause issues?

DarkRadiant 3.4.0 is ready for download. What's new: Feature: Allow Layers to be arranged into a Tree Fixed: Readable Editor displays "shader not found" in view Fixed: Undoing snap to grid with prefabs causes crash Fixed: Include doc in building instructions Fixed: Decal textures causes DR to crash - (textures/darkmod/decals/dirt/long_drip_pattern01) Fixed: Skin chooser: double click on materials list closes window Fixed: Selecting and deselecting a filtered child brush through layers leaves the brush selected Fixed: Material editor re-sorts stages on pasting image map resulting in wrong material stages list and wrong selected stage Fixed: Crash on start if engine path is choosen (Doom 3) Feature: Layers can now be arranged to form a hierarchy Windows and Mac Downloads are available on Github: https://github.com/codereader/DarkRadiant/releases/tag/3.4.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!

Can't speak for the others, but I start all new areas (and often whole maps) exactly how you describe: brush it out, add portals, add lights and add tentative ai with level comprising routes in order to see whether a. there are problems with AI navigation in general and b. if it is possible to sneak around AI in critical areas. If you want to create your own modules from brushes, then you should check Sotha's tutorial.

I still have the bug where the 2D ortho views don't show the outline on brush selections. I built from source this morning and ran it with local debugging on, and when I draw a new brush in an ortho view, visual studio shows: Exception thrown at 0x00007FF965B3477C in DarkRadiant.exe: Microsoft C++ exception: std::invalid_argument at memory location 0x000000000014EB40. Exception thrown at 0x00007FF965B3477C in DarkRadiant.exe: Microsoft C++ exception: std::invalid_argument at memory location 0x000000000014EB40. Exception thrown at 0x00007FF965B3477C in DarkRadiant.exe: Microsoft C++ exception: std::invalid_argument at memory location 0x000000000014EB40. Exception thrown at 0x00007FF965B3477C in DarkRadiant.exe: Microsoft C++ exception: std::invalid_argument at memory location 0x000000000014EB40. Exception thrown at 0x00007FF965B3477C in DarkRadiant.exe: Microsoft C++ exception: std::invalid_argument at memory location 0x000000000014EB40. Exception thrown at 0x00007FF965B3477C in DarkRadiant.exe: Microsoft C++ exception: std::invalid_argument at memory location 0x000000000014EB40. Exception thrown at 0x00007FF965B3477C in DarkRadiant.exe: Microsoft C++ exception: std::invalid_argument at memory location 0x000000000014EB40. Exception thrown at 0x00007FF965B3477C in DarkRadiant.exe: Microsoft C++ exception: std::invalid_argument at memory location 0x000000000014EB40. Exception thrown at 0x00007FF965B3477C in DarkRadiant.exe: Microsoft C++ exception: std::invalid_argument at memory location 0x000000000014EB40. And it keeps throwing that error as I drag the brush around. Might be related?

It's interesting because I recently read a thread on the Doomworld forums on people's opinions of single-segmenting maps in classic Doom/Doom 2. In other words, playing a map from start to finish without using saves - if you die, you have to replay the entire map. The general consensus was that saves are useful, however there was some merit in there being extra tension and challenge knowing that death couldn't be rewound easily by reloading a save. On the other hand (and speaking as an adult), people have to work and often have limited time for gaming. Having to replay a long map because you died can be quite off-putting and takes the joy out of a game if it happens often enough. Savegames keep the tempo going, keeps the feeling of progress going. Also someone pointed out that starting a map from scratch after a death is kinda like using saves anyway, just a single save at the beginning. You're just being tedious by denying the use of saves in this case. Dunno where I'm going with this. Trying to be diplomatic and say I can see all sides to the discussion.

DarkRadiant 3.3.0 is ready for download. What's new: Feature: Remove menu options which are not applicable to current game Feature: Grey-out menu entries that are not applicable Feature: FX Declaration Parsing Support Feature: FX Chooser Feature: Renderer now takes "translucent" keyword into account Fixed: Lighting Mode Renderer draws hidden lights Fixed: Loading map results in "Real Hard DarkRadiant Failure" exception Fixed: Crash when trying to set default mouse or keyboard bindings Fixed: Unit Tests intermittently get stuck on Github runner Fixed: xmlutil thread safety problems Fixed: Some materials aren't displayed correctly Windows and Mac Downloads are available on Github: https://github.com/codereader/DarkRadiant/releases/tag/3.3.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!

Yeah, there were a few dmap fixes since 2.10. I can't say for sure whether you hit any of the known ones but splitting brushes near lights is an old remedy anyway ( called Brush Carving by Doom 3 mappers ).

same on 2.11. I tried recreating the brush and it didn't help (if that's a thing).

I suspect that something in the DMAP precision is generating too many triangles for this brush. What does it look like with r_showTris 2 ? Does the same thing happen with a fresh dmap via the 2.11 Development Build ?

Does anyone know what's causing this weird effect? Besides looking strange, it also causes my framerate to tank heavily - like -150 FPS. This is a brush with the lamp post material (tdm_streetlamp_metal) applied to it with a light shining on it. Also, the effect (along with the FPS drop) goes away if I change the brush to a func_static, which I am probably going to do anyways. I see similar effects on some other metal materials as well (e.g. iron_flat), but not to this extreme.

I found the forum post I did about it here: https://forums.thedarkmod.com/index.php?/topic/9082-newbie-darkradiant-questions/&do=findComment&comment=459121 I don't think I got a reply, and we were near release time so I just gave up on it. It worked at some point, so was probably something on my end. Regardless, having to use a Perl script hosted on some obscure server that nobody maintains anymore doesn't seem like a robust process. I think you can build the FM from the start to support i18N and not have to use that script. That's the approach that I think I will take for my next FM. Looking at the Wiki page, it's not that clear how to do it so that's what I'll aim to sort out. But then again, unless there are plenty of people waiting in the wings to perform translation work, not sure how motivated FM authors will be to support this.

Yeah. I've deleted all the XML files and let Dr recreate them. Brush selection and brush selection camera are both set to red. However, it doesn't seem to matter what color I set it to, it won't highlight on selection.

Strange issue that I'm surprised no one has mentioned. When selecting brushes, they're no longer highlighted red, even though selected brush colour is red. DR2.9.1 DR3.2.0 Same thing on latest Git source 3.3.0 pre