Index | FAQ | Search | Memberlist | Usergroups | Profile | Log in to check your private messages | Log in | Register

spot animation? Goto page 1, 2 Next

| Inside3d Forums Forum Index -> General Discussion

View previous topic :: View next topic
Author | Message
--- | ---
Mathuzzz Joined: 09 May 2010 Posts: 14 |

Posted: Sun May 30, 2010 5:02 pm Post subject: spot animation? |

How could I force my monster to make animation when he spot me? I have large noisy monster, but I want him to make certain animation, not just sight sound.

Back to top |

frag.machine Joined: 25 Nov 2006 Posts: 728 |

Posted: Mon May 31, 2010 1:43 am Post subject: |

I made something similar once. Here how I did: EDITED: 1) create a new entity field, like this:

Code:
.entity mad_with;

2) in the monster spawn, make sure .mad_with= world;
3) in the first step of the run animation compare .enemy with .mad_with; if they are different, jump to the special animation sequence;
4) in the last step of the special animation, set .mad_with= .enemy, and the next animation step back to the first run animation step.
That's it. This has the added behavior of making your monster running the special animation every time it changes of enemy, too. If you don't want this, then use a different field (like .aflag or .cnt)
_________________
frag.machine - Q2K4 Project
http://fragmachine.quakedev.com/
Last edited by frag.machine on Mon May 31, 2010 5:35 pm; edited 1 time in total

Back to top |

Lardarse Joined: 05 Nov 2005 Posts: 243 Location: Bristol, UK |

Posted: Mon May 31, 2010 2:43 pm Post subject: |

Overloading .owner like that will cause problems, because it affects collision detection. Using a float field is probably enough. _________________ <ekiM> Son, you're writing data structures your CPU can't cache.

Back to top |

frag.machine Joined: 25 Nov 2006 Posts: 728 |

Posted: Mon May 31, 2010 3:51 pm Post subject: |

Lardarse wrote:
Overloading .owner like that will cause problems, because it affects collision detection. Using a float field is probably enough.

Are you sure ? The original shambler code uses .owner to hold the lightning entity without any collateral effect, so I assumed it was safe to reuse it.
_________________
frag.machine - Q2K4 Project
http://fragmachine.quakedev.com/

Back to top |

MauveBib Joined: 04 Nov 2004 Posts: 602 |

Posted: Mon May 31, 2010 5:14 pm Post subject: |

.owner is used in collision, don't overload it. Create a new field or use another unused one. _________________ Apathy Now!

Back to top |

frag.machine Joined: 25 Nov 2006 Posts: 728 |

Posted: Mon May 31, 2010 5:32 pm Post subject: |

Ouch, you guys were right , just found it in the C code. Fixed, thanks for pointing that out. _________________ frag.machine - Q2K4 Project http://fragmachine.quakedev.com/

Back to top |

Orion Joined: 12 Jan 2007 Posts: 413 Location: Brazil |

Posted: Mon May 31, 2010 5:40 pm Post subject: |

Lardarse is kinda right. Setting .owner to .enemy, will make the monster non-solid to the player (if the player is the monster's enemy, otherwise this monster would be non-solid to another monster). So the monster will ONLY take damage from explosives. Hitscan and projectile/grenade weapons will pass through it. But if a grenade or rocket explodes close enough to the monster he will take damage anyway.
Think the rocket actually spawns inside the player's body, not in the end of the gun's barrel. If the rocket has .owner set to world, the rocket will just explode in your face, and cause problems with death messages, which will be like 'player rides 's rocket', as world don't have a netname at all.
In the case of the shambler's external lightning model (s_light.mdl), the lightning owns the shambler, so the shambler is non-solid ONLY to the lightning, that's why there's no problem in these cases.
EDIT: Uhoh. I posted with other at the same time explaining the same thing lol!
_________________
There's no signature here. Stop looking for one.

Back to top |

frag.machine Joined: 25 Nov 2006 Posts: 728 |

Posted: Mon May 31, 2010 8:57 pm Post subject: |

Orion wrote:
Lardarse is kinda right. Setting .owner to .enemy, will make the monster non-solid to the player (if the player is the monster's enemy, otherwise this monster would be non-solid to another monster). So the monster will ONLY take damage from explosives. Hitscan and projectile/grenade weapons will pass through it. But if a grenade or rocket explodes close enough to the monster he will take damage anyway.
Think the rocket actually spawns inside the player's body, not in the end of the gun's barrel. If the rocket has .owner set to world, the rocket will just explode in your face, and cause problems with death messages, which will be like 'player rides 's rocket', as world don't have a netname at all.
In the case of the shambler's external lightning model (s_light.mdl), the lightning owns the shambler, so the shambler is non-solid ONLY to the lightning, that's why there's no problem in these cases.
EDIT: Uhoh. I posted with other at the same time explaining the same thing lol!

He's not "kinda" right, he's completely right.
_________________
frag.machine - Q2K4 Project
http://fragmachine.quakedev.com/

Back to top |

Wazat Joined: 15 Oct 2004 Posts: 732 Location: Middle 'o the desert, USA |

Posted: Tue Jun 01, 2010 3:57 am Post subject: |

frag.machine wrote:
4) in the last step of the special animation, set .mad_with= .enemy, and the next animation step back to the first run animation step.

Actually, I recommend doing this in the first animation step. If you do it in the last animation step, then beating the monster is easy. Just keep shooting it each time it starts its spot animation, and it will never update its .mad_with field because its pain animation interrupts it. This will lock it in its spot animation until the player manages to kill it.
This is similar to coop -- two players can kill any non-boss monster, including a shambler, with axes simply by alternating which player is attacking so the shambler can never decide who to attack. I solved the coop bug in Conquest by giving monsters an anger chance, which lowers each time they change targets until they become dead set on one target. It's still exploitable, but at least the monster stops being paralyzed.
Another way to fix this sight animation bug is to only play the animation when the monster chooses a new target, not in the run code. FoundTarget or HuntTarget in ai.qc should do, since sighting a target and getting mad from damage both channel through these functions. You could have your monster set its .think to the sight animation in hunt target instead of to its th_run.
To do this generically, add a new function: .th_sight. Set .th_sight in the monster spawn function (as with .th_pain, we'll set it up so that if some monsters don't set it, it simply isn't used by them).
Now, in HuntTarget, replace the self.think = self.th_run line with:
if(self.th_sight)
self.think = self.th_sight;
else
self.think = self.th_run;
This will do three things:
1) It solves the problem with getting caught in an infinite cycle when the player keeps attacking during the spot animation. If the monster is interrupted during its sight anim, it will finish its pain (or whatever) animation and start fighting as normal (skipping the rest of the sight anim). This means the player has to choose whether to attack during the sight animation -- if he needs a little time to position himself, it's a good idea to not shoot and let the monster yell and beat its chest while he runs for cover or a better weapon.
2) It removes the need for .mad_with, so that can be removed
3) It makes sight animations generic, so any monster can do one simply by setting .th_sight. Monsters without .th_sight just start moving as normal.
Viola
I hope that helps!
_________________
When my computer inevitably explodes and kills me, my cat inherits everything I own. He may be the only one capable of continuing my work.

Back to top |

leileilol Joined: 15 Oct 2004 Posts: 1321 |

Posted: Tue Jun 01, 2010 4:23 am Post subject: |

I would probably just shove in a direct animation call in SightSound

Wazat wrote:
Viola I hope that helps!

How would a musical instrument help QuakeC?
_________________

Back to top |

Mathuzzz Joined: 09 May 2010 Posts: 14 |

Posted: Tue Jun 01, 2010 8:41 pm Post subject: |

Thank you very much for your replies, guys. All I was looking for was answered by Wazath. Thanks again!

Back to top |

Mathuzzz Joined: 09 May 2010 Posts: 14 |

Posted: Wed Jun 02, 2010 2:16 pm Post subject: |

I have yet another question. It has nothing to do with spot animation, but it is the same monster Iīm trying to finish. Actually it is replacement for shambler, so I had to make some changes to size, but now when he shoot, the lightning comes from his legs. How can I change the origin of the lightning? Same thing happened with other monsters I was trying to replace. Maybe it is trivial, but I canīt figure it out. Thank you

Back to top |

ajay Joined: 29 Oct 2004 Posts: 295 Location: Swindon, UK |

Posted: Wed Jun 02, 2010 2:24 pm Post subject: |

In the original shambler.qc I think it's this bit:

Code:
void() CastLightning = { local vector org, dir; self.effects = self.effects | EF_MUZZLEFLASH; ai_face ();
org = self.origin + '0 0 40';

The 40 is the height the lightning attack comes from.
I could be wrong, I'm far from expert re: quakec
_________________
my site

Back to top |

Mathuzzz Joined: 09 May 2010 Posts: 14 |

Posted: Wed Jun 02, 2010 4:28 pm Post subject: |

Thanks

Back to top |

frag.machine Joined: 25 Nov 2006 Posts: 728 |

Posted: Wed Jun 02, 2010 5:41 pm Post subject: |

leileilol wrote:
I would probably just shove in a direct animation call in SightSound

Wazat wrote:
Viola I hope that helps!

How would a musical instrument help QuakeC?

Making music to monsters dance, of course!
_________________
frag.machine - Q2K4 Project
http://fragmachine.quakedev.com/

Back to top |

Display posts from previous:

| Inside3d Forums Forum Index -> General Discussion | All times are GMT Goto page 1, 2 Next
Page 1 of 2

Jump to:

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

Powered by phpBB © 2004 phpBB Group