Search the Community

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!

All of sudden, as I am building my mission, I am getting an error message that boog_gotisch is missing. Neither part of that name exits in my skin.mtr,or map files. In DR if I search for that name I see is listed under textures/darkmod/boog_gotish and it says Defined in _autogenerated_by_darkradiant_.mtr and Description says the material is missing! Well, DUH. I have not seen the name and it does NOT, nor as I know never has existed in my mission or ANY of the files. Is this part of default Dark Mod files? Confused (as usual), BlackMagic

PLAYERS * Volumetric lights appeared late before the previous beta, so the quality of volumetrics in 2.10 was rather poor, and the dithering pattern was very annoying to look at. The feature received a lot more development, and now adheres to the standards of modern rendering. The dithering pattern is gone, performance should be much better, and now you won't miss volumetrics even if you prefer to play with stencil shadows all the time! (thread) * Thanks to a certain "AI-heavy" mission, the game code has received major optimizations. It is most noticeable in low performance conditions, when game modelling takes a lot of CPU time. Previously the game could easily descend into the "spiral of death" with FPS falling below 5, now it is way harder due to better scheduling of AI thinking. There is a variety of other game code optimizations which make our lives slightly better. * New version includes several optimizations for shadows, mostly stencil shadows. A long-standing inefficiency of stencil shadows with antialiasing is fixed, new tile-based optimization is added for soft stencil shadows (thread), small lights with large meshes work faster due to BVH efforts (thread). On the side of shadow maps, the rules for distributing the resolution budget are changed: small distant lights no longer steal precious bandwidth for themselves. * There are several improvements on gameplay side as well. The core mechanics of blackjacking enemies has received subtle, yet helpful improvements (thread). Now you can grab many close pieces of loot by holding down the frob button, instead of picking up each item individually. There are several improvements to crouching, making it more responsive (thanks to @Daft Mugi). The in-game downloader now supports "sort by release date" ordering. * There were a ton of small bugfixes for issues like: bow stuck after load, wrong strafe-walk sound, crash when saving shortly after the death of an elemental, melee combat crash, issues with leaning onto doors, missing fracture sounds after loading a save, X-ray glitch in the first frame, toggling solidity/visibility, lightgem on game load, etc. MAPPERS * The engine now supports OBJ model format. This format is much more popular than ASE and LWO. The engine loading code is very lightweight: it will use your model exactly is as, and load it very quickly. The OBJ format is preferred for large meshes due for faster loading times. The only possible downside is somewhat larger download size compared to LWO, although not much and not always (thread). * Renderer should deal with large meshes much faster, thanks to BVH optimizations. Recall that idTech4 was made for very low-poly models. When renderer frontend sees a "surface" in a model, it always treats this surface as an atomic piece, doing all computations for all of its vertices and triangles. This is very good for low-poly models, can heavily drag performance down with large meshes, as several recent missions noticed during beta. The BVH data structure breaks every surface into smaller chunks, allowing renderer to quickly cull away whole chunks. This makes a big difference in case of large meshes (e.g. terrain) lit by many small lights (thread). * You no longer have to write frob-highlight stages in materials, since they are added implicitly. The problem with these stages was that were very easy to forget, which resulted in no highlight on frobable items. Also it increased cognitive load and scared mappers away. While writing frobstages is no longer necessary, the old stages work just fine. So mappers can still customize frob-highlighting if they really want to (thread). * It is now legal to override a single decl of core game in your mission. Recall that "decl" means a material, a skin, an entityDef, a particle, etc. Note that overriding a whole file from core game always worked as expected, but overriding a single decl from a file did not work reliably before (despite the common belief that it should). * The major cleaning of shaders resulted in some changes in lighting model. The aim was to make TDM lighting closer to the standard Phong model, and make it more logical in general. The changes should rarely make a big difference, aside from probably stronger specular (thread). * Added error-reporting to the GUI scripting engine. Implementing GUI scripts is very hard, error-prone, and confusing. Aside from surprising differences in Doom 3 GUI behavior compared to e.g. Javascript in DOM, a lot of confusion was caused by total lack of any error handling whatsoever! In the new version, all possible errors should result in easy-to-understand console warnings, so writing correct GUI is much easier. Also, we fixed a few features, and added a few new ones to the GUI engine (thread). * dmap command received minor improvements. Yet another big rewrite happened for T-junctions fixing code, since it took tremendous amount of time on one mission. Also a few precision improvements were made. * Other small fixes and additions: added script functions getAnimRate / setAnimRate for tweaking animations added script function setObjectiveNotification for silent objective change added script function getCurInvItemCount for interaction with inventory added script variable "AI_ENEMY_TACTILE" to the base AI scriptobject, which is true whenever the AI is in tactile range of an enemy added spawnarg absence_alert_increase for loot items as a proper substitute for absence_alert, giving control over how much an AI gets alerted if that piece goes missing added spawnargs allow_idle_anims / allow_random_headturning for customization during a running mission, useful i.e. for cutscenes AIs notice broken fracture entities trigger_multiple now works on stationary AIs almost doubled tracemodel limits, raising the restrictive limits for making collision meshes for moveable items door movers can now call "used_action_script" whenever something like a key, lockpick or other item is used on them, if they have the spawnarg "call_used_action_script" "1". ASSETS * Many new assets from capable creators in our community have been incorporated into the core assets. These include: Loot assets: Detailed coins and ingots with accompanying lore. Link Ancient loot items suitable for museums, collectors and ancient sites, first seen in the Volta series. A tiling treasure hoard texture for those with unimagineable wealth. 6 detailed book skins including 3 that are lootable, a first for TDM. Link Security assets Highly detailed standing and wall safes - with or without an accompanying combination lock. Link The combination "safe lock" is now part of core assets and can be operated by either scrolling or frobbing. Mappers no longer need to track down this asset and include it with their FM files as a custom asset. Wall-mounted locks in the style of those commonly found in the original Thief games. Camgoyle sentry, a magical stone guardian based on the security camera shooting magical projectiles at the player, first seen in Written in Stone. The prefab also includes a power source pedestal. Link Fully useable audiograph for playing recorded sounds, first seen in the Accountant and Shadow of Northdale missions. A new full-featured scriptobject makes them easy to implement and control via spawnargs. Wiki Furniture assets Posh upholstered armchairs and sofas for the wealthiest nobles. Link A new high-detail grandfather clock with a working scriptobject and a mantle clock. Link A gothic-style cabinet. Link Office assets Including bundled stacks of paper, blueprints, a letter, crumpled paper, waste bins, an end table and an ornate table. Nautical assets Full-scale modular ship prefabs with interiors, allowing anyone to assemble a ship for a nautical mission in a matter of seconds. 1 merchant galleon and 2 smaller sailing ships are available. Link Link Link A large galleon ship wreck in 2 pieces for those sailors who have met an unfortunate end. Decorative assets An impressive multi-tiered wall fountain, first seen in the mansion in Noble Affairs. A new pair of marble lion statues. Link A standing stone menir with carved symbols on it, ideal for pagan missions. Link Stone pedestal with purple cloth for presenting valuable items. Textures High-resolution cobblestone textures for detailing the streets of TDM. Link Starry wallpaper. Lamps A set of 6 bronze vintage lamps has been added for particulary posh establishments. Link Thief-style charge post streetlamp. A new open-top carriage, the barouche. Link Miscellaneous other models, including: wall planter, 7 small "foliage" herbs, 2 mine carts, 6 shop signs, equippable feather duster and 5 decor plates * We fixed all loading warnings on all existing assets. This became possible after creating an automatic map generator which forces the engine to load all assets from every group. All the references to missing files are fixed too, which means a variety of assets have become available: Old noblewoman skin, plain mage robes skin, moor helmet, electrical arcs, stone window decals (5178), yellow banner skin (5563), wine barrel (Link), grass particles (5689), lampion lights and more graffiti decals. PROGRAMMING Under the hood, we updated third-party libraries, and moved to Visual Studio 2022. The "Debug With Inlines" configuration was split into "Debug Editable" (with hot-reload support) and "Debug Fast" (fastest debuggable). Marking the final step in transition to tdm_installer, the old tdm_update program is finally removed, with TDM packaging code extracted to standalone program.

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?

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

I've been getting a lot of assets for a project recently. A lot of it is free, but during the Black Friday sale I did grab a good number of paid ones. I like the massive & kitbash kind of sets (like the Kitbash 3D ones) that give you basically an entire ecosystem, where you can drop entire city blocks in whole, but you can also take the modular parts and do your own thing with them. And once you have some big pieces laid out, it's much easier to do detail work around that than trying to do detail work from the ground up. That's the main lesson from the "stepwise refinement" method that's always been my go-to ever since I read it in Dromed's first tutorial that came on the Thief2 CD. I recommend that method to everyone, BTW. The thing with paid assets though is sometimes you do get a dud, something that just doesn't look good except in the one precise context the seller made a screenshot of, or at a distance but not up close. Sometimes you don't know the value of an asset until you're actually playing with it in a map, especially if you're mapping kitbash style (mixing & matching modular pieces). So that's the risk of paid assets. But like I said, sometimes they're just so good & you get so much that it's worth it.

@snatcher Hopefully there will be a sequel in the future. I started concepting and even building multiple times in the last ten years but never came close to something useful. I wish that I find more time in the future to have a decent sequel for this mission, yes.

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.

Not too thorough, I only found But through the years playing TDM there is a kind of default picture of what rooms and services different kinds of buildings should have. For example: Basic apartment: only one room (bed, chair and table or desk), shared loo in the hallway. For a meal the tenant has to go to the nearby inn, and to the nearby public bathhouse for washing up (can't remember having ever seen a public bathhouse in any mission, though. Maybe most inns usually provide bathtub service as well?). Lighting only by fire. Comprehensive apartment: sleeping room, private loo, heated living/dining room, serviced apartment kitchen. Lighting mostly by fire. Luxury apartment: multiple sleeping rooms, private loo, bathroom with tub, living room, dining room, study/library room, serviced apartment kitchen. All rooms heated. Lighting mostly by electricity. Manor: multiple sleeping rooms, loos, bathroom with tub, living room, dining room, study/library room, staff rooms, stairway, kitchen, storage room, garden, guards. All rooms for the residents heated and mostly lighted by electricity, staff rooms heated scarcely and lighted by fire. Fixed doors are a both credible and lazy way to 'hide' several rooms, while keeping the mission straightforward. All kinds of 'missing' rooms can be behind those doors, provided that the building is big enough to contain them. But regarding the organic Bridgeport way of building, most adjacent buildings got heavily intertwined by the years. Your CoS series makes clever use of fixed doors and these organic building blocks, which makes it both credible and straightforward, saving yourself and the player a lot of time. Ah, I missed that sign. If it's only for orientation, maybe put it on the map then? I have sore feet now, hehe!

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.

I was wondering whether there would be interest in making the dark mod (which is now a standalone game, based on the id Tech 4 game engine) into a modular game, and have the dark mod made into a mod/plugin that can be added to the game/game engine. The idea is to make a platform for making games -so that people can simply make a game by making a mod and then implement it to the modular game (lets call it the OS FPS for ease of reference). While this is all ready possible (id Tech 4 and some other game engines like id Tech 3 / Enemy Territory engine, Cube, Cube 2, Tesseract, ...), vehicle capability is not yet standardly introduced* to these game engines, not are the ability to use large maps; in some cases, system requirements are also high. The project outline can be found at http://sourceforge.n...heosfpsproject/ Note that, while I envision the system requirements to be lower than what they are with the Dark Mod presently, some mods/plugin content like the Dark Mod can be kept as is (so requiring higher system requirements). The vehicle capability won't be actively used in the Dark Mod plugin content neither, but this extra code won't significantly reduce efficiency neither. The other games/plug-ins I'm focusing can take full advantage of this then, and focus more on the type of games I wish to pursue with this project. I nonetheless think however that the id Tech 4 engine can nonetheless be a good game engine to use as for the OS FPS. This as the system requirements are not all that high (much higher than Battlefield Heroes or AssaultCube but still within a margin as long as a good GPU is used -see http://www.game-deba...9&game=Doom%203 -), and the engine is open-source. Large maps perhaps won't be too much of a problem neither (Enemy Territory uses rather large maps too -smaller than battlefield but still- and despite that, still runs fluid even on relatively slow(er) PC's). I'm also guessing (please confirm this) that for id Tech 4 games, there are also sufficient game development software. I got that impression from the ET Legacy site -see http://www.etlegacy.com/ -

YOU TAFFERS! Happy new year! Deadeye is a small/tiny assassination mission recommended for TDM newcomers and veterans alike. Briefing: Download link: https://drive.google.com/file/d/1JWslTAC3Ai9kkl1VCvJb14ZlVxWMmkUj/view?usp=sharing Enjoy! EDIT: I promised to someone to write something about the design of the map. This is in spoiler tags below. Possibly useful to new mappers or players interested in developer commentary.

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:

@snatcher did you play the FM? @computertech82 Your review is almost identical to that of the other review bomber, neonstyle, who didn't play the FM for even 5 seconds but who noclipped to an area where he airdropped before the same door which confounds you. How did you get to that door if you didn't use a rope arrow in the vents? If you were a bit observant and were actually trying to play the FM you might've noticed that the building with that confounding door has two floors, the second of which is ringed by a wooden balustrade where a well placed rope arrow (!!) allows the nimble or even not so very nimble player an entrance to a hall where there's a shooting gallery of open windows to use the water arrows (the player should have 20 or more of them by now) to extinguish the confounding torches. There's also a keyed (!!! how awful !!!) door up there where the thoughtful player might expect a key might be snagged from off the ass of one of the guards sitting up ahead playing poker. That allows the easiest entrance. But oh what the hell. Once targeted by bombers ever targeted and there's nothing to do about it. In a post above I appended an edit to a response to vozka that, since it was an edit, probably went unnoticed so I'll repeat it here since it's really my last word for the time being, given my circumstances of having to learn how to edit all over again (yes, I found myself in a situation where I lost the ability to do even basics like change the ambient light setting! and a lot of the necessary fixes are difficult). @vozka I can now give a more coherent reply and I'm recovering nicely. I agree with every point of the critique and I'm in a quandary about how I should go about applying fixes. I think your preamble to the actual critique shows an exact understanding of what I was attempting to do in the FM. You understand that it is story driven. You understood the main elements of the story, that basically a farm boy of pagan background entrusts himself with a mission. His village needs help. Because he's earned a certain bad reputation and fits the bills requirement for having daring and a certain amount of cunning, so the mission is a natural fit; also amongst other things he wants to earn himself a good name. He has friends to help him along the way, and makes friends of friends along the road of the pagans. The FM uses devices to distinguish the pagans from the enemy they face and divides the space into distinct enemy and pagan areas, and areas in between. The pagans are opposed by corrupt nobles and their army of fundamentalist Builders, as corrupt as the nobles they serve. It's very black and white. Then there's the city guard who, being ousted from real power by the Builders are resentful and won't help the Builders and will ignore the player unless attacked or the player is caught trespassing in their inner court. That's about it. The critique mentions some gameplay elements that detract from the story and I agree about those. It also mentions gameworld failings that interfere with enjoyment, with gameflow and immersion. It seems to me that to fix these flaws will require a total rewrite of the FM, rebuilding the entire thing. For example, I understand the problems mentioned w.r.t. the lighting and know how to fix them, or at least bandage them over so technically there's no apparent problem. But I have a notion that the not so apparent problem here is in what's being lit. That there should be a rearrangement of things so light can be more focused and contrasted with the dark. I'm only starting to think through ways that I might do this. Needless to say anything like this would take time, probably a year, and I'm not sure whether I'm up to it. I've been playing a new mission by Kingsal and know I haven't anything near that level of skill. IMO the FM is unplayable right now. Actually I had asked that it be removed from the TDM database. I don't like the idea of leaving a blot. Thank you again.

What you described is standard practice in the industry. You're supposed to start with rough brushwork first, laying out the entire level in a rough block form, see if it works, change what you need to, and then you take progressive passes developing and later detailing each area with modular set piece meshes or more detailed brushwork absent that.

Seems to confirm: https://bugs.thedarkmod.com/view.php?id=5718 does it happen in the latest dev build: https://forums.thedarkmod.com/index.php?/topic/20824-public-access-to-development-versions/

@Fidcal I know where you're coming from. GPT-4's continuity can sometimes falter over long stretches of text. However, I've found that there are ways to guide the model to maintain a more consistent narrative. I've not yet tried fully giving GPT-4 the free reins to write its own long format fiction, but I co-wrote a short story with GPT-4 that worked really well. I provided an outline, and we worked on the text piece by piece. In the end, approximately two-thirds of the text was GPT-4's original work. The story was well received by my writing group, showing that GPT-4 can indeed be a valuable contributor in creative endeavors. Building on my previously described experiments, I also ran GPT-4 through an entire fantasy campaign that eventually got so long the ChatGPT interface stopped working. It did forget certain details along the way, but (because the game master+player dynamic let me give constant reinforcement) it never lost the plot or the essential personality of its character (Thrumm Stoneshield: a dwarven barbarian goat herder who found a magic ring, fought a necromancer, and became temporary king of the Iron Home Dwarves). For maintaining the story's coherence, I've found it helpful to have GPT-4 first list out the themes of the story and generate an outline. From there, I have it produce the story piece by piece, while periodically reminding the model of its themes and outlines. This seems to help the AI stay focused and maintain better continuity. Examples: The adventure of Thrumm Stoneshield part 1: https://chat.openai.com/share/b77439c1-596a-4050-a018-b33fce5948ef Short story writing experiment: https://chat.openai.com/share/1c20988d-349d-4901-b300-25ce17658b5d

I just picked up on what nbohr1more posted here about building from prefabs. I was just wondering how easy could we make it for novices to plug together modules to make new simple FMs. OK, likely they would lack originality and have lots of weaknesses but they might draw in more mappers who would not normally map and not all maps need to be highly advanced 'super maps.' I can't work on this currently but we could spend a few months kicking ideas around so maybe one day... Many of my first thoughts likely won't work. Let's see what if any will. Performance: Keep it simple so performance is less of an issue. Do not optimise. You only normally gain tiny fractions anyway except in complex situations and the prefabs rooms can be kept small and simple anyway. Just cover up ragged edges and junk waste. Keep focus entirely on speed building. Start Map: Needs a new simple one just for this probably just extended objectives, tools, ammo etc. Needs some thought. Prefabs: So I'm thinking first of customisable 'rooms'. A 'room' is defined as one closed volume with 'doorways' whether it be an alley, a mineshaft, whatever. Each room built to a standard wall thickness and grid. Each prefab labelled, eg, 'plug in compatible'. Standard texture types of same scale and alignment so can easily change. Each prefab has distinctily named layers for ease of re-selection and re-texturing. Each room has doorways at set points, eg, always say at positions 0.25, 0.5 075 along any wall. So to connect any two rooms you can align them easily. Doorways designed so they can be blocked off easily. For instance, if all doorways have a frame that protrudes 0.5 units then a 'blocker' prefab can be dropped over it.. This might for instance just be a a big vertical brush. Possibly leave the doorway inside for quickness but disable any working door. Stair room connectors and stair units. AI and pathing: A set of prefabs each with one AI type and say 8 paths + waits linked in a loop. Waits set at say min 10, max 30. Easy to change. Mapper changes AI skin & head for variety. Paths dragged to where needed. You can't really have too many; a one corridor guard can have 4 at each end. Paths are just discarded if not wanted by removing the AI's first target. Don't waste time deleting - you might change your mind later. Sitter prefabs with seat Sleeper prefabs with bed Problems: Dark Radiant's multiple item rotation bug is a big problem. Rotating a complete room prefab is hopeless. 4 sets of every prefab is not practical. So anyway, the mapper just Starts with the start map Inserts prefab rooms so each connects with another at doorways. Forms a basic structure of rooms. Retextures if needed. Adds or moves or changes any furniture or other models (or maybe does this later Inserts AI and adjusts Inserts loot Inserts custom objects Inserts and modifies just a few ultra simple pre-made generic readables. Modifies simple objectives.