Search the Community

I have an idea. From time to time, these kind of guard create a penis during animation. This penis creates a thread during spawn, but it starts it as DelayedStart(0 ms). Instead of running the script immediately, it stores its entityNumber onto the callstack of the script thread. Let's suppose that for some reason penis gets destroyed immediately, and bow attachment gets spawned at this exact moment: then the bow attachment reuses entityNumber of the penis. At some moment suicide thread wakes up, reads entityNumber from stack, and kills the entity with this index --- but now it is bow attachment instead of penis. That's a simple explanation why dangling pointers are dangerous! However, if this really works like this, the whole scripting should be completely broken, since scripts in general often wait long time, and all the entities they reference might die during waiting. I can hardly believe this situation is always handled that bad. I'd like to ask people who have used scripting a lot. What happens if you have a local variable X of type "entity", then you do "sys.wait(1.0);", and then try to use X but it has died during waiting?

http://store.steampowered.com/app/219640/ Chivalry is now free for some reason. Get it now if you want it forever. Edit: Offer over, apologies.

I see you are trying to make subtitles system more complicated, but I don't understand what's the reason. And I prefer not to add complexity/normalization if not needed. If someone needs visual cues, he most likely needs them for all sounds. Why do you suggest adding another parameter about visual cues to subtitles definitions?

Author note: It's hard to believe it's already been a year since Act 1 came out! Well during this mission the player will be following Corbin into the Grimwood district to followup on a lead from last night (Act 1) .. the mysterious tablet! This mission is my first time including full EFX support as well as a HD briefing video file, additionally a new script has been added crafted by the talented Obsttorte which has loot flying towards the player when you pick it up. On a level design front I have tried to change things up a bit by really catering towards a number of play styles, this mission can be completely ghosted or you can use the tools at your disposal to wreak havoc on the citizens of Northdale. For the first time I have tried to create more sandbox environments which don't offer clear answers handed directly to you, so if you're having trouble figuring something out try a different method. This mission takes between 1 - 2 hours to finish depending on the difficulty you play on and how thoroughly you explore. I hope you enjoy your night in Northdale! - Goldwell Voice actors Fen Phoenix Goldwell Random_taffer Yandros Beta testers Amadeus Boiler's Hiss Cambridge Spy Chakkman Crowind Epifire Kingsal SquadaFroinx Custom Assets Andreas Rocha DrK Epifire Grayman Kingsal MalachiAD Obsttorte Sotha Springheel SquadaFroinx Purgator With special thanks to Epifire for creating a large collection of custom models, Grayman for helping out with coding, Kingsal for drawing the ingame map and Moonbo for his script revision on the briefing video. Available via in-game downloader MIRROR File Size: 417 mb EDIT: If you are having performance issues please consult this post by Nbohr1more which may address your issue http://forums.thedarkmod.com/topic/19936-fan-mission-shadows-of-northdale-act-ii-by-goldwell-20190320/page-2?do=findComment&comment=436271

Ok, I understand now. The name "Open Doors on Unlock" fooled me for some reason. There are regular doors (and windows) that can expose you and then there are trap doors, manhole covers, chests, strong boxes, jewelry boxes, wardrobes, cabinets, desks, panels, showcases... and the game treats them all as doors. Tricky business.

There is certainly a lot of garbage, conspiracy videos and mediocre influencers on YT. This naturally happens on any platform, especially on Odysee, although the reason is more understandable there, since Odysee is based on Blockchain, this makes it impossible to delete any inappropriate content, moderation, can only hide the videos if they are reported, but this only transfers them to LBRY. But YT does not have this problem and the moderation there is quite quick in deleting content that in its opinion is inappropriate, but this corresponds more to political reasons and content that is uncomfortable for Google, rather than other idiocies or complaints from users.

My brain is reeling with overload! First, being enthralled with your goblin roleplay, I overlooked your second link to your clockwork story. That is now even more fascinating to me. In particular, the AI's reasoning powers (eg, when it perceives and describes the allegorical element of your story) is staggering. Clearly the AI can reason intelligently. No matter that it isn't conscious and, like all software, it's merely a list of instructions & data (thought HUGE!) it can reason in an intelligent way. In that instance it was better than me! It definitely has (or can represent and function as if) an understanding of language. And I say if something looks like a spade, and be used to dig, then it's a spade, even if constructed differently. thanks, now found the sharing feature and discovered your post is publicly-readable but posting to it requires an openAI account. I added a brief message to test if you can see it. I'm sure it can be seen on the public page. But does that sync with the copy in your private version of it? For further interest, I posted a version of one of my earlier tests that might be of interest at.... https://chat.openai.com/share/36420a5f-f8d8-4eeb-939b-a1c4c017c2b3 It's a failed story fragment but I learned a lot about how to work with gpt.

Hi guys, through the "cheats" topic I got the idea, that it would be quite useful, if there were tags for missions (the post was about removing the killing restriction in some missions to suit the prefered play style). I don't know how easy or difficult this is, but with them, it would be quite convenient to pick missions with playstyles, environment, etc one does want to use. This could also be expanded to other mission properties. I remember a discussion about climbable drains, handles on doors, that cannot be picked and other things the map author chooses for himself. That way these things would be clearer and as I said before, it is easier to choose missions with playstyles that suit oneself. What do think?

Maybe the reason is that these sounds are non-streaming in the engine...

Is there a way to make multiple sounds while getting multiple items? That would be enough to make the player check the inventory. Also auto-search could be the final reason to accept the current implementation ;): short-frob shoulder body, long-frob auto-search body and grabbing it for movement.

Emotion won over reason.

There's no change regarding that. I would have already created a cvar to switch the behavior if it were simple. The code would almost double in size, become very difficult to read and understand, and it would be very hard to test all of the possibilities. I'm sorry this is the case. I spent time on it for you, but the code results were not good. At the risk of causing some confusion to some folks, here is the technical reason. Both the rat and the body in Heart of Lone Salvation have their body entities set as (shoulderable 0). The "fix", or tweak if you will, is to only allow "hold frob" on body entities set as (shoulderable 1). The result is that regular guards and bodies use "hold frob", the rat and other non-human creatures get grabbed on regular frob, and that body in Heart of Lone Salvation gets grabbed on regular frob.

Hello TDM-ers. I am encountering an issue where textures seem to partially disappear. I tried searching the forums, but, I don't know what to search for. The missing textures are a worldspawn brush acting as a roof with {for now} flat iron texture. There are other worldspawn brushes right below to create an attic ceiling with roof framework board texture. These gaps appeared a few edits ago. I can't "undo" to get back before whatever edit did this. The gaps are only visible during play and are not visible during editing. Closing and reopening DR and TDM do not fix anything. Some of the brushes overlap in areas behind the play area but I have never seen an issue doing that. The attached image has the effect I am now seeing. Ideas on where to start debugging this? Very much appreciated. Clint

Extensive customization options are appropriate during the pre-release testing or early roll out of a new feature. The people testing the feature can't know yet what configuration will work best for them, much less the people making the patch. My expectation is that by the time you have to make a final decision about including this patch in the next official update of TDM, there will be a rough consensus about the optimal parameters for the new mechanics, and you will only need one toggle for the new behavior. Or, preferably, there would be no need for an option at all if we can only get over our OCD about preserving arbitrary semantic grouping in our key-bind allocations; and embrace a superior control scheme that's not designed around highlighting an old gimmick feature whose trendiness expired with the Half-Life 2 era of FPS. But that's a pipe dream. Maybe instead we can just all agree that the general>gameplay options are getting a bit crowded. Perhaps we could split some of them off into an "appearance" or "accessibility" tag. As more people make their own mods and we modernize our accessibility options it is going to become a problem regardless. Best to get ahead of it. I agree, and that is one of TDM's strengths. It borrows and combines many of the best features from the three beloved Thief games, but it also gives FM creators tools to expand their creative vision in new directions. To some Thief purists that will never be an enticing proposition. But I don't see this feature as throwing a bone to those Thief players specifically, but just player in general who are bouncing off our game because it deviates from some genre conventions for no obvious reason, which makes them think this is an unpolished product. It is true that Thief was what set these conventions, and (shockingly/s) it is mostly Thief players who are interested enough in TDM to give it a try... but our responsibility to address these problems (if we can) is the same as if AMD or Linux players were having technical problems with TDM. They are people who we want to be part of our community because we never know if one of them might make the next FM like Iris, or do something crazy-innovative with TDM that we can't even imagine!

Wow! This is something interesting. You have areas 177 and 179 (you can detect them using teleportArea command) with 8 visportals between them, all in same plane. I hope this is as intended, and you really have many separate visportals? This should be perfectly valid of course. FloodLightThroughPortals searches for all visportal sequences which might get some light rays through. For some reason, it manages to go back and forth between areas 179 and 177 something like eight times in the same sequence. It is not forbidden for the traversal to go through the same area many times, but it is forbidden to go through oriented visportal twice. However, there are too many possible sequences of going through 8 two-sided visportals, and the code obviously tries to enumerate and save them all. At some point it bumps into 32-bit integer limits and everything crashes. By this moment it has wasted 32 GB of RAM so I don't think it would live long even if it did not crash here. You don't have the issue in 2.11 because: This is a dynamic light from some lantern bot, TDM 2.11 only runs this function for static lights. TDM 2.11 does not try to save all sequences, it would only enumerate them in horrendously slow time. I think some lantern bot crosses the visportal between areas 179 and 177 at this moment, causing the issue. Also, you can most likely reproduce it in 2.11 by putting a large enough light at the same location (12565.0205, 411.300110, 522.249939).

Is there some reason that the custom head can't be just given to the player at the outset (in some def file), and not swapped? Might be more stable, I'm guessing.

Awesome! Post is up! https://forums.thedarkmod.com/index.php?/topic/22200-beta-testing-the-house-of-delisle/#comment-487365 Thanks!

Seems like an inoffensive suggestion to me. It would not provide much of a challenge though since all one need do is let go of the mouse and voila: perfect stillness. For that reason, to work as advertised I feel like it would need to be tuned to be a non-factor 98% of the time, such that even veteran players would forget it exists until suddenly, surprise! here's an edge case where it matters. Like: only movements greater than 90 degrees per second trigger the effect. Basically it would just be an in-game jump scare mechanic. If something makes you as the player character involuntarily jump or flinch then that has a chance of being spotted. In the hands of a devious FM author that could make for some extremely memorable scripted moments. That's all just in principle though. In practice, this is an idea that would cost development energy to implement, and we want to make sure that investment is committed wisely. Remember how the community flipped the f*** out when Hazard Pay had the audacity to restrict saving, going so far as to make a mod specifically to negate the author's intent, and basically ensuring that no FM that's not a deliberate troll will ever use that feature again? Great use of resources that was. /s

DarkRadiant 3.7.0 is ready for download. What's new: Feature: Skin Editor Improvement: Script Window usability improvements Fixed: Hitting escape while autosaving crashes to desktop Fixed: Def parsing problem in tdm_playertools_lockpicks.def Fixed: DR hangs if selecting a lot of entities with entity list open Fixed: Float Property Editor's entry box is sticking around after selecting a float key Fixed: Spline entities without model spawnarg are unselectable Fixed: Entity window resets interior sizing forcing resize each time it is opened Fixed: Spline curves should not be created with a model spawnarg Fixed: Newly appended curve control vertices aren't shown at first Fixed: Light entities are zoomed out in preview window Fixed: Entity inspector spawnarg fields not always updated by UI windows such as Model Chooser Feature: Skin Editor (see video) Windows and Mac Downloads are available on Github: https://github.com/codereader/DarkRadiant/releases/tag/3.7.0 and of course linked from the website https://www.darkradiant.net Thanks to all the awesome people who keep using DarkRadiant to create Fan Missions - they are the main reason for me to keep going. 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!

Because of the latest reports in this topic I just re-played this mission in TDM 2.11a and I didn't run into any issues. For some reason though the map is duplicated, which is annoying but apparently harmless.

RE Glitches with the Stone (aka Stone Print) font. Probably the minor artifacts with this font - mentioned in the bugtracker - are due to the fact that this file is missing from the distribution: tdm_fonts01\fonts\english\stone\fontimage_12.dat <== MISSING which I surmise causes the 24pt font to be used instead and scaled down. There is some reason to believe the missing file was present at one time, because the corresponding .dds file is present: tdm_fonts01\dds\fonts\english\stone\stone_0_12.dds And the russian paths have both the .dat and .dds files (2 of the latter in the case of russian) for this font. (I think trying to copy the russian version of .dat to the english branch would fail big time.) If someone with access to an archive of very early TDM full distributions can check to see if it is available, that would be great. That would be the best way to go, because that file may contain hand-tweaks to the font spacing. Otherwise, it could be regenerated from the .ttf file and tweaked, a somewhat fraught endeavor (at least if I were to attempt it).

Nice knowing you are looking at this. Btw when I made my own version of "namedEvent" gui cmd, I just copied the convention of other gui cmds like the "localSound" cmd, what I found is that it made the usage of simple nameEvents in GUI's very fast, with no need to mess with c++ and compile the engine. I think exactly the same reason quake 4 developers said they implemented it, thou like you said we don't know how they made their version. Perhaps is why I had some issues with my implementation when trying to call more complex onNamedEvents, so is something that needs to be well tested. Simple example of usage (the following code is untested and should be looked as "pseudo" code) windowDef Desktop { rect 0,0,640,480 backcolor 0,0,0,1 menugui 1 float "text_state" 0 onInit { // just in case ... if("Desktop::text_state" != 0) { set "Desktop::text_state" "0"; } } //*************** Events ************************* onNamedEvent ClearText { set "Text::text" ""; set "Desktop::text_state" "0"; } onNamedEvent SetText { set "Text::text" "Hello world"; set "Desktop::text_state" "1"; } //************************************************ windowDef Text { rect 240,41,165,110 visible 1 forecolor 1,1,1,1 text "" textscale 0.5 font "fonts/micro" textalign 1 } windowDef back_btn { rect (320-55),(240-35),50,30 visible 1 text "Click Me" textalign 1 textscale 0.3 font "fonts/an" onActionRelease { if("Desktop::text_state" == 1){ namedEvent "ClearText"; } else { namedEvent "SetText"; } } } }