Forum

big enemies physics problems

Discuss programming in the QuakeC language.

Moderator: InsideQC Admins

big enemies physics problems

Postby Nahuel » Mon Feb 18, 2019 2:36 pm

well, I have noticed that the enemies with bbox sizes bigger than to the quake size of the player (-16 -16 -24,16 16 32), have a lot of trouble getting down-high stairs and often get stuck on the map.the solution would be simply to resize them to the player's size at max. but that's not what I want.. I'm using q3bsp so q1bsp hulls are not a problem. There is some way to make the big bboxes in enemies work with the same physics for smaller bboxes (like player size for example) . I am working in darkplaces :D if that requires engine changes, what are the steps to follow?
Thank you very much
hi, I am nahuel, I love quake and qc.
User avatar
Nahuel
 
Posts: 495
Joined: Wed Jan 12, 2011 8:42 pm
Location: mar del plata

Re: big enemies physics problems

Postby madf0x » Sat May 25, 2019 6:22 am

I'm quite a noob for the subject, and maybe it's not worth mentioning, but
could it make a difference changing the size to

setsize (self, VEC_HULL2_MIN, VEC_HULL2_MAX);

You said it's not the Q1 hull size, so I might be wrong for darkplaces.
User avatar
madf0x
 
Posts: 5
Joined: Sun Mar 17, 2019 3:09 am

Re: big enemies physics problems

Postby Spike » Sat May 25, 2019 12:26 pm

entities uses axially aligned boxes.
an axially aligned box on a slope gets further and further off the ground the steeper the slope gets.
walkmove/movetogoal fail the move if the entity is off the ground.

ergo, slopes = bad, and get worse with larger monsters.

If you just want to force it to work anyway, you can set FL_PARTIALGROUND before the walkmove/movetogoal calls. This will make the monster think that its already off the ground and thus won't care too much if the monster ends up off the ground too. Unfortunately, the monster will now quite happily walk off cliffs.
If you want to do things more intelligently, then you're probably going to have to do things very differently. Either using MOVETYPE_WALK and setting up .velocity to do the move for you, or manually using your own calls to tracebox, either option will be a fairly large departure from your existing code however.
Spike
 
Posts: 2908
Joined: Fri Nov 05, 2004 3:12 am
Location: UK

Re: big enemies physics problems

Postby Nahuel » Tue May 28, 2019 8:36 pm

thanks for the replies guys,

If you want to do things more intelligently, then you're probably going to have to do things very differently. Either using MOVETYPE_WALK and setting up .velocity to do the move for you,


I think that would be the best solution, I will forget about movetogoal and its limitations to use movetype_walk, although it may have unexpected inconveniences. Do you have any suggestions? Do you know maybe a mod that does this? I guess bots use movetype_walk and .velocity but I don't remember a mod where this is used in some monster.
From now on, thank you very much
hi, I am nahuel, I love quake and qc.
User avatar
Nahuel
 
Posts: 495
Joined: Wed Jan 12, 2011 8:42 pm
Location: mar del plata

Re: big enemies physics problems

Postby Spike » Thu May 30, 2019 12:38 pm

I believe that shpuld's various 2-day mods tend to use movetype_walk for monsters.
Spike
 
Posts: 2908
Joined: Fri Nov 05, 2004 3:12 am
Location: UK

Re: big enemies physics problems

Postby toneddu2000 » Fri Jun 07, 2019 1:30 pm

I never used neither movetype nor movetogoal, I prefer to choose a direction and then I interpolate it over time, and then apply gravity to it.
I personally prefer this kind of approach. But I use CSQC, maybe it's different with SSQC
Meadow Fun!! - my first commercial game, made with FTEQW game engine
toneddu2000
 
Posts: 1381
Joined: Tue Feb 24, 2009 4:39 pm
Location: Italy


Return to QuakeC Programming

Who is online

Users browsing this forum: No registered users and 1 guest