Search the Community

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.

I have an even better proposal for doing light cutting, aimed at achieving the same two benefits: No wall leaks for my irradiance lights, plus a performance optimization for all other lights by discarding areas they can't reach before calculation. Essentially the same thing but portal independent and done per brush. It's better as it's not regarded as a hack like areaLock, and will also work for brushes that aren't part of any portal (eg: little side walls). It should be about as cheap too since we'd only do this for worldspawn, simple geometry typically involving a few 8-vertice cubes (and we could discard the back-faces). The light simply loops through all worldspawn brushes it intersects preforming the same intersection check: If that brush or a set of overlapping brushes block that direction without leaving any cracks, so that no vertice / edge / face of the light's box reaches past that brush and the brush fully stops it, the light is cut and discards everything behind those brushes.... obviously if the brush in cause is using a non-transparent texture, and we include closed portal doors here. As Cabalistic pointed out, it can (kind of) be seen as duplicating the functionality of shadows, albeit it doesn't feel anything like shadows to me: It's a way of chopping the light before we calculate any lighting and shadows to discard what that light doesn't need to see... think of the light as a normal cubic brush in Darkradiant, then using the brush cut tool to cut 2D planes across it so it doesn't go through other brushes. What I'm suggesting here is NOT volumetric projection as we don't project anything: We'd only cut the light's box to a convex shape (no inner holes) when it can't get past a set of surfaces before deciding what gets included in its calculations.

Could someone explain the cause of this problem, and suggest the best solution? Here I have a path with a slight bend: The curved part of the wall is a mesh, with a simple set of Caulked brushes behind it. You can see that the triangles looks unpleasant. Long thin triangles don't seem like a good thing. Here's a DarkRadiant screenshot with the func_statics turned off, and the brushes selected: All the vertices are snapped to the grid (I think I had to go down to 1 to get the path texture lined up nicely at the corner). If I turn the pathway brushes into func_statics (with Caulk underneath to seal), the in game result is much nicer: It works, and the AI have no trouble walking over it, but is there a better solution? I can live with this for one part of the map, but if it occurs elsewhere I'd prefer a more elegant solution.

Following on from nbohr1more's comment - I found that figure after several days work & testing on the very large city map, when the map hit 33k it would instantly crash to desktop with malloc errors. had to get it down to 15k before it would stop crashing. As Goldwell pointed out I have created other large maps that have gotten close to 33k but they were fine, so as Obs pointed out the conclusion is that the engine is splitting brushes at compile time exponentially increasing the number of brushes.

(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.

How you can help depends a lot on what skills you have. I can Record Video Recording "Let's Play" videos or simple walkthroughs of existing missions and posting them to Youtube is great exposure for the mod (see example .) Be sure to let us know so we can link to them. If you have some editing ability, Video tutorials, where you explain how the mod works, or how to use specific tools, would also be great. Video trailers, showcasing interesting places and features, are also great for publicity. An example is . I can Write Writing reviews for missions are always nice, especially if they include good screenshots. Not only does it give us something to post on other forums, but it makes mappers feel good when their mission gets attention (especially if it's positive). We have a collective thread to post reviews in: http://forums.thedar...s-walkthroughs/ Writing reviews of the mod as a whole, targetted an an audience that doesn't know much about TDM, is also very useful. You could also try offering your services to mappers to create interesting readables, or to proofread for their mission. I can Act and Record Audio We are always on the lookout for good quality audio recordings for vocal sets. If interested, you can pick a few different lines from this script: http://wiki.thedarkm...t:_Average_Jack and send the recordings to Springheel, who then writes a script based on the type of voice you have. I can Translate We could always use translations of our menu/hud into more languages. Also, only a few FMs are aavailable in more than one language, so there is a lot of work there, see the I18N Translator's Guide in the Wiki. I can Model Great! Take a look at the model request thread:http://forums.thedar...-requests-here/ and pick something that interests you. Or just post a, "Hey, anybody want a model?" thread in this forum and I'm sure mappers will get back to you. I can Animate Fantastic. We can always use more good animations. Our current character rigs use a Maya skeleton. PM Springheel for more info. I know C++ Have a look at our coding section in the wiki, pick an issue or feature from the bugtracker of the mod or the leveleditor, download the recent sourcecode release (or better ask for an SVN checkout) and get cracking. Make sure nobody is already working on that specific issue and feel free to ask questions. I can Edit Images We can always use completely new textures and/or improved versions of older textures. How to get started and how to import them into the mod. I can Take Photos Good quality photos of useful textures (medieval-ish building facades, dirt, rocks, wood, etc) are always welcome. The fewer directional shadows and higher resolution, the better. I don't have any skills Even if you can't do any of the above, you can still help out. Talk about TDM in other forums; share your (preferably positive) experiences with other gamers you know. Last, but not least, compliment people when you like their work. Saying "thanks", to a developer or, "I really enjoyed your mission" to a mapper will make their day. -------------------- I'll update this further as more things occur to me.

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

Thanks. I was hoping to create the trigger in an arbitrary location. I guess I could create a brush trigger in a "blue room" (in DR), then have some script code that moves it to the arbitrary location (using setOrigin). Anyway, I found a different workaround for this, so it's not an issue anymore.

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?

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

Hi guys, through the "cheats" topic I got the idea, that it would be quite useful, if there were tags for missions (the post was about removing the killing restriction in some missions to suit the prefered play style). I don't know how easy or difficult this is, but with them, it would be quite convenient to pick missions with playstyles, environment, etc one does want to use. This could also be expanded to other mission properties. I remember a discussion about climbable drains, handles on doors, that cannot be picked and other things the map author chooses for himself. That way these things would be clearer and as I said before, it is easier to choose missions with playstyles that suit oneself. What do think?

Thanks for the great suggestion. This seems to be why the AI was walking through the door. The relight_position did not help this particular situation. So I experimented: 1) by converting the wall the switch is on to func_static... the ai found the switch properly. 2) by setting the wall to worldspawn and moving the orign of the swtich lever just outside of the wall dimension... the ai found the switch properly. I am using the prefab flip switch {prefabs}\Switches\small_wall_switch.pfb. It looks like when the switch and plate is flush against a worldspawn brush wall, the origin of the switch lever is inside the wall and throws off the AI from the relight. Does this make sense to the techno-experts? A switch origin cannot be inside a worldspawn brush and be used for relight? For now, I crafted a switch plate replacement that pulls the lever out of the wall dimension. I added the relight_position, too, to be thorough. So far, all of this seems to work now. The intended AI is much less of a dumdum, now. Thanks again. Clint

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.

1. Create a water entity (=water_source) 2. Create a small brush (size does not matter) and convert it into an entity of the class "sliding door" (=water mover) - give it the properties a. frobable - 0 b. noclipmodel - 1 3. Give the water mover the follownig spawnargs to remove the default sounds: a. snd_move - nosound b. snd_close - nosound c. snd_open - nosound 4. Bind the water_source to the water_mover 5. Give the water_mover a fitting translating value, for example "400 0 0" 6. Target the water mover from the switch in question

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.

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

In my mission, I have a round door that rotates AND translates. I started this 4 years ago before I got cancer, and then the door worked. Not anymore! I finally got a ROUND to testing this. It does not matter the type of door, if the door is a round brush OR a round model, in the game the door is non-solid and non frobable. I can, however trigger it in the console and it works as it should. I am going to try and make a solid (rectangular) door in front of it as an overlay and use script to achieve my goal. Will let you know how it goes. Update: Works great, had to do a screen grab of the circular door+ wall of the size of rectangular door. Create dds image and material file, so I textured the rectangle door and you can't see difference in game. frob the rectangle, it vanishes and circular one rolls out of way. YAY

After doing more testing and practically using DR under Wayland, I uncovered more bizarre functionality to this issue. Even when using the parameter GDK_BACKEND=x11 to run Radiant through X11, the same input issue will still occur in some cases. First of all the model chooser will always have it: If you choose to add a new model or edit the model of a selected entity, right-clicking in the 3D view of the Choose Model window to look at the mesh from different angles causes the mouse to wildly throw the camera around only allowing for small movements. Then I noticed the 2D view in the main window will sometimes start doing it too, though unlike the model browser it doesn't always have the problem and something triggers it (on X11 backend, full Wayland always does). Finally I was able to see what it is: After pressing X to select the clipper tool and cutting a brush, click-dragging the 2D view always produces the same exaggerated movement. Switching away from he clipper doesn't fix it once the issue has been triggered, right now I need to constantly restart DarkRadiant after using the clipper to cut a brush or I can't control the 2D view any more.