Jump to content
The Dark Mod Forums

Warm hands by fire


Domarius

Recommended Posts

Well this is a surprise :huh: I thought the whole reason it was in the list for the next milestone was because it was now possible for AI to react to fire nearby (in the same way we planned to have AI randomly stop and admire a painting) and was waiting for an animation to be done for it - that's why I didn't name it "idle_" in the first place...

Link to comment
Share on other sites

  • Replies 60
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Posted Images

I thought the whole reason it was in the list for the next milestone was because it was now possible for AI to react to fire nearby

 

It is. :mellow:

 

I think we need to distinguish between idle animations that might be played randomly anytime, and "interactive" animations that need to have a random chance of being played at specific times. Coughing and scratching would be the former. Warming hands or staring at a painting would be the latter.

 

While it would be nice to make a more generic system for those kinds of animations, path_animation nodes will do fine for now (IIRC, a random factor can already be built into them).

Link to comment
Share on other sites

It is. :mellow:

 

I think we need to distinguish between idle animations that might be played randomly anytime, and "interactive" animations that need to have a random chance of being played at specific times. Coughing and scratching would be the former. Warming hands or staring at a painting would be the latter.

 

While it would be nice to make a more generic system for those kinds of animations, path_animation nodes will do fine for now (IIRC, a random factor can already be built into them).

 

Yeah, I think path_animation is just the right thing. You would place it in front of the fire or a painting, and make the patrol do the animation with a certain probability (like 0.1 for "look at painting" and 0.7 for "warm hands").

 

Except. Wait for it. There is no "path_animation".

 

The closest ones are:

 

entityDef path_lookat {
"inherit"			   "path_default"
"editor_usage"		  "Causes character to look at an entity for a certain length of time or until triggered."
"editor_var anim"	   "Name of animation to play."
"editor_var blend_in"   "# frame to blend in to anim."
"editor_var blend_out"  "# frame to blend out of anim."
"editor_var focus"	  "Name of entity to look at."
"editor_var wait"	   "how long to look at the entity.  if 0, or not set, then only waits until character is triggered."

"blend_in"			  "4"
"blend_out"			 "4"

}

 

and

 

entityDef path_anim {
"inherit"			   "path_default"
"editor_showangle"	  "1"
"editor_rotatable"	  "1"

"editor_usage"		  "Character will play the specified animation.  Set angles to direction to face."
"editor_var anim"	   "anim to play."
"editor_var blend_in"   "# frame to blend in to anim."
"editor_var blend_out"  "# frame to blend out of anim."
"editor_var head_anim"  "if set, waits for animation in head to finish, instead of the body."

"blend_in"			  "4"
"blend_out"			 "4"
}

 

But both do not take a probability parameter yet.

"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

Link to comment
Share on other sites

Except. Wait for it. There is no "path_animation".

 

Ok, it's "path_anim". Sue me for not looking it up. :rolleyes:

 

As for the random factor, I believe you can set a random chance for an AI to go to a particular pathnode (at which point they would play the animation). However, I haven't looked that up recently either.

Link to comment
Share on other sites

We haven't got around to port the path_anim and path_lookat behaviour to the SDK AI code yet, but it's an easy thing to do. Just saying, before anybody wants to try it out and is wondering why they don't work.

Link to comment
Share on other sites

Ok, it's "path_anim". Sue me for not looking it up. :rolleyes:

 

Sorry, this was my fault. I didn't find "path_anim", either, then found it and amended my post, but forgot to take out the paragraph with "there is no path_animation". Sorry again :blush:

 

As for the random factor, I believe you can set a random chance for an AI to go to a particular pathnode (at which point they would play the animation). However, I haven't looked that up recently either.

 

But this is quite awkward, as the mapper then needs to place two nodes in the same spot (aka in front of the fire). Having a "random_anim" spawnarg would be better?

 

@greebo: Ah, yes, one of these things I was supposed to do :blush:

"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

Link to comment
Share on other sites

What makes me a bit desparate is how fast our team comes up with new ideas and new stuff we need to implement. Sometimes, I get the impression that we have 25 people coming up with good ideas and requests, but only 2 or 3 coders actually working off the list. Needless to say that this imbalance won't work out well. Also, suggesting so many new features has not a good impact on my personal motivation, the workload appears to be overwhelming.

 

(Sorry, I guess this is actually a rant. It's over, you can keep on moving.)

Link to comment
Share on other sites

What makes me a bit desparate is how fast our team comes up with new ideas and new stuff we need to implement. Sometimes, I get the impression that we have 25 people coming up with good ideas and requests, but only 2 or 3 coders actually working off the list. Needless to say that this imbalance won't work out well. Also, suggesting so many new features has not a good impact on my personal motivation, the workload appears to be overwhelming.

 

(Sorry, I guess this is actually a rant. It's over, you can keep on moving.)

 

I know, ideas are cheap :)

"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

Link to comment
Share on other sites

But this is quite awkward, as the mapper then needs to place two nodes in the same spot

 

That's not quite the way it works...you don't place two nodes, but you link node A (fireplace) to node B (a spot on the guard's regular route) and then add a variable to node B that gives a percentage chance the guard will go to node A. If they go to A, they play the animation. I'm fairly certain that's how it works but it's been a while since I checked.

Link to comment
Share on other sites

Currently, the AI are choosing randomly between all available "next" target nodes.

 

Example: Path Corner A targets both Path Corner B and Path Corner C. The AI arriving at Path Corner A will choose 50:50 between B and C.

 

I didn't quite get what exactly you wanted to achieve with the random spawnarg, though?

Link to comment
Share on other sites

I didn't quite get what exactly you wanted to achieve with the random spawnarg, though?

 

Is that @ me? If so, I was just saying that no special code is needed to make guards randomly wander over to a heat source and play the warming hands animation. You just use path_anim (once it is ported over). We don't want AI to go to the fireplace *every 30 seconds exactly* to warm their hands, however, like TDS. The random factor for choosing pathnodes should cover that nicely.

Link to comment
Share on other sites

Ah, well ok, my question wasn't specifically directed at you, but I didn't know exactly what the "random" spawnarg discussion was about. :)

 

But the upshot here is that you still need an extra link, and it seems not possible to set the actual probability.

 

Consider a path with three nodes, the second one in front of the fire place:

 

post-144-1205436374_thumb.png

 

In this case, the anim will be played *everytime* the guard reaches the node in front of the fireplace.

 

Now consider laying an alternative routes as greebo described:

 

post-144-1205436510_thumb.png

 

Problems:

 

* the alternative route would be a straight line between node 1 and 3, meaning the guard does not nec. pass in front of the fire place (you need another node to make him go there and continue)

* the guard will choose each path 50% of the time, but what if you want him to be 70% of the time near the fireplace?

 

That is why "path_anim" should have a "probability" spawnarg, that says "if a random number is smaller than this value (0..1), then skip playing the animation and continue".

 

That would simplify the path setup and make it more flexible at the same time.

 

Hope I explained that now :)

"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

Link to comment
Share on other sites

Well, if the random spawnarg just refers to the path_anim entity itself, that's dead easy to implement.

 

Tell me the name it should have, and I look into it. (path_anim is on my list, anyway) :D

 

Edit: That is the problem with these "lets discuss the feature first". In cases like this I spent 10 times the time to explain it than it would take me to implement it, but I am not bold enough to just do it, because you know, lets discuss it first until we all (including the people who don't even know yet what we talk about) have come to an conclusion. :) (end of rant :D

"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

Link to comment
Share on other sites

Well it's not my fault if you spend so much time on drawing vector graphics for your postings. You could've just explained it in a few words. ;) And don't you find it a bit ironic that you complain about discussing things too much? Nobody is posting as much as you do. :P

Link to comment
Share on other sites

That is why "path_anim" should have a "probability" spawnarg, that says "if a random number is smaller than this value (0..1), then skip playing the animation and continue".

 

That would simplify the path setup and make it more flexible at the same time.

 

I'm not sure it wouldn't be better to put the probability spawnarg on the pathnode where the AI chooses between multiple locations, rather than the animation.

 

In other words, AI gets to node A, and will proceed to either B or C. If you could set "30% B and 70% C", that would solve your issue above, and it would be more useful in general for other types of pathing (you could set AI to patrol down a side-corridor only 25% of the time, frex). It would also work better with path_cycleanim or path_lookat, which may also be used for similar effects.

 

Although a random spawnarg on the path_anim itself would probably be useful in some cases, you wouldn't generally want the AI to still walk to the heat source 50% of the time, but NOT play the warming animation 75% of the time after getting there. In general, if the AI goes to the path_anim, they should play the animation.

 

Edit: That is the problem with these "lets discuss the feature first".

 

This is exactly *why* we discuss features first. Because the first idea isn't always the best idea.

Link to comment
Share on other sites

I'm not sure it wouldn't be better to put the probability spawnarg on the pathnode, rather than the animation.

 

In other words, AI gets to node A, and will proceed to either B or C. If you could set "30% B and 70% C", that would solve your issue above, and it would be more useful in general for other types of pathing (you could set AI to patrol down a side-corridor only 25% of the time, frex).

 

That could/should be done in addition.

 

Although a random spawnarg on the path_anim itself would probably be useful in some cases, you wouldn't generally want the AI to still walk to the heat source 50% of the time, but NOT play the warming animation 75% of the time after getting there. In general, if the AI goes to the path_anim, they should play the animation.

 

I disagree. The same with the path_lookat (or whatever it is named), I'd set it up so that the AI looks *sometimes* at the painting, and sometimes not. Likewise with the fire, sometimes the guard just passes, sometimes he warms his hands.

 

Otherwise, the guard is like clockwork, 100% predictable.

 

Note that your idea with the probability on the paths still requires another additional path node (one entity) opoposed to one spawnarg on the already existing path node.

 

(I'd draw apicture, but its too late tonight, I am about to purchase a flatbed scanner, so maybe I do this first, then draw a real picture, then scan it in - thats certainly faster than me diddling in Inkscape for half an hour :-)

 

Summary: There is no reason we cant have both random next nodes and random "do animation/do look at" nodes in a path.

 

This is exactly *why* we "discuss features first". Because the first idea isn't always the best idea.

 

We can always amend an implementation, especially the "5min" ones :)

"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

Link to comment
Share on other sites

I disagree. The same with the path_lookat (or whatever it is named), I'd set it up so that the AI looks *sometimes* at the painting, and sometimes not. Likewise with the fire, sometimes the guard just passes, sometimes he warms his hands.

 

Otherwise, the guard is like clockwork, 100% predictable.

 

Note that your idea with the probability on the paths still requires another additional path node

 

You're clearly not understanding what I'm suggesting, because neither of those statements are true.

 

If they're in idle state, AI don't just wander about--they go specifically from one pathnode to another. If you don't put a pathnode in front of the fireplace, the AI isn't going to go there. You seem to envision the AI walking right by the fireplace, and then choosing whether to stop and play the animation or keep going. That doesn't happen unless there is a pathnode there.

 

Let's take a specific example. Let's say you have an AI who regularly patrols through a room. You want him to occasionally (20% chance) stop and warm his hands by the fireplace, and occasionally (30% chance) walk over to the table and sniff the stew there (or whatever).

 

path2.jpg

 

In #1, using your system, the AI goes from A to B. At B, he has a 20% chance of playing the warming animation. Regardless, he proceeds to C, where he has a 30% chance of playing the 'sniff' animation. Then he proceeds to D.

 

This isn't very realistic behaviour, since if the AI *doesn't* play the animation, it seems strange that he would walk a zig-zag path to the fireplace and the table, but not do anything. It is also extremely predictable, because the guard always proceeds in the same path.

 

Option #2 has the same number of pathnodes. Using your system, when reaching node A, the guard would have a 33% chance of proceeding to the fireplace, where he would then have a 20% chance of playing the animation. This would still result in zig-zag pathing for no apparent reason (though less than #1). It is less predictable, but also less flexible, as the AI would always have an equal chance of choosing any particular node.

 

Option #2 with my system would go as follows: The AI gets to node A. He then has a 20% chance to choose to go to node B, where he plays the warming animation and then continues to node D. He has a 30% chance of proceeding to node C and playing the sniff animation. And he has a 50% chance of just continuing his patrol straight to node D. This option is the least predictable and most versatile.

 

This system requires no additional nodes (and you only have to put special spawnargs on 1 node instead of 2). It results in more believable behaviour, and can be used in a wider variety of situations, since it can be used with regular path_corners--for example, giving an AI a 5% chance of wandering down the hallway to check the unused door at the end rather than passing by as he usually does.

Link to comment
Share on other sites

There isn't a need for an extra feature like this.

 

Warming hands by a fire would just use our existing planned stim system, where if they are near enough to something, they receive the stim, and in the case of a painting, have a random chance to turn and do the "admire" anim, or in the case of a fire, have a random chance of turning and doing the "warm hands" anim.

 

If you want these anims to be triggerd, you'd set your patrol paths to pass close enough to these objects to enter the stim radius.

Link to comment
Share on other sites

That would have the added benefit of not firing anymore when the source was extinguished. But are you sure that's easier than adding a random variable to a pathnode? Seems like extra coding would be needed to do things like establishing how close the AI needs to walk towards the stim (can't warm your hands from six feet away) how to ensure the AI faces the right way, etc.

Link to comment
Share on other sites

The node concept sounds best to me as well. It's already there for Doom3, it can play any anim you say instead of just being limited to warming hands (hardcoded limitations?), and is needed for conversations anyway (argue from across room, walk up and shake hands in other AI's face, etc). The random node choosing is needed as well; it was one of the best things in the TDS AI setup.

 

Current node --> one of three random nodes (one just a patrol, one a different patrol, one a patrol to a point of interest with anim). Nice and clean.

Link to comment
Share on other sites

You're clearly not understanding what I'm suggesting, because neither of those statements are true.

 

If they're in idle state, AI don't just wander about--they go specifically from one pathnode to another. If you don't put a pathnode in front of the fireplace, the AI isn't going to go there. You seem to envision the AI walking right by the fireplace, and then choosing whether to stop and play the animation or keep going. That doesn't happen unless there is a pathnode there.

 

And you clearly didn't understand what I was talking about, because the "node in front of the fire" was exactly what I had in mind. Duh!

 

I will reply to the rest of your post later, I am in a rush to the city. Sorry.

"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Recent Status Updates

    • Petike the Taffer  »  DeTeEff

      I've updated the articles for your FMs and your author category at the wiki. Your newer nickname (DeTeEff) now comes first, and the one in parentheses is your older nickname (Fieldmedic). Just to avoid confusing people who played your FMs years ago and remember your older nickname. I've added a wiki article for your latest FM, Who Watches the Watcher?, as part of my current updating efforts. Unless I overlooked something, you have five different FMs so far.
      · 0 replies
    • Petike the Taffer

      I've finally managed to log in to The Dark Mod Wiki. I'm back in the saddle and before the holidays start in full, I'll be adding a few new FM articles and doing other updates. Written in Stone is already done.
      · 4 replies
    • nbohr1more

      TDM 15th Anniversary Contest is now active! Please declare your participation: https://forums.thedarkmod.com/index.php?/topic/22413-the-dark-mod-15th-anniversary-contest-entry-thread/
       
      · 0 replies
    • JackFarmer

      @TheUnbeholden
      You cannot receive PMs. Could you please be so kind and check your mailbox if it is full (or maybe you switched off the function)?
      · 1 reply
    • OrbWeaver

      I like the new frob highlight but it would nice if it was less "flickery" while moving over objects (especially barred metal doors).
      · 4 replies
×
×
  • Create New...