Apples and Peaches: Obsttorte's Mapping and Scripting Thread

[Obsttorte]

I tested it and you are right. I don't know how to really lose the report (if I even can).

 

Anyways, I posted the suggestion to change the dmapping routine so it deletes the specific files before actually starting to dmap. Don't know if that is possible, though. I sometimes encountered problems that I solved by deleting these files (just didn't thought of it in this case). This is really something mappers can stumple over.

 

But thanks a lot for looking at it.

[Tels]

I've changed the bug report - that should be the most annoying bug of all times. I can't recound how many times I had walls you could walk through, triggers that did not work etc. The "human fix" sounds easy, but only if you know about the issue - which probably outside of us three, nobody does. And in 3 months I wil have forgotten it again and debug a non-working trigger for hours..

[Obsttorte]

Little status update of my Old Habits sequel. Just some numbers:

 

7460 Brushes, 3629 Patches, 2994 Entities.

For comparision, Old Habits had 4698 Brushes, 2686 Patches and 2840 Entities. Builder Roads had 1938 Brushes, 561 Patches and1328 Entities.

 

Two Pictures:

[RPGista]

Looks quite intriguing!

[Obsttorte]

Thanks. Still at least one month of work needed to get it finished.

[Bikerdude]

Nice progress there young man :-)

[Obsttorte]

Lil' update: I've connected the lower part with the upper one (as seen from the first shot). I basically need to seal this area, than add some sewers, create some indoor areas in the street section, connect the chapel (the third big thing in the screenie) with the rest of the map, add ai, pathways, readables, lights (some add least), .... so almost finished

 

The current size is (map + cm + proc) roughly 40 MB. In the end it willl be around 50-60 I guess. After this one and my contest entry I swear I'll never build maps of such scale again. No matter what you do, you never get ready.

[Obsttorte]

I have updated the hitmanstyle approach, thus meaning a way to implement missions in which the ai is neutral to you until you get seen doing something not allowed, like stealing for example.

 

The main problem with my last "solution" was, that in the case the player gets detected the whole team of ai to which the witness belonged to became hostile to the player. This is

• quite unrealistic, as the other people can't know that you have done something illegal if they didn't saw you to or weren't informed
  
• bad in gameplay terms, as the player does not have the ability to "correct" his mistake by killing the witness
  

This has now changed

 

What is needed is a script

void setHostile() {
$player1.StimEnable(1001,1);
}
void setNeutral() {
$player1.StimEnable(1001,1);
}
void setHostileZone(entity zone) {
 setHostile();
}
void setNeutralZone(entity zone) {
 setNeutral();
}
void checkStatus() {
do{
entity t;
string unarmed,snake,triangle,classname;
unarmed="atdm:weapon_unarmed";
snake="atdm:playertools_lockpick_snake";
  triangle="atdm:playertools_lockpick_triangle";
if ($player1.getCurrentWeapon() != unarmed) {
 $player1.StimEnable(1000,1);
}
else if ($player1.heldEntity()!=$null && $player1.heldEntity().getKey("spawnclass")=="idAI") {
 $player1.StimEnable(1000,1);
}
else {
 t=$player1.getFrobbed();
 if (t!=$null && t.IsLocked() && t.GetDoorhandle().isRotating()) {
  classname=$player1.getCurInvItemEntity().getKey("classname");
  if (classname==snake || classname==triangle) {
   $player1.StimEnable(1000,1);
  }
 }
}
sys.wait(1.0);
$player1.StimEnable(1000,0);
}while(true);
}
void becomeHostile(entity e,entity activator,entity this) {
if (e.canSee($player1)) {
 e.ResponseEnable(1000,0);
 e.setEntityRelation($player1,-1);
 e.StimEnable(1000,1);
}

}
void main() {
$player1.StimAdd(1000,300);
%player1.StimAdd(1001,300);
thread checkStatus();
}

And some other prerequisitories. The functions setHostile/setNeutral were already used in my last approach and are used the same way here, thus meaning that they are used to detect whether the player has stolen something. The functions setHostileZone/setNeutralZone are used for areas (this hasn't changed, too).

The main difference is that they activate a stim on the player (#1001). The checkStatus method continuosly checks whether the player

• holds a weapon
  
• carries a body
  
• picks a lock
  

and if so, activate another stim (#1000). Both stims have the same effect, but I've choosen two different ones to avoid interferences.

 

In DarkRadiant you first have to define both Stims in the S&R Editor under custon stims. Then, for every AI that is neutral to the player at mission start, do the following

• add a response to stim #1000 with the effect trigger entity nameOfCaller (activator _SELF)
  
• do the same for stim #1001
  
• add the stim #1000 to the ai's stim list and deactivate it by unchecking the active box
  
• create an entity target_callscriptfunction, name it nameOfCaller and set foreach to 1 and call to becomeHostile
  
• let the target entity target all your neutral ai
  

(Note: It may be possible that the number of working targets is limited, so you may have to add several such entities and group the ai's)

 

What is different now?

 

If an AI sees the player doing something illegal, they'll become hostile to the player. AI who have not seen the crime, will not become hostile unless they see you doing another crime or do see you while they are close enough to an AI, that has already identified you.

 

This simulates the effect of alerted AI informing their comrades about you, but will not have an effect on them if the other AI's can't see you. I think this is an improvement.

 

Optional: You may have to add the spawnarg "death_script" "scriptname" onto the ai that refers to a script function deactivating the stim on the death AI to avoid corpses "identifying" you. From 1.09 on there shall also be a "knockout_script" iirc. Until then you may not use this approach together with gas arrows (or add a response to a gas stim deactivating the stim # 1000). I didn't tested this yet so maybe it's not necessary.

 

I will post a testmap as soon as possible.

[RPGista]

This sounds very, very interesting, and definitely something that should be used as a norm, for any maps with neutral AI - I dont see any reason NOT to have this kind of behaviour, it adds a whole new level to the way neutrals interact with the player (right now, they basicly dont). This is certainly brilliant research and I would be very interested in that test map, if it proves simple enough I might try to include this in my own re-release, before it is done (I was already going to try your older method, in the wiki, anyway).

Edited March 12, 2013 by RPGista

[Obsttorte]

Still have to do some testing regarding the effects described under optional this evening. When I'm done, I'll post it here.

[Obsttorte]

Update: I've solved the knockout/kill issue. At the current state, knocked out or killed AI will only convert other AI to player enemies within a certain amount of time.

 

So if the player takes out an AI and is seen by an other AI within this amount of time, he will threated as an enemy. If the AI sees him after this time has passed, the AI will not become an enemy to the player (the AI "thinks" the player just found the body like himself).

[Obsttorte]

Here we go:

 

 

void setHostile() {
   $player1.StimEnable(1001,1);
}
void setNeutral() {
   $player1.StimEnable(1001,0);
   sys.println("TEST");
}
void setHostileZone(entity zone) {
 setHostile();
}
void setNeutralZone(entity zone) {
 setNeutral();
}
void checkStatus() {
   do{
   entity t;
   string unarmed,snake,triangle,classname;
   unarmed="atdm:weapon_unarmed";
   snake="atdm:playertools_lockpick_snake";
     triangle="atdm:playertools_lockpick_triangle";
   if ($player1.getCurrentWeapon() != unarmed) {
       $player1.StimEnable(1000,1);
   }
   else if ($player1.heldEntity()!=$null && $player1.heldEntity().getKey("spawnclass")=="idAI") {
       $player1.StimEnable(1000,1);
   }
   else {
       t=$player1.getFrobbed();
       if (t!=$null && t.IsLocked() && t.GetDoorhandle().isRotating()) {
           classname=$player1.getCurInvItemEntity().getKey("classname");
           if (classname==snake || classname==triangle) {
               $player1.StimEnable(1000,1);
           }
       }
   }
   sys.wait(1.0);
   $player1.StimEnable(1000,0);
   }while(true);
}    
void becomeHostile(entity e,entity activator,entity this) {
   string s="atdm:player_thief";
   //sys.println(e.getName()+" "+e.getMoveType());
   if (!e.getMoveType()){
       e.ResponseEnable(1000,0);
       e.ResponseEnable(1001,0);
       e.StimEnable(1000,0);
       return;
   }
   if (e.canSee($player1) && e.getHealth()>0) {
       e.ResponseEnable(1000,0);
       e.ResponseEnable(1001,0);
       e.setEntityRelation($player1,-1);
       e.StimEnable(1000,1);
   }

}
void main() {
   $player1.StimAdd(1000,512);
   $player1.StimAdd(1001,512);
   setNeutral();
   thread checkStatus();
}

 

 

This is the complete script needed. Let's go through it.

 

As already said, I use two different stims (#1000 and #1001) for my purposal. The first one is for checking whether the player lockpicks/carries weapon/drag a body and the latter is used for checking whether the player steals/carries body/is somewhere were he shouldn't be.

 

Stim #1000 is also used by alive and conscious AI to alert nearby AI if they see the player ("look over there, that's the guy" or so).

 

1. Areas where the player is not allowed to be:

 

Use the zone system. On all info_location entities belonging to zones were the player is allowed to be add the spawnarg "call_on_entry" "setNeutralZone", on the other ones "call_on_entry" "setHostileZone".

 

2. Stealing:

 

Every piece of loot targets a target_callscriptfunction entity with spawnarg "call" "setHostile" and a trigger_relay (with a delay set) which then targets another target_callscriptfunction with "call" "setNeutral".

 

3. Carrying a body:

 

On all AI add "equip_action_script" "setHostile" and "dequip_action_script" "setNeutral"

 

These three points haven't changed, with the only difference that now a stim (#1001) is used to alert AI.

 

What is new is the following:

 

The method checkStatus (former called checkWeapon) enables a stim on the player (#1000) which turns nearby AI seeing the player into enemies. This happens AI-wise and not team-wise like before. Enemy AI does emit this stim, too now, so if they get close to AI who can see the player, they'll become hostile, too. If they get killed or knocked out, the stim get's disabled. On the player, the stim does only last for the time he does something not allowed.

 

void becomeHostile(entity e,entity activator,entity this) {
   string s="atdm:player_thief";
   if (!e.getMoveType()){
       e.ResponseEnable(1000,0);
       e.ResponseEnable(1001,0);
       e.StimEnable(1000,0);
       return;
   }
   if (e.canSee($player1) && e.getHealth()>0) {
       e.ResponseEnable(1000,0);
       e.ResponseEnable(1001,0);
       e.setEntityRelation($player1,-1);
       e.StimEnable(1000,1);
   }

}

This gets caled if an AI receives the stim (#1000 or #1001). The entity e is the specific AI. The command e.getMoveType() returns one for an AI (ai_walk) as long as he is not ko'ed or killed. In the latter case, the method returns zero. So this part disables the stim on the AI.

The latter part checks whether the AI can see the player. If so, it becomes an enemy to the player and enables the stim #1000 on himself.

 

The rest of the code hasn't changed much.

void main() {
   $player1.StimAdd(1000,512);
   $player1.StimAdd(1001,512);
   setNeutral();
   thread checkStatus();
}

In the main method both stims are added to the player. The first argument is the stim number, the second one is the range of the stim.

 

To have the AI react to those stims, add responses to both stim types. The effect is as described above. To enable the code to activate the stim on the ai, it must be added to it. Otherwise it could be also added via the code.

 

Objectives like in the last approach are not needed.

[Obsttorte]

This zip file contains a test map and the script file (you must dmap it, the name is hitmanstyleII).hitmanstyleII.zip.txt

On the left side is a locked door which you can lockpick. The right door leads to an area where you aren't suppossed to be. The is a bottle on the table and you have both broadhead and gas arrows.

 

Play around with it to see how the AI behave.

 

If you have any questions regarding the setup or the script, don't fear to ask. I can post explanations in german, too, if my english explanation is hard to understand (or just pm me).

 

I hope that someone may want to make use of this.

 

Have fun.

[RPGista]

I'll definitely check this out soon as I have some time off, this should be really fun (and something ive been waiting to see in tdm for a long time). Thanks a lot!

[Obsttorte]

Thank you for the warm words.

 

If you have any questions regarding the setup just ask.

[Springheel]

This should definitely go in the core mod.

[Obsttorte]

Well, it is still not optimal. I have to add some last tweakes once I find the time.

 

EDIT: See here

[simplen00b]

Had a play around - drawing a weapon, stealing the bottle and going into the forbidden area always caused them to attack.

 

However the lockpicking was a lot more hit and miss - sometimes they attacked, sometimes they didn't. One little detail I noticed was that when they did attack, it only seemed to be when I started successfully lockpicking - if I was trying with the wrong lockpick, they never seemed to be bothered.

 

I've got a video of them ignoring a lockpick if it's of any help. At first I thought it was because I was huddling in the corner to the left of the door, but once I did a full-on crouch-right-in-front-of-the-door-lockpick and they still ignored me.

[Obsttorte]

it only seemed to be when I started successfully lockpicking

Yep, that's true. They will only react if the door handle is actually moving.

 

I'm still fiddling with it. But if you could upload that video I will take a look at it. Thanks.

 

Btw. I like your new avatar. What is it? A bird?

[simplen00b]

Video here:

http://youtu.be/9i1KaWauv2Q

Re AI only reacting if the door handle is actually moving - seems a bit odd to me. If I was an armed guard and saw someone crouching in front of a door trying to pick the lock, I wouldn't wait until I heard the tumblers turning before I 'investigated' (with my big hammer).

And thanks for the comment on the avatar - I really like it too. It's the Dishonored icon with some colour tweaking and rotated 180 degrees. (I think it looks like a bird too. A bird singing. Which I really like, given where it came from. )

[Obsttorte]

Looks like a problem with the stim time. I'll go and fix that. Thanks.

[Obsttorte]

OK, fixed.

 

The problem was the one second wait in the checkStatus method. I decreased the time to 0.1 seconds and added a one second wait after every stim-enable. Now the player will become suspicious if he lockpicks longer than 0.1 seconds.

 

Regarding the handle movement. I know it's not optimal, but as there is no function to find out whether the player is currently using his lockpicks, this little workaround gets as closed as it can get. Maybe I'll try to create my own custom lockpicks or so.

[simplen00b]

OK, fixed.

Cool.

[Obsttorte]

Happy update:

 

I've found another way to check whether the player attempts to lockpick. This code

else {
    t=$player1.getFrobbed();
    if (t!=$null && t.IsLocked() && t.GetDoorhandle().isRotating()) {
	    classname=$player1.getCurInvItemEntity().getKey("classname");
	    if (classname==snake || classname==triangle) {
		    $player1.StimEnable(1000,1);
		    $sys.wait(1.0);
	    }
    }
   }

gets replaced with this

else if ($player1.getImmobilization("Lockpicking")) {
   $player1.stimEnable(1000,1);
   sys.wait(1.0);
}

The benefits, beneath a much simpler code, is that the AI will get alerted if the player attempts to lockpick a door. Remember, in my original approach AI only get alerted if the player has choosen the right lockpick and the handle was actually moving.

 

One step further

[Obsttorte]

Update: The player will be threated as an enemy when seen throwing a flashbomb/flashmine/mine.

 

I attempt to change the code, so that only one stim is needed instead of two.