Search the Community

Is not being able to create new brushes from hiding all layers known? Repeatedly now I've found I've been unable to create new brushes by dragging. Hitting ESC doesn't change the behavior (confirming I don't have something random selected). Quitting DR and rerunning resolved it. But I believe I've found the cause, I was hitting Hide All layers, then turning on the layer I wanted--no new brush. Instead, if I unchecked other layers I was still able to build. Similarly, if you uncheck all layers (it's not just the Hide All button) so no layer is showing, then turn a layer on, no dragging out new brushes. So something about the condition of having no active layers seems to bork the new brush creation process it seems.

@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...."

I guess what I can do is open the map in a text editor and search for the entity by name, that gives me the entity number. Then I can go to menu Map -> Brush and there typ in the entity nr. I find it strange that even in DR version 3.8, there seems to be no direct way to search for entities by name. I mean, this should be on top of the list 10 versions ago I would think

For free ambience tracks it's as Freky said: you look around on the internet for tracks with the appropriate license to be included in your FM. Fortunately, you likely don't even need to bother doing this as a beginner as there's an entire "Music & SFX" section of the forums full of good ambient tracks for you to use if the stock tracks do not meet your fancy. You might also be interested in Orbweaver's "Dark Ambients", which come with a sndshd file already written for you.

I see this now and then. It's been happening for a couple months now. But after a half-dozen instances in the past hour, I thought I'd post something. I'm working with brushes, creating and dragging and moving ... ... and all of a sudden I left-click and drag to create a new brush, and nothing happens. It's not a case of drawing in a hidden layer, or drawing with a texture that's filtered out. The brush . simply . isn't . there. The only recourse I have is to restart DR, after which brush creation is back to normal. Anyone else seeing this behavior?

The problem with a "theme" system (I think) is that it's forcing the assets into categories they may not fit well into or that don't make sense; or I mean it's forcing the mapper to think in terms of discrete "categories" at all, when that may not be most effective. Whereas a tagging system doesn't impose any "system"... Tags are completely open-ended, and could be at any level of scale or heirarchy -- you could have: bathroom-furniture, made-of-wood, Victorian, X-author's set, good for triggers, items for a bookshelf, architectural, magic, etc, etc... as tags, but not all of those categories make sense as discrete themes with other co-themes at the same level. I guess this is a longwinded say tagging more intuitively lets you target what you want without imposing a structure you have to wedge it into ... just a totally open field of tags from any walk of life. Edit: This is not to say tags should be arbitrarily specific. There should be tags of general categories too of course; even these will be the backbone of the system. But the whole point is tagging allows multiple layers, so you can use the general category tags to start your search, then ween it down with increasingly specific tag sets, whatever is best for the asset set. Some asset sets, or especially combinations, will categorize differently than others, and tagging is ok with that. Edit2: The image I have in my mind anyway is like a photo-collection tagged collection. There's an opening page with a tag cloud with the most common basic tags (general category) the largest in size and minor ones smaller, which you click on and then you get a browser with that set of textures. Then on the left hand bar will be all the tag-combinations within that set (other tags textures in the set are carrying; then in parentheses maybe the number of AND-textures it'd filter down to / OR-new textures they'd bring in), the major tags again larger or highlighted somehow, which if you click one of those new tags, it'd filter the browser to show the AND set. And maybe there's also an option so you could have an OR set and get both (or even select a new OR set from the full tag cloud), which adds new textures into the browser window, and also new sets of tags in the left-bar (the new tags carried by one or more textures in the new set). Also there's a place you could back out of a tag to cut that subset out. So you could open up & winnow down the set as you desire. It ends up a kind of way to browse through the whole collection by navigating through tag AND/OR combinations. Also there's a search bar where you could type in a tag at any time also.

I investigated the topic, and I still think it is too hard. Precomputed visibility is perhaps the best thing for us. So we can split space into cells, and precompute whether cell A and cell B have unoccluded straight line connecting them. We can limit occlusion only by brushes: there is no need to take models/patches into account. Precomputed visibility should be done on per-area basis. When we compute the visibility data for one area, we consider all visportals and all other areas opaque. In other words, we only check for direct visibility within the area. If such information is available, it can be combined with existing visportal&area traversal code. The main problem is how to precompute visibility on per-cell basis. A solution must: Be conservative: you don't want to occasionally see small holes into nowhere Do perfect occluder fusion: otherwise a big house would not occlude most of the stuff behind it. Have sane build times for brush geometry of our scale. This inevitably leads to pretty complex algorithms. If mapper can add a special brush and say "this is major occluder in visarea N", then we can probably (not sure yet) verify that he is correct in saying that, and simply raytrace this occluder during visportal traversal. But realistically... I don't think mappers would really use this tecnhique, except maybe for a very few people/missions.

For the FM? For beta 1 it's here: https://drive.proton.me/urls/H1QBB04GA0#oBZTb1CmVFQb I've already done around 100 fixes though, so you might want to wait for beta 2 which should be ready in a couple of days hopefully. All links are in the first post of the beta thread here: https://forums.thedarkmod.com/index.php?/topic/22439-the-lieutenant-3-foreign-affairs-beta-testing/

Thanks for the clarification! I had no idea antiportals were a thing, I can't find an antiportal texture or entity in DarkRadiant so I presume it comes in another form? This means the behavior I'm imagining is already coded in there somewhere: Only change then would be automatically treating every solid brush as an antiportal, of course without having it derender itself only what's behind it... at least that's what I'd initially think, reality is always more complex. Obviously we don't check all world surfaces on the map: Visportal culling acts first so any wall that isn't in an open room doesn't exist from the start, same for surfaces that don't poke into the view frustum and are outside your FOV... if a smart approach is possible we could even check walls in order of distance from the camera so the mask masks itself and even walls covered by other walls are dropped. Only if a front-facing brush surface that wasn't portal-culled pokes into view it's calculated as an occluder; The engine then checks all entities that weren't themselves already culled by portals / frustum and removes those found to be completely covered by a wall's projection. This could be a big success is it could do all of 3 things: Hide models that don't poke beyond the mask, disable lights who's radius box is fully covered by the wall, and close portals that are fully covered by a wall meaning whole rooms can get hidden when their doorway is masked by an occluder. (Anti)portals do all of those things I believe, so it's a matter of somehow getting all surfaces to act as such in an optimal way.

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?

What has changed if anything between TDM 1.04-1.06..? in regard to copying a texture from the face of a brush to a patch..? Im workin on a large mansion where I am laying skirting board at floor and ceiling level, and jesus christ is f***ing annoying...!!! fyi - the patch is a 3 decision curve between wall/floor & wall/ceiling, the brush I am copying from is the same height and depth. if I copy from a horizontal face of the brush to the patch, the texture is stretched.if I copy from a vertical face of the brush to the patch, the texture is stretched.if I slice the brush in diagonally in half along its length and then copy from diagonal face of the brush to the patch, the texture is scaled correctly.if I then copy from the same diagonal face of the brush to a patch that's facing the opposite way (180 degrees), the texture is completely f***ed!if I then copy from the same diagonal face of the brush to a patch that's facing the opposite way (-Z 180 degrees), the texture is completely f***ed! So I have had to have 4 brushes, each in the plane of the path I am pasting too, each pair a mirror of each other and all with diagonal faces, just so I can paste correctly to these bloody patches.....AAARARGGHHHHHHJHHBH!!!!!!!!!!!!!!! FFS!!!!! Can I assume this is a bug and that possibly something can be done about it..? and I also assume I will have to post a bug report.

Interesting idea. Not sure about my upcoming time availability to help. A couple of concerns here - - I assume the popup words uses the "Informative Texts" slot, e.g., where you might see "Acquired 80 in Jewels", so it likely wouldn't interfere with that or with already-higher subtitles. - There are indications that #str is becoming unviable in FMs; see my just-posted: https://forums.thedarkmod.com/index.php?/topic/22434-western-language-support-in-2024/

In post https://forums.thedarkmod.com/index.php?/profile/254-orbweaver/&status=3994&type=status @nbohr1more found out what the Fixup Map functionality is for. But what does it actually do? Does it search for def references (to core?) that don't excist anymore and then link them to defs with the same name elswhere? Also I would recommend to change the name into something better understood what it is for. Fixup map could mean anything. And it should be documented in the wiki.

I started working on my first exterior area, and have been losing my mind over leaks. What causes a brush to go from being considered 'sealing', to 'needs to be sealed?'

Are you aware of the pointfile feature? Dmap writes these .lin files into the maps directory. Display them with File->Pointfile and look for red lines that visualize problems like leaks and visportal problems. Which faces of a brush are sealing depends on the material assigned to the face. I don't know exactly which ones seal and which don't.

Hi, I'm beginning to get somewhere in my understanding of DR and TDM. I've observed a few things in the learning process and want to make sure I understand the correct cause. I made a moat with shallow water at the bottom. Worked fine in TDM. I decided to make a bridge over this moat, and the first step was a large brush that filled the moat top to bottom partway along the length of the ravine forming the moat. Before I did any further work on the bridge, I dmap'd and went back in TDM to check on something else. When I came back to DR, I discovered that brush had somehow erased the part of the water brush which had lain inside it...and also erased the wall brushes it had crossed, which in this case opened a leak into the void. My question, then, is this: 1. Was this caused merely by crossing one brush over another? Or crossing centerlines? Or... 2. Does this only happen if one adjusts a dmap'd brush that crosses over another? Or... 3. Does this sort of thing only happen in relation to waterbrushes and/or void-sealing brushes? Or... 4. Is this because I still had the map open in TDM when I returned to DR to continue editing it? Or... 5. Was this just a fluke? I remember that in Dromed, it was important to keep brush creation order in mind. Is that the case in TDM as well? eg. should I put waterbrushes in only when I am finished with the solids of that area? Thanks again. I hope my questions aren't too annoying. They arise out of an active attempt to learn the editor. There is just so much to grasp at once. As a side note, my daughter's rabbit died today. She's had it since she was four, so now I guess this mission idea I had in mind has received an extra impetus, albeit a sad one, heh. We're writing the story together in detail as I begin to sketch out the mission shape.

I would only leave it as worldspawn if you need it to act like worldspawn. For example, if you have a nodrawsolid_wood brush covering a wonky wooden model and you want AI to be able to walk over it smoothly or it is to perform some sealing function. Other than that, just make a func_static so it gets filtered out in DR when you want to only look at sealing brushwork. So no harm in leaving it as worldspawn, but on the other hand you might get some benefit to making it a func_static.

Right now when you clone a brush the cloned version is offset by 1. I'm fairly certain I found a way to turn that off in my old installation, but now I can't find it. Anyone know where that option is?

Yes. Sure, I will change it, but I do mind. In addition to changing the forum title, I have also had the name of the pk4 changed in the mission downloader and the thiefguild.com site’s named changed. It's not just some "joke". The forum post and thread are intended to be a natural extension of the mission’s story, a concept that is already SUPER derivative of almost any haunted media story or most vaguely creepy things written on the internet in the past 10 or 15 years. Given your familiarity with myhouse.wad, you also can clearly engage with something like that on some conceptual level. Just not here on our forums? We can host several unhinged racist tirades in the off-topic section but can’t handle creepypasta without including an advisory the monsters aren’t actually under the bed? (Are they though?) I am also trying to keep an open mind, but I am not really feeling your implication that using a missing person as a framing of a work of fiction is somehow disrespectful to people who are actually gone. I have no idea as even a mediocre creative person what to say to that or why I need to be responsible for making sure nobody potentially believes some creative work I am involved in, or how that is even achievable in the first place. Anyway, apologies for the bummer. That part wasn’t intentional. I am still here. I will also clarify that while I love the game, I never got the biggest house in animal crossing either. In the end Tom Nook took even my last shiny coin.

Personally I think this is the worst idea ever. The Reason forums has LOADS of info and knowledge, built up through years and years. I'm really sad to see it go away, and I can't understand why they've made this decision. https://www.propellerheads.se/forum/showthread.php?p=1579099#poststop

I've seen fun workarounds like that in other game modding as well. Years ago, maybe even a decade, some fella who was making a mod for Mount & Blade over at the Taleworlds forums revealed that he put invisible human NPCs on the backs of regular horse NPCs, then put the horse NPCs inside a horse corral he built for one of his mod's locations/scenes and then did some minor scripting, so the horses with invisible riders would wander around the corral. The end result was that it looked they're doing this of their own will, rather than an NPC rider being scripted to ride around the corral slowly. Necessity is the mother of invention. I don't know about the newest Mount & Blade game, but the first generation ones (2008-2022) apparently had some sort of hardcoded issue back in the earlier years, where if you left a horse NPC without a rider in its saddle, the horses would just stand around and wait and you couldn't get them to move around. Placing an invisible rider in their saddles suddenly made it viable again, at least for background scenes, of riderless horses wandering around, for added atmosphere. First generation M&B presumed you'd mostly be seeing horses in movement with riders, and the only horses-wandering-loosely animations and scripting were done for situations when the rider was knocked off their horse or dismounted in the middle of a battle. Hence the really odd workarounds. So, an invisible NPC trick might not be out of the question in TDM, even though you could probably still bump into it, despite its invisibility.