Suggestion: onPlayerShootPlayer

Started by EK.IceFlake, May 19, 2016, 03:41 AM

Previous topic - Next topic

EK.IceFlake

int onPlayerShootPlayer(hinstance player, hinstance shot, int weapon)
return 1 - shot accepted
return 0 - shot rejected
Can you do something like this? I'll appreciate it (and probably many more people) :)

karan20000000000

The event is already available on the client side:
Player::PlayerShoot(player, weapon, hitEntity, hitPosition)
Parameter types: Player, int, entity, Vector. Return type: void.
Called when a player makes a shot. If something was hit, hitEntity points to that and hitPosition is the position of the collision. Otherwise, hitEntity is null and hitPosition is the end of the bullet trajectory.
With regards,
KP
------------------------------------------

.

You can't add this on the server side because... LAG! And to have this functionality on top of the average vcmp latency, would be crazy.
.

vito

Quote from: . on May 19, 2016, 09:47 AMYou can't add this on the server side because... LAG! And to have this functionality on top of the average vcmp latency, would be crazy.
Possible to make OnPlayerGetHurt for clientside. But I don't intresting about it anyway.

DizzasTeR

Default callbacks and methods are more important to be added in clientside first. You don't want to run a timer which sends all player's ping to client side just because we want to draw it on screen. ( Since textdraws are removed, we can only use gui labels and there is no player.Ping client sided )

Mötley

This should be a client side request, LU has a Similar code


[LU]
function onClientShot( player, weapon, bodypart )
{
// Get the local player
local player = FindLocalPlayer();
if(player)
{
// Check if they're called "Bob"
local name = player.Name;
if(name == "Bob")
{
// Cancel the damage
return 0;
}
}
}

KAKAN

Quote from: Doom_Kill3R on May 19, 2016, 12:50 PMDefault callbacks and methods are more important to be added in clientside first. You don't want to run a timer which sends all player's ping to client side just because we want to draw it on screen. ( Since textdraws are removed, we can only use gui labels and there is no player.Ping client sided )
And the streams are mind-eater. I can send a stream from a nodejs server instead from the VCMP client :P
Also, I want to make a system for a speedometer, but streams ah! Then there would be no difference between server-side and client-side.
oh no

Stormeus

Quote from: Mötley on May 19, 2016, 01:38 PMThis should be a client side request, LU has a Similar code

After seeing what happened with LU's client-side scripts, I don't trust the community here to not somehow weaponize client events to make hacks. I really don't want to add events to the client that allow them to just cancel out damage done to them.

vito

Quote from: Stormeus on May 19, 2016, 05:13 PM
Quote from: Mötley on May 19, 2016, 01:38 PMThis should be a client side request, LU has a Similar code

After seeing what happened with LU's client-side scripts, I don't trust the community here to not somehow weaponize client events to make hacks. I really don't want to add events to the client that allow them to just cancel out damage done to them.
It's overflow care, easier just to use hp hax. We need alot of stuff at client side at last for readonly (and we want attach to objects/cars ;))

EK.IceFlake

Quote from: Stormeus on May 19, 2016, 05:13 PM
Quote from: Mötley on May 19, 2016, 01:38 PMThis should be a client side request, LU has a Similar code

After seeing what happened with LU's client-side scripts, I don't trust the community here to not somehow weaponize client events to make hacks. I really don't want to add events to the client that allow them to just cancel out damage done to them.
You know we all could much more easier use cheat engine for infiny-hack-hax? Tested.

Mötley

I don't think anyone here but 2 people know how to do that.

My laughing point would be those who inject lua scripts into the games engine process. But that's something I will laugh at for the rest of the day today and tomorrow. As I don't think it would work unless you're a pro with no life..

Okay question though how connected are client scripts to non client example

Doing dofile to another script to keep everything attracted. I'm sure you understand where I'm going. LU is not really attracted except callserver functions which I hated compaired to its connected.
Another example lu
onClientRequest spawn.
Vcmp it's not in client and extremely easy to work with... some functions should stay server side as you said..

.

#11
Quote from: Mötley on May 19, 2016, 07:27 PMI don't think anyone here but 2 people know how to do that.

The only guys I can think of are @ext-d.CrystalBlue and @Finch Real . They're the only PROs I know who could achieve such task.

Said no one ever.
.

NewK

Quote from: Stormeus on May 19, 2016, 05:13 PM
Quote from: Mötley on May 19, 2016, 01:38 PMThis should be a client side request, LU has a Similar code

After seeing what happened with LU's client-side scripts, I don't trust the community here to not somehow weaponize client events to make hacks. I really don't want to add events to the client that allow them to just cancel out damage done to them.
That's a very valid concern. In general, I also believe that to some degree it's also the scripters' responsibility to use the client-side events responsibly. I agree that not all events should be client-side, that would be crazy, there's obviously some information that clients should just not have any access to, but when looking at LU's list of client side events here, it seems like a reasonable list of events to expose to the client. I only hope we can have something close to that one day.

It's a whole new world for VCMP scripters now that we have client side scripts, but it's also a really big responsibility for the scripters, and lets face it, some will inevitably fail to understand how to use it responsibly, and some script exploits will happen in those cases, but please don't inhibit new functionalities/events because of this, it's the scripters' responsibility to use these events responsibly and always do some server side validation. This makes sense to me if we compare this with how websites work. For instance, javascript's client side browser events have always existed, but any competent web dev knows better than to bind those events to critical server-side actions without atleast doing some sort of server side validation first. While a website is obviously not a game server, this logic still makes sense from my point of view. I trust your judgement to decide on what should be client-sided but please also take into account that vcmp scripters now have a much bigger role on server security and on preventing these "exploits" from happening.

DizzasTeR

So basically the logic here is that cuz of a few retards, we will have to suffer and not get the complete benefits of 'client-side' scripting cuz they will screw things up? K.

.

Quote from: Doom_Kill3R on May 20, 2016, 02:15 AMSo basically the logic here is that cuz of a few retards, we will have to suffer and not get the complete benefits of 'client-side' scripting cuz they will screw things up? K.

Isn't it funny how no one can name their children "Hitler"? And why? Because of one retard.
Isn't it funny how no one can spell the word ISIS in public anymore without someone calling 911? And why? Because of some retards.

That's just how the world works. You either get used to it or die trying :D
.