Search the Community

I detect two use cases where the script is limited: Trying to blackjack AI on the move (players may want to lean forward) Trying to pickpocket AI on the move (players may want to lean forward) The proper implementation of a Lean Modifier Key should be: If the player is moving and the Lean Modifier Key is pressed, the player leans while moving. If the player is not moving and the Lean Modifier Key is pressed, the player simply leans.

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.

sadly the upcomming 8xxx series from amd will only be for midrange atleast according to leaks (grain of salt maybe ?). well it would be something quite different thats for sure not sure if 32 gb vram would actually help (what is the max texture size today ?), it might help if they really go nuts with the detail level in upcomming titles but i suspect this might take longer as the game companies dont want to alienate players with less vram. ofc it will come at some point but i dont see it in the near future. the 2 and 3 gb vram chips might actually make a dent in the bus width war. what the hell happened with hbm memory ???, the old fury cards could actually do 4k no problem with only 4 gb vram because the hbm memory was so blazing fast.

Obviously the change will only work in last night's dev snapshot and onward. But missions can already start implementing this: It's just that older TDM versions won't see the debrief screen and only future players or dev users will enjoy them.

Done. @nbohr1moreWould you mind updating this on the server? Its a fairly bad bug, I've updated the OP but here is the link to the new pk4: https://www.dropbox.com/s/u279b60l40p29cq/moongate.pk4?dl=0 - I've fixed the issue with players getting places they shouldn't be. - Fixed an exploit with secrets - Fixed a few minor issues @snatcherIve included the stock tdm_playertools_flashbomb.def

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.

The room is suppose to be inaccessible, I think you got up somewhere I didn't intent for players to get to. Light hint: Stong hint:

Thanks for the feedback @Rio_Walker As mentioned in other comments in this thread, the optional objective was meant to be for players who enjoy exploring every inch of the map. If all you want to do is complete the mission via the primary objective it's pretty straightforward. It was also meant to be sort of 'open world' in that if you explore everywhere you pick up little hints and bits and pieces and put them together at the end to solve that objective with. It wasn't meant to spoon feed the player. But again maybe not everyone enjoyed that approach. It was also kind of a knee-jerk reaction to players not liking 'linear' missions. But it seems some people still do like that And yeah, some players don't like big maps. I get that. I don't like playing them myself a lot of the time The issue with the bow crash is a known issue (not just with this mission) which we haven't got to the bottom of unfortunately:

I suppose your right. The Dark Mod was originally made to be a challenge for those familiar with the Thief games, in terms of difficulty and perhaps lower in accessibility to the newer players. It wasn't meant to be a re-creation of what its like to fight or sneak or stealth takedown enemies at all of those games or to mimick real life in anyway. Its just supposed to put all our skills to the test. With that said, I sorta wish the dark mod took a different turn and made the gameplay and difficulty more organic and natural, rather than always relying on bumping it up by forcing certain rules on myself when playing. Like no tools except lockpicks, no KO's, and no killing any human NPC's, put everything back where it was except loot, and keep being spotted to a minimum by only moving around when the enemies our out of sight if I can help it. Your mod is certainly a improvement by a significant margin because its got some consistency that I appreciate And its also got a whistle and peek through doors Great work of course.

The coin is a little joke in the mission end stats. It exists solely to mock you, similar to the newspaper stating it's missing. There is no actual coin in the mission. Because it's missing, just like the newspaper says. You can clearly see how TDM players do not believe much in thieving-free missions. There has to be loot, right? Rather than pack their belongings and leave, they chase after a coin that does not exist, only because the stat screen tells them there is a coin even though there is none. TDM is a game about stealing, after all. There's no room left for locking your apartment, stacking your furniture onto a cart, and leaving. But perhaps sometimes that's all you can do. Maybe that is what you should do. Ignore the coin. Ignore the ugly stain on the wall, it's no good. Don't even look at it. Pack your belongings and forget. Ignorance is bliss.

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.

What version of TDM are you running? The problem with the elementals happens on 2.11, but it shouldn't happen on 2.12. The keys only show up after you get hit with the appropriate elemental. Brilliant! I love it when players do things I never thought of. I tried to just remove the weapons, but then I couldn't figure out how to give them back at the end. So I just made them unusable.

Is this a burglars request thread? Edit: This question was raised onto the original title of this thread, which looked somewhat like a request for players of sorts.

Thanks for playing and Im glad you went loud, that was the intention or at least to tease players into killing some zombies.. Also I hear ya on the survivor, I had plans to give him some vocal lines and maybe some interactivity but I ran out of time. Maybe someday Ill go back in and update this mission

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!

The Dark Mod 15th Anniversary Contest! To celebrate our 15th year, we are holding a fan mission contest! The Dark Mod project trundles onward for it’s 15th year in a row. In that time we have improved our game engine in countless ways and have grown to over 170 missions! To celebrate our perseverance and the years of improvements to come, we are hosting a contest to mark 15 years since the 1.0 release! Now is your time to demonstrate the mission design that best exemplifies your personal style and capabilities! Please consider entering this event! Unlike most recent contests, there is no defined theme and we are simply going to score based on our standard metrics of Story, Gameplay, and Visuals with our standard weighted scoring: Max Possible = Total Votes * 5 (Outstanding) TotalMaxPointsPoss (TMP) = AllCategoryVotecount(ACV) * 30 Full Weighted Score (FWS) = (Gameplay score*3 + Visual score*2 + Story score) / TMP Contest Submissions should be provided before October 16th so that players can start playing and celebrating on the 17th! The players have been keen to relay that they would like really creative missions so it may be worthwhile to examine our “Community Unusual Contest” to get an idea about the wild range of possibilities we offer to designers. Also, since the contest submission is in October, there will probably be an increased desire for Horror themes. The Dark Mod 2.12 was just released so including new 2.12 features is strongly encouraged. Finally, it might be nice if authors name their protagonist Corbin to match the included missions. ( None of the above suggestions are requirements for the submissions. ) Please post your intention to enter in this thread. Thank you! The Poll on this is to demonstrate the intended design used in the mission release threads.

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.

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.

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.

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?

Noticed all of these only because I played TDM by doing the opposite of stealth to practice swordfights. None of these bugs appeared as long as I played the game stealthily. Should also note that I used Snatcher's Core Essentials @snatcher on and off, but your mod does not alter the AI anyway, correct? Bugs happened both ways. 1) AI freezes in combat - https://bugs.thedarkmod.com/view.php?id=6371 It happens a lot with auto-parry disabled. It never happened with auto-parry enabled. It never happened with some guards, while it happened many times with specific guards. They unfreeze when player dies, or when AI is forced to re-equip the melee when player returned from a spot that usually causes them to throw rocks. Also experienced behavior of them only slowly walking towards me at the pace of "hunched sneakily searching mode", attacking once finally in proximity. 2) AI may collectively lose the ability to hear any of the players noise caused by footsteps / landing. Still unsure of what causes this, but Lockner Manor has a good layout to get to the result. Just follow the right-most path and repeat the process of winning sword-fights with City Watch, and then jump around the next guard to see if they can hear you. If they can not hear you, likely nobody can. If they still can, just combat them too and you will likely have deaf AI by the time you have dealt with the 3 Watch Guards outside. In my experience, when they hear the death scream well enough to run to its location or start searching - the deafening did not work. 3) Helmeted AI does not react to (nor hear) players overhead sword strikes made directly on helmet, stealthily from behind. Not sure if the same issue as deaf AI bug, but happened at least once while it was active. (Lockner Manor) 4) (Moor?) AI may lose the ability to hear AND see player after nearby swordfights and after two slashes to bloody their face. (I may have also Moss Arrowed them to face). Any sword strikes I make simply go through their model with no audio of impact. Collision still gets player detected. (A Good Neighbor) 5) Crash to desktop when archer puts bow away to take out melee (while I may have collided with them on staircase). (Lockner Manor) 6) Crash to desktop when I shot a shortsword-wielding charging Noble. Sound of a deflected arrow played (same that you hear when shooting a stone wall), when I expected a flesh-hitting sound. (A Good Neighbor) 7?) Sometimes AI says "Ow that hurt" merely because I block their strikes. - Is this an intended feature? Do they take actual damage too? Anyway, I didn't find mentions about many of these issues. Reporting aside, if you want me to experiment with something or find ways to replicate - I don't mind updating this thread, as I plan to mess around with sword-fights anyway. Just posted this initial version should anyone want to chime in with similar experiences, and I wanted to know if some of these bugs could be mission-, or mod-specific. Maybe caused by much or unfortunately timed quicksaving / loading?

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.

I though something similar and suggested adding objectives to the Training Mission. That would help introduce some linearity into the mission and also suggest tasks to players, where the objectives are listed in order of increasing level of difficulty.