I tested with default models on CS:S, so if there's a hitgroup 8, you're likely using another game and/or custom model. That line really isn't necessary, I only included it to show the name of the hitgroup (ie HEAD, LEFTARM, CHEST, etc..). I'll update my script for both of these errors.

velocity wrote:Is it possible to modify the hitboxes with this=?

The min/max are read/write, so I believe you might be able to. I'm honestly not sure how well it will work, but it's an idea.

Okay it actually works, but I have a problem it is only bullets that collide with the hitbox. I would like grenades to collide differently with the player, so I thought changing the hitbox would solve it. How would I proceed if grenades should work aswell? My theory is that the nades only collide with the bounding box, but i'm not sure.

velocity wrote:Nobody knows? Please tell if the issue is explained so it can be understood :/

Maybe you can accomplish what you want by parenting an entity to the player that has your desired dimensions/collision or maybe hook ontouch and push the grenade when it hits that entity or the player? (There are some caveats with that though, search the forums)

Doldol wrote:Maybe you can accomplish what you want by parenting an entity to the player that has your desired dimensions/collision or maybe hook ontouch and push the grenade when it hits that entity or the player? (There are some caveats with that though, search the forums)

Great idea Doldol! I kept trying to do this with virtual functions, but I think this should work:

# Is the entity that called OnStartTouch not a custom bounding box? # (specialised 'trigger_multiple') if caller.index not in bbox_triggers: return

# Is the entity that touched the 'trigger_multiple' not a projectile? # (hegrenade_projectile, flashbang_projectile, etc.) if 'projectile' not in activator.classname: return

player = player_instances[caller.parent.index] # Position of the player. player_pos = player.origin # Get the center / middle point of the player. player_pos.z += player.maxs.z / 2

# First pass at calculating the custom bounding box normal. # If you were to use this, it would act more like a cylinder and not a box. normal = activator.origin - player_pos normal.normalize() # Second and final pass at calculating the normal, this one should work. # Subtract the normalized projectile velocity from the normal to get # more pronounced values. Maybe I'm overthinking this? final_normal = get_box_normal(normal - activator.velocity.normalized())

def get_box_normal(normal): # If a projectile hits near the bottom of the custom bounding box, it # might freak out and go through the ground or the player. # Decrease the z axis of the normal to avoid this (mostly). normal.z *= 0.55 # Get the largest normal value to determine which side of the box got hit. primary_side = max(map(abs, normal))

# Go through all the normal axes. for axis, value in enumerate(normal): # Is this the side that got hit? # Subtracting 0.04 here allows for bouncing off of edges. if abs(value) >= primary_side - 0.04: normal[axis] = round(value) else: normal[axis] = 0

Look at a player and type custom_bbox in chat, they should now have a trigger_multiple on them that will act as their bounding box. You can do whatever you want with the projectile (and the player) inside the on_entity_output() function.

Last edited by VinciT on Fri Aug 17, 2018 7:36 pm, edited 3 times in total.

I don't think using a random model is a good idea because depending of the angles it will parent, you may end with the parented trigger being slightly off the player. I think the best approach would be to simply use the player's model and resize it how you want.

Don't forget that the size of a player is reduced when he is crouched so you might want to keep it updated to the size of the player at all time instead of using hard-coded vectors. And to make it compatible with other plugins, should also use dynamic size based on the scale of the player in case someone else is resizing them.

# Is the entity that called OnStartTouch not a 'trigger_multiple'? if caller.classname != 'trigger_multiple': return

I think you should rather stores the indexes and compare them to ensure that your code doesn't execute unless it was a trigger you created because in certain cases, this condition can pass without being by an entity you would expect (one present in the map, or created by another plugin for examples).

I completely forgot that crouching changes the bounding box! I've updated the plugin in my previous post based on a couple of your points.When it comes to the model, isn't it irrelevant what the model itself is? The trigger_multiple is a brush entity, so the model shouldn't matter, right?I'm not 100% sure on this, which is why I took your advice and changed it to use the player model.

L'In20Cible wrote:should also use dynamic size based on the scale of the player in case someone else is resizing them.

Velocity mentioned he needed this for CS:GO. Sadly, m_flModelScale doesn't work in CS:GO like it does in other Source games, so I left the mins and maxs hardcoded for now.

VinciT wrote:When it comes to the model, isn't it irrelevant what the model itself is? The trigger_multiple is a brush entity, so the model shouldn't matter, right?I'm not 100% sure on this, which is why I took your advice and changed it to use the player model.

It is more than important. The model is the shape of your trigger. Take in example bombsites, they are brush entities (you can use their model on other entities using *x or x* I don't remember if the asterisk is prefixed or suffixed -- been years last time I played with that, where x is their pre-cached index) and they will trigger in different shape and not a flat box. Same concept applies to any brush entities you are creating, for example a func_precipitation needs to be set to the current bsp file if you want it to be rendered on the entire map, or you can use any model and it will render the precipitation only in that shape, etc.

VinciT wrote:Velocity mentioned he needed this for CS:GO. Sadly, m_flModelScale doesn't work in CS:GO like it does in other Source games, so I left the mins and maxs hardcoded for now.

I still think you should use player.mins and player.maxs instead of hard-coding vectors if only to support custom models that might be set by other plugins.

L'In20Cible wrote:It is more than important. The model is the shape of your trigger. Take in example bombsites, they are brush entities (you can use their model on other entities using *x or x* I don't remember if the asterisk is prefixed or suffixed -- been years last time I played with that, where x is their pre-cached index) and they will trigger in different shape and not a flat box. Same concept applies to any brush entities you are creating, for example a func_precipitation needs to be set to the current bsp file if you want it to be rendered on the entire map, or you can use any model and it will render the precipitation only in that shape, etc.

I just thought that because we're using SolidType.BBOX and setting the mins and maxs directly, that the shape of the model doesn't matter. Thanks for the insight, L'In20Cible.

velocity wrote:So I tested it but the grenades doesn't collide with it before I change the trigger solid flags to USE_TRIGGER_BOUNDS, but then they player is stuck in place :/

That's because the plugin doesn't do anything other than give you access to the projectile that touched a player's custom bounding box and the instance of the player whose custom bounding box was touched. Until now, that is.

I've updated the plugin to make sure the mins and maxs of the trigger_multiple are dynamically adjusted and I've added basic collision.