Obsttorte

Well, actually the first part was called Dark Project: Der Meisterdieb in germany, so at least their thief was included. I guess it wasn't used in germany as most people here don't know how to pronounce th. (Me, too btw.)

The Dark MOD=The Dark Mooded Overhelming D...

@Capela: [quote] Your quotation here [/quote]

the covariance refers to the way the linear transformation (for example a gradient) appears after the transformation. If you transform a vector v it looks like v_new=A*v where A is your transformation. On the other hand if you transform a scalar-valued linear function L (like a gradient for example) it looks like this L_new=L*A So the difference is from which side the transformation gets applied. I hope that helps. EDIT: I've corrected my post. EDIT2: Referring to the gradient example you've mentioned you have to think of it as a function, not as a vector. So it is something that gets applied to vectors. This is a huge difference.

I'm not sure this is intented to be funny. But I like it.

TDS = The Dark Standalone Nee, let's stay with TDM. Everybody is used to it and it's like Sotha said: remember the roots.

I'm also not a big friend of 3D only, as I do most of my work in the 2D windows. Anyways, being able to manipulate patches in a more extensive way then it is possible now would definetely be a big plus. Regarding the "all day worksteps" like creating or cutting brushes it doesn't seem to be faster then DR to me.

Fires like torches are controlled by the script object tdm_light_holder. In this case it is lightname.LightsOn() and lightname.LightsOff(). The bonfire uses light_moving ext. In this case it is lightname.response_extinguish(entity stim,float threadnum) and lightname.response_ignite(entity stim, float threadnum). You can call them like lightname.response_ignite($null,0) I guess. On() and Off() are used by electric lamps. I hope that helps. Btw: If you wanna find out how some things can be manipulated via script, check out which script object it uses and look it up in the tdm_base.pk4. Edit: You can also use frob_extinguish() and frob_ignite(). The reason why response_extinguished() doesn't work is that such a function (without arguments!) doesn't exist. Don't forget the arguments when using script functions.

Did you actually try it? Just corious.

:laugh: :laugh: :laugh: :laugh: :laugh: :laugh:

+100

+1

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.

Here we go: 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.

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).

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

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.

Not sure if I've already asked this, but is there a way to pass an argument to a script function called by an entity as a response to a stim. So the response is "run script" and my script is like void functionname(entity e). The script, however, get called, but there seem to be no entity passed, as I can't retrieve any information from it. My goal is to find out which entity actually called the script.

Grayman and Springheel are working on some code changes anyway, so you could ask them. EDIT: If someone can tell me were to get the latest code and how to compile it, I could test it myself.

Sounds good to me.

In the editor fogs have the light flag "fog" while blend lights have the light flag "blend" and ambient lights uses "ambient". Don't know if this flags can be read out via a function or so.

Wouldn't it be then better to replace the "no distance falloff" case by defining a standard falloff, which is used if the mapper doesn't specify his own values? If there are a lots of lights around you, the world is already bright. Decreasing the ambient light then would cause the contrast to be increased what may suit better here. On the other hand, if the ambient light is increased a bit in dark areas, only weak lighted areas will look much more washed out due to low contrast, what may look good. As the ambient light also impacts the lightgem iirc, this would also simulate the effect of AI's eyes getting used to the darkness. EDIT: This is a reply to post #18. I'm a bit slow these days

The "picture" would be clearer if it was actually there.

I don't want to nitpick if this is the right word, but regarding the pvs approach I must say that this is very suboptimal. Imagine you are standing in a room with lots of light on the one side and no light on the other. In real life, if you were looking at the lights, your eyes would get used to the brightness and this would cause the unlit areas in your view to become even darker. On the other side, if you were looking at the dark side, your eyes would get used to the darkness and you could see much better in the shadows (thus meaning they become brighter). It seems to me that the current pvs approach does exactly the opposite. If you have lots of light in your view, everything gets brighter, while on the opposite in dark areas everything gets darker. Just my two cents.