Search the Community

Part of my point was that breakable electric lights could have an interesting contrast: They'd attract attention while also making it harder for you to get caught. When broken they should create a loud popping noise that makes nearby AI walk to them and investigate the disturbance, if they see the broken lamp even draw their swords and do an alert search... however once they've calmed down and moved on, you're rewarded with the ability to sneak there without being seen. The player will have one of two typical strategies: Either wait until there's no guards nearby in order to shoot a lamp, or shoot such lights if it's better to have guards searching but not able to see you compared to the guards being calm but able to spot you in bright light. Mappers would themselves place those lamps in areas where they want to create this particular challenge.

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/

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.

@The Black Arrow That's a good analysis. I don't disagree but we're referring to different time periods with different quality aims: In the early days of 3D and low-res CRT screens when we had 256x256 textures, detail textures were used to make surfaces appear as if they have 1024x1024 textures... today in the age of 1080p monitors such texture can appear blurry from up close, we want to make 1024x1024 textures appear of 4096x4096 quality. Back then the goal was to get at least a little bit of perceived sharpness, today the goal is to see those microscopic details on every surface as if everything is real... while the concept of detail textures is old it scales to cover both aims. As you correctly pointed out, the ideal solution would be upgrading the actual textures themselves. Sadly there are two big problems with this that will likely never be possible to overcome: Someone must create or find identical textures to replace existing ones, which have to retroactively fit every old FM. That would be a huge effort for so many images, and will not look exactly the same way so people would complain how "this wall used to be made of small red bricks which are now larger and yellower which isn't what I intended and no longer line up". An advanced upscaling filter may be able to bump the resolution with good results, this would be a lot less effort and retain the exact appearance of textures. The even greater issue is storage and memory use would go through the roof. Imagine all our textures (from surfaces to entity skins) being 4096x4096 which would be the aim for decent quality today: TDM could take over 100 GB of drive space, you'd need at least 16 GB of RAM to run it, and the loading time of a FM will be 5 minutes. Detail textures are a magic solution for both problems: They're overlayed in realtime on top of the standard textures without changing their base appearance. This means you see pixels several times the scale of the image without requiring any image to actually be at that resolution, no vRAM or loading time increase. And if detail layers are disabled with distance you also don't lose FPS in per-pixels calculations when distant lights update.

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 havent tried in 2.11 yet but I will. Just an update on this. For now I think I fixed it by: - Addressing most of the warning in the log above. Outside common errors like some missing textures and such that are part of the core. - Made sure to give my parallel lights "parallelSky " "1" spawnarg. - Deleted my .aas files and rebuilt them - Dmapped the entire thing Right now I am not getting the load error . It's a very hard problem to nail down because the console isn't giving a specific script name that it's getting hung up on (if that is even the issue similar to Amadeus's problem) AND I am actively working on the mission, creating new errors, fixing other broken things. ect. Its definitely something I fear will pop back up in beta testing though

In the Widow's apartment, there is her diary that mentions Smythe next door. (Combine that with a Thief-ette's note and you have a hint that you need to visit him) but you can't enter his place. Since my usual MO is to snuff all the lights, I kept missing the Attic. (Loved his stash tho) "Panic" - as in, casually leaving the room =D They didn't break or anything. It's just... Were they expecting ME, after my predecessor failed so bad he decomposed in days? Were they expecting someone else, like half a dozen of other people that they sent letters to, and seeing me they weren't happy? Mission 2 makes it clear they didn't get far but still....

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.

this sounds like something that'll need a custom def. I know you can bind lights to the player and a few other things; I feel like this should work too, but experimentation will be needed. If I have time today or tomorrow I might look into it

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!

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.

Yes, definitely needs to be distinguishable. Clear glass with light bulb visible would be the best way: You know that if you see clear glass and the bulb inside you can shoot it. The distinction isn't always possible to make without first trying it out though... paintings are the best example, you always need to get close to see if a painting can be looted. As for players learning about this, we should add those lights to the tutorial level where the basics of TDM are taught: In one of the hallways we'd have examples with the message "solid lights can't be shot, but ones with fragile glass and a lightbulb can be broken with broadhead arrows", the player is given arrows and can shoot at different lamps to compare. As for explosive barrels those would be cool to have too! In their case they should already be doable with a script, just that no one's ever done them: Remove the barrel, spawn the same explosion as the fire arrow or mine, and some temporary lasting physical debris if possible. Breakable lights would need support added to the builtin spawnfunc.

It took awhile to get used to the size of this mission. The long loading times didn't help, but after passing a certain point, I get it now. However, I will say this - the AI is crazy on this map. I started, right? And the first thing I see - all guards going ape because some thug cut loose. I sat in the dark corner, for like ten minutes, waiting for them to calm down, because I figured I should look around for loot (I only found some of it much later when I was returning here after finishing the mission) The same thing happened later, when I needed to pass an abandoned mansion. I waited for the epic battle, instead it was a massacre, but like an idiot I saved AFTER I left the tunnel, not before. So I couldn't reload and see if next time the battle will go differently. (Am I crazy or do leather thugs spawn after a moment?) I had to use up all gas arrows to pass that part because they kept trimming the bushes. The evidence part got me confused because I dropped a piece of evidence, but it didn't count, so I dropped everything that said evidence. Only then it counted, but later, as I was still hunting for loot, I finally remembered that I had a vent key and came looking and found yet another piece of evidence?! Finding Smythe was funny, because he kept saying "Show yourself" and the moment I did... I gathered skulls before I was prompted to, but Edgar... I don't get it. edit: Those glasses, tho. Holy crap, I did not expect to see "actual glass" in this game. The hidden room took me ages to find, despite TWO blatant hints. But I was sleep-deprived at the time. There was one snag, and one confusion that I had. The snag was that, when I finally reached the alchemist, the note told me to use the vent, right? But... I couldn't open the second vent in his lab. I don't know which key I was missing for that. So I figured - I could just go back the same way... and game CTD. I walked there again - CTD. I noclipped through that locked vent, killed the spiders, and tried to open the doors to my left (got spooked by friendly guards) - CTD. Only when I walked right and up the stairs did I finally progressed. Not sure what that was about. The confusion, however, came from Builders. I knocked out most of them in the Builder's outpost, but when I dealt with the Mr. Nom-nom-zom, they vanished. I guess they needed that many people to dig him out of the spider outhouse? (Never found the second news flash either) I still somehow missed 3.5k, and noticed that lights kept poking through walls (there is a piece of light pointed at doors leading into the inner garden of Builder's outpost that nearly got me killed a few times) Overall, however, this was an impressive piece of work.

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.

What Stgatilov mentioned about the psychological aspect of some lights being breakable and others not is going to be the toughest hurdle for you to overcome with this idea. Realism with the clear glass casing idea is nice, but you are still fighting against the rigid Thief programming that electric lights are always unbreakable. It needs to be very obvious, perhaps best identifiable at a glance, that it can be broken by the player. Consider how all explosive barrels in video games are red: it immediately differentiates them from regular set dressing barrels. I don’t believe that I would be able to consistently identify or interpret a clear glass bulb as different from any electric light. Add a red stripe to them, give them a specific recognizable light texture, make them look inherently damaged, etc. You may need to sacrifice a degree of realism in order to communicate what is thus far a contradictory mechanic to the player effectively.

And making it possible for the new electric lights to be broken adds a psychological problem: how will players know that they are breakable if in 99% missions they are not? Recall lootable paintings and frob-extinguishable unmoveable candles.

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.

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.

Yeah, I guess I didn't consider making a new entity for future mappers to implement in their future maps when I responded to you (sorry!), but that is not a bad idea. The changes should be done in a way where it wouldn't affect older FMs, and it would be a fair chunk of work. I actually have a few breakable lights in my WIP, although they are kinda glitchy and far from perfect.

Yeah, that is a true aspect. Which is why I think there could be one of two approaches if this happened: Either make breakable lights a new entity for some lamps that want to feature them, so just as you have "atdm_lamp_1" and "atdm_lamp_1_unlit" you'd have an "atdm_lamp_1_breakable"... or if we implemented it for all lamps retroactively, it should come at the cost of AI becoming suspicious whenever they see a broken lamp just like when they notice a rope arrow, in which case the player choosing to go down this route comes at the cost of attracting attention and possibly ruining their stealth score.

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?

Yes, I've been working with a mapper who ardently adheres to the principle that only moonfacing windows should cast moonrays indoors (so about 1/4 to 1/2 of all windows), even though this is a powerful tool for creating an atmosphere and for maintaining some gameplay challenge. I found that this approach often ended in scenes that had only dim and uniform ambient_world lighting, which meant players couldn't really appreciate many of the details. Something I've seen in things like Dishonored is the use of sourceless lights to add highlights to scenes that otherwise contain no lit lights. That could be an especially viable approach in a mission like this which has a haunted theme.