-
Notifications
You must be signed in to change notification settings - Fork 9
Description
I don't know how much this is needed, but I think that having this would be a huge help while programming.
The page for hook.Add
describes eventName
like this:
The event to hook on to. This can be any
GM
hook, gameevent after usinggameevent.Listen
, or custom hook run withhook.Call
orhook.Run
.
LuaLS allows to specify a string as its own separate type.
So, if we take the GM:Move
hook as an example, the hook.Add
function can have an overload like:
--- @overload fun(eventName: "Move", identifier: any, func: fun(ply: Player, mv: CMoveData): boolean?)
... which will then allow for this to happen:
ply
and mv
will also be of the right types already, though LuaLS will complain if nothing is returned here, which may not be wanted if, for example, the programmer wants to just inspect ply
and/or mv
.
This can be accounted for by having the return type be optional here (boolean?
).
Custom hooks should not be affected, as LuaLS will just use the original definition of the function, where eventName
is string
and func
is simply function
.
Adding GM
hooks would be okay, but there's also the hooks described on the page for gameevent
, which would require more special treatment.