Continous Use: Reimplemented

[TimGoll]

Fixes #1636

Due to the use rework, continuous use was broken. This PR fixes it by adding a timer that is called as long as the use key is pressed and the entity is close by.
Most of these changes are just code being moved into another function, the timer part is new though

[ZenBre4ker]

Not sure that all those actions were continously useable before my rework.
Spec, Bodysearch etc.

Also I'd normally have said, that those actions are triggered every frame. 0.1s seems a bit weird. But I am not sure how the timing was before, but it should probably be tickrate dependent. And every implementation of continuos use should do some deltaTime calcs to make sure the amount is tickrate independent.

[TimGoll]

Not sure that all those actions were continously useable before my rework.
Spec, Bodysearch etc.

Some of them are exited early, so are map entities withou continous use. I'm not sure how I could handle the rest, but I guess it is identical to how it was before? If you have any ideas, go ahead.

And yes, I could change to timer ot every tick (0 time) as well. I wasn't sure what the best interval here would be

[TimGoll]

@ZenBre4ker Judging by this:

https://github.com/ValveSoftware/source-sdk-2013/blob/master/sp/src/game/shared/baseplayer_shared.cpp#L161-L195

and this:

https://github.com/ValveSoftware/source-sdk-2013/blob/0d8dceea4310fde5706b3ce1c70609d72a38efdf/sp/src/game/shared/baseplayer_shared.cpp#L1275-L1399

I think it is safe to assume that it was handled every frame before.

Now I'm wondering if a 0 tick timer would be a good solution here. Or if I should handle it in the Think hook as well. ItemPreFrame is called in PreThink.

[ZenBre4ker]

0 tick timer should suffice. But I will take a look at the continuous use for the other interactions. Feel free to merge this if you tested it, as I wont promise to come up with an analysis early.

The following idea is meant as an enhancement and therefore should not be taken into consideration for this MR:

Im actually thinking about reverting it a little, so to return true on serverside use again.
On the server you allow use on clientside sent entities, but always prefer the server's view. If the client sees one, but the server doesnt, use the client one (our rework). If the server sees one, but the client doesnt, use the server ones (old behaviour). If both see different ones, we could prefer the server's view (old behaviour). This would at least help with entities the client can see, but the server has in another position and the other way round as well with the weird teleport button on waterworld or cars that dont behave well with our rework.

This would bring the old behavior back in most cases and only add the feature that the client can argue that there is an entity to use. To not double activate use, we could cache used ents to see if Use was triggered on the server already. It could be complicated though, therefore its just an idea.

[TimGoll]

I tested it and put it into today's release candidate. We will see what the feedback is

[ZenBre4ker]

Continuous use should be every tick and it should be tested on bodies, specs and all entities that are triggered in the timer. Then I'd approve.

[ZenBre4ker]

Suggested change

	if self:IsWeapon() or self.player_ragdoll then
	return true
	elseif self:IsScripted() and self.CanUseKey then
	if self:IsWeapon() or self.player_ragdoll or (self:IsScripted() and self.CanUseKey) then

[ZenBre4ker]

Not sure anymore if the brackets are needed.

[TimGoll]

I split this into two because I thought it is more readable

[ZenBre4ker]

Should be 0 IMO

[TimGoll]

Agreed, but I have to test this to see if that works