Apples and Peaches: Obsttorte's Mapping and Scripting Thread

[nbohr1more]

Time to add someone to the TDM team

[Tels]

It's on: http://wiki.thedarkm...eating_Automaps

 

Any language correction would be nice (you know, my english )

 

Hope you like it. Advices of any kind (for example if something is unclear) are always welcome.

 

A few screenshots of the feature would be nice - right now it's just a wall of tex.t

[Obsttorte]

Will think about that.

[Springheel]

Time to add someone to the TDM team

 

Now that you mention it...

[Obsttorte]

Just something I forgot to post. I was playing around with the stim/response editor as I've set up the hitmanstyle map. Well, actually you can set a response for flash on AI. So what I've tried was to add the effect knockout. This is quite funny. If you throw a flashbomb at a guard and blind him he will be knocked out than. Don't know if anyone can make use of that.

[Obsttorte]

Is it possible to read out the numbers of KOed/killed AI. I mean, they are shown at the end so they must be counted somehow. The script reference does not seem to provide such a function.

[Tels]

It doesn't seem possible, in game/Objectives/MissionData.cpp there are no events defined, so the scripting side cannot get at the data. Guess another tracker entry is in order, please make it read "add scripting events to get mission statistics", because other type of statistics (damage dealt, healed etc.) can be done at the same time and might be useful later.

[Obsttorte]

Done. #3304

 

Btw.: I'll try to upload some example maps for the other problems as soon as possible.

 

Done, too.

[Obsttorte]

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.

[grayman]

A few things:

 

1 - You don't initialize 'l', though you use it in the statement 'if (l < 100)'. Is that the distance from the player to the shield?

 

2 - Again, you don't need to use trigger_entityname when dealing the the player. A plain old trigger will recognize the player by default.

 

3 - Would a trigger_facing be of any use here, since it's already supported?

 

4 - In English, it's cosine, not cosinus.

[Flanders]

Aren't there easier functions you can use for this in doom_events.script or tdm_events.script? There are some that have names like Looks At or Can See or anything like that.

[Obsttorte]

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

[grayman]

Aren't there easier functions you can use for this in doom_events.script or tdm_events.script? There are some that have names like Looks At or Can See or anything like that.

 

Those are for use with AI, not the player.

[Obsttorte]

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

[Obsttorte]

I've just looked at the wiki and the answer to your question

Would a trigger_facing be of any use here, since it's already supported?

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.

[Tels]

Brilliant! This should get wrapped into a function that can be used in a more general manner. A few remarks:

 

* when making examples, it is good practice to use "speaking names". "shield" is fine for an entity, but "test" for a function is horrible, it will (or even does) clash with other things. And in 2 weeks nobody knows what $player1.test(vector a) does, w/o looking up test(). So better use names like playerLooksAt(vector origin) or similiar

 

Edit: I'd say float doesLookAt(entity who, vector point, float fudgeFactor); which returns 0 if "who" doesn't look at the piont, and 1 if he does. That way you also have decoupled the testing from the action it is supposed todo.

 

 

* there is a script event to normalize a vector:

 

/**
* Returns the normalized version of the given vector.
*/
scriptEvent vector			  vecNormalize(vector vec);

 

(Edit: I think you aren't actually normalizing the vector (make it so its length == 1), but calculating the length of the vector. There are two possible optimizations here:

 

* You can save the sqrt() and simple compare against the square (e.g. d == 10000 vs. sqrt(d) == 100)

* you could use vecLength()

 

end of edit)

 

* the variable is called "b" (lowcase):

 

x=sys.cos(*sys.cos(a);

 

* there is a script event to get the eye position of the player:

 

getEyePos()

 

This would be better than using the origin. (I forgot if getEyePos() only returns the eye height (e.g. 0,0,128 or whatever for Z) or the absolute position as X,Y,Z. But you'll find out

 

* if d becomes == 0, you are in trouble

 

But apart from these minor things, that sounds *very* useful and exactly what I need for Swift Mazes for the first goal the player needs to reach (he must look at an item).

[Obsttorte]

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 )

[Tels]

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 )

 

That's understandable, but I think if you go to 90%, you might as well go to 100%, polish it up (no, don't translate it to polish...) and package it into TDM so other people can use it the next time round. There always lots of ideas floating around and half-finished attemps, and even "almost working" solutions, so when something gets finished (no no, not translating to Finnish...), it has the chance that your work was not wasted.

 

I cna help you converting it to something that can be shipped with TDM if you wish, as example.

[Obsttorte]

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

[Obsttorte]

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?

[Obsttorte]

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

[grayman]

If triggers were that broken, most of the existing maps would stop working.

 

Can you make a test map available so we can see exactly what you're trying to do?

[Obsttorte]

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

[Obsttorte]

OK. I just created a test map and it seems they are working. Don't know what happened in the first map.

 

But what still occures is that if I rename a trigger it gets broken. If I rename it back to it's original name it works again. I filed a bug report for trigger_entityname about this but it seems to apply to all triggers.

[grayman]

Please see the note I added to this issue.

 

Prove it to yourself, after which you can close the issue as "not a problem".