Destined

I have read some time ago (or maybe someone told me? I forgot) that the current American accent is actually closer to the old British one than the current British accent, because it had less development compared to the English language in Great Britain. So, if you want an accent that is close to older English, you would have to use a North American accent.

You can create the model near the surface you want as Jedi_Wannabe wrote, lift it up in the 2D view and use the "Floor Selection" button on the left side, to drop it to the first surface beneath it. This way, you don't need to fiddle around with the height. Apart from that, I am not sure if there is a quicker way. Regarding the second question, you can use the combination Ctrl + Middle Mouse Button in your 2D view, to move the camera to the respective point. It is a bit difficult to orient oneself, but if you have the object in sight in all three 2D windows, you can center it quite easily by clicking on it in all three views. That is the only way I know, at least. EDIT: you see the current camera position as a blue diamond and the field of vision as two blue line emerging from it. This helps to adjust the camera. With the Middle Mouse Button (without Ctrl), you can rotate the camera in the respecticve view window.

If I remember correctly apart from the possible frustration, it was not clear why the AI should recognise the player's shadow as hostile, while shadows of other guards would be viewed as friendly. If they (literally) jump at every shadow, it would increase the alert rating into infinity; if they don't, it would be unrealistic that they only react to the player's shadow, which would defeat the purpose of wanting to increase realism and rather only increases difficulty. Consequently, you would have to implement another feature, that lets the guard recognise a shadow (without really alerting it) and let it check who the shadow belongs to before increasing alert rating. This, in turn, increases the work you would have to put in drastically.

You mean like this?

Agreed. I hope I find the time and motivation to continue my WIP. Maybe I could finally contribute something myself...

Loot should have its own entity class and according to the wiki it is possible to filter by them. I have no access to DR right now, so I cannot test this, though. I assume the filter as written in the section "More Complex Filters" would be exactly what you are looking for. All you need is the correct word for loot as an entity class. You could check in the def file, which entity type is defined there.

Thief Simulator is not really comparable to Thief apart drom playing a thief. It is a nice idea, but has no real story other than "you are a thief that tries ro make a living". I have started it, but have not played it for some time.

Ten years is really impressive. And it is nice to see that, even if the community has grown smaller, there are still new faces popping up from time to time. I have hopes that this community will survive another ten years and am really excited to see how it will develop further.

You can create filters in DR for specific entity types. See the Wiki: http://wiki.thedarkmod.com/index.php?title=Defining_custom_Filters_in_DarkRadiant

I love this song. I first heard it in the trailer to the movie "Logan" (also very recommended, if you like the X-Men; and even if you don't it is quite good). Since then, it is a permanent part of my playlist.

If you just want to change the model and both models use the same bones for animation (which is not the case for the werebeast, unfortunately), it may work, that you simply change the model via script / the S/R system. But I am not sure if there are problems with that, as AI may have more definitions that include the model. For a transparent model, where the skeleton shines through, I am not sure if this is possible. I fear you would rather have to merge the two models in Blender.

I agree. I had a mission (or rather a short campaign) plannes, in which the main character would be a pagan that was forced to live in the city. Unfortunately, I lost all progress due to a hard disc crash and insufficient back ups, so I am currently not really motivated to start that again. But maybe some time in the future I will actually take the idea up again.

Is this what you are looking for? http://wiki.thedarkmod.com/index.php?title=Security_Camera

As far as I understand, the problem with walking AI is that they currently have a target path_node that they are walking towards, so adding a new target will not change the target they currently have. Is there a way to clear all current targets before adding the new one? This would create the same case as with sitting/sleeping AI (no target -> new target) and could maybe have the same effect. I just don't know if it is possible to determine and delete the current target of an AI as this appears to be different from a target spawnarg. A more drastic measure to achieve this would be to replace each AI with the same model etc, but with a running point as a target. Problem here would be that the player might see the switch, if he has line of sight to them. If there are no AI around, while the alarm goes off, this should go unnoticed. Oh, it just occured to me that the script would also have to check, if the AI is currently KOed/dead, so these will not suddenly get woken up / resurrected to flee.

Amen to that! Assassin's Creed is fun, but compared to real stealth games like Thief and TDM it is really easy. I am glad that you like TDM and wish you a lot of fun with it!

Nice work! I like the elements theme (kinda reminds me of The Fitfth Element). Not 100% sure about the Move To Position effect, but I could imagine that this only works with moveable entities. If you just want to have the block in another location, try the Teleport (Set Origin) effect instead.

Shouldn't this simply work by using the name given via "name_attach#"? So, in the case above use the first three lines and then e.g. $gate_key.trigger(). I mean, it is an entity with a specific name in the map, so it should not be different to other entities that you target via their name. The only problem I could see is if there are multiple entities with the same name_attach line. In that case, I assume the def_attached entities will be numbered and the script would only target the first that was created with the def_attach, because it would be the only one with that name. However, this is more guessing based on my understanding...

In case of the grill lamp, it is actually a light entity with a model, not a model with a def_attached light. It also has a colorme skin by default. Hence, my assumption that it has to be rerendered. Here is a snippet from the "Attach Props to AI" Wiki page, which def_attaches a key to a guard an then changes some properties: "def_attach6" "atdm:prop_silverkey" "pos_attach6" "belt_back_right" "name_attach6" "gate_key" "set inv_name on gate_key" "gate key" "set name on gate_key" "gate_key" This should also work for other def_attached entities.

For the spawnarg I am not sure what the application was. I am sure I had one some time ago, but I cannot remember what it was ? The door scenario sounds like the door somehow got further frob stims right after the response. Did you also define a stim with frob besides the response frob? This would cause the door to emit a frob stim itself and consequently activate itself. This is the only thing that I could think of from the top of my head. Making stuff unfrobable is very handy for anything that you want to be triggered once and prevent the player from frobbing again. It may also work on the door, if it gets multiple frob stims: As the first response, make it unfrobable, in the second line, do what you want, and in the third line make it frobable again. Not sure what you meant by "reversed one", but it could be that there is troble with the origin. I am pretty sure the new model uses the same values for the origin, so if the new door has its origin on the right, while the first one had it on the left, the new door would appear in the wall, which would be why you cannot see it. you could test this by putting the door not inside a frame, but somewhere in the middle of a room. When you want to use the same model with a different skin, it would be better to use the Set Skin response. That's what it is there for. The grill light should be a light source that simply has a model defined, which lights you add with "Create Light..." do not. If the colour of the light changes, but not the colour of the model, I presume that the material of the light would have to be updated. I am not sure how often stuff like colour is checked, but I presume it is each time the model gets rendered, so apart from changing colour you would have TDM to update the material render. I think there is a console command, that lets you reload materials, but I could not find it right away. You could try to give the light the response Set Skin and use the skin it already has. This might cause TDM to reload the skin it has and update the colour, but I am not sure if this works. Regarding the traps, I will have to take a look at the video again; maybe I will get to it this weekend. For your last question, it should work by giving the entity that you want to be shot to turn off the light the response type "fire" (you can select it from the dropdown menu) and the response effect "Turn (extinguishable) Light Off" with the "Target Light" being the light you want to turn off. Now, as soon as anything with a fire stim (which fire arrows have, but as written before the slow match or candles, as well) gets near the entity with the response, the light should be turned off. The same works for the response type water and water arrows etc. You always have two pairs: one entity that gives you a response to a stim and an entity that emits the stim. With frob the player emits the frob stim, when you hit the frob key. For others you need to find an entity that emits the respective stim. A side note here: entities other than AI and the player do not receive damage. Thus, it is not possible to give a random entity the damage response and create an effect, when it is hit with the sword or an arrow. This is something I spent some time in trying to get it to work, until I was told that it is not possible.

Set spawnarg has the problem that it sets a spawnarg, i.e. an argument that is set, when the entity is spawned. After spawning this does not do anything anymore (with very few exceptions). In order to work better, you would need set keyVal (this is possible via script), but even that does not work for everything. Frob acting weird on doors may be, because doors use a frob action script on their own. It may be that there is some interference there (though I am not sure why; some people with more knowledge about the code would have to chime in here). For this to work better you could try to target a trigger with the door and let the trigger trigger a response. At least, I think that a trigger entity gets activated, when it is targeted by a door. For set model, I am not sure why it does not work for you. I am currently using it in my WIP and it works fine. Maybe you have the path of the model wrong, so it uses a nodraw model instead? In my case, I am replacing a filled quiver with an empty one and the path for the new model is "models/darkmod/wearables/quiver.lwo". Note that you have to include the whole "models/darkmod/[subfolders]" part, when you choose the model. I am not sure what the problem with the grill light is. Maybe you could elaborate, what you want to achieve and which response and response effects you have used. So to summarize, at least most (don't want to say all, because I don't know for sure) of the response effects work, but many have some restrictions that are not that evident or need a specific format in which the arguments have to be set (like the model case). As said before, with scripts you can do a lot more, but these are also harder to grasp.

One thing that took me a while to understand was that you only need to define a response in 90% of cases. The stim is the info the entity needs to activate the response. I.e. if you frob something, the player emits a frob stim and the frob response on the entity is activated. If you want an entity to react to fire, you need a fire response etc. The stim part is only needed if you want an entity to emit a stim. E.g. the short match (player tool) emits a fire stim at its glowing end, so anything that has a response to a fire stim will react to it, when the slow match gets close. Another example would be a damage stim on an entity. This will damage anything in a certain radius around the entity. That way you can create stuff like toxic fumes etc. The S/R system is quite versatile. Not quite as powerful as scripting (as it is restrivted to certain effects), but more user friendly. Yet, it may help if you think of it as a little script: The stim is the requirement "if Stim happens" and the effect is ... well ... the effect "do stuff". The downside is that you only have the stim as a requirement and cannot define more like "if Stim happens AND light is green, set light colour to red". If you want to do that you would need a script or a more complex setup like VanishedOne suggested.

Just to elaborate a bit more: in order to play a mission, it must not only be on your computer, but you need to additionally tell the game that you want to play it. So, after selecting "New Mission", you should see a list on the rightern side. There you can select the mission you want to play and then select "Install Mission" on the bottom right of the window with the mission's description. You should get a message that TDM will be restarted now and it restarts (this is a relic of old times and is quite hard to fix, so we have to live with the restart). Now you are able to play the mission (i.e. the mission is installed). It now ocurs to me that the name "install" is maybe a bit confusing here. The Load button is only available after you actually have saved and only saves for the currently installed mission appear there. If you have no missions appearing in the list, TDM cannot find the missions. There should be a folder called "fms" (short for fan missions), which should contain the folders "training_mission", "newjob" and "stlucia". These are the missions that come with the mod (if I remember correctly). While I agree that TDM is very similar (e.g. Light Gem, noise on surfaces) and you will be able to play without much trouble if you know the old Thief games, there are some differences. As a consequence, people often complain that something does not work, when in truth it simply works differently than in Thief. The first example that comes to mind is lockpicking: it can be set to work automatically (as it did in Thief), but it is actually a small mini game in TDM, in which you have to listen to a series of clicking sounds and time your action right to open the lock. So, I would play the training mission, just to know which differences there are compared to Thief.

It is generally a good idea to check if they are working properly. Otherwise you will have to spend a lot of time leak hunting later on.

@STRUNK: did you test you visportals with r_showportals? If you had a sealing problem, the visportal should also make some problems (i.e. not close properly).

I am using this script in my current WIP, but have not played around with the parameters too much. One difference I noticed is that I have created a folder "script" in my FM folder and put the trigger_look there. In order for TDM to use modified files over the stock files, you have to mimic the folder structure of TDM in your FM. So I would try to create a "script" folder in your FM folder and put it in there. Also, I have put the #include "script/trigger_look.script" not into the FM's script, but into a file named "tdm_custom_scripts.script", which is also located in the script folder. I hope this helps.