Search the Community

Beta 11 Fix finished-on state auto-update was unreliable Slighty improve scanner title/author detect Tags are now named some whatever regular-version-looking thing to force GitHub to put the newest at the top

It's hard. I see what you are thinking about is a "bullet point" pattern, with or without a bullet point character. For that case, I suppose what we are trying to detect is: - the line starts with the bullet point pattern - a "J" character (say) with a shortened spacing, is somewhere in the line. - the line itself in the xd file is long enough to force a word wrap (let's just think about a single wrapping here) - the author assumed a particular word wrap point, and put in extra spaces in mid-line, immediately at the wrap point, so as to indent the latter part of the line, aligning with the indent of the first part. - the shortened-spacing J screws up the resulting alignment. Probably would need a script/program to winnow this down... ideally, that algorithm could also restrict attention to just Stone font. I'm OK with putting such an effort off for now, maybe revisiting it for 2.13.

The problem does not show up with all related dev builds. However, I cannot test with the last build (16854-10518), which I simply cannot start and get the report EDIT: As per our friend dragofer's suggestion, I made a blank script file in this build and removed the turrets from the WIP for a test. Then I can start the game and the mission and can save/load without problems. Summary: 16842-10488: no problems 16854-10518: cannot test (see above) 16854-10518 (modified scriptfile, no turrets) : no problems beta 1: problem appears

I've always ran into an unsolvable limitations when it comes to creating FM independent mods. This probably wasn't brought up a lot as I seem to be one of the few creators working on universal modifications rather than per-FM ones, meaning they're meant to always work when placing their pk4 in the core TDM directory. The issue is similar to tdm_custom_scripts.script: Since script files don't get automatically executed but must be called (unlike defs) you need to run yours by using an #include then calling your main function from a builtin script called tdm_user_addons.script. The problem is you can't have multiple addons installed this way since each pk4 overrides that file causing only the last one (in alphabetical order) to function. With tdm_custom_scripts this isn't an issue as that's meant to be overwritten per FM and only one can be loaded by design... for tdm_user_addons it becomes a problem when you want to make multiple mods that don't conflict with each other. I wanted to know if there's any workaround so far, or one could please be taken into account for the next update. Can we have some means of automatically #including a global script with an unique name? A quick solution I'm thinking of is to just automatically execute the script with the same name as the pk4: If you have "tdm_mod_whatever.pk4" inside your DarkMod directory, "script/tdm_mod_whatever.script" would be ran by the engine once the map starts, or something among those lines.

So, I wanted to build on my good experiences with the "Frob" stim/responses that are attached to all entities and find another use for them...and I failed again. Task: If the player extinguishes a certain flame (A) with a water arrow, a script should be started and A should be completely removed from the map (so that it cannot be ignited again with a fire arrow). Solution idea: Every flame has an inherited response to water/water arrows. You can also see this in the S/R editor. So I thought, I'll just add another response to water on the flame and add the desired commands. Result: It doesn't work, the script won't start and A does not get removed. What am I doing wrong? @Dragofer: Sorry for being such a pain, but this drives me crazy. @grodenglaive@Frost_Salamander: For your information...Maybe we should start an extra topic for the the whole subject...?

Hey folks, I am looking to call a certain script in my map.script-file repeatedly while lockpicking a door. The goal is to check if any guards (which are spawning as "neutral") are able to see me lockpicking, and change their relation to the player accordingly. Like this: void witnessCheck(string entity_name) { ai theAI = sys.getEntity(entity_name); if(theAI.canSeeExt($player1, 1, 1)) { sys.println(theAI.getName() + " has witnessed a crime!"); theAI.lookAt($player1, 3); theAI.setEntityRelation($player1, -1); // theAI is now hostile } else { sys.println(theAI.getName() + " didn't see anything suspicious."); } } void crime_lockpick() { sys.println("You commited a crime! Check for witnesses..."); // call one check for each guard entity on the map witnessCheck("atdm_ai_citywatch_1"); // .... } with crime_lockpick() being called repeatedly while lockpicking. (It's a simplified version of the code suggested in https://wiki.thedarkmod.com/index.php?title=AI_Ignore_Player ) A frob-response of the door entity with a "run script"-effect is only called once, and I see no way of telling the script if the player is currently lockpicking or not, hence missing the break condition for any while-loop. Furthermore, there's no distinction between frobbing/opening an unlocked door and lockpicking a locked one using this method. Sadly, the get-method in void getDoorStatus(entity door) { if(door.getBoolKey("locked")) sys.println("This door is locked."); else sys.println("This door is unlocked."); } always returned 0. A used_action_script as described in https://wiki.thedarkmod.com/index.php?title=Tool,_Key,_custom_used_by_inventory_actions would be neat (calling the func every frame in respect of the used inventory item, i.e. a lockpick), but doesn't work on doors apparently. I wasn't able to wrap my head around the whole door mechanics yet, and obviously lack knowledge of idtech4 in general. Thus, I hope that any experienced DarkRadiant user might point me in the right direction. Thanks in advance have a good one

I actually committed the relevant changes in source several months ago, but for some reason it looks like the generated HTML on the public user guide page hasn't update. I'll have to see if there is some problem with the CI script which is supposed to generate the web page from source control. I think the problem may be that the CI system is expecting the .html file to be included in source control directly (which it no longer is) rather than running AsciiDoctor itself.

With TDM 2.12, after the credits finished, the "Mission Complete" screen did not display. I found that the screen was black and I could hear my footsteps when I tried to move around. I think the reason for the mission not completing successfully was that the "Do not kill or harm allies" objective was never marked as "1 = STATE_COMPLETE" instead it was left as "0 = STATE_INCOMPLETE". Note, I didn't use noclip throughout the mission. Same as: https://forums.thedarkmod.com/index.php?/topic/18054-fan-mission-the-accountant-2-new-in-town-by-goldwell-20160509/&do=findComment&comment=458491

How about using TDM automation framework (and maybe pcem/qemu)? More info see: https://forums.thedarkmod.com/index.php?/topic/19828-automation-features-and-discussion/

As my custom assets work has increasingly shifted from models towards scripting, I'll open a new thread here to contain any scripts that I write which can be reused in other missions, starting with the A ) Presence Lamp This is a Lost City-style lamp that brightens and dims depending on the presence of the player or an AI. It fades between 2 colours and can trigger its targets whenever it switches fully on or off, so it should also be viable in various other situations. The standard setup consists of the following: - a trigger_multiple brush. The spawnarg "anyTouch" controls whether AIs, too, are able to activate it - a presence lamp, highly recommended with a colorme skin - one presence light, or any other light with appropriate spawnargs The targeting chain is trigger brush -> lamp -> light When the player or an AI stands in the trigger_multiple brush, the lamp switches on and starts a short timer. Subsequent triggers reset the timer. If the timer runs out because no one's standing in the trigger brush anymore, the lamp switches itself off. Notes - Multiple trigger brushes can target the same lamp, and one trigger brush can target multiple lamps. However, each presence lamp can only target one light, so if you want i.e. a bouncelight you'll need to hide an additional silent presence lamp somewhere and target it from the same trigger brush. - The lamp and the light use their own colour spawnargs respectively, since setting 0 0 0 on a lamp would make it appear pitch black. - Technically the trigger brush can be exchanged for anything else that triggers the lamp every 0.5s (this number can be changed via "update_interval" on the lamp), i.e. a trigger_timer. - This was originally named the proximity lamp and was one of many scripting jobs for The Painter's Wife. I've renamed it to "presence lamp" because the mapper may place the trigger brush(es) wherever he wishes: proximity to the lamp is not a factor. Credits go to Bikerdude for putting together the crystal lamp models. Download Presence Lamps - Google Drive Place or extract the .pk4 into your FM archive, then look up the presence lamp prefabs. If you already are using other custom scripts, remember to add the presence lamp's .script to your tdm_custom_scripts file. B ) Teledoor This is a Skyrim-style door which opens just a bit into a black_matt "void" before teleporting the player to a different area of the map, which may represent the other side of the door. This is used for connecting physically separated map areas with each other, such as when there's an exterior/interior split of a building or ship to allow for more mapping freedom. [Full Thread] C ) Mass Teleport This is a teleportation setup designed to seamlessly teleport the player and any moveables between two identical-looking areas. This allows the mapper to link 2 physically distant areas with each other while maintaining the illusion that they're connected. The teleportation zones should be free of AIs as they can't be teleported like this. [Post] D ) Automaton Station A station for Sotha's automatons (includes the automatons) which can be switched on and off by patrolling automatons. (Part of core assets as of 2.10) [Post] E ) Camgoyle A sentient turret originally made for the FM Written in Stone. It's based on the new security camera entity and augmented with scripting to allow it to fire magical projectiles at the enemies it detects. People are more than welcome to use it and to convert it into something else, such as a mechanical turret. [Post] [Download] F ) Audiograph The audiograph is an Inventor's Guild device for playing back recordings stored on spindles, which are small metal cylinders the player can pick up and store in his inventory. [Post] G ) Turret A new companion to security cameras familiar to Thief players. It will become active as soon as an enemy is detected by a targeted security camera, firing projectiles to fend off the intruders. Similar to the security camera and the camgoyle sentry, turrets are highly customisable in their behaviour and appearance. [Thread] G ) Fog Fade Dynamically change fog density depending on what location the player is in. [Thread]

A Problem Arises I've paused subtitling of the Lady02 vocal set, because of a problem with the voice clips described here: https://forums.thedarkmod.com/index.php?/topic/21741-subtitles-possibilities-beyond-211/&do=findComment&comment=490151 While a way forward is being determined, I'll work on a different vocal set. Maybe manbeast, for which Kingsal just provided me the voice script.

If the "mission fails as soon as stealth score turns non-zero," that would not be good for ghost players. They might need to find out "how" they failed and experiment to avoid alerting guards. They might need to take those score points as a "bust". They might need to take those score points to complete an objective. Then, mission authors would need to encode exceptions into their missions, which would be a lot of work (if they decide to do it at all). However, part of what makes ghosting challenging and fun is when mission authors do not create their missions with ghosting in mind. Please see: Official Ghosting Rules: https://www.ttlg.com/forums/showthread.php?t=148523 Writing code for these rules would be a huge undertaking. Ghost Rules Discussion: https://www.ttlg.com/forums/showthread.php?t=148487 Creating an official mode could alienate these dedicated ghost players, because it would clash with what is considered ghosting in the community. Including the Stealth Stat Tool mod in the official release would be more useful. Or, making the audible alert states of guards quick and easy to recognize could help as well. For these reasons, I don't agree with an official "Ghost" mode. If the dev team were to do it, we should consult with @Klatremus so we get it 100% correct or not pursue it at all. (This ghosting bit should probably be in its own thread.)

Regarding the earlier discussion about telling when an objective is complete from script, I just added a brief entry under the wiki's "Objective Editor/FAQ & Examples" called "Determining an Objective's Current State from a Script" As for as Stim/Response... I often find it hard to wrap my head around too. I don't recall writing anything very authoritative about it, but maybe in some narrow context? Or maybe @JackFarmer, you were remembering someone else's explanation? So, I can put it on my list of possible wiki topics for 2024, but it would require a lot of research by me, and likely @Dragofer or others could do it better & quicker.

My implementation is just a simple gui script cmd, is very naive and just follows the same system of other existing gui script cmds, made by idSoftware. I have zero idea if is synchronous or asynchronous that is beyond my expertise, nor if it is the same as done in Quake 4. Plus like I said above I do remember experiencing some small problems with it, when trying to use it to call more complex namedEvent's, that may be connected to the "synchronous or asynchronous" stuff.

Yes: It could then be distributed as a mod that works universally. I may propose it for the modpack! I already did a brief test and it worked: I managed to give the player a guard head while the guard helmet was being worn! But soon after TDM would crash to the main menu, and after a few tweaks to the script even that stopped working and there's only the crash now. Likely some obscure internal issue that can be hopefully tackled in the engine. Thank you, that I shall! And the biggest issue with getting mods to work is the need for a tdm_custom_scripts.script which has been the biggest thorn in the backs of modders: I'd say either execute all scripts automatically the way all files are loaded, or if that's unsafe just allow a script carrying the name of the pk4 to be auto-executed.

Part of the location system is a script hook, where you can trigger a script based on location. But of course it's geared to the player's location. But it itself is just a script, so it's easy to just make a new copy, keep just what you need, change the variable names, and instead of a player location check at the top, you make an AI location check. And then you can have that new location script trigger a AI-location-script to keep track of the AI's location. (I tend to use the spawn args of dummy objects to hold data like this, but however you want to do it.) Then have it or another script trigger the barks based on that location value. And because it's all being done by script, you can package it with your FM to work. No sourcecode change necessary. The catch is, I don't know if id4's location system even recognizes AI. I think it may only be able to send back the player's location. If that's so, either you have to then change the source code for it to track AI location (which might give a performance hit?). Or another way is what I originally did for the location system, which was to use trigger brushes (the "object inside boundary" trigger brush type) at the entrances of locations and let those trigger the script that does the work. That should work but is more fiddly since you have to make sure the AI can't break its logic going back and forth many times. It's definitely possible. (Anything is technically possible. It's an open source game.) It might take some work to make it robust and not fiddly. Edit: A thing to keep in mind is that most AI are mostly frozen when you're not near them anyway. If I were trying something like this, I'd just use the location system for the player as usual, so it's the AI barking differently based on the player's location, not the AI's location, and then just design the level so that works out properly. (Most AI that the player will ever hear will be in the same location as the player. So the player location is a fine proxy.) Then you can just use the current Location system script as I mentioned at the top.

To cater to both audiences. I mentioned LibreGameWiki as one example. nbohr1more mentioned other uses. Explicitly allowing reuse and spread will help TDM reach a wider audience and would hopefully attract more volunteers. More volunteers which can help improve both TDM versions. There are several benefits for a project of being in the Debian repo. One is that TDM Debian-users can report defects on any package directly to Debian (no need to register on separate forums). Debian may then fix the issue themselves (in their "TDM-libre" package) and will offer the patch upstream to TDM, who can then choose to accept or reject the patch. I envision "TDM-libre" to have the same capability of downloading any mission as regular TDM. The only difference is that "TDM-libre" would come packaged with the regular engine (which is GPL+BSD) and an included mission that has libre media/gamedata. When I play TDM by myself, I want the unlimited-play and can accept commercial restrictions. But if I were to promote it somewhere, or charge for a stream when playing online, or make a video, I would want a version without commercial restrictions (and can temporarily accept limited-play) to make sure I don't violate anyone's copyright. Perhaps. That's what I'm trying to find out.

I rather regret that the namedEvent and runScript ideas were put in the same bugtracker request, since they each clearly justify their own topic. From the discussion above, it seems that namedEvent would be easier/safer to implement this round. It appears runScript is more problematic, and furthermore, may not be the only or best way to implement new capabilities for readables. The latter (e.g., tabs, different backdrops for different pages) probably also needs a separate bugtracker item. Turning to namedEvent... @stgatilov in the OP was wondering about whether the in-GUI call to namedEvent should be synchronous (i.e., happen immediately) or asynchronous. Synchronous is easier for the script writer to think about, and would be my preference. As he indicates, this would be less like other gui script aspects (some of them "weird"), but more like calls to gui named events from doomscript. And, by introducing nested call stacks, he thinks may provide future opportunities for reduction in weirdness. It is unclear to me if HMart's implementation is synchronous or asynchronous. Probably we should not worry about whether this usage is consistent with Quake 4, since we'll probably never know.

I suggest you use the term "I", to make clear that it is something YOU want, and that you speak for yourself. But, as wesp5 mentioned, I don't really know what this is about, at all. And, I'm also wondering about all the newly registered people lately, who just arrived at this forum, and already want to revolutionize this mod. This is a thing I noticed 2 or 3 years ago, and which hasn't been present in the 15 years I play this mod and frequent these forums now. Really seems like a common thing these days, to not knock on the door, but kick it in, and stomp right in.

And shelve new initiatives for 12 months. At a glance, the below script-heavy missions are orbiting close to the boundaries: A house of locked secrets Hazard Pay Iris Painter's Wife Shadows of Northdale ACT I Seeking Lady Leicester Written in stone All it takes is a little push. Each new release of TDM comes with new core scripts and sooner or later something needs to happen. Let's hope the next "big one" doesn't get impacted.

I dom't use it, i found it here with the filter set to OpenSource. the TOS and PP isn't excluding for an OpenSource app, if they use ads mean that they also need to pay an server for this online service. OpenSource is not synonymous with free either, perhaps after the beta phase it is no longer free, so perhaps you can take advantage of the fact that it is still free to create a series of textures that can be used or search another one in Futuretools. AI generated textures and assets, by definition, don't have any copyright, so you can use them as you want. https://www.futuretools.io/?pricing-model=free|open-source&tags-n5zn=gaming

TDM has tons of textures from "free" texture resources that do not allow redistribution and cannot be incorporated into a commercial project. Someone would need to create a huge replacement pack of textures that do not break the look of existing missions and do not infringe on the copyrighted textures. Also, many artists who contributed to this project do not want 3rd party entities to use their work in commercial projects. They intended the models, textures, sounds, animations to be exclusively used for Darkmod content. You would either have to replace ALL assets or contact every contributor and ask them to re-license their assets. Many contributors are no longer active with the project and haven't visited the forums in years so it would be no easy feat. I cannot speak to Debian policy but I think that they treat installers that add non-free content the same as non-free content itself. One could argue that Steam is such an installer but I guess Debian would counter that there are a few fully Libre games on Steam. I think Debian, Ubuntu, or Linux Mint need to consider a repo that allows for games (etc) that include non-libre content but intentionally offer this content for free to the community with no stipulations other than "don't try to sell it as a product".

The gamepad implementation allows for a great degree of flexibility to personalize settings, aside from a few minor issues that I mentioned here: https://forums.thedarkmod.com/index.php?/topic/22337-gamepad-bindings/ I would say that playing TDM with a gamepad works very well, especially considering that it was implemented as experimental and hasn't been changed since then. If I could, I'd go back to 2021-you and congratulate you on buying that gamepad. I notice that your DarkmodPadbinds.cfg looks very different from mine...

It seems like more and more "thief" and "thief players" is becoming a short hand to dismiss community members earnest desire to improve the game - which happens to be a barely legally distinct "thief style" game which was made by thief fans for thief fans and is "designed to simulate the stealth gameplay of Thief". Who is the predominant player base of the game supposed to be beyond fans of the thief games? Is there some better avenue to find feedback for the game beyond this forum? FOSS and linux forums? I have seen maybe half a dozen posts from that segment. I am a thief fan, I play thief fms, my association with those games is what drives me to play and make things for this game. Are we supposed to pretend the original games are not a huge reason why most of us are here at all? TL;DR version: