Search the Community

Thanks for those fixes! They didn't affect me and any FM's I've been working on, but I'm happy to see a solution was found and you could help those affected so quickly. I like the idea of being able to customize arrow behaviors from cvars! Most open-source FPS's (eg: Red Eclipse) offer the ability to set weapon behaviors with custom configs and create your own unique balance. While I agree it's good to not have a ton of settings, I think the weapon slots should be customizable this way... at least for now as we remain stuck with the old in-engine weapon system and can't turn the blackjack / sword / arrows into items like everything else.

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/

I think you just gave me an idea for the next April Fool's FM

Gosh you're right. As a result it only managed to snag spot #10 in terms of highest user rated TDM missions on thiefguild. Kingsal could make a mission where you crawl around like a baby in moon gravity and I might be right there with you saying it was a bad idea. It'd still be his mission so his choice.

I hope you didn't forget the (controversial) discussion about his implementation of a Resident Evil style save room in Hazard Pay. Or the change to the arrows, which one head shot zombies. These changes are anything but commonly accepted and wanted. Rather something he implemented, because he thought it was a good idea. Which is fair enough, but, it unfortunately leads to the lack of uniformity that I was talking about, when every FM author thinks he has to reinvent the wheel. Especially new players can't get used to how the game, weapons and enemies behave, if the behavior is different in every FM.

The idea is that mapper can set spawnargs on map entity to override defaults from entityDef. If some entityDef is used only to dynamically spawn entity without any map entity, then it does not fit. I guess this is the case with arrow weapons, sadly. UPDATE: At some moment we discussed an option to specify "patches" to core entityDefs, but the idea never got far.

To summarize bullet points: https://github.com/fholger/thedarkmodvr/wiki/Gamepad-support https://bugs.thedarkmod.com/view.php?id=5400 Also an idea is having vibration while lockpicking: http://www.thief-thecircle.com/thief3/saamspreview.asp "Now, what are the differences in the controls between the Xbox and PC versions of TDS? For starters, lock-picking on the Xbox enables the force-feedback on the controller, so you feel different levels of “rumble” as you get closer or farther away from a successful pick. It does make lock-picking easier, especially when you’re in a hurry (while a guard is coming your way!) but you can always turn the rumble off if you’re a purist in playing everything to the hardest level possible."

Because the default script doesn’t feel as smooth as Kingsal’s tweaked one. I believe the main advantage is as Amadeus mentioned a 3 second bow draw time vs 6 seconds which feels a lot better. I’m not completely married to the idea of this but if you’re able to integrate the ability for us to customize this without replacing the core files that would be appreciated.

Probably something like: $player1.setImmobilization("missionspecific", IM_ATTACK); ... $player1.setImmobilization("missionspecific", 0); No idea whether it works or not --- maybe it blocks using weapons, maybe also wielding them.

Innovation is good: someone has a new idea (or need) and executes it to the best of his/her knowledge and ability. When we start borrowing and adopting other people's innovations we are no longer innovating but creating a trend, for better or worse. Stgatilov is touching the tip of this, still small, but growing by the mission iceberg.

Completely disagree it was a very good idea that unfortunately came too early with idSoftware RAGE 1 because hardware was still and is not truly ready for it. Megatexture is for textures, what UE5 nanite is for geometry, it permits huge amounts of texture data in a level and even totally unique textures per each surface, no repetition unlike older methods. MT isn't simple a giant texture slapped unto a level, it is a type of virtual texturing system, the MT is a huge "texture" but it's data, is not all drawn on a level at the same time, like a normal one is, it is broken into smaller squared peace's and those peace's into even smaller ones for LOD aka mipmapping, then those peace's are streamed in, in real time has the player moves around. Again IMO It is a very cool idea and if the hardware was fast enough, to stream it fast and it was possible to compress the MT data, to very small amounts and still keep good quality, it would be a fantastic system for very unique levels. Rage 1 world may look bad at close distance, but at medium to large distances imo it looks fantastic and totally unique.

Megatextures were a horrible idea for obvious reasons, not sure why ID chose to learn that the hard way. The concept from what I remember is the whole map uses a single gigantic texture... instead of how we independently pick a couple of 1024 px brick materials for a few brushes and surfaces, the whole map acts as one model with one material and a single texture which probably needs to be 1 million x 1 million pixels even for a small level. This is ridiculous from a perspective of system resources with 100's of GB's of storage and huge (v)RAM requirements and hours of loading time, as well as raising the skills required for level editing since you now need mappers to also be texture artists and sculpt / paint their levels instead of just placing stuff. The only thinkable benefit is there's no repetition since every pixel on every part of the world is unique, but who notices any similarity with independent texturing if it's done right anyway? Detail textures have yet another advantage there: Since you scale the pattern independently on top of the original texture, you can make every surface appear as if it has unique pixels like megatextures. Hence why I'd advice having the details be very high-res, 4k or 8k even 16k if we can take it: Yes that's enormous, but remember we'd only have a few patterns probably no more than 15 in total, and can store them as grayscale then use a single image to modify both albedo / specular / normal (heightmap to normalmap): Map the detail in world space rather than the brush or model UV map, and the resulting pattern on every surface in the world will always be unique since the original and detail textures will be out of sync.

I'm just here to gush embarrassingly about another Wellington Crab mission. MD2: LHMN is a delicious bit of offbeat strangeness, dreamlike, surreal, but made odd sense to me at the right moments, so that I made it though the entire thing by myself this time, instead of being constantly (though enjoyably) overwhelmed as in Iris. Of course, it's lovingly crafted and peppered with clever little bits of window dressing that might seem distracting and extraneous in a lesser mission. I still have little idea what the overall story was, but I enjoyed every minute of the experience. Wellington Crab, you are a genius and an artist, and I look forward keenly to your next mission.

I mentioned this elsewhere, but just a historical note: the existing i18n.pl conversion script expects only a numeric value after #str_ in its pattern matching regex (and possibly method of hashing). I do think @datiswous's idea to have key/value pairs with values like: "#str_Nobody crosses me! Must get back Frothley's scepter Creep stole off me." is a good way forward. Maybe with this version, DR could actually choose over time to provide some .lang support. And probably the engine would have to create hash tables to avoid slow string matching with these long non-numeric strings. (Oh, one other thing, since we're talking about The Outpost. When I played it earlier the month under 2.12, my screen would periodically go black for a second or two, every minute or two. I wonder if anyone else sees this, or just my odd Intel graphics chip?)

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/

EDIT - v1.1 can be found a few posts below ------------------------------------------------------------------ Nameless Objects Mod v1.0 Description: this mod adds names to almost all core objects players can grab and hold in their hands. ------------------------------------------------------------------- How to use: As of this moment the Mod only works if you have "Core Essentials", which is included in TDM Modpack v4.0. Make sure to have "Core Essentials" and then download the *.pk4 attached to this post and place it in your TDM folder. I try my best to provide stuff people can experience first hand to form an opinion. I suggest you try "Business as Usual" by Bikerdude since this mission includes quite a few items you can grab right at the beginning. ------------------------------------------------------------------- Technical: The mod consists in a couple of def files and a script. I had to include two defs because otherwise there can be issues related with inheritance. The script does most of the work and it will run in the background as soon as a mission starts. The script runs once but it takes its time (10 to 30 seconds) not to hinder performance. All this is transparent to you. ------------------------------------------------------------------ Future: I wouldn't like this to remain as a mod and I volunteer to add names to all core defs for 2.13. I would, of course, use the translation system so that names can be translated in the future to languages other than English. I can name all core defs in a couple of rainy mornings but the Development Team must guarantee this work won't go to waste. The idea is that we name all core objects today and we let it stay: nothing changes in the source code and nothing gets displayed on screen. We get stuff done in the background and someday perhaps, all or part of it sees the light in some form. ------------------------------------------------------------------ There are quite a few things that must be discussed and agreed before we get started but the first step is: yes or no. People that might be interested in supporting and helping with this initiative: @datiswous, @Geep. Cheers! z_nameless_objects_mod_v1.0.pk4

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 commit which introduced unconditional writing of the s_mindistance and s_maxdistance spawnargs was this one: https://github.com/codereader/DarkRadiant/commit/541f2638c810588ada12e9a28360f16df6143d45 and it appears it was intended to fix this bug: https://bugs.thedarkmod.com/view.php?id=6062 The current logic is to set the spawnargs to the same values as in the sound shader, if a shader is set: // Write the s_mindistance/s_maxdistance keyvalues if we have a valid shader if (!_spawnArgs.getKeyValue(KEY_S_SHADER).empty()) { // Note: Write the spawnargs in meters _spawnArgs.setKeyValue(KEY_S_MAXDISTANCE, string::to_string(_radii.getMax(true))); _spawnArgs.setKeyValue(KEY_S_MINDISTANCE, string::to_string(_radii.getMin(true))); } This happens in the freezeTransform method which is called after performing some manipulation of the speaker entity such as moving or resizing it. In this case _radii is the object which contains the modified speaker radii, so this code is persisting the modified radii into the relevant spawnargs. This seems to be working correctly when I manipulate a speaker with a valid sound shader. The only way I can get 0 is by creating a speaker with a sound shader like blackjack_swing which does not have radii defined. In this case the speaker has a default minimum radius of 0.0 and a default maximum radius of 10.0. We could avoid setting a radius at all, but then the speaker just appears as an entity box rather than a sphere/circle, which I assume is the original reason for setting a default value. Right now I have no idea what code path would lead to having both a minimum and a maximum of 0.0. I think we'd need more detailed reproduction steps. This is the current logic for setting the spawnargs on speaker construction (rather than manipulation, which is the previous code): // Initialise the speaker with suitable distance values auto radii = soundShader->getRadii(); entity.setKeyValue("s_mindistance", string::to_string(radii.getMin(true))); entity.setKeyValue("s_maxdistance", radii.getMax(true) > 0 ? string::to_string(radii.getMax(true)) : "10"); So there is a specific check that s_maxdistance is greater than 0 before setting it as a spawnarg. Code similar to this has existed for many years, as far as I can see, and I have to go as far back as 2009 to find something different (originally all speakers just had hardcoded 16/32 radii to make them visible).

Now there's a good idea for a custom AI. A spider queen with six or seven spiders following her....

Might be worth a try. I browsed the source code yesterday a little, but I had no idea where to even start looking for it. I've been building a sort of starter-project for it, but it's not public yet. But my support for DR is not ready for production or anything. Everything seems to work fine, except I'm having issues with textures, and tbh I'm not sure I'm gonna make it. I am about to make my repo public regardless of that, though, but I still need to get a lot of stuff in order. Meanwhile, if you'd like to move forward without DR, you could try NetRadiantCustom or TrenchBroom. Personally I recommend NRC (although TB might be a bit easier to start with). The plugin I'm using is FuncGodot (formerly known as Qodot). It's currently the most recommendable. Patches and NURBS aren't supported by any plugins yet, btw.

Skins don't require a model path, that's just a convenience feature to allow the skins to be associated with the model(s) in the editor. However I have no idea if an unassociated skin can be used on a func_static. I suppose there's no reason why it couldn't work, but it's not something I've ever tested and I wouldn't be surprised if it fails to do anything (either in the editor or the game).

After editing some objectives, now I'm getting this console warning pop up any time I check the objectives in game. I've never seen it before. Everything appears to be working though. I have not edited the tdm_objectives.gui file and it is intact in the tdm_gui01.pk4 folder in TDM. It references DestroyDelay here. onAction { set "gui::DestroyDelay" OBJECTIVES_DESTROY_DELAY; set "gui::CloseGUI" "1"; set "cmd" "updateObjectives"; } but I have no idea what I could have done in my fm to give it issue. [EDIT] I get this warning in other missions now, not just mine. I reinstalled TDM and I still get this warning. Is this a 2.12 thing?

SVN is here? https://svn.thedarkmod.com/publicsvn/darkmod_src/ no idea where these files are

Do you see an error/warning in the console? You could upload it so someone could take a look. Just an idea.