Obsttorte

I second that. Beneath the possibility of map breakage no one was complaining about that so far, so I guess it is not worth the effort (which would be extreme high, I guess). Regarding the spawnargs: I guess the main point of Tels position is that the player has no cut off like the AI has. If the volume of a sound the AI "hears" is lower than a specific value (I think 20dB or so), the AI does not react to it as if it wouldn't hear it. The player, on the other side, can hear such noises or not depending on the enviromental volume (machine sounds, wind, ...), something the AI algorithm didn't even take into consideration. So I guess having two spawnargs makes sense. Obviously the naming convention suggested by Tels does not work due to what Grayman said. I suggest leaving "sound_loss" for the AI and have another spawnarg called "sound_loss_player" for example. Regarding doors: It makes sense that thick metal doors have another impact on sound propagation than thin wooden doors have, so this could be tweaked if possible. Taking the enviromental noise into consideration as described above would also be a plus, but as the current code ignores everything that comes not from an enemy, the amount of work needed to reach this behaviour may be not worth the result gained. Regarding func_portals: I didn't tested it yet if portals closed by func_portal entities really block all sounds, but I guess it is so as Springheel tested it. Well, this is definetily not senseful and should be tweaked, too. The portal should use the "muffling" spawnargs if set and if not should not muffle sounds at all. A visportal in a hallway should not propagate sound different dependent on whether it is closed or not for example. So IMHO the points to work at are: make it possible to muffle sounds via spawnargs on info_locationseperator entities and/or a new entity that does not split the map on that visportal into zones (use different spawnargs for the player then for the AI) tweak the func_portals so sound can propagate through visportals closed by them change the way door affects sound propagation depending on the material they are made off optional: make the cut off volume depending on enviromental noise, so that AI hear less in a loud enviroment like the player do (may be difficult in implementation and have a high impact on performance) I would NOT mess around with sounds passing through worldspawn, as it was not asked for and will definetily break all existing maps.

What kind of key. Should it be one associated with a certain command (like the "map" key or so). If so it should be possible. In general I guess not.

@ Sir Taffsalot: @ Theothesnopp: The more the merrier

select single face: ctrl+shift+left-mouse vertex drag mode: v (or the button on the top that has the edges highlighted) edge drag mode: e copy shader: middle-mouse-click on surface paste shader: ctrl+shift+middle-mouse-click (this is the "projected version", there is also a "natural" one that works a bit different) (the latter two are essential for working with patches) general hint: if you press ctrl or alt you can see the available commands on the bottom of the DR window. You can also change shortcuts under Edit->Keyboard shortcuts Regarding triggers and visportals: I would suggest to read Fidcal's beginner tutorial, he explained it very nice there. I don't know much about the HL2 engine, but in the doom3 engine visportals (the equivalent to area-portals I guess) are essential not only for performance, but they are also used for sound propagation.

Most of the existing maps don't use them. But yeah, I'll upload something.

As far as I recognized it closed doors only muffles the sound, so there should not be any problem here. Regarding sound trough walls: I must agree Tels and Baddcog. Such a change would definetely break existing maps. Not all rooms that are only seperated by a thin wall are meant to be part of the same building or whatever. So hearing sound through the wall is not intented in most cases. And, as Baddcog said, if the mapper actually wants this effect, there is an easy way to accomplish it (as described by him). Regarding seperate sound loss values for AI and player: I'm not really a fan of this idea. Why should sound propagate in a different way to AI as it does to the player. Giving the mappers such possibilities will lead to two problems IMHO: The mappers may overlook that there are two values two set, and will only set one. This will effect in what we have now or in the situation that the sound gets muffled to the player but not to the AI. I guess especially the latter is a problem as the mapper would need to invest a lot of time testing just to find out that he forgot to set a spawnarg. Such things would break gameplay. I guess that most players use the loudness at which they can hear the AI as an indicator for how good they can be heard by them. Tweaking with two different values only gives us inconsistencies and confusion. So I would say that we use the "sound_loss" spawnarg that is already there, and apply it to what the player hears. I suggested a relatively easy possibility to fix that by adding a distance to the path the sound travels trough visportals to accomplish the muffling. My idea was the following: read the sound_loss spawnarg from the info_locationseperator, if such an entity doesn't exist in the visportal choose a value depending on visportal size (this is something to think about it) calculate the distance that is equivalent to the sound loss (shall mean the distance the sound normally would have to travel to decrease by this value) apply the length to the length of the path the sound has to travel IMHO this would only require a few new lines in the code and we don't break the existing system. As said any bigger changes will most certainly only cause negative side effects. Regarding visportal size to sound muffle: As said by Springheel this approach is not optimal. Tels also noted that it is not the best idea to force the mapper to have info_locationseperators in every visportal that shall muffle sound, as this would lead to a high amount of zones. He also had the idea of using a new entity instead. So it would be placed in a visportal that has no seperator in it and apply the values, without breaking the map up into seperate zones at this specific portal.

It seems that trigger_entityname_once is also not working, although trigger_entityname does. Also trigger_hurt works. I guess something is broken.

Hi there, I'm just meesing around with triggers. To be mre precise I use a trigger_multiple entity, but it doesn't seem to work. I tried "anytouch" "1" but this doesn't change anything, if I step into the trigger nothing happens. I targeted a light from it, but it stays one. I also tested the call spawnarg, but the trigger neither called a void functionname() nor a void functionname(entity arg) type function. Am I doing something wrong or are they just broken?

The mapper can already do this, although it is a bunch of work. You should also keep in mind that the quality of the equipment has also to do with the wealth of the persons they are guarding. In the proposed way all guards would be killable with one arrow as long as they are unalerted. It only makes a difference once they are alerted. Increasing HP of AI for difficulty reasons is a common method used over all the years in almost all games. I don't see anything bad about it, especially as the fighting isn't really a core part of the game IMHO. It's a game. I have no problem with the health bar and would leave it as it is. Sometimes it can happen that you are surprised by a guard and get a slash in you back. Instant dead in such a situation would only be frustrating. I don't see any point in "resting" either. How did you imaginate this. You are robbing a tomb, get injured by a trap and than lay inside a sarcophagus to take a rest.

So regarding seeing an AI been killed: AI type, relationship to player, relationship to dead AI: reaction unarmed, hostile or neutral, hostile or neutral: flee unarmed, friendly, neutral: some sort of reaction ("What are you doing?", flee if player don't put away his weapon (maybe switch to neutral relationship) unarmed, friendly, hostile: stay + some sort of reaction ("kill that bastard") unarmed, friendly, friendly: set to neutral, if player don't stops it set to hostile+ flee armed, hostile, all cases: search and attack armed, neutral, hostile: he will attack anyway (no changes) armed, neutral, neutral: this should depend on the kind of AI, if it is a city watch or a builder he should not tolerate murder, else the AI should tolerate it as long as the player puts away his weapon afterwards armed, neutral, friendly: attack the player + set to hostile armed, friendly, neutral or hostile: assist the player armed, friendly, friendly: set to neutral, if player don't stops it set to hostile+ flee These are my ideas. Regarding the other topic (unarmed AI finds body): In terms of gameplay I would say that the AI should flee the first time he saw the body if and only if there is a guarded flee point nearby (thus meaning within a certain range). If it is not it may investigate the corpse ("Is he really dead?") and look around nervously. I guess this is a good compromise. In both cases the AI should use a bark that alerts nearby AI, but in the latter case the bark may be not as "loud". Sorry Tels, just had to say this

It is not really about enforcing stealth gameplay, it should just become a bit more rewarding. I'm not a big friend of randomness I must say. If you engage in fight those fights won't end up the same every time because the player behaves different every time he tries it. Also having some sort of randomness on the possibility of one arrow killing a guard will only cause the player to reload if it fails. In addition if something works the one time and do not work the other time although the player does exactly the same it will only get frustrating to the player. I think it is a bit overseen how rewarding the proposed system is. If you do not alert any guards, you'll be able to take them out one by one. Actually you can even retrieve the used arrow from the corpse. This means you can take out a hundret guards with one single arrow. The absence of this possibility once an AI is alerted is just some sort of punishment. Having this embedded as a fundamental part of the system makes more sense IMHO then laying this into the hands of the mapper. Beneath the fact that it results in extra work it only leads to inconsistencies. I think that what Springheel suggested is still something to be seen as a compromise as it still leaves the possibility for "one strike takedowns".

@zergrush: I can imagine that there are people who aim for good scores in games, and in TDM I sometimes do this with very small missions, too. But in general I tend to go the easiest way. Shortly after Splinter Cell came out a friend watched me playing it. He had played it himself and was asking me why I kill so much people. Actually I was more sniping through the levels then ghosting. I asked him "Why not?" and he meant that it is not the way it is supposed to be played. But the problem was not that I didn't played it correct but that the rules did allow me to. While some people may welcome this "lack of rules" other people (like me) find it somehow frustrating. This is really a matter of personal opinion, but I think that the "one arrow if unalerted, several arrows if alerted" approach is the best way to satisfy all parties.

@ Baddcog: I was not complaining about people complaining on the ghost objectives on my last mission, this is a misunderstandment. I had my reasons to set this objectives and I did it not because I think it is the "true" way of playing this game, I did it because of gameplay reasons. If you load the map in DR, delete the specific objectives and add a blackjack and a couple of broadhead arrows to the player inventory and replay this one, I guess you would see what I mean. No, actually it was just a reply to what Fieldmedic wrote and the fact that some restrictions (no kill objectives, having no bj in a mission and so one) are mostly not very welcome

Ähem ... yes. The actual problem that should be solved by these calibrations is the following IMO. It's a stealth game, so stealthing should be somehow honored (except some scores in the end) It's a strategic game, so the player must have the possibility to choose out of several options to accomplish his task, prohibiting some of those is mostly not very welcome sneaking by a guard is in most cases more difficult than blackjacking or killing him, so the latter options must have some possible downside to outweight that As Sotha is always saying, it is all about choices the player make.

Actually running to a flee point would only make sense if the specific flee points are guarded. Running to an area that is supposed to be not guarded when seeing a dead body seems silly to me. On the second note: Yes, it would be strange if the AI would do this The question is what else the civilians should do in such a case. As there are some thoughts behind the patrol routes it may have some negative effects on gameplay to just force them to avoid the area or set them on a patrol that does not go through the specific area (not mentioning the implementation effort). I guess the easiest effort would be to let them flee once to a flee point that is set to guarded or, if such a flee point doesn't exist, just let it run to a nearby guard (yeah, it's cheating). The civilian should do this only once per body.

The problem is that the takedown of several AI can "break" a mission in terms of wandering around in an empty area. Another thing to consider may be that shooting an AI with an arrow is a very powerful way compared to blackjacking (what requires you to get close enough) or simple sneak around (what may be difficult because of the specific guard). I think every advantage a possibility gives the player should be outweighted with a certain disadvantage, in this case the possibility of not hitting the AI properly and therefore running into troubles. Beeing able to take out unalerted guards with one shot still gives the player a lot of possibilities inusing the broadhead arrows. On the other hand it may be noted that many people are complaining about objectives "forcing" the player to stealth a mission.

Does "difficulty level" refer to the mission difficulty or the combat difficulty?

It's been anounced here and is listed on the mod page. I guess it's quite hard to miss it.

Maybe it's an error with the engine itself. Don't know. I fairly doubt we'll get behind this soon. If you have snapshots or failsaves, you may start workingfrom them on and hope the error does not reoccur.

Nice. If you have questions just ask me.

@Springheel: As said on the wiki the main work is to actually draw the map and position the parts correctly. The example map is just a "proof of concept". Of course you can use pictures instead of labels to achieve the automap effect as known by the original thief series. If I find the time I could create a new example map showing this, but actually the code and the guis nearly stay the same (you just have to replace the "text" line in the guis with a "background" line pointing to the picture to be shown).

There are some missions that were created in a rather short time (after the mappers learned using DR). A good example for "roughly 10 rooms" is Too Late by Nielson. Take a look at it in DR to get a feeling of how big a first map intent should be. Obviously there is nothing to keep you from starting with something bigger, but it's relatively sure you'll lose motivation doing so. After all its all about patience and endurance. The more you map the faster you get and the bigger can be the things you are trying to accomplish without getting frustrated. Another advice would be to start with indoor areas. They are more easy to make for most peoples then natural looking street sections or so. This is mainly because interiors in real life tend to be blocky, so you have not much to do here.

Regarding internal leaks: the console command "r_showTris 3" shows you what is currently rendered. This way you can look up if something is rendered that shouldn't.

I don't see a big problem with having some areas more. I mean we are mainly talking about windows (seperating in- and outside normally) and little holes (which often also should two different locations, like groundfloor and cellar or so). So I think you will have the areas seperated anyways and don't really need an extra entity for that. But even if another entity is used for that I think it would make sense to have these spawnargs available for info_locationseperators, too. Why should I place a second entity in my visportal just for sound purposes, this just gets confusing and can cause the mapper to set the wrong spawnargs on the wrong entity.