Search the Community

I'm trying to write a DarkRadiant python script with the purpose of orienting/angling a model between 2 arbitrary points (i.e. for a clothesline, or hanging pennant flags, etc). The goal is: The user selects 2 entities (target_null's). The user runs the script. A window will pop up, and ideally display the rotation matrix between these 2 entities. I can get the XYZ of these entities, and I can get the euler angle between them. The problem is: props want a rotation matrix, not euler angles -- I can't quite figure out how to get the rotation matrix, or how to convert the euler angle into a matrix. I'm not sure if I'm approaching this correctly -- has anyone had experience with this, or can point me in a direction?

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

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

Uh, I think I've made a SNAFU in DR... Perhaps it's a bug. Either way, unless there's a simple fix for a SNAFU, it looks like a clean deinstall/reinstall of DR to fix what might be a bug. I changed an entity, to test, to one of the entity classes that is a damage def - at the bottom of the list - "damage_triggerhurt_25". Doing this removed the brush from appearing in TDM. No damage. OK, np, I kinda knew these didn't work but thought I'd try them anyway. Changing back to "trigger_hurt" - it appears and causes damage to the player as it did before. So decided to try changing the entity to "atdm:damage_moveable" to see if it worked or not. Doing this also removed the brush from appearing in TDM. No damage. After this - if I create a new brush, it is impossible to change it from worldspawn to ANY entity class at all. However - I am able to change the entity class of any existing object in DR. Selecting the brush, clicking the classname in the entity info panel under camera view and then using the "choose entity class" button to bring up the menu, I get the list - but selecting any class and then clicking "add" does nothing. Even if I select the brush and then type in the name of the entity, eg "trigger_multiple", under classname - it will not store any change, clicking the tick or pressing enter on the keyboard. This persists after (both software and computer) restart, in other maps and in any new map I create. I am able to change the entity class of any existing object by either of these "usual" methods otherwise. The only way I am able to change a new worldspawn brush into an entity is to select the brush and then right-click and select, "create entity" to bring up the same list from which to select, eg "trigger_mulitple" as I would by clicking the button in the entity info panel. Once the entity is created this way - it is then possible to change it using the entity info panel method or by typing in the entity class into the classname box, as usual. (it is often faster to type [/paste] "func_static" into the classname box than navigate to "func_static" by creating an entity from worldspawn using the "choose entity class" button or right-click "create entity") Furthermore, it appears as if some filters have been activated by choosing these entity classes - meaning that it looks as if deselecting a clip or nodraw texture is deleting the worldspawn brush / func_static. The filters it did activate are "clip textures", "func_static entities" (even though they are evidently displayed with any other texture but clip or nodraw...), "nodraw", "visportals" and "world geometry". These are filters that I have had selected several instances of DR ago, but since have deactivated all filters... The recent files are correctly displayed. Once again deactivating all the filters - it is still impossible to create an entity by any other method than right-clicking it, instead of simply typing in the worldclass box or accessing the entity class directory through the entity info panel button. Bit strange.

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?

This is a thread for members to post inofficial hotfix patches in. These hotfixes are for people who want to keep using stable official releases of The Dark Mod and Dark Radiant, but with somewhat less bugs. These patches will overrule parts of the official release, and are therefor only compatible with the specific version of TDM/DR that they were created to patch. It is therefor necessary that you keep track of which hotfixes you installed, and uninstall them all when you upgrade to a new TDM/DR version. If any bugs persist in a future version, it's best to wait for a new patch to be released for that version. At time of writing, the official released versions are The Dark Mod version 2.10, and Dark Radiant version 2.14.0. When posting a patch, please include which version it is for. (Patches for developer versions are allowed, but don't expect those versions to last long.) Developers, keep in mind that while these patches will point you in the direction of a problem, the patch solution will sometimes differ from an official release solution. (For example, we can't rename packaged files, and so we have to sometimes refer to badly named ones.) It's possible that I - Nort - will be the only one posting these patches, and I'm fine with that. Update After having worked out a lot of patches during these past weeks, I've attached version 1.0 of my hotfix pack to this post. This pack makes all my previous hotfixes obsolete. Details about what they contain, are in the included release notes, because the list is too long to post here. The main features is the fixed console warnings, as well as the fixed mages. (Do not miss these mages. They are eating apples and everything.) If you have any questions about any changes, just ask. Version: The Dark Mod 2.10, Dark Radiant 2.14.0 Small correction: The release notes should say: "This new file creates defines several placeholder shaders. Placeholder shaders are mesh defaults which skins can refer to without risking conflicts with other meshes sharing the same skin. They are not simply misnamed shaders, or deprecated legacy shaders." Update Dark Radiant version 3.0.0 released today, so my patch version 1.0, only stayed relevant for about 24 hours. ...and that's fine. A great changelog of Progress, is all I ever wanted. While devs should still download my patch to see if everything in my patch change log has been addressed (which I doubt), normal users should instead go download Dark Radiant 3.0.0, where every change is official. Once I've assembled enough mental strength to begin over from the beginning again, I will start working on the next patch. It will likely take a shorter time to make this time. Update Remember, before uninstalling any def files, to first remove any entities they have created, mainly the noble and mage ragdolls. If Dark Radiant can't find the definitions for entities, it won't display them in the map. I don't know if they still remain in the code, and you probably don't want invisible obsolete entities in your map, so it's cleanest to remove the entities from the map before removing the patch files. Update I've decided to post-pone any further development until Dark Radiant release 3.1.0. The 3.0.0 was a big update, and big updates will typically come with smaller unforeseen issues. One such issue is that whole numbers aren't being displayed properly. It's thankfully only a cosmetic issue, but since it's so in-your-face, I think that the devs are likely dealing with other issues as well, and that the next update will be coming as soon as possible. ...so I think 3.1.0 will be more stable, and will come soonish.

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!

Yeah, grouping is an option. I normally don't think of it as it was added years after I've started working with DR. You can edit combined entities as easy as non combined ones. And electric lights are one entity either way, so it really makes no difference there. One big advantage of combined entities, for example torch models with a light def_attached to them, is, that you can alter the appearence of ALL those entities by making one adjustment in the respective definition file. If you use your approach and notice later on that something with the torches isn't quiet right (let's say, they are a bit too bright, making the mission too hard), you would have to go through all said torch lights to change that. Another aspect to consider is that this can easely cause similar models to have lights with different properties (big differences, not slight variations that may even be a good thing), either by oversight or because you forgot to consider it, which would create inconsistencies that the player may not even be able to put his finger on what's causing them. That's not really a good thing design-wise nor considering how often the unreliability of the gameplay in TDM and the considerable high difficulty level tends to frustrate players, especially new ones.

There is no need to create light source and model seperately. You can easely tweak the light on combined entities, and having two seperate entities serving one purpose is a guarantee for additional work and errors. If you shift the light, you have to shift both entities, if you want to create a copy of the light, you have to copy both etc... You should really not get used to this kind of workflow. Create lights via the create entity menu.

Why do I have to shoulder entities to get to know their status (KO/dead), or their name (Mr Bad)? The reason we are talking all this is because I wanted to display the "shouldering name" of AI on frob. As soon as the goal was achieved I wondered about non-AI names and here we are. Precisely. A chair is a chair and an apple is an apple. Most of us will see it as redundant and conclude it is pointless or useless. I am not yet ready to give up so let's go beyond the obvious: does having a little tag at the bottom go in detriment of the intended experience? This must be difficult to answer because, I guess, it needs to be experienced. Another little concern in my list is that sometimes you cannot tell if you are holding an object or not. Having a name can help in these situations.

So (maybe) you need a gui that is always active that shows the entity name every time an entity is frobbed. This only works when the entity is properly named (so not atdm_moveable_ball_spiked_large_2 for example). But maybe you think of an addon to include a bunch of alternative names for the entities of a specific mission?

Movable entities have a name spawnarg. It just doesn't show up in the game. So I have no idea what you mean. You propose an always active gui that lists the entity name when you point your cursor on it?

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. During development of HHI I did not know how to do that. Since the following HHVF was planned much smaller (I think the release version did not include more than 4,000 entities), I did not consider combining entities as dmap still was possible in acceptable times on my machine. In HHTLC I started combining entities when reaching ca. 7,000 entities. At that time, almost everything was finished and I did not add more than ca. 150 entites after that. 2. I save new revisions every 20 - 30 minutes and mark every revision to understand what I combined in there. This approach allows you at least to retrieve certain items during a later stage in case something went wrong or a module needs changes. In HHTLC most of the piping stuff in the logistics building and below the lake has been merged into new entities each consisting of ca. 10 - 20 source entities. 3. This depends on the nature of the architecture. For warehouses, building facades and mansion interiors (just to name a few) there are lots of core assets as you know, but there is not really something suitable for, let's say, an underwater station as I included in HHTLC. Thus I used in my last mission brushes for most of the stuff below the lake. Apart from that, there is the question whether certain modules should allow access into a single room or an entire building. I had lots of entry points in HHVF and thus did not use Springheels exterior modules, but used brushes with the respective exterior textures in order to receive snapped surfaces even with modules including windows/door frames for building access. 4. The thought crossed my mind as well. When reaching 7,200+ entities in HHI, I tried to SEED certain entities as I learned from your map "Into the Black". Did not work on my end: after seeding only a small amount of identical entities (ten or so) I was not able to dmap anymore (=dmap never completed). I ended up deleting ca. 300 or 400 entitiy modules and replaced them with brush modules merging those then into func_statics. I guess SEED should be used long before the critical value of 7,000 entities (that is, 7,200 on my machine) has been reached? I once tried SEED for grass as described in the Wiki. As far as I recall it worked pretty well, but had a dramatic impact on fps. Don't know why: the "SEEDED" grass area was quite small, but maybe the rest of the area was too large in general. On the other hand, I do not really know how to apply SEED properly as I never completely understood the explanations in the Wiki. Hm...don't know if this is helpful. Jack

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

Since it already has been mentioned in the forums, I'd like to announce a small project of mine. A few weeks ago I was playing Legend of Grimrock and it struck me that their level design is extremely simple and modular, and yet, the player can spend quite a lot of time in the game. And it looks pretty, too! So I wondered if it wouldn't be possible to create a modern "Dungeon Crawler" (solve puzzles, fight monsters, collect loot, progress your character, upgrade your equipment) type of game inside the TDM engine. The engine already supports a lot of things one needs for this, and the overal structure and assets work, too. And with prefabs, one might get the level layout done quickly. However, building a few test prefabs in DR is easy, but creating a full mission out of them is quite painful. Not only needs it a lot of planning, but you can also spend a lot of time "upgrading" things later on. For instance if you later want to add a grime decal to the walls, you have to revisit the entire map. Even worse is if you find out later that your block size must be bigger or smaller. So the idea was born to create a sort of framework that can assemble missions from prefabs. Preferable while getting the description of the mission from a text file. So far, this has been a lot easier than I thought. Here is what I got working so far: Overview: You can describe your mission in a (Unicode) text file. This contains overall options, different locations (each location can have its own ambient light, music,name, fog), and the connections between the locations. Each location can have multiple "floor levels", these are stacked on top of each other. The config file also specifies which symbol means "use this prefab". It is also possible to specify links (per location), which means you can say "this lever with the symbol A opens the door with the symbol D". The framework reads the prefabs, and then positiones them in the map. It also glues all the locations together, adds location_info entities, a player start, an exit, and an objective to reach the exit. The resulting map is then enhanced with script objects (all nec. assets are bundled together), and automatically dmapped via TDM. Everything then is packaged together into a working .PK4 file. My demo map takes about 20 seconds, where 15 are dmap. In addition to the "basic" stuff I also managed to get a few things working, like a pressure plate, portcullies, and also made some puzzles. Oh, and per location fog (fading from location to location). Different difficulty levels are also supported, one can specify "this prefab appears only on easy" etc. You can find more info and screenshots and demo here: http://bloodgate.com/swift/ There is also a developer diary where I will be posting interesting entries from time to time. Here is an DR shot of a sample level, consisting of small modular prefabs and one large (the large hall on the lower left): The next steps will be to add more randomness (either static at map generation, or at runtime, so the map is slightly different each time you replay it). Also, while it is already possible to "overlay" prefabs (e.g. "for this location, look first here before falling back to the default"), it is not yet possible to "reskin" prefabs. This would be something which is impossible in DR (you cannot really reskin worldspawn brushes, unless you live with the fact that it is all manual For now I'm quite excited!

Last night we chatted on Discord about Vulkan support and PBR, bringing up a system for adding proper reflections once more. I suggested screenspace reflections but it was argued reflection probes would still be better than SSR in our case, a ticket for that is already open but I'm uncertain whether it's the best way: A manual approach would need new entities to be placed by the mapper... this requires extra effort and would exclude old FM's that are no longer updated, while the result will also be inaccurate and static meaning you won't see an AI reflected as they walk on a shiny metal plate for instance. If PBR with realistic graphics can be a hope for 2.12 or later, we'll definitely want to do it right rather than using a limited / limiting system. A technique came to mind that might just work for our engine and setup. I wanted to share it here before I forget the specifics; This might already be a common practice and even have a definition, for the purpose of this thread I'll just describe it as I originally imagined it and feel this would work for our engine. The idea is we'd use reflection probes but in an automated fashion: A probe is automatically spawned in every valid area (within bounds) in the player's view, at a given grid unit size. For example: If the grid scale is 16, a probe may exist at position '0 -48 16' another at ''0 -48 32' and so on. Every point projects its result on all surfaces in its radius which contain a specular channel masking it, the best alternative presently available till we were to convert all textures for PBR support. The cool thing is the same cubemap can also be projected as a light source, allow for global illumination in addition to just reflections! This would be similar to how the Irradiance Volume works in Blender / Eevee except each dot renders a little cubemap from its perspective. I already know what everyone is rightfully thinking: This is going to kill performance! After all each probe needs to produce a render from its perspective, and being a 360* panorama it will open portals in all directions. Normally that would be insane, but I thought of various ways in which the impact could be greatly minimized to very bearable amounts. The frame buffer of each probe will be at a very small resolution by default since much detail shouldn't be needed. Even 64x64 per cube face might do. Each probe only needs a draw distance double its grid size, given it only has to see as much as is necessary to fill the gaps between it and its neighbors. So if the grid size is set to 64, each probe would only have a draw distance of 128 to cover the space in between its neighbors, nothing beyond that would exist to it. Only probes the player can see would ever be spawned and calculated; If the view frustum doesn't overlap the virtual cube who's corners touch that probe's neighbors, the probe is dropped from memory. Probes are also only spawned in a valid visible space, never out of bounds including rooms culled by portals. A draw distance after which probes are removed or not spawned can also be included. This would further help by making any probe further than X distance be ignored, slowly fading away as to not noticeably pop in and out of existence. Reflections / GI are a discrete effect you'll only see up close. Similar to lights and shadows, the result of a probe should be cached and not calculated unless necessary. This means that unless something moves within radius of that probe its cubemap won't be rendered again. Probes would only be updated either when they first come into the player's view, or if something touching their cube has moved. Note that particles and lights with animated textures would have to count as you may see them in a detailed reflection, candles and torches would force constant updates per-frame for probes they intersect. If with all that performance is still affected, frame skipping is also a solution: Reflection probes can update at a lower frame rate to further decrease their impact. If you have a 60 Hz monitor and are running TDM at 60 FPS max, reflections could run at 30 / 20 / 10 FPS without looking out of place. They could in fact be defined as a fraction of your average framerate, so for the FPS you get you can decide whether it's going to be 1/2 or 1/4 or so on of that... this would have the added advantage of exponentially gaining back FPS the lower your FPS goes. There are several reasons why I believe this would be better than mappers manually placing new probe entities: Extra work is required for the mapper, who needs to figure out how to cover each area in probe lights. Every piece of the map would need to be encompassed in a reflection / GI probe otherwise you won't get shiny surfaces or bounce lighting which will look out of place. Most existing FM's will never be updated to use this: Only maps created or updated after the feature is introduced would benefit, anyone playing old missions will get boring visuals without reflections / GI which will be inconsistent to new ones. I strongly believe this should be done as an universal effect like SSAO. Single large probes will produce inaccurate results; The larger a cubemap is, the more drift and a fake results you get with distance from its center. This can be mitigated by using parallax corrected cubemaps which should be used for automated cubemaps too... none the less you get a single point of vision for a large room which makes the result inaccurate the further you go... with an automated approach you could have many probes in a dense grid (if your hardware allows it) for a much more accurate result at any position and angle. What are your thoughts on this solution, do you think it's realistic and can work out? I do believe it should be either this or screenspace reflections the way they're done in Godot or Blender / Eevee. If SSR isn't the right choice for our engine, reflections and global illumination alike could be captured using a global grid of capture points shining within their respective areas.

LOD entities are basically just func_statics with pre-applied LOD spawnargs unique to that model - so the LOD attributes can already be applied to func_statics. The LOD entities are just needed to store these spawnargs. What could work is to introduce a new type of file, .lod, which would assign default LOD properties to models. This way any (func_static) entities with these models would automatically exhibit LOD behaviour. LOD entities would become redundant. Yes, this sounds very good. Some more brainstorming to refine the concept: - would be good if deprecated entities (mostly light sources) were excluded. Without seeing the entity tree view or folder path, you have no way of knowing that an entity has been deprecated. - it'd be helpful if entity descriptions were shown in the model browser when an entity is highlighted. Maybe they can take the place of the material or model stats, if they're available. - the old search method (type in a string, then press arrow keys to jump from result to result) might need some refinement to stop it from expanding so many nodes in the process. There will be more and larger expandable nodes if entities are added.

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.