Search the Community

id Studio did a poor job in defining its categorization of variable nomenclature, so in subsequent documentation and discussions there are divergent views (or just slop). In my series, I had to choose something, and went with what I thought would be clearest for the GUI programmer: Properties, which are either Registers (like true variables) Non-registers (like tags) User Variables (also true variables) I see that your view is more along these lines (which perhaps reflects C++ internals?): Flags (like my non-registers) Properties, which are either Built-in (like my registers) Custom (like user Variables) Also, elsewhere, you refer to "registers" as temporaries. I am willing to consider that there could be temporary registers during expression evaluation, but by my interpretation those would be in addition to named property registers. I'm not sure where to go next with this particular aspect, but at least can state it.

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

Yep, that'd be the one! I had some issues with minor syntax errors, when setting it up; which is why I'd still opt to write a short guide about it. The one click, do-all option is really nice. I've only had one issue (only tested with Maya) that has UV borders being rendered as hard edged in the final product. I worked around it by doing one final export with Lightwave, as it seems to be a smoothing issue. Other than that, it's worked flawlessly for me.

Thanks, I can also recommend gog galaxy. The idea of the custom tags is really nice, I'll have to try this out too!

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

YOU TAFFERS! Happy new year! Deadeye is a small/tiny assassination mission recommended for TDM newcomers and veterans alike. Briefing: Download link: https://drive.google.com/file/d/1JWslTAC3Ai9kkl1VCvJb14ZlVxWMmkUj/view?usp=sharing Enjoy! EDIT: I promised to someone to write something about the design of the map. This is in spoiler tags below. Possibly useful to new mappers or players interested in developer commentary.

No later than Tuesday, I'll be releasing the following - - A spreadsheet with all The Lord subtitles. The spreadsheet calculates metrics, that help decide which subtitles benefit from extension and what those extensions individually should be. Plenty of examples there. - A companion Word doc explaining the spreadsheet and the workflow generally. The spreadsheet is relatively complicated and so benefits from a column-by-column explanation. - The testSubtitlesLord FM with the resulting polished subtitles embedded in it. This FM is slightly different than its Thug predecessor; the Word doc has the differences. To come in March/April - - My personal Style Guide for these barks - A cleaned-up C++ program to gather sound clip durations to import into the spreadsheet. (Current version works but is a bit too smelly to release.) - Possibly the spreadsheet in template form - And another AI character's utterances.

I wrote an article describing how to install The Dark Mod on Chromebooks: http://zipso.net/play-thief-like-game-the-dark-mod-on-a-chromebook/ Any feedback from anyone trying it would be interesting..

I recently started with DarkRadiant working through Fidcal's A-Z Beginner Guide and I thought it might be helpfull to have a German translation of this tutorial at hand. Actually i'm not the first proposing this. There were some people working on a translation quite a long time ago: http://forums.thedarkmod.com/topic/11795-my-first-darkradiant-session/page-2 I suppose the project is abadoned... but i might get started on this again if there is some demand for a translation. So what do you (especially the German folks who haven't really got started with DarkRadiant yet) think? Would this be helpful to s.o. or are you just fine with the English version anyway?

It's the duration that matters. If the clip exceeds 6 seconds, use srt. Individual segments within srt should be 1-6 seconds long. There's more to it than that. I'll DM you later today with a Word doc, a draft fragment of the style guide under development, that delves into this. Specifically, if there's too many words to read in the time that a subtitle is shown, you may need to edit out some words. That is, move away from a verbatim caption. The fragment has quantitative guidance on this.

https://github.com/HansKristian-Work/vkd3d-proton/tags <- directx 12 wrapper for dxvk https://github.com/doitsujin/dxvk/tags <- directx to vulkan wrappers D3D 9 to 11 eg. dxvk if you want to try it with horizon zero dawn you need to copy out dxcompiler.dll from Tools\ShaderCompiler\PC\1.0.2595\x64 and bink2w64.dll from Tools\bin and place them next to HorizonZeroDawn.exe. then copy over dxgi.dll from dxvk and d3d12.dll from vkd3d and place them next to it to. now fire up the game and let the shaders recompile -> profit.

@stgatilov, in the Subtitles_decls section of the Subtitles wiki page, you show example code, that includes an srt reference. Wouldn't it be better to guide people to place the corresponding .srt files within the "subtitles" tree (where their .subs live), rather than the "sound" tree? Also, should FM authors be encouraged (if not required) to prefix .srt files with "fm_" ? Like "fm_sound8_long.srt" ? Finally, in the "displayed text" section, under the srt command, there's a desperate need to see example .srt content, in this case, something made up for sound8_long.srt (or fm_sound8_long.srt) like: 1 00:00:06,612 --> 00:00:10,376 Something's wrong with this crystal ball. 2 00:00:15,482 --> 00:00:20,609 Bugger me! It's not showing the right dream. 3 00:00:25,336 --> 00:00:28,167 Ah! Here we go. --end

The *DOOM3* shaders are ARB2 ('cause of old GeForce support) carmack plan + arb2 - OpenGL / OpenGL: Advanced Coding - Khronos Forums

In a private message on Monday (2022-01-16), I asked about some patches. Then, I was asked why I waited until the second half of beta testing. My reply was "(1) I recently shared some config with Thief players and some expressed interest in TDM. So, I decided to write a guide. (2) I've been beta testing a mission, so I've uncovered these recently. (3) I don't know the beta release schedule, so I don't know where we are in the process." In a private message on Tuesday (2022-01-24), I was asked when I would be done with my patches for 2.11. I gave a list, and there was no definitive communication from the dev team that they would not be considered for 2.11. Just that patches would need to stop soon, because the dev team was deciding when to end beta testing. It seemed that I was given the go ahead. I didn't want to hold up the beta's (unknown) schedule anymore, so I put in extra time and effort to get all of my patches in no later than the next day (Wednesday) to give the dev team time. In a private message on Wednesday (2022-01-25), I told a developer, "I've submitted all the patches that I've planned: 6241, 6231, 5892. I'm ready for feedback and fixing any issues with those patches. That'll be it from me for 2.11." I was given some feedback about (5892), and there was no mention that my patches would be excluded from 2.11. This week's work getting into the next beta was going to be my personal triumph and moment to be proud of, because my hard work was going to be done for 2.11. My patches were already submitted, after all. Now, it's ending in a bust. After my post yesterday, I found out that one of my patches that had already been accepted in SVN for both code and assets will be reverted and postponed until 2.12. No reason given. I had checked SVN to make sure it was applied correctly and made sure the core assets were correct. I've been playing with the latest SVN code and haven't encountered any issues with that patch. Now, I don't know the state of that code. (As an aside, I don't have read access to the assets SVN, so I had to request the changed files from a dev.) The patch is for (6242). That patch fixes a bug that can be read about on (thread). Does the dev team think those players are going to be happy that this patch was reverted and won't be available for an entire year? I fixed that for the players, not myself. For (5892), a feature requested by Bikerdude. This was a reason given for not allowing mantle while carrying a body: On Saturday (2022-01-21), the "tdm_mantle_while_shouldering" cvar was accepted and merged into SVN. Bikerdude replied: Now, if I'm understanding right, that cvar will be removed and not included in 2.11. Bikerdude is one of the most prominent mission authors, is he not? Now, Bikerdude's feature is being taken away. A less prominent contributor, myself, is getting his contributions reverted. It's a shame, because my fixes and suggestions mostly come from listening to the community and dev feedback. Submitting patches is a lot of effort, and I could keep those changes to myself instead. My work is for the players, not myself. Usually, I don't propose something or act on something unless I see other players having the same issue as I've experienced. I think TDM is mostly fine as is. It's not like I'm suggesting new arrows, how doors work, rewriting AI, or something like that. I'm at a tipping point of losing trust in this project, because this situation is fixable. Miscommunication happens. How it's handled matters. I did my best to communicate and hold true to no more patches after this week. Also, the dev team could have told me something like "any patches submitted after X date will not be considered until after the beta cycle." From my point of view, the dev team suddenly changed course from Tuesday's "deciding when to end beta testing" to Thursday's "still unknown but sooner than before, I guess?", and the proposed solution from the dev team is "Tough. Deal with it." or "Don't like it? Fork it." instead of "Let's do one additional beta release" to get everything worked out (whether or not patches get included). I think one more beta release to get these completed or decided on is fair, because that's what the agreement seemed to be, as vague as it was. I'm doing this for free as well, and it sure doesn't feel good to see my work handled in this manner.

I think that the existence of a dedicated bug tracker for this engine proves that I should somehow make it known when it crashes. I just figured that the tracker was an internal thing between developers, and that it was okay to instead report the bugs here, especially since I desperately needed help with it, and since you have two sub-forums mentioning that they're intended for reporting bugs. ...so why, when I report a bug, am I getting shamed for it? Why was the guy in the thread you linked getting shamed for not backing up his project, instead of the main dev acknowledging that there is a very deceptive button in the engine, that can remove fan mission folders when you press it? Blaming the reporter for not backing up his work, is certainly not how I would personally handle reports of entire projects disappearing, but I guess now I'm warned about how he sees these things, to the point where I'm wondering if it's a good idea to report any bugs I find in the future, at all, if I'm just going to be considered a bad person for it. "Hm, to my experience, crashes in free software is a regular thing. Try "Natron" and you will understand what I mean." I don't understand your point. If crashes happen frequently enough, should we treat them like Covid and just "try to live with it"? I'm pretty sure that the bind bug is easy to fix, but it's like you're saying that bugs have a right to exist too. "Lots of longtime DR mappers ask questions in the Newbie thread (myself included). Nothing to be ashamed of and by DR/DM standards you are a newbie (and you have not to be ashamed of that as well! )" So if I've programmed for 30 years, mapped for Dromed for countless years (since roughly the turn of the millenia), mapped for the Dark Mod for 1 year, but joined these forums just a few weeks ago, I'm a newbie. I think that by that definition, the word "newbie" has lost all meaning. Besides, reporting crashes are not the same as just asking questions. Anyone can reply to a question. It takes a developer to fix a crash issue. ...and it's like you don't expect the developers to even fix crashes, and I really hope that you're wrong about that. For example, since I updated to this year's version, Dark Radiant itself, hasn't even crashed once, and it used to crash all the time, and so I take that as evidence that development involves fixing crashes. "If you want to report a bug, then please use the Bug Tracker." Will do. I was just fooled by the subforum descriptions actually telling me to report bugs in them. "You wouldn't believe how many mappers lost WIPs because of defective hardware" Again: I don't see your point here, where you argue for not fixing defective hardware. When I'm told about a bug in my program, I just go "Thank you. I'll fix that.". I don't go "Well, weren't you a sucker for using my program.". That's not how I was brought up at all. "for somebody who expects Armageddon in the near future (and there are really good reasons for that), you have a pronounced need for communication. I think that does not fit, because: Why go on with communication when all hell will break lose the day after tomorrow?" Well, why not? Yes, I am so interested in mapping, that it's actually cutting into my apocalypse survival routines a bit, but that's just human nature, and a month's vacation from prepping, won't make that much of a difference. "I hope that you - despite of your own assessment - will finish your WIP and we all can enjoy a cool new mission in the future with your name in the credits." Well, for me, mapping is about pleasing myself - not others. Play The Beginner's Guide, and you'll see what I mean.

OK, I've updated parts of Page 1 (and a bit of Page 5) of the A - Z Beginners Guide, to cover a choice of using project and non-project file structures. That part's hopefully clearer and certainly longer, but I shortened the intro. No plans to revisit rest of that guide. That would be Labors of Hercules.

Keep in mind also that mission size, and complexity have increased dramatically since the beginning. For a lot of veteran mappers, it can take over a year to get a map made and released. The last dozen missions have for the most part been pretty massive, with new textures, sounds, scripts, models etc. We seem to be long past the point of people loading up the tools, and banging out a mission in a few weeks that's very barebones. We still do see some of those, but I noticed in the beta mapper forums and on Discord, that mappers seem to make these maps, but don't release them, and instead use the knowledge gained to make something even better. Could just be bias on my part scrolling through the forums and discord server though.