Wire: Add PlayerEnteredVehicle and PlayerLeaveVehicle hook/event functions

[CaptainPRICE]

I have a way to work-around (E2 hook implementation) for these two hooks, but it requires E2 to run every tick (it is such CPU waste). Honestly, it would perform much better if this were builtin functionality..
I am talking about:
GM:PlayerEnteredVehicle
GM:PlayerLeaveVehicle

Add new E2 hook/event functions:
runOnPlayerEnteredVehicle(number): If set to 1, the E2 chip will run when a player enters a vehicle.
runOnPlayerLeaveVehicle(number): If set to 1, the E2 chip will run when a player leaves a vehicle.
Optionally, provide these two overloads to only run for specified Vehicle entity:
runOnPlayerEnteredVehicle(entity, number): If set to 1, the E2 chip will run when a player enters the specified vehicle.
runOnPlayerLeaveVehicle(entity, number): If set to 1, the E2 chip will run when a player leaves the specified vehicle.

And then add a few more E2 functions to be able to get the information from the hook/event:
number=playerEnteredVehicleClk(): Returns whether the execution was run because of "runOnPlayerEnteredVehicle".
number=playerLeaveVehicleClk(): Returns whether the execution was run because of "runOnPlayerLeaveVehicle".
entity=lastPlayerEnteredVehicle(): Returns the last player who entered vehicle.
entity=lastEnteredVehicle(): Returns the last vehicle the player entered.
entity=lastPlayerLeaveVehicle(): Returns the last player who left a vehicle.
entity=lastLeaveVehicle(): Returns the last vehicle the player left.

React to this issue:
Vote 👍 to support; otherwise 👎

edited (twice; READ IT):
Please vote wisely, and think twice:

1. Do you really want E2s to run every tick on your server just to be able to work with those events?
2. Do you really want E2s to depend on Pod Controller (which require you to give PP access before it can be linked to your vehicle), just to be able to work with those events?

If your answer is "no" (negative) to either of the questions (you are expected to vote 👍); otherwise, we count on you as 👎. Also, if you are not supporting this, it means you are promoting/encouraging bad/inefficient E2 code.
Read the comments below!
So, I myself support this for several obvious reasons.
Later, I may opensource the E2 (runOnTick) implementation so you can try it yourself..

I am working on this. Expect PR soon.

[TomyLobo]

pod controller has an output for this, you can tick chips on input changes
use some wires dammit.
👎

[CaptainPRICE]

@TomyLobo Yeah, correct. But - The thing is, I don't want E2s to depend on Pod Controller (it also adds to the time for setup/installation: spawn pod, link it, wire it, gosh...), so there a lot of scenarios/cases where I want E2s to work completely independently.

[CaptainPRICE]

Oh it already hit 8 support-votes. Those who don't support this addition to E2, let us hear your arguments please.

I'll work on this, expect the PR soon.

[CaptainPRICE]

pod controller has an output for this, you can tick chips on input changes
use some wires dammit.

Also, your argument just doesn't fit there. Let me point out an example: What if I can't use Pod Controller because of prop-protection, you should know that linking pod controller to someone's vehicle requires PP access.
As you could probably think of this, do you want to give PP to someone just so they can link Pod Controller to your vehicle? (😆 LOL...)
@TomyLobo So yeah, thanks for increasing my arguments here, now I have two. You may want to correct your vote into +1.

---

Still waiting for a good "not support" reason, let me hear your arguments; referring to people who voted -1.
So far I didn't hear any good reason for "not supporting this". :)

[oldmud0]

do you want to give PP to someone just so they can link Pod Controller to your vehicle?

If I have to, then I will. Nobody should be linking anything to my vehicle without permission.

The approach being taken here is too aggressive. How many of those people who you asked to vote +1 actually considered the technical implications of adding this, as opposed to simply clicking on a link on Discord? A developer's opinion has significantly more weight and consideration than that of a user, you know. You can't just say, "but 8 is greater than 4!" and cry tyranny because "majority rule" is not being followed.

If you would like to have your ideas seriously considered, then my suggestion is to lighten your tone and speak in a more formal, propositional manner, as opposed to making it sound like a call to arms every time a feature you would like is not available. It is nothing personal; just adhere to general guidelines and maintain a level of sanity and respect. Thank you.

[CaptainPRICE]

If I have to, then I will. Nobody should be linking anything to my vehicle without permission.

Really? Wow a bad one. With now-a-days shitty prop-protection in most build servers, I don't think you would..

If you would like to have your ideas seriously considered, then my suggestion is to lighten your tone and speak in a more formal, propositional manner, as opposed to making it sound like a call to arms every time a feature you would like is not available. It is nothing personal; just adhere to general guidelines and maintain a level of sanity and respect. Thank you.

Fine - Okay then, please let me tell you an example to the previous statement to what you have just said:
Lets say you do give PP to random guys, it means they could use tools like advdupe (i.e. area copy your contraption without your knowledge) and even upload/download to/from your E2s (i.e. "remoteupload" extension), and practically use any tool on any of your entities... But to make it all even worse: After that, you find that your random friend disconnects right away from the server (since he/she had just stolen some of your stuff), because as I have said, thanks to shitty prop-protections (yeah "Nadmod" is being one of them; just to name one of them), now when a player is gone you can't even "unfriend" the random guy.
And there you have it - you lost, it smells to frustration to me. Do you expect your random guy to ever come back and play on the same server you do? If he/she is any smart, he/she would be using a temporary Steam account too (Steam ID is unique to each Steam account, so even if you find the random guy Steam ID, it won't have any value), haa-haaa, meaning you are completely screwed!
Without going any further, I will just stop here, because you are obviously and clearly not on the "bright" side here. Hopefully that "lightens" you now :)

edit:

The approach being taken here is too aggressive. How many of those people who you asked to vote +1 actually considered the technical implications of adding this, as opposed to simply clicking on a link on Discord? A developer's opinion has significantly more weight and consideration than that of a user, you know. You can't just say, "but 8 is greater than 4!" and cry tyranny because "majority rule" is not being followed.

Also, I do the same here, and stand behind my words, just like @Divran have said it himself:

I'm basing my arguments here from what other people tell me, and forming a compromise, not from what I think.

edit 2:
Ha-ha.. But also, what happened to "encouraging bad code" reason too? (I have updated OP description, read it.)
If you are not supporting this, it means you encourage bad/inefficient E2 code.
I have three arguments now. While the opposing "no-support" side have (barely) 1 argument, assuming that "use Pod Controller" reason counts as one...
And finally if we also take votes into an account, so far, there are no doubts for it to not be implemented/merged.
I am working on it, expect the PR soon.

[adosikas]

Its funny how you are always completely dismissive of opposing viewpoints, while pushing your arguments as infallible. All in a constantly passive agressive and derogatary tone. At least you are not straight up insulting people in this thread (yet).

You may want to correct your vote into +1.

Without going any further, I will just stop here, because you are obviously and clearly not on the "bright" side here. Hopefully that "lightens" you now :)

If you are not supporting this, it means you encourage bad/inefficient E2 code.

---

I am against this, as you can (as already mentioned) already wire the pod controller or - if you are not using a pod controller for whatever reason - just a if(changed(Pod:driver())){}.
I fail to see why a <20 ops statement would be bad code or even make a noticable difference in actual projects.

I think E2 is already way more complex than it was ever designed to be, no need to bloat it with more functions of fringe use (this seems to apply to almost all issues and PRs created by you).

[Divran]

if you are not using a pod controller for whatever reason - just a if(changed(Pod:driver())){}.

Yes, but the lowest ops count might be runOnKeys(Player,1) followed by checking if they pressed "E", followed by a short timer to give the source engine time to insert them into the vehicle, followed by a check to see if they are sitting in the vehicle you want. That way, there's no runOnTick or interval to check the driver constantly.

[CaptainPRICE]

@Divran So, you want to join the "no-support" team, with adosikas and 👎 company, okay cool (but so far they are losing, no good arguments on their side). Let me continue this topic then:

Yes, but the lowest ops count might be runOnKeys(Player,1) followed by checking if they pressed "E", followed by a short timer to give the source engine time to insert them into the vehicle, followed by a check to see if they are sitting in the vehicle you want.

Would consider that a bad "hack". Oh, bad one, are you wondering why I said "bad"? No problem, let me lighten you to what you have just said:

1. Completely didn't consider custom key binds: Not everyone have their +use command bound to the default - E key.
2. Completely didn't consider addons: Players can enter a vehicle via context menu and clicking "Enter Vehicle" (Rubat's addon provides this functionality, it uses net messages which can be send via clientside GLua from any distance).
3. Completely didn't consider Wire User entity (... LOL, gotcha! 😆).
4. I forgot what I wanted to say here, but whatever, I have already pointed out 3 valid arguments against using the "runOnKeys" E2 implementation for this type of events.

In short: What you have described will most likely produce the unexpected behavior - I know that. I have already tried it via "runOnKeys" way, and it just doesn't work as good as "runOnTick" way.
So, I will repeat it, like I have already said:
The only _right way_ of doing it (within current E2 code) is to use runOnTick (or very short interval, or depend on Pod Controller as input) implementation. Loop through the vehicles "watch list", check if entity:driver() has changed and then fire the appropriate callback function.
Also, that's just a lot of "boilerplate" code too, seriously.
It is obvious that "no-support" is losing the battle here, just saying, but come on give some proper arguments for "no-support" finally. Think twice before posting your arguments.

Referring to the "no-support" team: Surrender the battle?

[RevoluPowered]

_I think this has gone too far, can someone please close and lock this issue; this is toxic and getting nobody anywhere._

Please stop, the core developers of WM have said no. It's not worth upsetting everyone over it, your protest was written down, and examined. That's enough.