Search the Community

This is probably the most practical way of indicating breakable electric lights and can be done with existing models if the effect consists of something like sparks + flickering.

I was confused by this as well when I first started learning DR, the user guide is now slightly out of date. Dark Radiant now uses a modular system that you can freely rearrange and add elements to as you see fit. In your screenshot you can see the buttons to add new cameras and orthoviews, which you can move or resize like a browser window. You can do the same with the UI that contains things like the media and entities tab and even drag them out into their own separate UI element if need be. With a little tweaking you should be able to approximate the Doom 3 editor layout by hand. Hope this helps!

It might then be best to add it to new light models designed for the purpose. The visual cue should be making them more glassy and fragile looking: Existing lamps look pretty solid, we can argue those were made of reinforced glass built to withstand powerful impacts, something something Inventors Guild... in contrast we'd have a few lamps with very transparent glass that show the light bulb inside, their design shows their fragility and makes it clear those are meant to be shot.

Breakable lights might be an interesting concept so long as they are not implemented retroactively. Add a loud sound or other punishment for breaking them as you see fit, but it would still change the difficulty and design intended by level authors if you applied it to all previously made levels. I would also suggest that if you instead intend to make breakable variants of existing light models that you add a clear visual indicator that the light is breakable, otherwise it would require explicit messaging to the player that electric lights are breakable in that particular FM. I’m hesitant to see something of this sort added as it is in stark contrast to Thief precedent, but I would be more supportive of it if it was added carefully and responsibly.

The weapon hack is something that IIRC forces a model to render in front of everything else. It's limited by the fact that it can only apply to .md5mesh models, currently, such as the viewmodel of the player's arm and any weapons attached to the arm.

It's okay! I'm down with any option hence why I asked. But I agree: Most players would likely not approve of such a change being done retroactively and affecting all old FM's, so it would likely be best as a derivative entity for mappers to use in the future based on new or existing lamps that can provide one. In any case it would likely require engine changes, not something you can currently do with a script: Lights already use their own hardcoded script classname which can't be overridden. Even if it weren't for that I don't think there's a way to intercept broadhead arrow collisions and check what kind of surface they hit, even with the Stim / Response system. There should probably be two new spawnargs: A breakable boolean enabling the feature on an entity, and a skin_broken to specify the skin used when a light was smashed.

This kind of mechanic would break a ton of existing FMs. Some (I dare say even most) mappers often choose electric lamps so that they can't be extinguished or turned off, forcing the player to time their movements through the light. There are of course switchable electric lights, but that is up to the author on how they want to implement those. It would definitely be fun to see an FM implement this Splinter Cell-style mechanic, where the mapper has designed their map to function in such a way, but to add this as a core feature would break the gameplay of countless maps

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 always loved the "connections" theme and I think it is very fitting to celebrate TDM. It's a shame we can't have 4 polls per thread because then my proposal would be to have free-for-all with a "connections"-rating added that evaluates how well the mission integrates into or expands upon the existing lore.

In principle I like the idea of community campaign building. But the official campaign itself never really captured my imagination, not to mention it'd be hard for people to have an idea of where it's going, much less making it cohere. I scripted a Dark Mod campaign meant to introduce the districts, factions, and lore that does capture my imagination. But I'm not in any real position to ask people to build for it, and also there's still the problem that people may have different visions for it that may not cohere well. As for the "connecting mission", that might be interesting... But I'd reframe it a little, not that it has to be connecting per se, but you know, a hero or even another character from some FM in an adjacent setting alongside (or before or after) an existing FM, kind of like what Rozencranz and Guildenstern did for Hamlet, if you know about that. I think it's better to have it more open ended how an author wants to build off an existing FM than only connecting two FMs per se. That might be a really interesting theme to see play out.

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.

Well some good news for those who have the 2080 ti and no money to upgrade to the 4000 series. Alan Wake 2 runs at > 70 fps with the FSR3 mod on it at high at 4K need to set "m_bLensDistortion": false, in AppData\Remedy\Renderer.ini to get rid of some ghosting effect on the main char when moving, but other than that it looks quite nice. the FSR3 mod is here -> https://www.nexusmods.com/site/mods/738 an alternative is this mod -> https://www.nexusmods.com/site/mods/757 which also supports intels xee models. there is also one for slightly older AMD cards but it is a paid mod and the author got himself into quite a shitstorm due to some rude behaviour so i wont link it here, look for LukeFZ if you really must. The other FSR3 mods require an RTX or Xee card so for nvidia everything from a 20 series and 30 series. The LukeFZ mod also supports the older GTX 10 series. One thing to note is that your card must be able to handle atleast 30 FPS minimum else it will look like crap and if movement is laggy without it it will still be laggy with framegen (this also applies to cards that support it natively like the 40 series).

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

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

You're too kind! I don't think I've created something on par with what some of the veteran creators have put out just yet, but I'm very happy about how well it's been received. It's been especially nice reading messages sent to me about the lighting and sound design inside the house, as I spent a long time tweaking it and was afraid others wouldn't appreciate those tiny details. I'll certainly be back again to release another mission in the future as you've all been very welcoming, especially the dev team!

The Numbers don't lie. It has been 15 years since the release of TDM 1.0 in 2009. I think we should consider a contest to celebrate this. Further, the contest goal should be with the intention of motivating the completion of a campaign that can be deemed official. Here are some possible ways forward: Proposal 1: Middle mission(s) Authors are asked to create a mission that expands the story between "A New Job" and "Tears of St Lucia". This can involve escaping the heavily guarded city perimeter, stowing away on a ship or caravan, attempting to recruit a partner for St Lucia and failing, getting caught by Builders before arriving and having to escape their compound, getting lost in haunted woods on the way there, etc. Any interesting way that the connection between the two official missions can be expanded. Points are awarded for making explicit references to Corbin, St Lucia, and any story elements in the two official missions. If the resultant mission is of high enough quality, it can possibly be made into an official mission. If we get a number of excellent submissions and they do not cause logical inconsistencies, we might even be able to add two or more to the official list. Proposal 2: Intellectual Property distinct approximation of TDS missions Over the years, many have asked that we recreate Thief 1 \ 2 in this engine. Obviously we cannot do this due to copyright law but we could create similar missions and stories that approximate the Thief 1 or 2 designs. That said, I think that most of our audience has played these missions to death so it may be underwhelming to see them arrive in approximate form anyway. What might be better would be to develop a similar story to TDS and make missions that resemble what T1 \ T2 players were dreaming would arrive when TDS was announced and the first screen-shots were shown in gaming magazines. So take any TDS mission you like, examine the story arc and wildly re-interpret something similar but on a much grander scale. Since it's possible that two or more contestants will choose the same mission to re-interpret, we have a slot system were authors need to claim their preferred mission and if it is taken then they must select another one or lose some story points. The slots represent a sketch of what the mission author might try to do rather than a blueprint. If authors can come up with a mission that has almost no resemblance to any TDS mission but would make for a compelling story development in a similar story arc then that can be claimed as an alternative to a slot. Proposal 3: Same as proposal 2 but we stick with Thief 1 rather than TDS. Wildly re-interpret T1 based on what you may have dreamed of when reading the gaming magazines or playing the demo. Slots system to prevent duplicate submissions. Maybe with either proposals 3 and 4, we still require the use of Corbin as the protagonist and a connective enough story that they could also be adapted as middle missions for the official campaign if the team agrees on it. Proposal 4: Another "Connections" Contest. We just allow authors to connect any two missions with each other or expand the story of an existing series or single mission. So those are my thoughts. I'll leave it to players and mission authors to suggest other proposals and if we have some sort of consensus about the most popular proposals then we will make a poll. Realistically between now and October we may not be able to hold a contest with any strict guidelines ( and tricky issues with maintaining a distance to Thief IP ) so proposal 4 may still be the easiest option.

I'm no graphics nerd, but I can barely tell the difference between the two. What I can tell from messing around a bit: soft shadows of low quality look like garbage with both maps and stencils (EDIT: wrong, I didn't realize I was looking at shadow maps for a volumetric light shadow. Stencil definitely looks better). increasing soft shadow quality decreases performance in both implementations. I think the CPU/GPU of the end user would influence which is gives better performance both maps and stencils can produce a pixelated shadow if you look close enough. (EDIT: wrong. Again, was looking at a volumetric light shadow). I tend to use maps, because for whatever reason I seem to get a few more FPS out of them. As a mapper, I am certainly NOT interested in endlessly tweaking a scene to make the shadows look perfect. I just don't care enough. If they look shockingly bad I will put some effort into it though (which will probably mean just disabling them for the offending entity). It's rare that I feel this is necessary though. So I guess I don't really get the argument that stencils are amazing and maps are crap. I just don't see it or am too dense to notice. (EDIT: indeed I was being dense. I was comparing shadow maps with shadow maps because I was looking at a volumetric light shadow). Also, in my last couple of missions I had graphical bugs that only showed up with stencil shadows enabled. It would be nice to not have to deal with that all the time.

And those pics that Daft Mugi posted do show the problem with TDM maps, but I also have to say, that is a problem with TDM shadow maps, not with maps in general, I never seen such ugly issues in Stalker for example or Call of Juarez and many other games. Perhaps those shadow maps issues arise from people not thinking of shadow maps at all, when creating their lights, shadow maps do require a little more tweaking to look good, specially at grazing angles, because they are literally textures, so perhaps moving the lights a little solves those problems or even increasing the shadow map res. Just think about this, if shadow maps where that ugly, the gaming industry would never deprecate stencil shadows and we would still be seeing a ton of games using them, but is totally the contrary, games with stencil shadows, are the minority, even idSoftware removed them, I think since Rage (i'm not totally sure about Rage...) and up (besides obviously Doom 3 BFG). For example: Wolfenstein II Dishonored 2 Evil within 2 (this particular shot is impossible with stencil shadows, because of the blood that is a particle effect with alpha) etc. For obvious reasons TDM fans have a good opinion of stencil shadows and I comprehend that, they do look very good, TDM and Wolfenstein 2009 are the games with the best soft stencil shadows that I haver seen, but maps can also look good, if given the chance and used to their full potencial. another game with good stencil soft shadows Thou tree shadows on this game seem to use something else or literally stencil shadows because sometimes they look like a blob on the floor instead of seeing the individual leaf.

wtf... the second cable was also the wrong type the third worked and the board runs again . corsair has some explaining to do i reckon since all my current PSU's are from them and the only indicator that the type is not for that PSU is a small badge printed on the connector that its either a type 3 or 4 (both fit on the modular types but only one will work) the models are a 750 watt cw and a 1000 watt hx. the hx was the one i swapped in and its a gold certified PSU with 10 years warranty. the cables despite the type number are also visually the same except the type 4 having 1 cable mounted differently and is the only one that fits the hx model appareantly. luckily the cable that is mounted differently has no connection inside the 1000 watt PSU so thats a plus as otherwise it would probably had incurred damage to either the board or the PSU but damn...

Welcome to the forums Ansome! And congrats on making it to beta phase!

"...to a robber whose soul is in his profession, there is a lure about a very old and feeble man who pays for his few necessities with Spanish gold." Good day, TDM community! I'm Ansome, a long-time forums lurker, and I'm here to recruit beta testers for my first FM: "The Terrible Old Man", based on H.P. Lovecraft's short story of the same name. This is a short (30-45 minute), story-driven FM with plenty of readables and a gloomy atmosphere. Do keep in mind that this is a more linear FM than you may be used to as it was deemed necessary for the purposes of the story's pacing. Regardless, the player does still have a degree of freedom in tackling challenges in the latter half of the FM. If this sounds interesting to you, please head over to the beta testing thread I will be posting shortly. Thank you!

I mean moving models around inside the models folder. If I try to restructure my models folder via internal folders, but have already placed models, it causes the placed models to break. Thankfully it looks like I was careful enough to save models into the map folder and not somewhere else.

I mean that moving them from one internal models file to another causes it to break. Example, building with models before creating a folder inside the models folder, and then moving models in there, causes all placed versions of those models to become blue/black squares.

What do you mean by moving them around? You move them from the models folder into another folder? Models must be placed in the models folder. Otherwise, DM/DR cannot find them anymore causing the problems you mentioned in your post.

I have been building my map using some models I've created. I noticed that moving the models around in the folders caused the models in-game to break. Are there any precautions I must take for when I want to upload the map for beta-testing/finalizing the upload?