I have got a really strange problem with a script. It overrides the original hook.Call with this code:
[LUA]
Lib = {}
if ( Lib.HookCall == nil )then
Lib.HookCall = hook.Call
end
hook.Call = function( name, gm, ... )
ErrorNoHalt( "Hook call! "..name.." . \n" )
return Lib.HookCall( name , gm , ... )
end
[/LUA]
It works fine. But there is the problem. Some hooks somehow bypasses it.
So if I respawn I supposed to see: 'Hook call! PlayerSpawn .' But I see nothing except:
[RELEASE]
Hook call! PlayerLoadout .
Hook call! PlayerSetModel .
[/RELEASE]
So somehow PlayerSpawn hook is not runt. But it did:
hook.Add( "PlayerSpawn" , "Test" , function() ErrorNoHalt("HELLO! \n") end )
Result:
[RELEASE]
HELLO!
Hook call! PlayerLoadout .
Hook call! PlayerSetModel .
[/RELEASE]
So my 'Test' hook runs somehow.
How is this can be?! :supaburn:
Maybe it's calling gamemode.Call instead
I dunno if gamemode call calls hook.Call again though
[QUOTE=CapsAdmin;23539846]
I dunno if gamemode call calls hook.Call again though[/QUOTE]
Yes it does:
[LUA]
/*---------------------------------------------------------
Name: Call( name, args )
Desc: Calls a gamemode function
---------------------------------------------------------*/
function Call( name, ... )
local CurrentGM = gmod.GetGamemode()
// If the gamemode function doesn't exist just return false
if (CurrentGM && CurrentGM[ name] == nil) then return false end
return hook.Call( name, CurrentGM, ... )
end
[/LUA]
From : [URL]http://luabin.foszor.com/code/lua/includes/modules/gamemode.lua[/URL]
[editline]06:06PM[/editline]
Any other ideas?
Maybe PlayerSpawn isn't being called by a hook, maybe it's hard coded?
You can call gamemode hooks without using gamemode.Call or hook.Call, e.g. GAMEMODE:PlayerSpawn(objPl) calls the gamemode's PlayerSpawn hook.
hook.Call is for manually calling a hook from inside your code. The engine does not use hook.Call.
[QUOTE=ralle105;23565514]hook.Call is for manually calling a hook from inside your code. The engine does not use hook.Call.[/QUOTE]
Lua()->GetMember("hook")* hook;
hook->GetMember("call");
Lua()->Push("AHOOK");
Example by my incorrect C++. Basically, you can call hooks in Lua via Lua modules, and so will be able to in the engine.
[QUOTE=|FlapJack|;23565722]Lua()->GetMember("hook")* hook;
hook->GetMember("call");
Lua()->Push("AHOOK");
Example by my incorrect C++. Basically, you can call hooks in Lua via Lua modules, and so will be able to in the engine.[/QUOTE]
It is possible yes, but it isn't implemented. It would be cool if the engine would call functions in lua like hook.Call and Entity:DrawModel() rather than doing it internally so they could be overridden.
What does the engine call then? It can't access the table of hooks easily without using hook.Call. Besides, garry's comments in hook.lua say that the engine calls hook.Call.
engine calls gamemode.Call in most cases, override that instead, gamemode.Call has hook.Call localized
no it doesn't, it has hook localised.
[editline]26th November 2010[/editline]
I don't see why you need to do this, but you'll want to override gamemode.call, hook.call and then do some witchery using a new GAMEMODE table with a funky metatable __index function.
[editline]26th November 2010[/editline]
Or perhaps override the current GAMEMODE table's metatable. I'm not too hot on the black arts.
[lua]
local hook = hook;
hook.OverrideCall = hook.Call;
function hook.Call(name, gamemode, ...)
if (!gamemode) then
gamemode = GAMEMODE;
end;
return hook.OverrideCall( name, gamemode, unpack( {...} ) );
end;
[/lua]
Works great here.
IIRC unpack is a slow function which you shouldn't use in things like hooks.
also "..." is deprecated, kuro, use "args"
It works TGiFallen, I don't care what is deprecated. And my input was only: it works great here, I didn't say it works great [i]and[/i] is the best and most optimised way to do it. Sheesh you Facepunchers really like to split hairs over a guy just helping a guy out.
[QUOTE=Lexic;26321192]wait what?[/QUOTE]
Doing just hook.OverrideCall(name, gamemode, ...) like the OP didn't work for me, that's why I said to do it that way (probably cause ... is deprecated).
[b]Edit:[/b] and I'm pretty sure using unpack has no real performance loss, or if it does have any, it's really trivial. Please don't comment on trivial optimisations.
[QUOTE=TGiFallen;26323339]also "..." is deprecated, kuro, use "args"[/QUOTE]
You've got that backwards. ... is not depreciated, but rather args.
[QUOTE=Kogitsune;26325988]You've got that backwards. ... is not depreciated, but rather args.[/QUOTE]
ohh, but that doesn't make sense because using ... all people do is local tab = {...} and with args it's already in a table.
arg not args. args is a common table name for concommand callback arguments whereas arg is a magical table autogenerated when you put ... at the end of your argument list. It's useful, but it's been depreciated in this version of Lua and phased out in the next version, so not using it adds forward compatibility.
[QUOTE=TGiFallen;26326347]ohh, but that doesn't make sense because using ... all people do is local tab = {...} and with args it's already in a table.[/QUOTE]
That's the point. Having it as a table isn't as convenient to plug into another function. Leaving it a table means you need to run it through unpack, which is just adding an extra step.
Also, the arg table has a mysterious 't' index with a value of the number of args passed.
(its n not t)
Sorry, you need to Log In to post a reply to this thread.
