Anti prop kill script not working

[FPtje]

[QUOTE=Lerpaderp;39863477]It does, but why would it matter? It would only take a few seconds to add !ply:IsAdmin() in there.[/QUOTE]
It's usually the scripts that don't apply to admins that cause a lot of trouble. It's like Assmod's anti spam in 2007. The way it worked was [i]really[/i] annoying, but admins told people that it wasn't that bad. The admins never had to worry about antispam because it didn't apply to them.

If I were you I'd only remove DMG_Crush. With the no-colliding people will get other people stuck by freezing a prop inside them.

[MIKEYMASTALSKi]

[QUOTE=FPtje;39864328]It's usually the scripts that don't apply to admins that cause a lot of trouble. It's like Assmod's anti spam in 2007. The way it worked was [i]really[/i] annoying, but admins told people that it wasn't that bad. The admins never had to worry about antispam because it didn't apply to them.

If I were you I'd only remove DMG_Crush. With the no-colliding people will get other people stuck by freezing a prop inside them.[/QUOTE]

[lua]for k,v in pairs(ents.FindInSphere(ent:GetPos(), 50) do
if v:IsValid() and v:GetClass()=="prop_physics" then v:Remove()
end
end[/lua]

Tada.

[>>oubliet]

I may have slightly over done it and the code isn't tested so it may not work (typos, wrong arguments, etc) so this more of a code explanation of what I had in mind :

[lua]
local propClasses = {
["prop_physics"] = true
};

/*

'retal' is the action that is taken on the player or players found
to be responisble or involved in a prop-kill. retal can be any of the following :

"alert" - Alert's all Admins (Player.IsAdmin) and the console that a incident took place.
"kick" - Kicks the involded player(s).
"ban-AMOUNT OF TIME" - Bans the involved player(s) for "AMOUNT OF TIME" minutes
"slay" - Slay's the involved player(s)

'action' is the action that is taken to the player that was effected in the incident
this can be either 'allow' or 'deny', respectively allowing or denying the damage that
the player would of taken.

*/
local rules = {
["noBranch"] = {
action = "allow",
},
["multiplBranches"] = {
action = "deny",
retal = {"alert"}
},
["singleBranch"] = {
action = "deny",
retal = {"kick"}
},

["maxCycles"] = 50,
["minVelocity"] = 100
};

local function GetSumVev( vec ) return math.abs( vec.z ) + math.abs( vec.y ) + math.abs( vec.z ); end

hook.Add( "ShouldCollide", "CollisionDetection", function( e1, e2 )

if ( !e1 || !IsValid( e1 ) || !propClasses[ e1:GetClass() ] ) then return; end
if ( !e2 || !IsValid( e2 ) || !propClasses[ e2:GetClass() ] ) then return; end

// The prop that was the fastest was the prop that "collided" with the other.
if ( GetSumVev( e1:GetVelocity() ) > GetSumVev( e2:GetVelocity() ) ) then

e1.lastCollision = e2;

else

e2.lastCollision = e1;

end

end);

// Not sure about the arguments for this hook, wasn't documented on the wiki.
hook.Add( "PhysgunPickup", "LastTouchDetection", function( ply, ent )

if ( ent && IsValid( ent ) && propClasses[ ent:GetClass() ] ) then

ent.lastHolder = ply;

end

end);

hook.Add( "PlayerShouldTakeDamage", "PropKillDetection", function( ply, ent )

if ( !propClasses[ ent:GetClass ] || GetSumVev( ent:GetVelocity() ) < rules.minVelocity ) then return true; end

local tEnt = ent;
local players = {};

local trace = {};

for i = 0, rules.maxCycles do

trace[ #trace + 1 ] = {};
trace[ #trace ].ent = tEnt:GetClass() .. " => " .. tEnt:GetModel();

if ( tEnt.lastHolder && tEnt.lastHolder && tEnt.lastHolder:IsPlayer() ) then

players[ tEnt.lastHolder ] = true;
trace[ #trace ].lastHolder = tEnt.lastHolder:SteamID() .. " => " .. tEnt.lastHolder:GetName();

else

trace[ #trace ].lastHolder = "none";

end

if ( tEnt:GetOwner() && IsValid( tEnt:GetOwner() ) && tEnt:GetOwner():IsPlayer() ) then

trace[ #trace ].owner = tEnt:GetOwner():SteamID() .. " => " .. tEnt:GetOwner():GetName();

else

trace[ #trace ].owner = "none";

end

if ( tEnt.lastCollision && IsValid( tEnt.lastCollision ) && propClasses[ tEnt.lastCollision:GetClass() ] ) then

tEnt = tEnt.lastCollision;
trace[ #trace ].collison = tEnt.lastCollision:GetClass() .. " => " .. tEnt.lastCollision:GetModel();

else

trace[ #trace ].collison = "none";
break;

end

end

local ruleBranch = table.Count( players ) == 1 and "singleBranch" or ( table.Count( players ) > 1 and "multiplBranches" or "noBranch" );

local ruleSet = rules[ ruleBranch ];

local reportPlayers = false;

if ( ruleBranch != "noBranch" ) then

for ply, _ in pairs( players ) do

for _, rule in pairs( ruleSet.retal ) do

if ( rule == "alert" ) then

reportPlayers = true;

elseif ( rule == "kick" ) then

ply:Kick( "Illegal Prop kill detected!" );

elseif ( string.Left( rule, 3 ) == "ban" ) then

ply:Ban( tonumber( string.Explode( "-", rule )[2] ), "Illegal prop kill detected!" );

elseif ( rule == "slay" ) then

ply:Kill();
ply:ChatPrint( "You were slayed as you were involved in a prop kill that violated the rules." );

end

end

end

local alertString = string.format([[
[APK] %s was hit by a %s ( model = %s, owner = %s). %s Players were found to be involved.
Prop trace :
]], ply:GetName(), ent:GetClass(), ent:GetModel(), ent:GetOwner():GetName(), table.Count( players ) );

for k, data in pairs( trace ) do

alertString = alertString .. k .. " : \n\n Entity : " .. data.ent .. "\nLast Holder : " .. data.lastHolder .. "\nOwner : " .. data.owner .. "\n" .. "\nLast Collision : " .. data.colision .. "\n";

end

Msg(alertString);

if ( reportPlayers ) then

for _, ply in pairs( player.GetAll() ) do

if ( ply:IsAdmin() ) then

ply:ChatPrint( alertString );

end

end

end

end

return ruleSet.action == "allow";

end);
[/lua]

The main thing this is meant to do is give information on what exactly happened, the Admins can figure it out from there. If it was a simple case of throw a prop at someone automatic action can be taken.

[FPtje]

Any action the script performs has a chance of punishing the wrong player, it does not always find the prop killer and sometimes it doesn't print the prop killer while it compiles a whole list of other people.
your script is slow and can't be more wrong. ShouldCollide is called even when two entities never collide.

I told you to check your script against my evidence. The evidence holds and therefore your script is damn useless.

[Zyler]

How about something like this?:

[video=youtube;poQmsHvOypc]http://www.youtube.com/watch?v=poQmsHvOypc[/video]

It's from a gamemode I'm working on.

[&gt;&gt;oubliet]

[QUOTE=FPtje;39868848]Any action the script performs has a chance of punishing the wrong player, it does not always find the prop killer and sometimes it doesn't print the prop killer while it compiles a whole list of other people.
your script is slow and can't be more wrong. ShouldCollide is called even when two entities never collide.

I told you to check your script against my evidence. The evidence holds and therefore your script is damn useless.[/QUOTE]

Can you explain or list things that this script will fail to do the right thing on? And fair enough, I didn't know the hook got called all the time, I'll simply detour the Entity.PhysicsCollide function when the entity is created.

I know there's a lot of looping there, but it's not looping huge tables or anything, so it shouldn't be that slow, I'll do some time tests in a minute.

[DaneSomdahl]

[QUOTE=Zyler;39868939]How about something like this?:

[video=youtube;poQmsHvOypc]http://www.youtube.com/watch?v=poQmsHvOypc[/video]

It's from a gamemode I'm working on.[/QUOTE]

What if there's an AFK player and I just put the barrel realllly high up in the sky directly above him? :D

[FPtje]

[QUOTE=>>oubliette<<;39869360]Can you explain or list things that this script will fail to do the right thing on? And fair enough, I didn't know the hook got called all the time, I'll simply detour the Entity.PhysicsCollide function when the entity is created.

I know there's a lot of looping there, but it's not looping huge tables or anything, so it shouldn't be that slow, I'll do some time tests in a minute.[/QUOTE]

I explained it before you even posted your script. Read my proof and apply the situation on your script. Specifically, try the one where Prop Y has a lower velocity than prop X.

- you can prop kill without being in the list
- you can have the script point at other players as the prop killer

what if someone picks up someone else's prop with the gravgun and drops it on a player from a roof?
What if someone pushes props with a wire forcer?
What if they use E2 to move a prop?
What if they use any other means of moving a prop?

With all above cases, the prop killer won't get any blame and someone else will. Your script is full of bugs, not just in implementation, but in the concept of your script.

[&gt;&gt;oubliet]

[QUOTE=FPtje;39873326]I explained it before you even posted your script. Read my proof and apply the situation on your script. Specifically, try the one where Prop Y has a lower velocity than prop X.

- you can prop kill without being in the list
- you can have the script point at other players as the prop killer

what if someone picks up someone else's prop with the gravgun and drops it on a player from a roof?
What if someone pushes props with a wire forcer?
What if they use E2 to move a prop?
What if they use any other means of moving a prop?

With all above cases, the prop killer won't get any blame and someone else will. Your script is full of bugs, not just in implementation, but in the concept of your script.[/QUOTE]
I can agree, the chances that someone will make a script that will stop every case of prop killing is damn [I]near[/I] impossible.

At the same time I can disagree, I could fairly easily if I put my mind to it make a script that will block the easiest and most commonly used forms of prop killing, making it too difficult for someone to bother.

I haven't looked into the gravity gun, but I'm sure there's a way I can detect when that's used to pick up a prop.

I have changed my script, it now cycles up the path that had the most respective velocity to find the culprit. If this methods reports there is more than one player responsible, which is unlikely it will alert admins with every piece of information it found.

I have fixed the collision detection by overwriting the prop_physics entity with my own that will log the last entity and information about that entity to the entity on ENT.Touch. Other entities ENT.Touch function is detoured to include my code when it's created.

[Lexic]

And does your script detect the props that cause worldspawn to deal damage when they drop on you?

[FPtje]

[QUOTE=>>oubliette<<;39875894]I can agree, the chances that someone will make a script that will stop every case of prop killing is damn [highlight][I]near[/I][/highlight] impossible.[/QUOTE]
I have taken the burden of proof upon me and I have delivered.
It is [b]proven[/b] that it is [highlight]absolutely[/highlight] impossible to make a correct anti prop kill script with the given premises.

You don't seem to "believe" in impossibilities. I guess you would also say
- It is "nearly" impossible to have anything go faster than light
- It is "nearly" impossible to sum up all natural numbers within a life time
- it is "nearly" impossible to make a computer program that solves the god damn halting problem

Stop bothering with prevention scripts. Go and try to solve the [url=http://en.wikipedia.org/wiki/Halting_problem]halting problem[/url] instead if you really don't believe in the word "impossible".

If you really want to do something in the direction of anti prop kill scripts, [b]AT LEAST[/b] look in the realm of prevention scripts. Detection scripts are impossible.

Impossible means "not possible; unable to be, exist, happen, etc."
No matter what you do, no matter how hard you try, your script will always be incorrect and incomplete.

[&gt;&gt;oubliet]

[QUOTE=FPtje;39879592]I have taken the burden of proof upon me and I have delivered.
It is [b]proven[/b] that it is [highlight]absolutely[/highlight] impossible to make a correct anti prop kill script with the given premises.

You don't seem to "believe" in impossibilities. I guess you would also say
- It is "nearly" impossible to have anything go faster than light
- It is "nearly" impossible to sum up all natural numbers within a life time
- it is "nearly" impossible to make a computer program that solves the god damn halting problem

Stop bothering with prevention scripts. Go and try to solve the [url=http://en.wikipedia.org/wiki/Halting_problem]halting problem[/url] instead if you really don't believe in the word "impossible".

If you really want to do something in the direction of anti prop kill scripts, [b]AT LEAST[/b] look in the realm of prevention scripts. Detection scripts are impossible.

Impossible means "not possible; unable to be, exist, happen, etc."
No matter what you do, no matter how hard you try, your script will always be incorrect and incomplete.[/QUOTE]

I never said I don't believe in Impossibilities just that this isn't one of them. It can't be impossible to find the source of an energy and the player that created it. Just because that's outside of your knowledge and other's [B]doesn't [/B] mean it's impossible.

Things are impossible, 1 will never equal 3. Other things may seem impossible but they're not, for example it's incredibly likely that 1000 people named Bob that never knew each other went to a concert all wearing the same clothes.

Would you say anti-cheats are also impossible to code?

[SashaWolf]

Someone should start an antipropkill thread.

Also, if it is possible to tell what props have collided, then you could probably easily write a script that follows collisions up the tree until it finds the person who initially pushed the prop. Say you have several props sitting on the floor. The script detects the first collision, and flags the pushed prop as pushed until it stops moving. If it strikes another prop, you could make the script basically say "Hey! I'm only hitting you because Falco's prop bumped me". This could continue until the kill happens or until the props stop moving. I'm sure with a little bit of work I could make it. That would defeat your original "impossibility proof" or whatever you called it.

And yes, I am aware of other methods (worldspawn killing, button/gps/whatever killing, etc) but this idea would stop the main problem.

Also, I am not advocating antiban with this. If released, it should warn the admins to spectate X player because he may have propkilled someone.

[QUOTE=>>oubliette<<;39880050]I never said I don't believe in Impossibilities just that this isn't one of them. It can't be impossible to find the source of an energy and the player that created it. [B]Just because that's outside of your knowledge and other's doesn't mean it's impossible.[/B]

Things are impossible, 1 will never equal 3. Other things may seem impossible but they're not, for example it's incredibly likely that 1000 people named Bob that never knew each other went to a concert all wearing the same clothes.[/QUOTE]

Also, this is what I was trying to say above when I originally made fun of you.

[FPtje]

[QUOTE=>>oubliette<<;39880050]I never said I don't believe in Impossibilities just that this isn't one of them. It can't be impossible to find the source of an energy and the player that created it. Just because that's outside of your knowledge and other's [B]doesn't [/B] mean it's impossible. [/quote]

You don't seem to know how logic proofs work. My proof is eternal in the way that it does not depend on "my current knowledge" to succeed. Unless my evidence is incorrect, Alan Turing himself wouldn't be able to make an anti prop kill. Hell, the most advanced scientists wouldn't be able to make the script as long as they held to the premises.

really, the way my evidence is structured, is the usual way a lot of things are proven in computer science. Usually the proofs include statements from predicate logic and set theory, but I know people here don't want to see that stuff. And that's alright, but a proof in prose is also a proof.

Do I really have to formulate my proof to use set theory to make you understand what a proof of impossibility is?
Should I resort to stating a position of authority because I'm a computer science student?
Is there a way in which I can explain how evidence works in the scientific world?

edit:
if it helps any, the method I used for the evidence is reductio ad absurdum:
[url]http://en.wikipedia.org/wiki/Reductio_ad_absurdum[/url]

[editline]12th March 2013[/editline]

[QUOTE=SashaWolf;39880117]Someone should start an antipropkill thread.

Also, if it is possible to tell what props have collided, then you could probably easily write a script that follows collisions up the tree until it finds the person who initially pushed the prop. Say you have several props sitting on the floor. The script detects the first collision, and flags the pushed prop as pushed until it stops moving. If it strikes another prop, you could make the script basically say "Hey! I'm only hitting you because Falco's prop bumped me". This could continue until the kill happens or until the props stop moving. I'm sure with a little bit of work I could make it. That would defeat your original "impossibility proof" or whatever you called it.

[/quote]
take the first situation from my proof in which player A is the prop killer. Your script would point at Player B because he is the person who initially pushed the prop.

if you count the spawner of the prop as "initial pusher" until the prop stops moving, player A would be the initial pusher because he spawned prop X in midair which falls until it kills Player C. Then take situation 2 where Player B pushes prop X in the direction of player C. Player A will incorrectly get the blame.

[ash47]

IMO, as far as RP server goes, I think all props should either be:
i) Frozen, and fully collide against everything
ii) Unfrozen and collide with nothing else, except other frozen props, and the world (including doors etc)

Just my opinion, on Aussie servers, when people make 'moving contraptions', the servers lag really bad, so it's a waste anyways :P

[&gt;&gt;oubliet]

[QUOTE=FPtje;39884834]You don't seem to know how logic proofs work. My proof is eternal in the way that it does not depend on "my current knowledge" to succeed. Unless my evidence is incorrect, Alan Turing himself wouldn't be able to make an anti prop kill. Hell, the most advanced scientists wouldn't be able to make the script as long as they held to the premises.

really, the way my evidence is structured, is the usual way a lot of things are proven in computer science. Usually the proofs include statements from predicate logic and set theory, but I know people here don't want to see that stuff. And that's alright, but a proof in prose is also a proof.

Do I really have to formulate my proof to use set theory to make you understand what a proof of impossibility is?
Should I resort to stating a position of authority because I'm a computer science student?
Is there a way in which I can explain how evidence works in the scientific world?

edit:
if it helps any, the method I used for the evidence is reductio ad absurdum:
[url]http://en.wikipedia.org/wiki/Reductio_ad_absurdum[/url]

[editline]12th March 2013[/editline]

take the first situation from my proof in which player A is the prop killer. Your script would point at Player B because he is the person who initially pushed the prop.

if you count the spawner of the prop as "initial pusher" until the prop stops moving, player A would be the initial pusher because he spawned prop X in midair which falls until it kills Player C. Then take situation 2 where Player B pushes prop X in the direction of player C. Player A will incorrectly get the blame.[/QUOTE]

I see where you're coming from, your proof against my theory is a lost battle, but my theory still does what I want it to, find the most common and easily done methods of prop killing. I'm going to release it as a Addon as soon as I put it together.

Just because there's proof to support one theory doesn't mean the other is incorrect, take the flat-earth theory for example, I can look out my window and see a flat surface, does that mean the world IS flat and any other theory is absurd? I don't think so.

Stating your authority is pointless and stupid. How does you being a computer science student make you immediately better and your opinion worth more? Some colleges teach scratch for god sake.

I want to leave this argument as decently as possible, when I get my script together, you can mindlessly poke holes in it if it doesn't work, I'll shake your hand over the internet and submit to defeat.

[FPtje]

WARNING: My post is long. I took a long time to write it, WAY too long. It starts cynical, but it gets nicer towards the end. Heated discussions can piss me off at times, making me cynical. Sorry about that.

Except you don't have a theory. You have one script that is wrong in exactly the way I predicted it.
You haven't mentioned a single argument against my actual proof. The only thing you've done is declaring that you don't believe it.

I know I make very bold claims, but I have backed them up.
You want me to go on poking holes in your scripts, which I will do. I trust my evidence enough that I can throw Prop X and Players A to D in your face every time you update your script. Forever until you give up.

As a last attempt to teach you something about computer science, I'll make a sidestep to the halting problem.
The halting problem is a really typical computer science problem: Can you make a program that knows of other programs whether they will ever end?
In gmod Lua terms:
Can you make a Lua function that accurately knows whether another Lua function will ever stop running?
[lua]function doesStop(func)
...
if func stops then return true else return false end
end
[/lua]

Examples of this function:
[lua]print(doesStop(function() /*Do nothing*/ end))
> true
[/lua]

[lua]
print(doesStop(function() while(true) do /*infinite work*/ end end))
> false
[/lua]

Think of it, the problem doesn't seem that difficult at first, right? You read the source code and decide whether the program looks like it will stop, you return true if it does, false if it doesn't.

Well, as it turns out. The halting problem is [b]impossible[/b] to solve. Not now, not ever. Here's why (the evidence is simplified).
Assume this Lua function doesStop() exists.
Feed it this function:
[lua]function HAHA()
if doesStop(HAHA) then while(true) do /* NO I'M NOT GOING TO STOP HAHA*/ end
else /*You said I wouldn't stop, let's do nothing and stop!*/ end
end[/lua]

When doesStop() says the function will stop, it will loop forever, when it says it doesn't, it stops.

The halting problem was proven impossible to solve by Alan Turing, a computer scientist who is very famous for his work.

I love how similar the halting problem is to the prop kill detection problem. There's a proof of impossibility, but it's really hard to believe that it's [b]really[/b] impossible to solve. It looks like such an easy problem, which might be why I'm having a really hard time explaining it.

It's easily possible to make a Lua function that knows of [i]a lot[/i] of other functions whether they will stop or not. However, you can't make a Lua function that knows this about [b]all[/b] possible Lua functions. There will always be some input for which the halting problem solver will give a wrong answer.

Likewise
It's easily possible to make a Lua function that finds [b]many[/b] prop killers accurately. However, you can't make a Lua function that [b]always[/b] finds the prop killer accurately. There will always be a situation thinkable where it will give the wrong answer.

I hope you learned some computer science from this. I won't force my authority on you, you're right in saying that it doesn't mean I'm automatically right. It does mean that I know stuff about the subject, but I can make the best of efforts to explain it.
-----------------------------------------------------------------------

Hey, I'm in a nice mood today and I'll give you some credit. You [b]have[/b] found a way around my evidence. My evidence states that no [b]one[/b] answer can be accurately given. You don't give one answer, you give many. You don't make the eventual decision of who the prop killer is. Proving that an accurate script exists that [b]accurately[/b] identifies [i]everyone[/i] involved in a prop kill is fairly easy.

In computer science, we call this "trivial":
In any situation a prop kill occurs, print the names of everyone who has been on the server since it started. (including the ones who have disconnected, because what if someone disconnects before his props hits the victim?)

You might say, Falco, this script is worthless, what the fuck am I supposed to do with it? Well, oubliette, here's the fun bit: This simple evidence proves that it is impossible to construct an evidence that states that "it is impossible to make a script that accurately prints everyone involved". (Still follow me?)

So you [b]can[/b] make a correct script that prints [i]everyone[/i] involved.
[highlight]HOWEVER[/highlight]
Two objections:
1. You're going to have to be very careful. When someone is [b]NOT[/b] in the list of involved people, you'll have to be ABSOLUTELY certain that he is innocent. If he's on the other side of the level, he could be using a contraption with thrusters, if he never touched the prop, he might have only spawned it. There are [i]many, many, many[/i] situations you have to account for when you decide that a player REALLY is innocent.
2. If you print a list of people that are involved in the prop kill, my evidence still holds about the [b]one[/b] answer. Even an admin can't choose when he gets a list of Players A, B and C in his console.

But yeah I'll poke holes in the script until either you create a correct script (which hey, at least it's possible with your approach), or until either of us gives up.

[&gt;&gt;oubliet]

[QUOTE=FPtje;39886957]WARNING: My post is long. I took a long time to write it, WAY too long. It starts cynical, but it gets nicer towards the end. Heated discussions can piss me off at times, making me cynical. Sorry about that.

Except you don't have a theory. You have one script that is wrong in exactly the way I predicted it.
You haven't mentioned a single argument against my actual proof. The only thing you've done is declaring that you don't believe it.

I know I make very bold claims, but I have backed them up.
You want me to go on poking holes in your scripts, which I will do. I trust my evidence enough that I can throw Prop X and Players A to D in your face every time you update your script. Forever until you give up.

As a last attempt to teach you something about computer science, I'll make a sidestep to the halting problem.
The halting problem is a really typical computer science problem: Can you make a program that knows of other programs whether they will ever end?
In gmod Lua terms:
Can you make a Lua function that accurately knows whether another Lua function will ever stop running?
[lua]function doesStop(func)
...
if func stops then return true else return false end
end
[/lua]

Examples of this function:
[lua]print(doesStop(function() /*Do nothing*/ end))
> true
[/lua]

[lua]
print(doesStop(function() while(true) do /*infinite work*/ end end))
> false
[/lua]

Think of it, the problem doesn't seem that difficult at first, right? You read the source code and decide whether the program looks like it will stop, you return true if it does, false if it doesn't.

Well, as it turns out. The halting problem is [b]impossible[/b] to solve. Not now, not ever. Here's why (the evidence is simplified).
Assume this Lua function doesStop() exists.
Feed it this function:
[lua]function HAHA()
if doesStop(HAHA) then while(true) do /* NO I'M NOT GOING TO STOP HAHA*/ end
else /*You said I wouldn't stop, let's do nothing and stop!*/ end
end[/lua]

When doesStop() says the function will stop, it will loop forever, when it says it doesn't, it stops.

The halting problem was proven impossible to solve by Alan Turing, a computer scientist who is very famous for his work.

I love how similar the halting problem is to the prop kill detection problem. There's a proof of impossibility, but it's really hard to believe that it's [b]really[/b] impossible to solve. It looks like such an easy problem, which might be why I'm having a really hard time explaining it.

It's easily possible to make a Lua function that knows of [i]a lot[/i] of other functions whether they will stop or not. However, you can't make a Lua function that knows this about [b]all[/b] possible Lua functions. There will always be some input for which the halting problem solver will give a wrong answer.

Likewise
It's easily possible to make a Lua function that finds [b]many[/b] prop killers accurately. However, you can't make a Lua function that [b]always[/b] finds the prop killer accurately. There will always be a situation thinkable where it will give the wrong answer.

I hope you learned some computer science from this. I won't force my authority on you, you're right in saying that it doesn't mean I'm automatically right. It does mean that I know stuff about the subject, but I can make the best of efforts to explain it.
-----------------------------------------------------------------------

Hey, I'm in a nice mood today and I'll give you some credit. You [b]have[/b] found a way around my evidence. My evidence states that no [b]one[/b] answer can be accurately given. You don't give one answer, you give many. You don't make the eventual decision of who the prop killer is. Proving that an accurate script exists that [b]accurately[/b] identifies [i]everyone[/i] involved in a prop kill is fairly easy.

In computer science, we call this "trivial":
In any situation a prop kill occurs, print the names of everyone who has been on the server since it started. (including the ones who have disconnected, because what if someone disconnects before his props hits the victim?)

You might say, Falco, this script is worthless, what the fuck am I supposed to do with it? Well, oubliette, here's the fun bit: This simple evidence proves that it is impossible to construct an evidence that states that "it is impossible to make a script that accurately prints everyone involved". (Still follow me?)

So you [b]can[/b] make a correct script that prints [i]everyone[/i] involved.
[highlight]HOWEVER[/highlight]
Two objections:
1. You're going to have to be very careful. When someone is [b]NOT[/b] in the list of involved people, you'll have to be ABSOLUTELY certain that he is innocent. If he's on the other side of the level, he could be using a contraption with thrusters, if he never touched the prop, he might have only spawned it. There are [i]many, many, many[/i] situations you have to account for when you decide that a player REALLY is innocent.
2. If you print a list of people that are involved in the prop kill, my evidence still holds about the [b]one[/b] answer. Even an admin can't choose when he gets a list of Players A, B and C in his console.

But yeah I'll poke holes in the script until either you create a correct script (which hey, at least it's possible with your approach), or until either of us gives up.[/QUOTE]

The difference between the halting problem and this is that I can see why the halting problem is impossible to solve. I just don't see it with the prop killing scripts. I admit, you are right, not one of these scripts have worked but I don't see any recurring theory as to why. I don't see a "if you check if a player is doing x, then you won't be able to check if they're doing y and therefore it is impossible.".

I don't have the time to spend weeks comprehending all of the prop killing methods ever found, all I can do is come up with a effective work-around. Take your halting problem for example, it can be solved with this java program :

public class HaltingProblem extends Thread {

	private boolean hasStopped = false;

	private boolean condition = true;

	public HaltingProblem(){
		this.start();
	}

	@Override
	public void run(){

		while (condition){
			// whatever
		}

		hasStopped = true;

	}

	public boolean hasStopped(){
		return this.hasStopped;
	}

}

public class Main(){

	public static void main(){

		HaltingProblem hp = new HaltingProblem();

		if ( hp.hasStopped ){

			System.out.println("it has stopped.");

		}
		else {

			System.out.println("it hasn't stopped.");

		}

	}

}

I'll try and have my script done by tonight, if android decides to stop being a bitch.

[FPtje]

The idea of the halting problem is to always give an answer and to always give the right answer.

If you feed your program an infinite loop, it will simply not generate an answer. Therefore it doesn't solve the halting problem.

Surely Turing would have thought of your proposed solution. People in my class did come up with the solution you came up with. I remember it from last year :v:

[QUOTE=>>oubliette<<;39887171]I don't see a "if you check if a player is doing x, then you won't be able to check if they're doing y and therefore it is impossible.".[/QUOTE]
The reasoning for the proof is there for all to see:
[quote=I]Regardless of which player is the prop killer, in ALL three cases it looks exactly the same in Lua. the owners of the props are the same, the whole chain of entities [that touched] the prop killing prop X is the same.
Therefore, any script that would point at either player A OR player B OR player C OR player D has a chance > 0 of being wrong. [/quote]

God damn, there are a lot of grammar mistakes in my post. That must be because I write them in a hurry.

But you said you consider Turing's evidence valid, yet mine invalid. Surely then my evidence has errors, or it is missing something? What am I missing? What is wrong in my evidence?

[&gt;&gt;oubliet]

Well, here's my second attempt :

[lua]
apk = {};

apk.propClasses = {
["prop_physics"] = true
};

/*

'retal' is the action that is taken on the player or players found
to be responisble or involved in a prop-kill. retal can be any of the following :

"alert" - Alert's all Admins (Player.IsAdmin) and the console that a incident took place.
"kick" - Kicks the involded player(s).
"ban-AMOUNT OF TIME" - Bans the involved player(s) for "AMOUNT OF TIME" minutes
"slay" - Slay's the involved player(s)

'action' is the action that is taken to the player that was effected in the incident
this can be either 'allow' or 'deny', respectively allowing or denying the damage that
the player would of taken.

*/

apk.rules = {
["noBranch"] = {
action = "allow",
retal = {}
},
["singleBranch"] = {
action = "deny",
retal = {"slay","alert"}
},

["maxCycles"] = 50,
["minVelocity"] = 10
};

function apk.CalculateCombinedVelocity( ent )

local vV = ent:GetVelocity();
local aV = ent:GetLocalAngularVelocity(); // I'm presuming this function does what I want it to ..
local mA = math.abs; // I'm lazy

return mA( vV.x ) + mA( vV.y ) + mA( vV.z ) + mA( aV.p ) + mA( aV.y ) + mA( aV.r );

end

// Presumes entities are valid
function apk.DoCollision( e1, e2 )

e1.lastCollision = e2;
e2.lastCollision = e1;

e1.lastCVelocity = apk.CalculateCombinedVelocity( e2 );
e2.lastCVelocity = apk.CalculateCombinedVelocity( e1 );

end

hook.Add( "EntityCreated", "CollisionDetection", function( ent )

if ( ent && IsValid( ent ) && apk.propClasses[ ent ] && ent:GetClass() != "prop_physics" ) then

ent.Touch = apk.DoCollision;

end

end);

// Not sure about the arguments for this hook, wasn't documented on the wiki.
hook.Add( "PhysgunPickup", "LastTouchDetection", function( ply, ent )

if ( ent && IsValid( ent ) && apk.propClasses[ ent:GetClass() ] ) then

ent.lastHolder = ply;

end

end);

// I've never used this hook in my life.
hook.Add( "GravGunOnPickedUp", "LastTouchDetectionGG", function( ply, ent )

if ( ent && IsValid( ent ) && apk.propClasses[ ent:GetClass() ] ) then

ent.lastHolder = ply;

end

end);

hook.Add( "PlayerShouldTakeDamage", "PropKillDetection", function( ply, ent )

local tEnt = ent;
local oldEnt = ent;

local trace = { ent };

for i = 0, apk.rules.maxCycles do

if ( tEnt && IsValid( tEnt ) && apk.propClasses[ tEnt:GetClass() ] ) then

if ( tEnt.lastCollision && IsValid( tEnt.lastCollision ) && apk.propClasses[ tEnt.lastCollision:GetClass() ] ) then

if ( tEnt.lastCVelocity >= oldEnt.lastCVelocity ) then

trace[ #trace + 1 ] = tEnt;

oldEnt = tEnt;

tEnt = tEnt.lastCollision;

continue;

end

end

end

break;

end

local culprit;
if ( tEnt && IsValid( tEnt ) && apk.propClasses[ tEnt:GetClass() ] ) then

culprit = ( tEnt.lastHolder && IsValid( tEnt.lastHolder ) && tEnt.lastHolder:IsPlayer() ) and tEnt.lastHolder or tEnt:GetOwner();

if ( culprit == ply ) then culprit = nil; end

end

local ruleSet = apk.rules[ culprit and "singleBranch" or "noBranch" ];

if ( culprit && IsValid( culprit ) && culprit:IsPlayer() ) then

for _, rule in pairs( ruleSet.retal ) do

if ( rule == "slay" ) then

if ( culprit:Alive() ) then

culprit:Kill();
culprit:ChatPrint("[APK] You were slayed becauce of a prop-kill violation against " .. ply:GetName() );

end

elseif ( rule == "kick" ) then

culprit:Kick( "[APK] You were kicked becauce of a prop-kill violation against " .. ply:GetName() );

elseif ( string.Left( rule, 3 ) == "ban" ) then

culprit:Ban( tonumber( string.Explode( rule, "-" )[2] ), "[APK] You were banned becauce of a prop-kill violation against " .. ply:GetName() );

elseif ( rule == "alert" ) then

MsgN( ply:GetName() .. " => " .. ply:SteamID() .. "'s PK trace ( Suggested culprit = " .. culprit:GetName() .. " => " .. culprit:SteamID() .. ")");

for pn, ent in pairs( trace ) do

MsgN( "= = = = = Prop number " .. pn .. " = = = = =" );
MsgN("");
MsgN(" - Owner : " .. ( ( ent:GetOwner() and IsValid( ent:GetOwner() ) ) and ent:GetOwner():GetName() .. " => " .. ent:GetOwner():SteamID() or "none" ) );
MsgN(" - Last Collision : " ..( ( ent.lastCollision and IsValid( ent.lastCollision ) ) and tostring( ent.lastCollision ) or "none" ) );
MsgN(" - Last Collided Entity's Velocity : " .. ( ent.lastCVelocity and tostring( ent.lastCVelocity ) or "none" ) );
MsgN(" - Last Holder : " .. ( ( ent.lastHolder and IsValid( ent.lastHolder ) ) and ent.lastHolder:GetName() .. " => " .. ent.lastHolder:SteamID() or "none" ) );
MsgN("");

end

end

end

end

return ruleSet.action == "allow";

end);

MsgN("[APK] Loaded!");
[/lua]

You can't detour the ENT.Touch function for the prop_physics entity for some reason, so I've re-created the entity in the addon's entity folder. That code is not included above.

This program assumes :

* You can't pick up other props with a Physgun.
* You can't push props with the Gravity Cannon.
* You haven't modified to physics in a way that would make something colliding with something else end up with one entity having higher velocity then the first.
* Entity.GetOwner returns the player that placed the prop.

[FPtje]

1. player A spawns prop X on the roof of the map
2. prop X falls down
3. Player B is holding prop Y
4. Prop X hits prop Y in its fall (on purpose, making him the prop killer), however the velocity of prop Y is lower than that of prop X, since prop X is falling down and prop Y is just pushing in the right direction.
5. prop X lands on Player C with C =/= A

Player B is not in your list of involved people, yet he is the prop killer.

[&gt;&gt;oubliet]

The velocity is an absolute value, no matter which direction it's going it will always be a positive number.

[FPtje]

Here's another problem with your script: you're building a chain of touched entities, when it should actually be a tree.

Consider this situation:
Prop X owned by player A
prop Y owned by player B
Prop Z owned by player B
Victim C

Player A pushes prop Y with prop X.
Y.lastCollision = X
Player B sees what's going on, panics, and shoots prop Z at prop X to try to prevent the prop kill.
Y.lastCollision = Z
Prop Y prop kills Victim C.

Back goes the trace: first it prints Y, then it prints Z. Player B gets the full blame and player A, who actually prop killed, is not printed in console.

[editline]12th March 2013[/editline]

[QUOTE=>>oubliette<<;39889047]The velocity is an absolute value, no matter which direction it's going it will always be a positive number.[/QUOTE]

A velocity is never negative, you don't need to abs it. The velocity of prop Y is lower because prop X is falling down at the maximum falling speed and prop Y could even almost be held still by player B.
Your velocity calculation function is wrong anyway, use pythagoras, but that's not what I was criticizing.

I'm mostly criticizing your code as pseudocode. I care about the concept of your code, not so much the implementation.

[&gt;&gt;oubliet]

I could make a few changes to cater for this, is there anything else that you can think of that my script would fail on? (Assuming that the problem aforementioned was patched)

[editline]12th March 2013[/editline]

Didn't see the edit. The velocity function wasn't meant to return the actual velocity, just a number that I could use to test if one entity is moving [I]faster[/I] than the another.

[editline]12th March 2013[/editline]

I looked straight up and spawned a prop.

> print(player.GetAll()[1]:GetEyeTrace().Entity:GetVelocity())...
-0.000023 0.000040 -651.882813
Oubliette was killed by prop_physics

[FPtje]

Make the prop hit someone else's prop before it kills you from above.
It won't print that other person's prop.

Oh you're talking about the velocity?
The vector is negative, but its length isn't. Speed is measured by the length of that vector. ply:GetVelocity():Length()

[&gt;&gt;oubliet]

Does it need to?

[editline]12th March 2013[/editline]

Completely forgot about that, I suppose I should use that, it would cut all the abs calls.

[FPtje]

[QUOTE=>>oubliette<<;39890665]Does it need to?.[/QUOTE]

yes

[&gt;&gt;oubliet]

I'm not sure if this is what you meant by the first situation, but if player B used his prop to deflect A's prop into C, then my script would fail. And for this reason I give up.

I can't go any further without hindering my code's efficiency and structure.

You put up a good argument, *handshake*

[SashaWolf]

[QUOTE=FPtje;39884834]
take the first situation from my proof in which player A is the prop killer. Your script would point at Player B because he is the person who initially pushed the prop.

if you count the spawner of the prop as "initial pusher" until the prop stops moving, player A would be the initial pusher because he spawned prop X in midair which falls until it kills Player C. Then take situation 2 where Player B pushes prop X in the direction of player C. Player A will incorrectly get the blame.[/QUOTE]

[QUOTE=FPtje;39884834]
1. player A spawns prop X on the roof of the map
2.prop X falls down
3. Player B is holding prop Y
4. Prop X hits prop Y in its fall
5. prop X lands on Player C with C =/= A
[/QUOTE]
I find this example and a lot of your other ones kind of irrelevant in practice because some of them have a very small chance of being done arbitrarily. For the sake of disproving your "proof", however, Ill keep on trying to answer the situations you use to prove it.

Do note, however, that I think admins should check the logs and view the events that occurred in order to correctly assess who is at fault. Look at time the prop was spawned and compare it to time of initial collision, velocity gained after collision, maybe even log the last X seconds of every moving prop on the server's paths and make a script to play back the props' paths in the tree of the propkill event (or even all of them) on the admin's screen. EDIT: Emphasis on that last idea. That could solve a lot of problems.

Anyway, here is how such a system I would propose (that would obviously need to be refined while it is in development) could counter your problem.

1. Player A's prop X is registered as moving. It has not stopped moving nor has been physgunned or gravgunned or grabbed by a player, so it can be flagged as not having been interfered with by a player.
2. At this point the collision occurs. The first thing to check here would be whether or not the prop gains signifigant velocity off of the collision. I highly doubt anyone is thrusting props in a direction facing people or in a manner in which the prop is going to give something a lot of velocity, so you can safely say that if the prop gains a lot of velocity, then Player B was misusing props or irrisponsibly using props and should be watched by an admin to verify that he is in the server to cause trouble. Most serious propkillers are going to be repeat offenders, so their name should come up as being involved later. If you have a problem with assuming that the player giving the prop a lot more velocity is at fault, then you could always limit the prop speed (forgot the cvar) and not have to worry about it as much.

[QUOTE=FPtje;39889137]Here's another problem with your script: you're building a chain of touched entities, when it should actually be a tree.

Consider this situation:
Prop X owned by player A
prop Y owned by player B
Prop Z owned by player B
Victim C

Player A pushes prop Y with prop X.
Y.lastCollision = X
Player B sees what's going on, panics, and shoots prop Z at prop X to try to prevent the prop kill.
Y.lastCollision = Z
Prop Y prop kills Victim C.
[/QUOTE]

Firstly, if I didn't say tree back in my original idea, that is what I meant.

Even though the intent of the player was to prevent being propkilled, he still DID propkill someone by reflecting the prop (making him the cause of the propkill). What that player should have done in practice is get propkilled and let the propkill detection system do it's job. With my system, however, the admin could check the replay I described and get a more accurate picture of what happened. Most servers I have been on consider reflecting props or fighting a propkiller to be prop abuse, no matter how justified.
However, for the purposes of disproving your theory/proof/whatever, the system correctly identified who caused the propkill, even though the players intent was (probably) not to cause harm.

Also, does your "proof" only take effect when normal physics are on, or could we toss a prevention system into the mix as well?

Please poke more holes in my idea, it helps refine it.

[MisterFoxx]

IMO either the prop damage all together was removed or if it hits a player and the dmg is crush then fade the prop so it just goes through the player then when it no longer is inside the player after the dmg_crush then "re-enable" the prop. Rather than check for the player that is prop killing.