Search the Community

Not so long ago I found what could make a pretty good profile picture and decided to try it out on these new forums. But I couldn't find a button anywhere that would let me change it. I asked on Discord and it seems Spooks also couldn't find anything anywhere. So I logged into an old alternative account and, lo and behold, that account has a button. This is on the first screen I get when I: 1) click on my account name in the top-right of the browser -> 2) click on 'profile'. Compared to my actual account: Are you also missing this button on your account? It'd be very much appreciated if that functionality could be restored to any of the affected accounts.

We will look at some of this stuff, but SPOILER tags, please!!!

Terrific! The beta test thread is up: https://forums.thedarkmod.com/index.php?/topic/22238-beta-testing-the-spider-and-the-finch/

This may make sense in that the performance impact of the volumetric effect can scale with how much of the effect is filling the screen. We shipped with a “performance mode” but had to setup the entities by hand to do it (so it’s not perfect). If you change the LOD detail settings to “Low” or “Lowest” this will disable certain lights, particles and such that can be very heavy to render. You can try these settings and see if you notice an improvement. If not sending us some pictures of heavy areas (with spoiler tags please) will be helpful with tuning these “performance modes” in subsequent patches. Thanks for playing!

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!

Welcome to the Dark Mod forums MarsManon! Thank you very much for the kind words about SLL, it's always nice to hear We all worked real hard on bringing Grayman's map to life and I'm glad you enjoyed it

I was so enchanted by this FM, I had to sign up to the forums the same day I finished it to come thank the authors Genuinely, truly incredible work! I was so overwhelmed in places that I resorted to just shouting joy at my monitor two, three, maybe four entirely separate times while playing. Exploring, puzzling, finding something new, trying to use it, and finding it does a whole new, separate, wonderful thing! There aren't enough words inside me to describe the feeling. It was breathtaking. I don't have any specific feedback that hasn't come through this thread before Thanks so much for making this, for all the inspiration and ingenuity and effort it took. If I never play another level this good, in any other game, in my life, I'd be fine with that.

Ok thanks. Yeah this roof build seems to defy the grid by its shape, so will look at that and see if I can create it better with the grid in mind. What is the minimum grid? Should I avoid the fractional grids and go with 1 or above? EDIT>>> Thanks AluminumHate. I think this is the exact advice I needed. I selected each roof brush and hit control-G to align to grid (grid 1 in this case), and it corrected all of the missing textures in game play. I now need to address roof brushes better as there is now a lot of misalignment. I will try and keep gridding in mind going forward. Clint

Here's an interesting question. If you apply a clip texture, like monsterclip, to a non-brush entity, does it/should it act like a clip in-game? Certainly, DR filtering treats it as just like any other clip object. This arose in the context of thinking about atdm:target_set_frobable, and whether mappers will need to deploy it "defensively" and more widely if the new 2.10-dev frob highlight default is not changed. There is no special texture for a target_set_frobable, and a clip texture is traditionally used. In the wiki "Containers, Chests, etc.", Fidcal said: Giving target_set_frobable a standard clip texture if its not actually performing that clip function (which I don't know) is misleading. Maybe NoDraw would be a better choice? Of maybe it could benefit from its own custom texture, with text, say "Frob Control"?

I was wondering how feasible it would be to tweak the way brush texture alignments are handled for diagonal brushes. In the screen below I'm trying to make a diagonal brush by shifting the top 4 vertices horizontally. The top half shows the current behaviour, where the texture basically stays vertical. The bottom half shows what would be preferrable. Currently, as far as I'm aware, the desired look in the bottom half can be achieved by: Using brush-shaped patches, which is probably the most time-efficient method that's also precise. Rotating the brush. If the vertices must be snapped to grid without changing the dimensions of the brush, one can copy the brush, rotate it and use the MMB to paste the texture over to the original brush. Open the surface inspector, select 1 face at a time and rotate the texture until it looks right (i.e. by setting the rotation increment to 1 and then holding down one of the arrow keys), then adjust the vertical alignment. Definitely a wishlist kind of thing and can be disregarded if it requires drastic changes to the brush texturing algorithm. But some kind of "texture lock" that lets the texture follow the angle of the brush face would be nice.

After a long time and a lot of delays, I'm extremely happy and relieved to announce the release date for my first map; Lords & Legacy, on Friday the 30th of August, 2013! Lords & Legacy v.2.1 Resume: Screenshots: http://imgur.com/a/Lj8UJ#0 Notes: Build time: 2013/03/30 - 2013/08/30 To install, simply put the .pk4 file in your fm folder and install from the in-game mission menu. It is a large mission with optional objectives, so make sure to save often. The ropes in the beginning have a 'slick' surface, to simulate being 'slack lines'. They are difficult, but once you get a hang of the slide they can be fun. A couple of the large areas can be a bit rough on performance, and can be improved by adjusting the LOD slider in video options. A few of visportals open only when you get close. This is to keep the frames smooth inside the respective building, due to early inexperienced design. If you find any bugs which affect the gameplay experience, then you're very welcome to post them here, but please use the spoiler tags. Big thanks to 'Obsttorte', 'Springheel', 'Greyman', 'Bikerdude', 'Sotha' and rest of 'The Dark Mod Team'for all the help, guides and tricks. Also thanks to the other TDM users who provided fantastic support and feedback during the build. Thank you for beta-testing: 'Bikerdude', 'TylerVocal', 'Simplen00b', 'nbohr1more', 'Briareos H.' Special thanks to: 'Danus', 'Dsx' & 'Stanleh' for testing, help and support. v.2.0.1 changelog: Bugs: -The "Master Thief" challenge was impossible to do for a while, due to incorrect values. Fixed. -Getting seen by "The Killer" now also fails the "Ghost" challenge. -The 3 cardplaying guards no longer float mid air, as their chairs are now nailed to the floor. -Fixed the sound of the furnace continuing after the flames were extinguished. -Fixed weird glittering on the power cables around the map. -Fixed some moonlight popping in and out. -Fixed openable windows in Commons, clipping into the frame. -Fixed a book dropping through a desk. -Fixed visportals closing too close in Lancel's Tower, slight hit on performance though. -Added more monsterclip to Service Tower and Robert's Tower's entrance. -Improved a few vis_portals with func_portals. -Replaced curbs in Slums and Commons with some more detailed versions and changed textures. And a lot more little unecessary tweaks. Gameplay: -Added new challenge: (Jack White) - Do not knock-out anyone. -Reduced the amount of starting gear, depending on difficulty. -Added cubemaps to most windows on the map. -Redid most func_statics in Commmons Quarter to reduce tris and increase performance. Draw count is still somewhat high. -Removed all transparent windows as they didn't have actual gameplay value, just a performance drain in exchange for glitchy visuals. -Lancel's safe can no longer be picked. Find the key! -Added a couple minor cosmetic details in the sewers. -Moved a coinpurse from a wealthy commoner's sleeping butt to his nightside table. Also adjusted his furniture so thieves can better move around. -Changed sounds for several doors across the map. Once again, a big thanks to 'Bikerdude' for taking the time help out and locate room for improvement! v.2.0 changelog: Bugs: -Fixed various textures and surfaces and a few minor tweaks. -Tweaked some sounds to be in line with TDM 2.0 changes. -Fixed 2 certain AIs being too sensitive rather than drunk. (Thanks to AluminumHaste!) -Tweaked LOD on some objects, to prevent windows "popping" in and out. Gameplay: -Added more monsterclip to the towers, so the AI can now run up and down stairs. Only the stairs in the small tower has issues still. -Added more monsterclip in the city so the guards can follow you up all stairs. -Added a few minor details. -Windows in the city now dims sound, resulting in less aggro from guards and more convincing soundscape. -Reduced 'draw calls' in all the large areas, increasing performance. The map is still heavy at certain areas. Another big thanks to 'Bikerdude' and 'Greyman', for taking time out of their own schedules to help optimize the map's draw count and other significant adjustements! v.1.0.3 changelog: Bugs: -Fixed 4 black chairs in one of the towers -Fixed a floating painting -Fixed several clipping objects v.1.0.2 changelog: Bugs: -Fixed zfighting in the library's bookshelves -Fixed a black window in one of the towers -Fixed several typos in readables Gameplay: v.1.0.1 changelog: Bugs: -Fixed an issue with the main objectives not being in "sync". -Fixed console spam from a script Gameplay: -Adjusted required loot for each difficulty from "3000, 4000 and 5000" to "2500, 3500 and 4500".

I'm opening this topic to summarise the technical changes that have been made to DR's renderer and get some feedback from my fellow coders. I'd love to get a peer review on the code changes, but going through that by looking at a pull request of that renderer branch would be a terrible experience, I assume, so instead I'd like to give an overview over what is done differently now. General things to know about DR's renderer DarkRadiant needs to support three different render views or modes: orthographic view, editor preview (fullbright) and lighting preview. Each of them has very different needs, but the lit preview is the most complex one, since it ideally should resemble what the TDM engine is producing. Apart from the obvious things like brush faces and model geometry, it needs to support drawing editor-specific things like path connection lines, light volumes, manipulators (like the rotation widget) or patch vertices. Nodes can be selected, which makes them appear highlighted: they display a red overlay and a white outline in the camera preview, whereas the orthoview shows selected item using a thicker red dashed line to outline selected items. DarkRadiant cannot specialise its renderer on displaying triangles only. Path lines for instance are using GL_LINE_STRIPs, Single brush faces (windings) are using GL_POLYGON for their outline (triangulation of brush faces in the ortho view or the camera (when selected) introduce a lot of visual noise, we just want the outline), patches want to have their control mesh rendered using GL_QUADS. Model surfaces (like .ASE and .LWO models) on the other hand are using GL_TRIANGLES all the way. Almost every object in DarkRadiant is mutable and can change its appearance as authors are manipulating the scene. CPU-intensive optimisations like generating visportal areas is not a likely option for DR, the scene can fundamentally change between operations. The Renderer before the changes DR's rendering used to work like this: all the visible scene nodes (brushes, patches, entities, models, etc.) were collected. They have been visited and were asked to forward any Renderable object they'd like to display to a provided RenderableCollector. The collector class (as part of the frontend render pass) sorted these renderables into their shaders (materials). So at the end of the front end pass, every shader held a list of objects it needed to display. The back end renderer sorted all the material stages by priority and asked each of them to render the objects that have been collected, by calling their OpenGLRenderable::render() method. After all objects rendered their stuff, the shader objects were emptied for the next frame. Culling of invisible objects has been happening by sorting objects into an Octree (which is a good choice for ortho view culling), some culling has been done in the render methods themselves (both frontend and backend calls). The problems at hand Doing the same work over and over again: it's rare that all the objects in the scene change at once. Usually prefabs are moved around, faces are textured, brushes are clipped. When flying through a map using the camera view, or by shifting the ortho view around, the scene objects are unchanged for quite a number of frames. Separation of concerns: every renderable object in the scene has been implementing its own render() method that invoked the corresponding openGL calls. There were legacy-style glBegin/glEnd rendering (used for path nodes), glDrawElements, glCallList, including state changes like enabling arrays, setting up blend modes or colours. These are render calls that should rather be performed by the back end renderer, and should not be the responsibility of, let's say, a BrushNode. Draw Calls: Since every object has been submitting its own geometry, there has been no way to group the calls. A moderately sized map features more than 50k brush faces, and about half as many patch surfaces. Rendering the whole map can easily add up to about 100k draw calls, with each draw call submitting 4 vertices (using GL_POLYGON). Inconsistent Vertex Data: since each object was doing the rendering on its own, it has been free to choose what format to save its data in. Some stored just the vertex' 3D coordinate, some had been adding colour information, some were using full featured vertices including normal and tangents. State Changes: since every object was handled individually, the openGL state could change back and forth in between a few brush windings. The entity can be influencing the shader passes by altering e.g. the texture matrix, so each renderable of the same material triggered a re-evaluation of the material stage, leading to a massive amount of openGL state changes. Then again, a lot of brushes and patches are worldspawn, which never does anything like this, but optimisation was not possible since the backend knew nothing about that. Lighting mode rendering: Lighting mode had a hard time figuring out which object was actually hit by a single light entity. Also, the object-to-entity relationship was tough to handle by the back end. Seeing how idTech4 or the TDM engine is handling things, DR has been doing it reversed. Lighting mode rendering has been part of the "solid render" mode, which caused quite a few if/else branches in the back end render methods. Lighting mode and fullbright mode are fundamentally different, yet they're using the same frontend and backend methods. The Goals openGL calls moved to the backend: no (frontend) scene object should be bothered with how the object is going to be rendered. Everything in terms of openGL is handled by the back end. Reduced amount of draw calls: so many objects are using the same render setup, they're using the same material, are child of the same parent entity, are even in almost the same 3D location. Windings need to be grouped and submitted in a single draw call wherever possible. Same goes for other geometry. Vertex Data stored in a central memory chunk: provide an infrastructure to store all the objects in a single chunk of memory. This will enable us to transition to store all the render data in one or two large VBOs. Support Object Changes: if everything should be stored in a continuous memory block, how do we go about changing, adding and removing vertex data? Changes to geometry (and also material changes like when texturing brushes) is a common use-case and it must happen fast. Support Oriented Model Surfaces: many map objects are influenced by their parent node's orientation, like a torch model surface that is rotated by the "rotation" spawnarg of its parent entity. A map can feature a lot of instances of the same model, the renderer needs to support that use-case. On the other hand, brush windings and patches are never oriented, they are always using world coordinates. Unified vertex data format: everything that is submitted as renderable geometry to the back end must define its vertex data in the same format. The natural choice would be the ArbitraryMeshVertex type that has been around for a while. All in all, get closer to what the TDM engine is doing: by doing all of the above, we put ourselves in the position to port more engine render features over to DR, maybe even add a shadow implementation at some point.

Hi, I need to know what the code is to use Spoiler Tags. I am using my tablet and I don't have the options to use anything, like spoiler tags, quote tags, text changes etc. Thanks

OK I think I've got to the bottom of this. I've created this forum thread (with bug report): https://forums.thedarkmod.com/index.php?/topic/22221-bug-drowning-ai-in-shallow-water/ I can apply a workaround, although it won't be perfect and the bug itself needs fixing in the engine. There are a few other things that need fixing so will put an update together soonish.

If any mappers have encountered weirdness with kill objectives not working with drowning AI, I think I've found out why. I don't think it would be a particularly difficult one to fix either. I've raised this bug report: https://bugs.thedarkmod.com/view.php?id=6323 Some context here: https://forums.thedarkmod.com/index.php?/topic/21837-fan-mission-the-lieutenant-2-high-expectations-by-frost_salamander-20230424/&do=findComment&comment=487316 I think this is a bug, but just raising here in case some people think otherwise.

Since there was no explanation yet. Based on my experience, the portal sky texture only works when being on the border of a visleaf. Hence, the comment for the necessity of a visportal. So in my earlier attempt I just put the texture on a random brush in the middle of the map, which was then transparent instead of the skybox texture. However, creating a proper door out of a portal sky brush is still tricky, when it comes to immersion. Once the door/visportal is opened the portal sky texture looses it's effect and will turn transparent. Which means, it works but looks strange to the player. So there should be a way to blend from the portal sky texture to the new texture from what you see behind. Also it might be necessary to stack two doors behind each other, that will be opend together, Otherwise you would end up having a transparent door from the side of the portal texture (once it's opened). Even though the wiki was just mentioned when it comes to objectives. Alternatively you can also listen to Sothas calm voice

I have a more conventional question myself for a change. I'm working with the building modules which are very awesome and helpful. I'm trying to understand how I can use them in ways that play nicely with vis portals and the need to isolate large areas. I want to know to what extent it's considered safe to put a roof model inside a brush block textured with textures/smf/portal_sky in hopes that it will always show properly when seen from below. The issue is you typically want the brushes of your your buildings to be blocks stretching up to the ceiling, so you can put portal surfaces in between them without any leaks. However the roof model is triangular now square. For this reason I initially went with making the brush a triangle in its shape with the tip edge stretching up to the ceiling, but of course this only lets me draw a portal across the axis where the triangle touches the world roof. It would be easier to just make the whole building a sky cube, put the module parts on its surface, then stick the roof inside and leave only the front sticking out. This seems to work in practice: If any part of the model is outside of the brush, the entire model appears to be rendered accordingly. But is this a safe practice to rely on? Should you intentionally allow large models to go through brushes like that? Can you officially rely on caulk and portal skies not to mask models that go into them or break their lighting? Here's a mockup screenshot to show what I mean and how I'd want to do it in the future:

Ulysses 2: Protecting the Flock By Sotha The mission starts some time after the events of Ulysses: Genesis, and continues the story of Ulysses. It is a medium sized mission with a focus on stealthy assassinations and hostage liberation. BUILD TIME: 12/2014 - 05/2015 CREDITS The TDM Community is thanked for steady supply of excellent mapping advice. Thanks goes also to everyone contributing to TDM! Voice Actors: Goldwell (as Goubert and Ulysses), Goldwell's Girlfriend (as Alis) Betatesters: Airship Ballet, Ryan101. Special Thanks to: Springheel and Melan (for proofreading). Story: Read & listen it in game. Link: https://drive.google.com/file/d/0BwR0ORZU5sraRGduUWlVRmtsX3c/view?usp=sharing Other: Spoilers: When discussing, please use spoiler tags, like this: [spoiler] Hidden text. [/spoiler] Mirrors: Could someone put this on TDM ingame downloader? Thanks!

@datiswous, made that correction fm_test.subs --> fm_conversations.subs @stgatilov, about srt naming and file location, would you be OK with the following edit? New/changed stuff in italics: srt command is followed by paths to a sound sample and its .srt file, typically with matching filenames. An .srt file is usually placed either with its sound file or in a "subtitles" folder. The .srt file format is described e.g. [1]. The file must be in engine-native encoding (internationalization is not supported yet anyway) and have no BOM mark. It contains a sequence of text messages to show during the sound sample, each with start and end timestamps within the sample's timeline. It is recommended to use common software to create .srt files for sound samples, instead of writing them manually. This way is more flexible but more complicated, and it is only necessary for long sounds, for instance sound sample of a briefing video. It's a simple enough standard that it can be shown as an short example, demonstrating that subtitle segments can have time gaps between them. And the example can show correct TDM usage, without requiring a trip off-site and picking through features that TDM doesn't support. Specifically, the example shows how to define two lines by direct entry, rather than using unsupported message location tags (X1, Y1, etc.). And skips other unavailable SRT font markups like italics, mentioned in the wikipedia description. The example would also show the TDM-specific path treatment. The example could be inserted before the sentence "It is recommended to use common software...."

Author note: It's hard to believe it's already been a year since Act 1 came out! Well during this mission the player will be following Corbin into the Grimwood district to followup on a lead from last night (Act 1) .. the mysterious tablet! This mission is my first time including full EFX support as well as a HD briefing video file, additionally a new script has been added crafted by the talented Obsttorte which has loot flying towards the player when you pick it up. On a level design front I have tried to change things up a bit by really catering towards a number of play styles, this mission can be completely ghosted or you can use the tools at your disposal to wreak havoc on the citizens of Northdale. For the first time I have tried to create more sandbox environments which don't offer clear answers handed directly to you, so if you're having trouble figuring something out try a different method. This mission takes between 1 - 2 hours to finish depending on the difficulty you play on and how thoroughly you explore. I hope you enjoy your night in Northdale! - Goldwell Voice actors Fen Phoenix Goldwell Random_taffer Yandros Beta testers Amadeus Boiler's Hiss Cambridge Spy Chakkman Crowind Epifire Kingsal SquadaFroinx Custom Assets Andreas Rocha DrK Epifire Grayman Kingsal MalachiAD Obsttorte Sotha Springheel SquadaFroinx Purgator With special thanks to Epifire for creating a large collection of custom models, Grayman for helping out with coding, Kingsal for drawing the ingame map and Moonbo for his script revision on the briefing video. Available via in-game downloader MIRROR File Size: 417 mb EDIT: If you are having performance issues please consult this post by Nbohr1more which may address your issue http://forums.thedarkmod.com/topic/19936-fan-mission-shadows-of-northdale-act-ii-by-goldwell-20190320/page-2?do=findComment&comment=436271

(I apologize for the odd poll question layout. I wasn't able to add five yes-no questions, because polls are limited to three questions.) Hi everyone, I've recently been working on some patches for issues that I've read about from players on the TDM and TTLG forums — and Discord. My goal is to make it as easy as possible for players, especially new players and those who need usability/accessibility options, to find what they need in order to have a better TDM experience. I've already written the GUI and game engine code for these settings, which I've been using in my personal build. The reason for this poll and discussion is to both guide the finalization of my work and collect data to help inform the dev team. Which patches I submit depend on the outcome of this poll, discussion, and what the dev team agrees to accept. Once decided, I can coordinate with the dev team. I've attached screenshots of what the new settings menu would look like if all of the settings are accepted. Below, I have detailed each menu setting, so you can have an easier time understanding each one. Very important to keep in mind: None of these settings change TDM default behavior. They are all opt-in. If you are already happy with the behavior of 2.10, 2.11, etc. and these menu settings are accepted, nothing will change for you. Rename "Always Run" to "Run Mode" with options "None, Always, Toggle" After 2.11 was released, @i30817 requested that "toggle run" be added to the settings menu. Its cvar is already in TDM as "in_toggleRun" (same as Doom 3). I propose renaming the "Always Run" setting to "Run Mode" with options: "None", "Always", and "Toggle". None = in_alwaysRun 0; in_toggleRun 0 Always = in_alwaysRun 1; in_toggleRun 0 Toggle = in_alwaysRun 0; in_toggleRun 1 Show Blackjack Helper @Wellingtoncrab suggested that the new blackjack helper be added to the settings menu. Its cvar was added to 2.11 as "tdm_blackjack_indicate". More info: It's the new blackjack helper added to 2.11. When the game detects that the blackjack can be used for a successful hit or KO, the blackjack will rise slightly. I propose a "Yes/No" setting for this. Slider for "View: Head Bob" @ChronA requested a way to disable head bobbing, because a viewer watching him play was having severe motion sickness. Also, there was a bug in TDM that made setting the head bob in the console not stick after loading a saved game. (Even with 2.11, if a mission overrides the "tdm_player_thief.def" file and sets "pm_bobroll", "pm_bobpitch", "pm_bobup", and other cvars, it will override player preferences.) As far back as 2008, players have had trouble setting head bob. Another one from 2018. At the end of 2022, @Shadowex3 registered just to voice the need for a way to control head bob. I propose that a slider be added to adjust the amount of head bob. This would use a new "pm_headbob_mod" cvar with a value between 0.0 and 1.0 (default 1.0, no change). The "pm_headbob_mod" would be a multiplier for "pm_bobroll", "pm_bobpitch", and "pm_bobup". The advantage to this approach is that missions like Volta 2 and Hazard Pay would not need to adjust their "tdm_player_thief.def" files for head bob to work properly. And, the player can still adjust "pm_bobroll", "pm_bobpitch", and "pm_bobup" as they like. Slider for "View: Mantle Roll" This is similar to head bob for those who are sensitive to motion. Its cvar was added to 2.11 as "pm_mantle_roll_mod". A Thief player on Discord said, "2.11 will have a cvar to tune down the mantling animation at last." I propose that a slider be added for "pm_mantle_roll_mod". Auto-Search Bodies @Zaratul requested the "auto-search bodies" feature from Thief 1 & 2. Its cvar was added to 2.12 dev16783-10307 as "tdm_autosearch_bodies". I did a poll on the a Thief Discord server and roughly 20% of players there use the Thief auto-search bodies feature. I propose a menu setting for this, so that players coming from Thief 1 & 2 can easily find it.

When loading that brush, DoomEdit just spits out this in the console and continues: The game loader deals with brushes on several occasions, for instance the dmap code will send another warning, removing the second duplicate: if ( sides[i].planenum == sides[j].planenum ) { common->Printf("Entity %i, Brush %i: duplicate plane\n", b->entitynum, b->brushnum); // remove the second duplicate for ( k = i + 1 ; k < b->numsides ; k++ ) { sides[k-1] = sides[k]; } b->numsides--; i--; break; } DarkRadiant's brush BREP code will reject the brush, and the code doing that is very old, I'm pretty sure it has already been in place when we forked GtkRadiant. I'll try to adjust DarkRadiant to not remove the brush and to treat it the same way as the game code.

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