big enemies physics problems

Discuss programming in the QuakeC language.
Post Reply
Nahuel
Posts: 495
Joined: Wed Jan 12, 2011 8:42 pm
Location: mar del plata

big enemies physics problems

Post by Nahuel »

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.
madf0x
Posts: 5
Joined: Sun Mar 17, 2019 3:09 am

Re: big enemies physics problems

Post by madf0x »

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.
Spike
Posts: 2914
Joined: Fri Nov 05, 2004 3:12 am
Location: UK
Contact:

Re: big enemies physics problems

Post by Spike »

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.
Nahuel
Posts: 495
Joined: Wed Jan 12, 2011 8:42 pm
Location: mar del plata

Re: big enemies physics problems

Post by Nahuel »

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.
Spike
Posts: 2914
Joined: Fri Nov 05, 2004 3:12 am
Location: UK
Contact:

Re: big enemies physics problems

Post by Spike »

I believe that shpuld's various 2-day mods tend to use movetype_walk for monsters.
toneddu2000
Posts: 1395
Joined: Tue Feb 24, 2009 4:39 pm
Location: Italy

Re: big enemies physics problems

Post by toneddu2000 »

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
Post Reply