Obsttorte

You could check whether ai emit a visual stim, they player should. The lamps could than do a proximity test. Otherwise a custom stim applied to the ai could serve the purpose. It would probably good to allow both versions, either by using a trigger to control the lamp or the stim variant. You could basically have both. If the minimum velocity needed for the lamp to turn on is controlled via a spawnarg, mappers would have the choice to set it to zero if the want a "presence lamp". A "motion lamp" could be interesting in respect to gameplay. Besides the magical lamp type of Lost City style one could also think of such lamps in manor missions or similar, whereas those are something by the inventors guild. Sneaking by lamps that go on if you are to fast while there is ai around could create quiet some tensive moments.

"extinguished" is for flames (candles, torches, fireplaces etc...), electric lights use "start_off" (you cannot extinguish an electric light ) As VanishedOne stated the respective entity probably needs to use the tdm_light_holder scriptobject you could change the frobability via the generator. So the switch that turns on the generator also changes the frobability of the secret button, which starts unfrobable. Use a target_setfrobable entity for that purpose (that's thesame entity used on footlockers etc... to change the frobability of the items inside, check the respective prefabs to see how it works and you can read up here )

@VanishedOneThat's indeed the case. Note that Dragofer doesn't directly triggers the light via the trigger_multiple, but instead uses it to reset a timer that turns the light off once it ran out.

Haven't looked at the linked script, but arrays can be faked using in game entities to store them, for example by storing them as spawnargs on worldspawn (can be referred via $world) or if you want a behaviour like typical array-styled containers by writing a scriptobject that mimics the behaviour. Trigger_touches as proposed by Dragofer are an option, but iirc they only react to entities that can get into the volume on their own (player, ai and probably moveables). Also, having several of them can become performance houngry. In addition I guess youdon't want to check what's inside the boundaries continuosly but only in specific situations?!

twosided

Blackjacking needs to get used to when you come from Thief, where it is easier. However, it is mainly a matter of practise. Regarding taking out most of the ai. It makes sense to create missions in a way that players can follow different approaches, but taking out most of the ai is definetely not the idea behind a stealth game (the emphasis lies on stealth). Surely the average mission shouldn't force you to ghost it (and they usually don't), but it should be pretty obvious that going rambo isn't something you should expect to be successful. If you do so, you are probably in the wrong genre.

That's correct. The ai needs to "see" the missing entity marker, and that depends on the lighting. Punishing the player for carrying lots of loot is really a bad idea as stated by others. But the major reason given, that it punishes the player for doing what the game requires from him or her, is also applyable on things like ko limitations or no kill objectives. I mean you are giving the player broadheads, fire arrows, mines and what else and then tell him not to use it. That is pretty ridiculous. The main issue here is the mission design. Of course it sooner or later breaks immersion if the player collects 40 vases, 20 golden plates, 12 paintings etc... But there is no reason for mission authors to clutter the mission with loot. Simple place less. Of course taking out too much guards will leave an almost empty mission that provides no more challenge and stands in contrast to the actual idea of a stealth game. But mappers can place ai in a way that taking them out is a worse option then sneaking by them. I don't see Thief and TDM as ghosting games, were the player should not interact with the ai at all. You have your tools for a purpose, and killing is an option, of course. Leaving an ai alive and conscious should be the best option in most situation and not something the player does because it is trve (in terms of how real Thief pros play such games ).

https://wiki.thedarkmod.com/index.php?title=Creating_Automaps The functionality can easely be altered. Marking the exact position of the player on the map is easy in theory, but would require the map to exactly represent the actual mission geometry (proportions must match). This isn't necessarely the case, though.

Glad you like my stuff Regarding your question. My script replaces the location settings script that is used by the info_locationsettings entity by default, and that one handles the script calls mentioned by you (call_on_entry, call_on_exit etc.). What you can try is to create a second info_locationsettings entity and keep it as it is. This way both scripts should be run. I haven't tested it now (I may have in the past, but it was almost seven years ago, so ...). Tell me whether it works.

Well, his setup isn't really complicated. A static model bound to an invisible door. I've used similar setups in the past either if I needed a model to rotate around a point different then the origin (for example a swinging chain).

@Geep: If I get you correctly (and it hasn'T been changed ) than yes, it is possible. Visportals edges have to touch either a worldspawn brush or another visportal, whereas in the first case the VP can even reach into the Brush, although this is probably not desireable (one generally tries to keep the VP's as small as possible).

Now that is ninja style Glad you liked it.

AI_KNOCKEDOUT isn't a function, it is a boolean. You can find its definition in tdm_ai.script, line 80.

You should be able to overwrite them via "copy_joint Head" "-" etc. Besides that, if there are only console warnings and everything is working fine, you could probably ignore these. There is a modifier key for this, like shift or so, that lets you rotate in 5° steps iirc. You can do this via script. There is an entity allowing you to run object scripts on entities. In this case it is Lock (written with capital letter at the beginning iirc, if you get an console error stating the funciton is unknown, try lower letter). The spawnarg "locked" is only read upon spawning the door like most spawnargs (hence their name ).

Just so I get it correctly what you are aiming for: The player has to collect four pieces of a specific item, that is stackable. Once the player has found all four pieces (so the inventory count should be four either), those pieces get removed from the inventory and replaced with another item, that, upon using it, will teleport an ai in front of the player. Is that correct? In regards to you saying the code could as well have been Chinese. A programming (or in this case scripting) language is an own language, and even though it may not be as extensive as Chinese for example, one has to learn it. There is no way around that. But you also have to learn how to use the level editor, and you have managed to do so either, so I wouldn't give up upon scripting that fast

"could this be another instance of the "items changing name when they stack in the inventory" bug?" This isn't a bug. When picking up items they are removed. The inventory item and the one the player interacts with differ. If the item is stackable, you can remove it by decreasing its inventory count down to zero. Regarding your second problem. Frobbing and using are different. You can however specify what should be done when an inventory item is used in the items scriptobject. Check the playertools script file for instances (flashbomb etc...). There you can also see how to get the direction the player is looking at (see throwable items like again, the flashbomb) or you can take a look at my triggerlook script as suggested above. The view angles are specified as euler anlges (why ever?!). They need to be transformed into a vector specifying the viewing direction. If you want to avoid that the ai is spawn or teleported into a wall, I would suggest to let the player throw a projectile to see whether the space in front of him is sufficient. There may be more convenient ways to do so, but I can't tell you how to do it in a different way because it is a secret I don't know how (never needed it myself).

Very nice work. Regarding the climbable banners: there isn't much consistancy in what and what not should be climbable in FM's anyway, so if you want it like that it's fine imho. What may cause issues though is that if you are planning other mission authors to use those models, then it may happen that they don't realize they are climbable, as typically most if not all models aren't climbable by default and a specifically textured brush needs to be added to allow for climbing. As your approach with having them climbable by default goes in a different direction, you may note this in the comment section of the specific entities.

I thnik there is a special class for animated characters that don't act as AI, so they are more or less statically playing htere animation without interacting with the world otherwise. Func_animate could be worth a try.

Indeed. I have him in my steam friends list and we were talking from time to time. In addition, (almost) all team members have TDM associated email addresses, so they are reachable from the outside. Although I am not sure whether those can be found anywhere, and there is the tdm steam group Biker still has access to, so he can be contacted there.

IIRC ai will only use elevators if there is no direct way to reach the destination, for example via stairs. So if every area is reachable via stairs, they won't be using the elevator.

+1000

I don't think that those things are comparable. In nature, I have to do certain things to survive, indeed. But those things are concrete. I need food as a source of energy, I need other persons as living in groups grant me protection and so forth. The problem nowadays is that most of the time we worry about something abstract - money. We have to work to get this pieces of metal or paper, or most often just a digital transfer to buy the stuff we need. In return, I can't just go to the next lake and fish for food, as it is forbidden. I can't cut a tree to build myself a home, as it is forbidden. My only choice is to participate in the economical system. It is descriptive that a move called "The pursuit of Happyness" is about someone trying to get a better job, although at the very beginning of the movie he already had a wife and a child. Although I liked the movie (and Will Smith as an actor), I consider it not worthwhile to keep following that track any further. Taking the statistics into account I am very much with Springheel. One year is not nearly enough to draw any meaningful conclusions. And regarding economical effects you also have take the government expenses into account. In germany, every fourth person does not work until they get retired, as they become too sick to do so. More than a fourth of them due to physical diseases, another big part because of problems with their back or similar diseases. Comparing the low-risk and high-risk professions it appears, that working in a well paid job that requires a higher qualification grants a lower risk of becoming too sick to work. So increasing the overall happyness and allowing people with badly paid and unsatisfying jobs to pause from them may lead to a lower amount of people becoming unfit to work which would reduce the government expenses, that in germany as an example consist out of social expenses to a huge degree. In addition it may help balancing the payment people receive for their work. Many jobs are paid badly because there is always a "dumb one" doing it because he or she is just happy having a job. If people don't have to rely on those jobs, they must get paid better to attract people doing them. And getting paid at a reasonable level (not neccessarely high, but also not low) is an important part of the satisfication a job is able to provide, as it tells the employee how valued the job really is. Current payments don't reflect that very well.

I've used Linux in addition to Windows during writing my Diploma Thesis, as some of the program libraries I needed back then only worked under Linux (well, there may have been a way to get it to work under Windows, too, but as I am no programmer using Linux was the easier way). I can't remember the exact distro right now but I haven't had any issues at all, and besides some minor things it was not much of a difference than working under Windows. And as a little bonus TDM ran smoother under Linux back then (TDM 1.07, from 1.08 on it didn't made a difference on whether I've ran it under Windows or Linux). The main reason I am using Windows 7 right now instead of Linux is that I mainly use my computer for gaming, and most games run under Windows only, at least if you don't want to fallback to virtual machines and stuff like that. I guess once the day comes when most games require Windows 8/10 to run I will rethink my decision.

This is something I only know from Latin (as in the image) or from Runes. A short look at wikipedia implies that Old English used Runes, but not an U or V, and Middle English (which is probably more what the above quotes are refering to) seems to have had an U. I am neither a native speaker nor an expert, though. But I could imagine that someone who is actually familiar with older forms of English may consider it odd if something like this is done although it wasn't typical. In additionit would make those quotes even more harder to understand for non-english players as they already are. I mean, they sound nice, but it is really hard to get what they mean.

Nice.