Apples and Peaches: Obsttorte's Mapping and Scripting Thread

[Sotha]

Caulk ceiling, caulk floors and/or noshadow ceiling vaultwork?

I recommend having vaultwork as noshadow and have the ceiling behind it to be real texture, not caulk. Caulk lets the light shine through.

[Obsttorte]

Thanks, I'll try that out.

[Obsttorte]

Didn't work I don't think it has something to do with texturizing or leaking.

 

The light does not always shine trough, only when I open the door. But independently from whether the door is open or not the light source never gets rendered.

[demagogue]

That is very typical of noshadows on something. A light with noshadows on will shine right through brushwork.

 

Why it happens when the door opens sounds very much like an internal leak between the leaf on the other side of the door and the floor below you. Opening that door opens its portal & renders everything in its leaf, and if that lower floor isn't hermetically sealed, it will render too. It's not just having portals that makes leafs, but they have to be absolutely hermetically sealed from each other or the portals are killed. The tiniest unportaled crack, or a hole only covered by a func_static can make an internal leak.

 

Note also that even "sealed" brushwork that's complex enough (strange angles or little slivers or protrusions) will cough-up the renderer and create an artificial crack. I had that happen many times in my early messy-brushwork days.

[Obsttorte]

I only set up some very simple brushwork. Everything is rectangular. The portals are working properly (checked that with com_showFPS) and the leaf where the torches are in is not rendered (checked that with r_showTris). I have to check if the torches I used ave noshadows on by default, as I used other torches normally, but I don't think so.

 

Maybe I just go and replace the torches by other ones and see if this problem still occurs.

[Obsttorte]

I wanted to try some things that could enhance the possibilities for Hitman-style map (referring to the fact that you're counted as non-hostile by default). The feature I'm aiming for is to let the AI get hostile to the player when they see him lockpicking a door.

 

So I thought I could use the stim response system for this. The problem is that the door seems not react to any stims. I tried frob, water and gas. Especially the first case seems a bit strange to me as a door entity is something that should react to frobs by default. I used such things one loot some time ago and it worked very nice.

 

Any suggestions what may be the problem here? Thanks in advice.

 

If someone has another suggestion on how such a feature could be implemented I'll be happy to here.

[Springheel]

This has been discussed a few times before, and solutions offered. Try a search?

[Obsttorte]

Well, doing a rough search doesn't give me much useful (in fact nothing). If you have something special in mind...?

[Springheel]

I don't know what the solutions were, I just remember it being discussed and various ideas presented...someone involved will speak up soon I'm sure.

[Obsttorte]

Well there were a lot of discussions about changing team relations and about the already in the wiki article described features.

[grayman]

In Remembrance of Him changes AI relations to the player when the player opens a particular door. This is a simple solution, and doesn't involve lockpicking. Look for the door named atdm_mover_door_32 and check its target.

 

There was a discussion, which I can't find now, of how an AI could recognize when the player is actively lockpicking a door. The solution was to write a script that checked whether a particular door was highlighted at the same time the player was using a lockpick. I forget who was trying to implement this, and it was probably asked in a thread like "So-and-so's mapping thread", making it difficult to dig out. I tried searching for "relation" and "lockpick" and came up empty.

[Obsttorte]

Well I searched for "lockpick" and "script" and found some discussion in the Newbie DR thread. You gave the solution btw.

 

So the result was that if the player highlights a door AND have lockpicks selected the AI would get alerted if seeing the player. This is relatively close but not exactly what I want.

 

This solution inhabits the following problem: Imagine the player stands in front of a door he just tried to open by simply frobbing it and sees, that it is locked. He knows that there are far too much guards around to try anything illegal, so he now plans how he could make progress. He scrolls trough his inventory to see what tools he has left and that could help him. Doing so, he also scrolls trough the lockpicks while still looking at the door and BOOOM, as there are guards nearby he suddenly becomes a thread.

 

I know this sounds a bit constructed. What I'm trying to say is, that scrolling through your inventory may not occur to most players as really taking the things out of your bag and looking at them. Especially when it comes to lockpicks, which are pretty small I think and could be hidden in the hands.

 

I think that most players would expect only the attempt of actually lockpicking the door as illegal, not having them selected while looking at a door. I will see if #I can change this behaviour a bit.

[Obsttorte]

Update: I found out now how I can accompish the specific behaviour. It's quite close to what grayman suggested in the Newbie DR Thread.

 

This will be added to the script, which continuosly checks whether the player carries a weapon. I will update the wiki entry soon, but the basic steps I shall explain here:

 

- check if the player is highlighting something that is locked

- check whether the player has selected the lockpicks (one of them)

- check if the locked entity has a door handle

- check whether the handle is rotating

 

The only sidekick here is the case, when a locked entity, for example a little treasure chest, has no handle attached to it. This would lead to two possible cases:

 

- the AI won't notice the player lockpicking it

- the AI will behave as seeing the player lockpicking it if the player has just frobhighlighted the chest with the picks in his hands

 

Both possibilities are not very satisfactory, but can be bypassed by the mapper by adding a (possible invisible) handle to the specific chest

 

In the cases of doors and chests that have handles, the AI will only be alerted when the player really attempts to pick the lock, not just by having the lockpicks selected and looking on the door. I think this is an improvement.

 

Wiki update will follow.

 

Edit: This method suggests, that the player should not be able to enter through locked doors. Just for notice.

Edited January 10, 2013 by Obsttorte

[Obsttorte]

Is it possible to change an AI's team once it gets to a certain alert level?

[Sotha]

Sure it is. Make an objective "Entityname reaches alert level X" (was it "AI is alerted" or something?) and give that objective completion target, which calls a script (or entity business) that changes the team. Should work.

[Obsttorte]

The success script does not get any arguments. Obviously I could just go through all the AI's in the map, but if you have like three douzens of them, this gets quite unhandy. And everytime you change something, you have to change the script.

 

Another question: Is there a possiblity to find out whether the player is currently holding an unconscious body. I tried entity heldEntity(), but this only gives you the unconscious AI if you frobbed it. Once you shoulder it, this method returns $null as if your hands were empty.

[grayman]

Another question: Is there a possiblity to find out whether the player is currently holding an unconscious body.

 

Not that I can see. We could add a script event named IsShoulderingBody() in 1.09.

 

Edit: A better solution would be to make heldEntity() return a shouldered body, since the player can't grab anything else while carrying the body.

[Tels]

Not that I can see. We could add a script event named IsShoulderingBody() in 1.09.

If someone makes a tracker entry and assigns it to me, I can do this easily. Also something to find out what the player has in the grabber (I think you can onlymake him hold something, but not find out what he holds?)

 

We could also add a "isCurrentlyLockpicking()" method (that might even get some arguments like "onlyifCurrentlyPicking" so you can alert AI if the player just holds picks, or actually uses them).

[Obsttorte]

I just made another test. As long as you shoulder an unconscious or dead body, the AI completely ignores it. It only gets alerted when you drop the body. This is really weird behaviour.

[Springheel]

We have specific barks for AI spotting the player while holding a body, ("Hey, drop that body and surrender!"). I'm relatively certain I've heard them while playing, so there must be some way that the code checks whether the player has a body. I don't think it distinguishes between alive or dead though, and it would only play if the AI was hostile to the player.

[Obsttorte]

Some other starting point: I noticed that whenever I shoulder the body there is the line "Equip called" writtten to the console. when I drop the body, line "Dequip called" is printed to the console. I'll see if that gets me somewhere.

[Obsttorte]

OK, found it out. I can set equip_action_script and dequip_action_script on the AI. The specified scripts then get called when (un)shouldering the AI.

[Obsttorte]

UPDATE:

 

I noticed that the there are some minor mistakes in the code on the wiki causing the setup not to work as intented. I made the changes and will update the wiki as soon as possible.

 

The actual version implements the following behavior: Guards get hostile when

• you get seen steeling something
  
• you get seen lockpicking a door
  
• you get seen carrying a weapon
  
• you get seen in an area you're not suppossed to be
  
• you get seen grabbing or shouldering an unconscious or dead body
  

I still need to implement the behaviour that AI gets hostile when seeing you opening a door with a key you are not suppossed to possess. What also neeeds implementation is that they get hostile when you for example throw a flashbomb at them or attack them. (If you attack them from behind without killing them and put away your weapon fast enough they won't notice it was you who attacked them).

 

With this setup always every AI on a specific team gets hostile to you. The only way to bypass this behaviour a bit is to use several teams for several areas, all friendly to each other. In this case only a specific team will be alerted. So if the player gets far enough away the AI there is still neutral to him. The other teams could get set hostile after a while like if they were informed about the identity of the intruder. I'm not sure this is neccessary. At least it will cost some effort to implement this on a specific map.

 

When I made the last changes I will update the wiki and post an example map here.

[Springheel]

Sounds really cool!

[Obsttorte]

OK. I've implemented the reaction to flash bombs and mines. I also tried to add a reaction for standard mines, but that didn't work. One approach was to use the objective system, but it seems that the specific objective type "AI finds item" is not implemented yet. Another thought was to use stim/response. The problem here is that I don't know how to activate the stim after the player dropped the mine. So this must be left out.

 

"Opening doors you're not suppossed to have the key for" can be implemented the same way the loot thingy. You just need to let the door target the same both entities as the loot does.

 

Here is an example map that shows all the above mentioned features. The AI is friendly to you. The left door from the start is locked and should not be opened (the key for the door is in your inventory). The right door is unlocked, but you're not allowed to enter there.

 

The zip file contains the map and the script file. Put that in your darkmod/maps folder and dmap it for testing.

hitmanstyle.zip.txt

Edited January 10, 2013 by Obsttorte