Obsttorte

Yup. Sound propagation to ai works fine. Additionaly the mapper has the possibility to control the sound spreading via spawnargs on the info_locationseperator entities (something like "loss_open" or so). It's "sound_loss".

This should only happen if enough time has elapsed. If not, the behaviour may depend on the team relation of the thief and the player or on the behaviour of the player. If, for example, the player still has his weapon drawn several seconds after the kill, the thief should consider the player as a threat (if he were not he would already put away his weapon, wouldn't he?).

What do you mean by that, I don't understood? That it has nothing to do with reacting to bodies? That it should not be part of the code handling the ai reactions? That this is impossible to implement? Regarding possible implementation notes: "arrow out of nowhere": if one retrieve the person who shot the arrow (for example the player) you get his position and depending on the shot distance "draw" a circle around the specific entity. Pick a point out of this circle and let the alerted ai run to it to search the location "subdividing tasks": the ai is already chatting to each other, for example when the inform the others about evidence seen. The first ai reacting to the dead body could go into the "investigating corpse" state. The other ai would go to the corpse and receive the information by the first ai that he is already inspecting the corpse, what cause them to search the area instead. Letting ai spread out in different directions in a way that makes sense is a bit trickier though.

Seen that, too. This also happens with brushes soetimes. I'musing 1.72.

There is already an example map. http://forums.thedarkmod.com/topic/14394-apples-and-peaches-obsttortes-mapping-and-scripting-thread/page__view__findpost__p__304066 Shouldn't be too hard to fix it to ones need.

This could be fixed if the stealth score only counts alarms that are caused by the player.

Actually the portals are counted for the sound-propagation to AI as there is a limit on how many portals a sound can cross before it becomes unable to reach an AI. This is to help performance I think. Regarding the sound loss. As there is already such a mechanism for the sound to AI propagation, couldn't we just take the code and put it in the specific lines handling the sound propagation for the player. Another mechanism to implement (as we are just talking about) would be some kind of auto-decrease-sound, thus meaning if the mapper does not specify the spawnarg handling the sound_loss an value is automatically choosen depending on the size of the visportal. This would save some work for the mapper. Just an idea.

We'll talk about that (preferable in german ).

Use "r_showPortals 1" in console to see the portals. The open ones are green, the closed ones are red. This way you can also check out that all your visportals are working. With "r_showTris 3" you can see which surfaces are currently drawn. This can be of help if you occour slowdowns in some areas of the map. But I think as long as you stick to interior areas performance shouldn't be a big problem, as long as you don't fill the place up with tousends of particles or so. The main problem are huge outdoor areas, as the Doom3 engine isn't really designed for that. According visportal placement check out these links to get a feeling http://wiki.thedarkmod.com/index.php?title=Visportal http://wiki.thedarkmod.com/index.php?title=City_Street_Visportal_Tutorial Good luck.

Well, as said these warnings can be ignored.

Personally I never read books on my PC. Maybe I'm a bit old-fashioned but I like the feel and the smell of books. According steampunk books: I recently read Affinity Bridge by George Mann. I just stumpled over this one. It's pretty nice. I always like it when books have some sort of fantastic things in it that turns out to be described in a natural way in the end. I'm not the type who believe in supernatural things and if something like that occures in a roman I'm always thinking there must be a rational explanation. It's nice if you get something like that in the end what you never thought of. Sci-Fy: I can highly recommend Metro 2033/2034 by Dmitri Glukhovsky. Also the Stalker books were not bad.

According the slowed odwn door movement. Ravenshield used the mouse wheel for that purpose. You could use the "use" key to open it up immediately or the mouse wheel to open it up very slow. The point there was that the enemies reacted to opened doors, thus meaning that they heared it when you open the door fast and looked into that direction. As long as such behaviour shall not be implemented to the AI I don't see what use you have from such things. (The AI in Ravenshield also heard it when you switched your weapon close to them ). There were already some discussions about making the AI more realistic/the game a bit more difficult. But I guess some people may be distracted if we are overdoing it.

Nice, thanks. Actually everytime I try something out I create a new testmap and therefore a new scriptfile. And as it is a test, I just tend to name the function this way (I know it is cruel). I have to take the squareroot because I divide trough it when calculating the cosine of the angle. d could only become zero if the origin of the object is at exactly the same height then the (modified) player origin and lies a bit outside the entity so they could actually overlap. But of course you are right I will make some changes once I find the :cough: interest to do so. Should make thinks a bit easier to understand and reuse. I may add that everything I post here is not intented to be understood as THE perfect way of doing it. I just want to show what is possible with the things one get shipped with DR. (And I want to show that it is useful to get in touch with scripting )

Normally these errors should be dissapeared since the 4GB patch is part of the 1.08 exe. Anyways, is it possible that you've run another memory hungry application in the background. I don't think that the entity it's pointing to plays a role. Maybe it just ran out of memory when trying to load it. What was the last things you've done in your map (roughly)?

I've just looked at the wiki and the answer to your question is no. The trigger triggers when the player is inside and is facing a certain angle. But the angle needed to actually look at the item is dependent on where you stand. Actually if you stay with the limitations mentioned by Fidcal in this article (looking down a hallway or through a window) it might work. But in the example map this trigger won't be of any use to accomplish the same effect. Also it seems to only work horizontal. So it would not be able to create the "stones falling from the roof" example.

Addition: From the description I have actually no idea how the trigger_facing should work.

@Grayman: Corrected 1 and 4. 2. Yeah, you could. I'd said use a trigger that is able to recognize the player. I don't think it makes a big difference. 3. Never used that one. @Flanders: There is a lookAt function IIRC but is for AI to force them to look at something. I don't saw a function that checks if the player sees something. The problem is, even if such a function exists, it could also return true when the object is in the fov what may not fit into the requirements. With this setup the mapper can adjust things as needed (if he wants to trigger something then timing may be important. I also don't think these functions are easier. The script would get shorter (obviously) but the calculation needed should still be the same.

I just wondered what books you guys may be reading. Actually I don't know much people that really read books, what is sad. I prefer scientific thrillers. I love the books by Douglas Preston and Lincon Child (Aloysius Pendergast is just ... cool ) and the ones by Frank Schätzing (that's a german author). Funnily the latter I've started reading because of Thief. The first book of him I've read was "Death and Devil". It's about an assassination and the main actor is a thief (he is the good guy, so not the assassin). It plays in medieval Cologne. Pretty good.

Many prefab use intersecting elements. It's just easier to map.

I noticed that the amount of these warnings is much higher one maps that uses a lot of "strange" geometry (everything that is not a cube and even worse ). I'm not a hundret percent sure what is meant by node, though. The same thing (the amount of error messages) counts for "backwards triangle in input". This is the part where I start guessing. If a node is something like a room and the engine tries to split up the map so that all geometry is in a room, than a vertex inside another brush may cause this warning. So if you have a lot of intersecting worldspawn/func_static that intersects each other than I guess you would get a warning for every single intersection/every single vertex or whatever. (Always suppossed my guess is right ). Actually such things can hardly be avoided. But as warning can be ignored as you say, it would be good not to display them, as they are of no use IMHO.

Triggering actions when player looks at something Imagine a map where it is your purpose to get to a certain street. If the player reaches the street you want him to say something (or simply display a little message telling him that he has reached his goal). If there are street signs it would make sense when the message appears once he has discovered the sign. Imagine a road. On the left side there is a building with a shield in front of it, warning you that the building is still under construction. The player takes a look upwards to see if the building provides some entrance possibilities (the rope arrows already selected), when shortly after his eyes discovered the fragile rooftop some stones come falling down, leaving him just about enough time to step sidewards and avoid the huge stone crashing on the streets exactly on the position he was just standing. Imagine a manor. The player is suppossed to steal something really valueable out of it. He arrives in the galerie where the suppossed object should be. There are a lot of loot in this room, but nothing compared to what he is aiming for and what his eyes have just discovered, accompanied by a beautyful sound that roses right out of his chest so it seems. Imagine a guy trying to explain what the stuff described in the folllowing lines could be used for. This post is about how to setup a triggered event that happens once the player discovered an item (streetsign, rooftop, something valueable, whatever). By discovered I mean that he is close enough and looks at the specific object. So, what do we need for that: Obviously we need the item to look at. An area that can trigger a script as long as the player is inside (I've choosen a trigger_entityname here) A script (this is the point where most people stop reading) something to trigger when the player has looked at the object Now, what do you have to do: Give the item a name you can remember. Let's suppose it is a shield on the wall, then you may call it "shield". (Brilliant) Create a brush around that item that is large enough to contain the area the player should be in to be able to trigger the event right-click->create entity->trigger/trigger_entityname on that trigger set "entityname" "player1" (this will cause it to react to the player) also on the entity set "call" "isPlayerLooking" (this is the function to be called once the player is inside. You can rename it if you want, but don't forget to rename the actual function either) if you want a message to be displayed, create a gui_message (create entity-> targets) set the text spawnarg for the text to be displayed and change the other spawnargs if needed give the message a suitable name, for example "message" (once again, brilliant) create a script file yourmapname.script with the following content void isPlayerLooking() { vector playerView,playerShield; //get the players view angles playerView=$player1.getViewAngles(); //calculate the vector pointing from the player //to the item playerShield=$shield.getOrigin()-$player1.getOrigin(); playerShield_z-=64; float x,y,z,a,b; float xps,yps,zps,d; float angle; //calculate the vector pointing in the direction //the player is currently looking a=playerView_x; //up-down-angle b=playerView_y; //left-right-angle x=sys.cos(*sys.cos(a); y=sys.sin(*sys.cos(a); z=-sys.sin(a); //retrieve the vector coordinates and //calculate the length player-shield xps=playerShield_x; yps=playerShield_y; zps=playerShield_z; d=vecLength(playerShield); if (d==0) d=0.01; //just to be sure //if the player is close enough if (d<100) { //calculate the cosine of the angle between //the players view vector and the vector //pointing from the player to the item angle=(x*xps+y*yps+z*zps)/(d); //if the player looks at the item if (angle>0.9) sys.trigger($message); } } void main() { } Note 1: The cosine is ONE if the player looks exactly at the origin of the item. The lower you set the value angle is compared with, the less accurate has the player to look. This means that you choose lower values for larger objects and higher values for smaller objects. Note 2: The reduction of the playerShield z-coordinate is caused by the fact, that the player origin is between his feets (one the ground). But actually we want the vector pointing from the players face to the origin of the object. Depending on where the origin of the object the player should look at is, it may be neccessary to adjust the vector entrees furthermore. Here is an example map. looktest.map.txt Delete the txt ending. Create a looktest.script file and copy the above code into it. Then you can dmap and run the map to chack it out. If you are less then roughly 2 meters away from the shield hanging on the wall and look at it a message will appear. In the current setup this will happen again and again, but this can be changed to happen only one-time.

If you only want to mark the room the player currently is by a cross, it should be simplier, as long as you just want to mark the room as whole and not the detailed gps-evaluated position. The latter would be handable via the players position. The problem is that the map must be exactly scaled for such a purpose. Quite a bit hard to accomplish that if your map is hand-drawn. You could also divide your rooms into smaller zones. This would make it possible to mark at least a bit more detailed. The question is if that is really neccessary if the room is not extremely large. Btw.: With "room" I mean a closed area (could be also something outside, a street or whatever).

Thanks

I agree with almost everything Sotha has mentioned, except three points: 1. I would not use the zoom function as an equivalent to precicion. I, and so maybe others, always found that a "bow zoom" is unlogical and distracting. Therefore I never make use of it. Beeing forced to do so just to land a precise shot isn't a good idea IMHO. Actually I think it would be fairly enough if the bow needs roughly 1-2 seconds to become precise. A "swinging" animation that shows the player the bow is still innaccurate wiuld be needed for this time. 2. When the bow is at highest accuracy, it shouldn't be pixel accurate. I'm not sure it is used now as Sotha refers to it as "usual" but I think there should be a limit range before this weapon becomes unpractical. 3. The headshot topic is obviously a matter of taste and one of Gameplay vs. Realism: Anyways, I think the former is more important then the first. So I would stick to the "alarmed AI can not be taken down with one shot" mentality or, as a comprmise, give the ai abilities to protect against such things. Examples for the latter would be: Let the ai hold/swing his weapon in front of his head, let them swing their heads more when rnning (or run ont that straight) or give the helmets ventails. I guess the last option would only fit to elite guards.

Very, very cool. Looking forward to your release.