Added CBaseCombatCharacter::IsInFieldOfView data for CSGO.

[vinci6k]

As promised: https://forums.sourcepython.com/viewtopic.php?f=7&t=1866#p13834

I wanted to add the data for other games as well, but after testing the virtual function in HL2DM and CSS, I gave up. The function always returns True, even when it shouldn't.

I'll see if the other CBaseCombatCharacter::IsInFieldOfView() function that takes an entity as an argument instead of a vector works in those games.

If it does work, how should I handle different virtual functions that have the same name? Do I just change the name of the function in the data file? (is_in_field_of_view and is_in_field_of_view_vec)
Or is there some form of overloading we can do?

[jordanbriere]

I wanted to add the data for other games as well, but after testing the virtual function in HL2DM and CSS, I gave up. The function always returns True, even when it shouldn't.

I'll see if the other CBaseCombatCharacter::IsInFieldOfView() function that takes an entity as an argument instead of a vector works in those games.

While having them wrap the functions is generally better (because it enable them to be used with Entity[Pre/Post]Hook, etc.), perhaps we could simply mimic what it internally does for those games. I thought it was doing more tracing and bounding checks but it doesn't sound too hard to reproduce.

If it does work, how should I handle different virtual functions that have the same name? Do I just change the name of the function in the data file? (is_in_field_of_view and is_in_field_of_view_vec)
Or is there some form of overloading we can do?

There is no overloading support and naming them explicitly is the best we can do. The problem with overloading in Python in general is that you have to add a dispatcher that evaluates the types before forwarding which add extra calls and is not that great for an interpreted language. The type manager would also not know which one to pick, because it doesn't see past native types and would see both calls as pointers. Perhaps is_in_field_of_view for the basic Vector and is_entity_in_field_of_view for the entity variation could do the trick.

That said, the wrap_entity_mem_func wrapper is not needed here. That decorator is used to set default values to some arguments and keywords, mainly when the prototypes aren't consistent across all games or to make arguments optional. For example, Player.give_named_item all have different prototypes, so they are internally wrapped with default keywords to make pl.give_named_item('classname') uniform across all games/engines without removing flexibility for the games that support more parameters.

It would be useful here if we wanted, for example, to support pl.is_in_field_of_view() and pl.is_in_field_of_view(vec) calls. In such case a wrapper would be used with a default value for the target, for example, a NULL_VECTOR:

@wrap_entity_mem_func
def is_in_field_of_view(self, target=NULL_VECTOR):

But since it just forward the target as is without default value assigned the wrapper is redundant and can be removed.

[vinci6k]

While having them wrap the functions is generally better (because it enable them to be used with Entity[Pre/Post]Hook, etc.), perhaps we could simply mimic what it internally does for those games. I thought it was doing more tracing and bounding checks but it doesn't sound too hard to reproduce.

While looking for a way to check if players could see where the point_worldtext would spawn for my plugin, my main concern was performance, which is why I settled for this virtual function. And you're pretty much spot on about it not being too hard to reproduce:

if ( pPlayer )
	return IsLookingTowards( pos, cos( (float)pPlayer->GetFOV() * 0.5f ) );

bool CBaseCombatCharacter::IsLookingTowards( const Vector &target, float cosTolerance ) const
{
	Vector toTarget = target - EyePosition();
	toTarget.NormalizeInPlace();

	Vector forward;
	AngleVectors( EyeAngles(), &forward );

	return ( DotProduct( forward, toTarget ) >= cosTolerance );
}

I just wanted to make the engine do all the work. 😄

There is no overloading support and naming them explicitly is the best we can do. The problem with overloading in Python in general is that you have to add a dispatcher that evaluates the types before forwarding which add extra calls and is not that great for an interpreted language. The type manager would also not know which one to pick, because it doesn't see past native types and would see both calls as pointers. Perhaps is_in_field_of_view for the basic Vector and is_entity_in_field_of_view for the entity variation could do the trick.

Alright, if I do add the other function, I'll keep this in mind.

It would be useful here if we wanted, for example, to support pl.is_in_field_of_view() and pl.is_in_field_of_view(vec) calls. In such case a wrapper would be used with a default value for the target, for example, a NULL_VECTOR:

@wrap_entity_mem_func
def is_in_field_of_view(self, target=NULL_VECTOR):

But since it just forward the target as is without default value assigned the wrapper is redundant and can be removed.

Ooooh, so that's how the wrapper works! Thanks for the quick lesson. I'll remove the wrapped function right away.

I really want to find out why the function isn't working in the other two games, it's bugging me to no end. Guess I could try calling CBaseCombatCharacter::IsLookingTowards() and seeing if that one works.