Search the Community

Unfortunately many things in this engine are best done on the editor and then called through script, not created directly through script, one of them afaik is triggers. You normally create a trigger by creating a square brush on the editor manually, and give it the trigger_hurt material, so the size and shape comes from that brush, it also creates the physics (a clip model) automatically, then just need to use the script function, entity ent = sys.FindEntity("entity_name"); To get it and use it in the script to do whatever you want. Creating a clip model from script, is probably possible, thou I never did it, so I don't know how... thou I do know how to do it through c++. But I don't think there's any equivalent script functions exposed to the script system, if I'm mistaken please anyone correct me. Perhaps something to recommend in the TDM roadmap?

I just read@motorsep Discovered that you are able to create a brush, then select it and right click "create light". Now you have a light that ha the radius of the former brush. Just read it on discord and thought it may be of use for some people in the forums here too.

I just found this thread on ttlg listing Immersive Sims: https://www.ttlg.com/forums/showthread.php?t=151176

Recently revisiting the forums after a longer period of time I wanted to check the unread content. I don't know if I am doing this wrong since.. ever... but on mobile (visiting the unread content page on my smartphone) you have to click on that tiny speech bubble to go to the most recent post in a thread. If you don't click correctly you'll hit the headline and end up at post 1 in the beginning of the thread. It's terrible on mobile, since not only the speech bubble is really small and was to miss. But also the thread headline is just millimeters away from it so you go right to the first post that was ever made instead of the most recent ones. Am I doing it wrong? I just want to go through u read content a d the to the newest post from that topic.

1. Create a water entity (=water_source) 2. Create a small brush (size does not matter) and convert it into an entity of the class "sliding door" (=water mover) - give it the properties a. frobable - 0 b. noclipmodel - 1 3. Give the water mover the follownig spawnargs to remove the default sounds: a. snd_move - nosound b. snd_close - nosound c. snd_open - nosound 4. Bind the water_source to the water_mover 5. Give the water_mover a fitting translating value, for example "400 0 0" 6. Target the water mover from the switch in question

A@datiswous Ah yeah, well sorry, I was quiet busy and only visiting discord. First time here on the forums since months now I think.. Thank you for the subtitles. I encourage everyone who is interested in using them to download it from here as I'm not sure when I'll be able to implement them myself into the mission. Again, thank you for your work.

Of course, it is one of the reasons for the decline of online forums, since the advent of mobile phones. Forums on a mobile are a pain in the ass, but on the other hand, for certain things there are no real alternatives to forums, social networks cannot be with their sequential threads, where it is almost impossible to retrieve answers to a question that is asked. has done days ago. For devs for internal communication, the only thing offered is a collaborative app, such as System D (not to be confused with systemd). FOSS, free and anonymous registration, access further members only by invitation, full encrypted and private. https://www.system-d.org

Ignoring is somewhat inadequate as you still see other members engaging in a discussion with the problematic user, and as Wellingtoncrab says such discussions displace all other content within that channel. Moderation is also imperfect as being unpleasant to engage with is not in itself banworthy, so there is nothing more to do if such people return to their old behaviour after a moderator had a talk with them, except live with it or move away. I'd be more willing to deal with it if it felt like there were more on-topic discussion, i.e. thoughts about recently played fan missions or mappers showcasing their progress, rather than a stream of consciousness about a meta topic that may or not have to do with TDM. I guess the forums already serve the desired purpose, or they just compartmentalise discussions better.

Yep. Both checked. Tried it on round door with only rotate and only translate as well as both (my goal). In all cases the door was visually there but NON solid and NON frobable. Guess some change in base code over past 4 years. No biggie as I did a work-around. But acouple of hours testing - was it the water against the door? no. Something screwy with the brush door? No, deleted recreated, converted to model, still NG. Created regular sliding and rotating doors in water and out, with round model replacing normal one. Still NG. Was there any test I missed? On with the mapping, tally forth once more into the breaches. Mwah ha ha ha

In my mission, I have a round door that rotates AND translates. I started this 4 years ago before I got cancer, and then the door worked. Not anymore! I finally got a ROUND to testing this. It does not matter the type of door, if the door is a round brush OR a round model, in the game the door is non-solid and non frobable. I can, however trigger it in the console and it works as it should. I am going to try and make a solid (rectangular) door in front of it as an overlay and use script to achieve my goal. Will let you know how it goes. Update: Works great, had to do a screen grab of the circular door+ wall of the size of rectangular door. Create dds image and material file, so I textured the rectangle door and you can't see difference in game. frob the rectangle, it vanishes and circular one rolls out of way. YAY

FEATURE REQUESTS: 1. Array tool - to duplicate selected model or entity or brush via UI on XYZ with spacing parameters (kinda like Blender's array modifier). 2. One-click surface/material copy to either face or entire brush. Currently I have to setup one face by using Surface dialog and then copy/paste it (using hotkeys combo) to desired faces (for which I still have to deselect selected face and then select new one). Very very tedious process. It would be a lot smoother of copied surface parms (material, tiling, etc.) could be applied in one click in 3D view. 3. Ability to set tiling on the entire brush numerically. Currently numerical entry fields are grayed out in the Surface UI when whole brush is selected Thanks beforehand

I don't recall a system for noise masking. It sounds like it'd be a good idea, but when you get into the details you realize it'd be complicated to implement. It's not only noise that that goes into it, I think. E.g., a high register can cut through even a loud but low register rumble. And it's not like the .wav file even has data on the register of what it's playing. So either you have to add meta-data (which is insane), or you have to have a system to literally check pitch on the .wav data and paramaterize it in time to know when it's going to cut through what other parameters from other sounds. For that matter, it doesn't even have the data on the loudness either, so you'd have to get that off the file too and time the peaks with the "simultaneous" moment at arbitrary places in every other sound file correctly. And then position is going to matter independently for each AI. So it's not like you can have one computation that works the same for all AI. You'd have to compute the masking level for each one, and then you get into the expense you're mentioning. I know there was a long discussion about it in the internal forums, and probably on the public subforums too, but it's been so long ago now I can't even remember the gist of them. Anyway the main issue is I don't know if you'll find a champion that wants to work on it. But if you're really curious to see how it might work, you could always try your hand at coding & implementing it. Nothing beats a good demo to test an idea in action. And there's no better way to learn how to code than a little project like that. I always encourage people to try to implement an idea they have, whether or not it may be a good idea, just because it shows the power of an open source game. We fans can try anything we want and see if it works!

That turns out to be not completely trivial. You can use the start_off spawnarg on the foglight to have the fog be turned off at map start, but this just turns the grey fog into black fog. I doubt if that's what you want, so don't use that spawnarg. With a little bit of scripting to hack the foglight radius, you can fake it pretty convincingly though. Suppose your foglight has a radius of 1024, that is, shaderParm3 = 1024 on your foglight. Then put the following in your script file: float foglightradius = 1024; void toggle_fog() { foglightradius = 10000000 - foglightradius; $foglight.setLightParm( 3, foglightradius ); $foglight.activate($player1); return; } We'll turn the fog off at map start; make an atdm:target_callscriptfunction entity that calls the toggle_fog() function, go to any worldspawn brush and target that entity from it. That'll call the script once the moment the level starts and switch off the fog. Crucially, it will also set the fog radius to 9998976, which is huge and will make the fog almost completely transparent so the fact that it's now black fog instead of grey will be almost imperceptible. When you want to turn the fog back on, call the script again from trigger_once or whatever you're using, and it'll switch the light on and restore the fogradius to 10000000-9998976 = 1024.

I investigated the topic, and I still think it is too hard. Precomputed visibility is perhaps the best thing for us. So we can split space into cells, and precompute whether cell A and cell B have unoccluded straight line connecting them. We can limit occlusion only by brushes: there is no need to take models/patches into account. Precomputed visibility should be done on per-area basis. When we compute the visibility data for one area, we consider all visportals and all other areas opaque. In other words, we only check for direct visibility within the area. If such information is available, it can be combined with existing visportal&area traversal code. The main problem is how to precompute visibility on per-cell basis. A solution must: Be conservative: you don't want to occasionally see small holes into nowhere Do perfect occluder fusion: otherwise a big house would not occlude most of the stuff behind it. Have sane build times for brush geometry of our scale. This inevitably leads to pretty complex algorithms. If mapper can add a special brush and say "this is major occluder in visarea N", then we can probably (not sure yet) verify that he is correct in saying that, and simply raytrace this occluder during visportal traversal. But realistically... I don't think mappers would really use this tecnhique, except maybe for a very few people/missions.

I'm using the version from kcghost. I just tested and I can't see any difference inside the inventory. On the stats itself it doesn't show the different loot types (still seen in the inventory), but instead gives more info on stealth score. Edit: I see Dragofer made an updated version of his script. I have to check that out. Edit2: That version works: https://forums.thedarkmod.com/applications/core/interface/file/attachment.php?id=21272&key=02755164a3bed10498683771fe9a0453

Thanks for the clarification! I had no idea antiportals were a thing, I can't find an antiportal texture or entity in DarkRadiant so I presume it comes in another form? This means the behavior I'm imagining is already coded in there somewhere: Only change then would be automatically treating every solid brush as an antiportal, of course without having it derender itself only what's behind it... at least that's what I'd initially think, reality is always more complex. Obviously we don't check all world surfaces on the map: Visportal culling acts first so any wall that isn't in an open room doesn't exist from the start, same for surfaces that don't poke into the view frustum and are outside your FOV... if a smart approach is possible we could even check walls in order of distance from the camera so the mask masks itself and even walls covered by other walls are dropped. Only if a front-facing brush surface that wasn't portal-culled pokes into view it's calculated as an occluder; The engine then checks all entities that weren't themselves already culled by portals / frustum and removes those found to be completely covered by a wall's projection. This could be a big success is it could do all of 3 things: Hide models that don't poke beyond the mask, disable lights who's radius box is fully covered by the wall, and close portals that are fully covered by a wall meaning whole rooms can get hidden when their doorway is masked by an occluder. (Anti)portals do all of those things I believe, so it's a matter of somehow getting all surfaces to act as such in an optimal way.

Occlusion culling is not as easy as it looks. For instance, if you simply check entity's bbox against individual brushes, then most of the entities behind walls would pass the check because no individual brush covers a whole entity completely. Also, there are dozens thousand brushes on large maps, you cannot iterate through them naively. On the other hand, this is close to the concept of "antiportals". That's when mapper puts an "antiportal", ensuring that everything behind it is occluded, and the engine takes it into account whenever it works with portals. But this requires work from mapper, and I don't think it would provide much help. To get serious benefits, you need to recognize the whole wall consisting of many brushes as a single inpenetrable surface, at which point you necessarily have something really complicated. I thought about doing Umbra-like occlusion culling on brushes (with automatic portals and conservative rasterization inside), but I realized it's ton of work. There is always something else to do. By the way, the recent change is not about what player does not see, it's about what light don't see/hit. Just rendering a surface is very cheap because of depth prepass, but light interactions are costly with all the textures, soft shadows, etc. Realizing that you don't need light interaction on something you see is quite beneficial. The problem with original Doom 3 engine is that it basically lights up all objects within light volume. With the exception of static shadow-casting lights, portals are just ignored! I have expanded usage of portals to dynamic lights. It might sound funny, but there is still some room for improvement in this area...

I looked but didn't see this video posted in these forums. It's pretty cool.

It wasn't a "sacrifice", it was a deliberate decision. People wanted the game to be as close as possible to the original, including pixelated graphics. If you ask me, the former version based on the Unity engine looked and felt better. But, hey... I guess I'm not the right person to judge that, as I never played the original, and always found that the art style of System Shock 2 is much better anyway. This also illustrates the issue with community funded games: Too many cooks spoil the broth. In game design, you need freedom, not thousands of people who want you to do this and this and that. Just take a look at the Steam forums and see how all those wimps complain again about everything. Hopeless.

If you're using transparent textures, remember they need to be visportaled. A worldspawn brush with transparent textures won't seal. Not sure if this is the cause of the issue you're having, but I remember having trouble with it once.

So giving it none of those tags, but making the AI invisible, silent, non-solid, and on a team neutral to everyone would not work? Oh well, it was a horrible inelegant idea anyway.

Yes, I started a new map, made my usual Large brush box (with default lighting/etc.) and saved it. Then loaded the box and imported the original layers. Things are fine with each layer, no internal leaks or external leaks. As I have been proceeding, and adding more structure/areas - each in it's own layer I am only having normal(?) blunders as I am trying to re-learn scripting, DEF's, etc. Can't seem to seal any building with transparent windows, and in one new area DM drops two portals but does not say why (no lin files) and throws another out as useless (inside a non leaky building but separating two rooms). Still have a long to-do list, finish town, visportals, add AI, yadda yadda. BTW I downloaded a free to use 3D cowboy hat but it is in obj format. Imported it in DR how do I orient it/attach to heads? Man, this stuff is time consuming! but loving it.

What I understood is that the idea of TDM was born from that it was unclear if T3 would get a level editor at the time. Source: https://web.archive.org/web/20050218173856/http://evilavatar.com/forums/showthread.php?t=268

This one is really essential: https://www.ttlg.com/forums/showthread.php?t=138607 Should work fine with the GOG version.

https://www.ttlg.com/forums/showthread.php?t=152224 There is a new mapping contest over on TTLG for the Thief: Deadly Shadows 20th Anniversary and the organizers were kind enough to include The Dark Mod along with all of the Thief games as an options for making a mission to submit as an entry. The deadline is a year from yesterday and the rules are pretty open. I recommend going to the original thread for the details but I will summarize here: Rules: - The mission(s) can be for Thief 1, Thief 2, Deadly Shadows or The Dark Mod. - Collaborations are allowed. - Contestants can use any custom resource they want, though TDM cannot use the Deadly Shadows resource pack. - Contestants can submit more than one mission. - Contestants can enter anonymously. - The mission(s) can be of any size. Using prefabs is allowed but the idea is this is a new mission and starting from an abandoned map or importing large areas from other maps is not allowed. Naturally this is on the honor system as we have no way of validating. Mission themes and contents: There is no requirement from a theme or story viewpoint, however contestants might consider that many players may expect or prefer missions to be celebratory of Thief: Deadly Shadows in this respect: castles, manors, museums, ruins inhabited by Pagans and the like, with a balance of magic versus technology. This is entirely up to the authors, though, to follow or not - it is just mentioned here as an FYI and, while individual voters may of course choose to vote higher or lower based on this on their own, it will not be a criteria used explicitly in voting or scoring. Deadline: May 25th, 2024 at 23:59 Pacific Time. See the TTLG thread for details on submissions and the voting process. Provided I can make the deadline I hope to participate. It would be nice to see the entire community do something together, and expressing our complicated relationship with this divisive game seems as good a pretext as any.