Search the Community

I was looking into this a bit more and conclude that the translation system in itself is actually an universal external data system. So instead of xdata, you could use a #str_someword and then reference to that in the /strings/fm/english.lang file. Well I guess it's probably not really news for some of us. Edit: This actually works fine: File english.lang for Thief's Den "#str_Nobody crosses me! Must get back Frothley's scepter Creep stole off me." "Nobody crosses me! Must get back Frothley's scepter Creep stole off me." Then in the objective editor you add #str_ before every objective text. This way it's easier and you can still see which is which.

This might be frowned onto by tdm mappers/veterans, but I find it strange that it's considered ok to use text inside entities, which can then be found inside map files. That in general seems badly organised. Like for example with text decals: https://wiki.thedarkmod.com/index.php?title=Text_Decals_for_Signs_etc.#The_Decal Personally I think xdata could/should be used for all instances of text (except maybe darkmod.txt and subtitles), including readme files and GUI files. Or at least some kind of external text file. Could be something else, but the xdata format seems good and supported. So the sign text prefab could have a default xdata_contents spawnarg instead of gui_parm1 . Edit: Objective description text is also inside an entity inside the map file, but it could just as well be a reference to an xdata file. I posted about this before, here:

I don't like pumpkins, but fortunately we were not required to eat any. I ate the mushrooms though! It sounded like the pub goers were having a great time, stomping to the beat of the music - a cool and fitting soundtrack. +1 for the Canadian reference

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.

Another failure by @kingsal. Firstly the mission is way too short. And like his other missions, the quality is supreme, keeps me playing and neglecting real life duties. Never feeling the frustration of getting stuck, never resolving to walkthrough material. Is it a sign of excellent design or rather a lack of challenge? Also extreme attention to detail, engaging maps from room to a room, gorgeous visually. I understand this is just a free-time effort for someone who could instead make money out of his skills but, I'm sure you could do better.

There's been talk over the years on how we could improve texture quality, often to no avail as it requires new high-resolution replacements that need to be created and will look different and add a strain on system resources. The sharpness post-process filter was supposed to improve that, but even with it you see ugly blurry pixels on any nearby surface. Yet there is a way, a highly efficient technique used by some engines in the 90's notably the first Unreal engine, and as it did wonders then it can still do so today: Detail textures. Base concept: You have a grayscale pattern for various surfaces, such as metal scratches or the waves of polished wood or the stucco of a rough rock, usually only a few highly generic patterns are needed. Each pattern is overlayed on top of corresponding textures several times, every iteration at a smaller... as with model LOD smaller iterations fade with camera distance as to not waste resources, the closer you get the more detail you see. This does wonders in making any texture look much sharper without changing the resolution of the original image, and because the final mixture is unique you don't perceive any repetitiveness! Here's a good resource from UE5 which seems to support them to this day: https://dev.epicgames.com/documentation/en-us/unreal-engine/adding-detail-textures-to-unreal-engine-materials Who else agrees this is something we can use and would greatly improve graphical fidelity? No one's ever going to replace every texture with a higher resolution version in vanilla TDM; Without this technique we'll always be stuck with early 2000's graphics, with it we have a magic way of making it look close to AAA games today! Imagine being able to see all those fine scratches on a guard's helmet as light shines on it, the thousands of little holes on a brick, the waves of wood as you lean into a table... all without even losing much performance nor a considerable increase in the size of game data. It's like the best deal one could hope for! The idTech 4 material system should already have what we need, namely the ability to mix any textures at independent sizes; Unlike the old days when only a diffuse texture was used, the pattern would now need to be applied to both albedo / specular / normal maps, to my knowledge there are shader keywords to combine each. Needless to say it would require editing every single material to specify its detail texture with a base scale and rotation: It would be painful but doable with a text injection script... I made a bash script to add cubemap reflections once, if it were worth it I could try adapting it to inject the base notation for details. A few changes will be needed of course: Details must be controlled by a main menu setting activating this system and specifying the level of detail, materials properties can't be controlled by cvars. Ultimately we may need to overlay them in realtime, rather than permanently modifying every material at load time which may have a bigger performance impact; We want each iteration to fade with distance and only appear a certain length from the camera, the effect will cause per-pixel lighting to have to render more detail per light - surface interaction so we'll need to control the pixel density.

Is it possble to make skins for brushes/patches by conferting them to func_static? Models are func_static when you add them in DR, but in the skin file you reference them with the model name instead of the entity name. When you convert a brush/patch though, it converts it uses a model with the same name as the entity name, so in this case func_static_1 for example. Would it be enough to use that in the skin file? Allthough the wiki article states it's important to add an extension.

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.

I'm honestly not sure, it's a race condition maybe? I found and fixed 2 different segfaults (PR is here), one relating to threading and the other one relating to a variable being referenced after it was cleared out. This stops the skin editor from crashing, but it seems there are still a lot of usability issues. I'm not sure if they are all Linux only, but here's what I found: The rename operation happens every time you type a character, which is a little laggy. It would be better to rename it when you are done typing and the field loses focus Typing new characters while renaming works as expected, but deleting characters causes the box to highlight so you have to reset the cursor before deleting another one. On the Material Replacements tab, click to edit is not working for me. I spent a lot of time on this, I can get a box to show up if I replace the editbox+button with a simple edit box. I think it's related to the compound control not being able to have focus. The skin name is showing up on top of the Close button This will require more wxWidget-fu than I have time to do right now.

A couple of things you can try (yes .ase files should work): I'm no expert with models, but do you have a field in the .ase file that looks something like this: *MATERIAL_NAME "textures\darkmod\plaster\plaster01" ? If the material name there isn't exactly as you specify in the skin it won't get replaced Check the console log in DarkRadiant to see if you have any errors when loading the skin. It's there in the 'console' tab.

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.

I tried the script on the core assets, and find an interesting case called textures/darkmod/metal/flat/tiling_1d/gen_smooth_gold01 This material has time-dependent envmap color: { blend add maskalpha cubeMap env/gen1 red sintable[time*0.1] green sintable[time*0.1] blue sintable[time*0.1] texgen reflect } I wonder whether it was intentional or not. Here is how it looks: I suppose it would be worthwhile to manually review the modified materials, because in some cases the color adjustment was actually meaningful...

DarkRadiant 3.9.0 is ready for download. What's new: Feature: Add "Show definition" button for the "inherit" spawnarg Improvement: Preserve patch tesselation fixed subdivisions when creating caps Improvement: Add Filters for Location Entities and Player Start Improvement: Support saving entity key/value pairs containing double quotes Improvement: Allow a way to easily see all properties of attached entities Fixed: "Show definition" doesn't work for inherited properties Fixed: Incorrect mouse movement in 3D / 2D views on Plasma Wayland Fixed: Objective Description flumoxed by double-quotes Fixed: Spinboxes in Background Image panel don't work correctly Fixed: Skins defined on modelDefs are ignored Fixed: Crash on activating lighting mode in the Model Chooser Fixed: Can't undo deletion of atdm_conversation_info entity via conversation editor Fixed: 2D views revert to original ortho layout each time running DR. Fixed: WX assertion failure when docking windows on top of the Properties panel on Linux Fixed: Empty rotation when cloning an entity using editor_rotatable and an angle key Fixed: Three-way merge produces duplicate primitives when a func_static is moved Fixed: Renderer crash during three-way map merge Internal: Replace libxml2 with pugixml Internal: Update wxWidgets to 3.2.4 Windows and Mac Downloads are available on Github: https://github.com/codereader/DarkRadiant/releases/tag/3.9.0 and of course linked from the website https://www.darkradiant.net Thanks to all the awesome people who keep creating Fan Missions! 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. Keep on mapping!

I've decided to make a list of my posts in this thread thus far. Only the posts where I shared images of real world locations for inspiration (mostly reference images of various historical architecture). 19th century octagon houses as inspiration for more fancy houses of industralists (12 May 2015) Old electric powerplant building in Poprad, Slovakia - red brick Gothic Revival stylistics (17 July 2015) - needs image fixin' Plas Mawr in Conwy, Wales - well-preserved medieval and early modern Welsh townhouse, with interior museum (29 July 2015) Castell Coch in Wales - reconstructed medieval castle, with minor 19th century industrial details (13 August 2015) + addendum Illustrations and concept art for Bree from various game projects (3 September 2015) Run-down Neo-classical manor house in a rural area (15 December 2015) - dated image links, I need to fix 'em Smaller but interesting manor houses and fortified manor houses in Slovakia (30 August 2016) Manor houses and fortified manor houses in Slovakia (13 March 2017) Environmental storytelling inspired by "reading" real world ruins (3 May 2021) Stokesay Castle rural fortified manor house, one of the few of its kind in England (26 March 2024) Houses, inns and market halls of medieval and early modern England (26 March 2024) Aberconwy House in Conwy, Wales - well-preserved 14th century Welsh medieval merchant townhouse (27 March 2024)

Ah, pity I wasn't reading the forums back in February. I'm fond of that game, along with Bugbear's other early title, Rally Trophy. I was never too good at FlatOut, but it was always a hoot to play.

Thanks. No scripts were harmed in the making of this. It's pretty simple to do because of the broken and brake spawn args. 1. It does distinguish, but I don't even know why It must be a property inherent in the glass material. 2. Good question, I'll have to get back to you. 3. I don't know how to use skins. OK, I tested it on a stock model. That doesn't work. If you use the same model for "broken", but just change the skin in the properties, it also applies the skin to the unbroken model (and vice versa). Oh, I just discovered you don't even need to put a stim/response on the arrow. It automatically breaks glass when you add the break and broken spawn arg on the object (you still need to make a broken model of course). Isn't that handy?

I couldn't help thinking of another realism related suggestion, don't know if it was discussed before but it seemed like an interesting idea. If this were to be changed on existing lights by default, it would have minor gameplay implications, but the sort that make missions easier in a fair way. So... electric lights: Like the real ones of the era, they're implied to use incandescent light bulbs... the kind that in reality will explore and shatter upon the smallest impact, and which like real lamps are encased in glass or paper. In any realistic scenario, shooting a broadhead arrow at a lamp or even throwing a rock at it would cause it to go through the glass and break the light bulb inside. Is it wrong to imagine TDM emulating this behavior as a gameplay mechanic? Just as you can shoot water arrows at flame based lights to put them out, you'd shoot broadhead arrows at electric lights to disable them... you must however hit the glass precisely, there's no room for error and it must be a perfect shot. As a way to compensate for the benefit, AI can treat this as suspicious and become alert if seeing or hearing a lamp break, or finding a broken lamp at any time if that's deemed to provide better balance. A technical look at implementing this: Just as broadhead arrows can go and stick through small soft objects such as books, they should do the same if you hit the glass material on a lamp, while of course still bouncing off if you hit metal: Lamp glass would need a special material flag that sends a signal to the entity upon collisions but allows arrows to go through, unlike glass in other parts of the world which is meant to act as solid and changing that everywhere would break a lot of things. When pierced by an arrow, the lamp should immediately turn itself off while playing a broken glass sound and spawning a few glass particles. The glass material should be hidden if the model is a transparent surface, or replaced with a broken glass texture in case the glass is painted on a lamp model without an interior... obviously this would be done by defining a broken skin for the entity to switch to. This does imply a few complexities which should be manageable: Existing lamps supporting this behavior will need new skins and in a few cases new textures, the def must include a new skin variable similar to the lit / unlit skins in this case a broken skin. Any electric light may be connected to a light switch, we don't want toggling the switch to bring the light bulb back to life... as such a flag to permanently disable triggering the light from that point on would be required. For special purposes such as scripted events to reset the world, we should allow an event to unbreak lamps, setting their state back to being lit / unlit while re-enabling trigger toggling. What do you think about this idea and who else wants it? Would it be worth the trouble to try and implement? If so should it only be done for new lights or as a separate entity definition of existing ones, or would the change be welcome retroactively for existing missions without players and FM authors alike feeling it makes them too easy?

I intend to update the FM if any bugs/errors are found or updates to TDM necessitate it, but you're correct that I'm not updating it for content going forwards. The ambient tracks I used in this FM were a little bit busier than I normally would use, mostly because I knew this was going to be a very short FM going in and I had to deliver an atmosphere somewhat quickly. Rest assured that my next FM is going to be a bit less busy and more varied in terms of ambience. Don't worry, I don't view this as a major failing or anything. I don't really find Lovecraft's works "scary" in a traditional sense, if I wanted this to be overtly scary I likely would have gone way over the top and diverted too heavily from the source material. I've always enjoyed Lovecraft's works for their ominous tone, ambience, and mystery, which it seems from your feedback I more or less achieved. I'm glad you enjoyed my FM, Arrow, and thanks for the feedback!

That bash script does not (as far as I can see) "extract all textures with specular maps". It extracts all materials to disk, then locates lines that include the word "specularmap" and blindly injects a couple of new material stages underneath. It does not identify the name of the material at all, and I'm not sure it will correctly handle materials where the specular map is part of a full stage block "{ blend specularmap ... }".

A visually breaking change is planned for 2.13 (6354). Environment mapping is used when material contains a stage like this: { blend add cubeMap env/gen3 texgen reflect } Historically, there are two separate shaders for this case: one if the material has bumpmapping, and one if it does not. Note that if the material has diffuse or specular stage, then bumpmap is added implicitly. The shader with bumpmap was apparently "tweaked" by someone in TDM and got several major differences: it has fresnel term output color is tonemapped to [0..1] range using X / (1 + X) the color multiplier is hardcoded to (0.4, 0.4, 0.4) I'd like to delete all of these differences and restore the same behavior as in non-bumpmapped case. It is also the same behavior which is used in both cases in Doom 3 BFG (and supposedly in Doom 3 too). Speaking of points 1 and 2, nobody will notice the difference except in rare corner cases. The point 3 however is serious. It is also the main reason behind the change. Right now nobody can tweak the intensity of environment mapping: if you try to set red/green/blue/rgb, these settings are simply ignored. Now the problem is that the intensity of most environment mapping materials will change. In core files I see text like this (stainglass_saint_01) : { blend add maskalpha cubeMap env/gen3 // tone down the reflection a bit //I see no evidence that these values do anything red Parm0 * 0.2 green Parm1 * 0.2 blue Parm2 * 0.2 texgen reflect } Since the default parameter was 0.4, after the change this material will get 2x less intensity. The situation is even worse if rgb multiplier is not specified, since then it will change from 0.4 to 1.0, i.e. envmapping will become 2.5 times brighter. I can probably collect the list of all materials using environment mapping, but I'm not sure I'll be able to check them all one by one. Perhaps I can delete existing rgb settings, blindly set "rgb 0.4" and hope for the best.

@snatcher I understand that when you feel your work doesn't live up to your goals that you don't want it out in the wild advertising your own perceived shortcomings but that leads to a troubling dilemma of authors who are never satisfied with their work offering fleeting access to their in-progress designs then rescinding them or allowing them to be lost. When I was a member of Doom3world forums, I would often see members do interesting experiments and sometimes that work would languish until someone new would examine it and pickup the torch. This seemed like a perfectly viable system until Doom3world was killed by spambots and countless projects and conceptual works were lost. I guess what I am trying to say is that mods don't need to be perfect to be valuable. If they contain some grain of a useable feature they might be adapted by mission authors in custom scenarios. They might offer instructive details that others trying to achieve the same results can examine. It would be great if known compelling works were kept somewhere safe other than via forum attachments and temporary file sharing sites. I suppose we used to collect such things in our internal SVN for safe keeping but even that isn't always viable. If folks would rather not post beta or incomplete mods to TDM's Moddb page, perhaps they would consider creating their own Moddb page or allow them to be added to my page for safe keeping. Please don't look at this as some sort of pressure campaign or anything. I fully understand anyone not willing to put their name next to something they aren't fully happy with. As a general proviso, ( if possible \ permitted ) I just want to prevent the loss of some valuable investigations and formative works. The end of Doom3world was a digital apocalypse similar to the death of photobucket. It is one of my greatest fears that TDM will become a digital memory with only the skeletons of old forum threads at the wayback archive site.

I'd love some criticism, thank you! I'm very glad that you got super absorbed into this FM's atmosphere, I loved reading your theories about the story! Your criticism about the readables/story is entirely valid and highlights an element that is most often criticized about Lovecraft's work: you rarely get straight answers or a clear picture of the greater threat. I encourage you to read the original "The Terrible Old Man" (all of H.P. Lovecraft's works are in the public domain and readable online), as you'll get an idea of how short and vague the source material was as well as the careful moves I had to make to not show my hand too much when constructing the narrative. Whether or not I kept in line with Lovecraft's principles is for others to judge, but I'm glad your imagination went wild with this FM! Your curiosity regarding what the bottles are, what the purpose of the little statuettes is, and immersion into the story from what little breadcrumbs I planted gave me a smile from ear to ear. Thanks, Bergante!

Congrats on the release! Remember to check ThiefGuild as well as the DarkFate forums (via Google Translate) for additional feedback.