Problem with Pointshop hooks while using ULib

[Megiddo]

Moving this thread to help and support; we will never implement a way to bypass ULib hooks. Such behavior would be nonsensical anyways, since ULib performs functionally exactly the same as gmod default, excepting hook ordering.

I also tried to replicate this behavior with no success, though I was also using Windows.

[lynx]

You said that the sandbox server was out of use for a while. What versions of ULX, ULib, Pointshop (1 or 2 and what update), and as said what OS (or host if unknown) are you running on?

[TomatoSoup]

I'm using Windows, Pointshop 1 with the latest from their git, the SVN version of ULX/ULib were downloaded less than an hour before the test, likewise with validating GMod itself via SteamCMD (but I made a mistake in earlier statements, more on that later).

Importantly, though, I have a way to replicate the issue.

Code: [Select]

function BreakPointshop()
    return true
end
hook.Add("PlayerInitialSpawn", "breakpointshop", BreakPointshop)

In lua/autorun. When that is there, it breaks pointshop. When it's not there, pointshop works. When it's there and ULib is NOT there, Pointshop works.

The problem does not occur in a totally vanilla install of GMod, I'd accidently left some debug code that prints player information in lua/autorun. I only checked addons because I forgot about that code. Sorry for misrepresenting this as a bug that occurs in totally vanilla gmod.

But my point remains that hooks.lua does not actually have the same behavior as regular GMod. Returning true in a hook in regular gmod stops the gamemode's version of that hook from executing. Returning true under hooks.lua's regime, however, causes all subsequent hooks to not execute. This is not analogous to GMod's behavior as it stops other hooks from executing, rather than just stopping the default gamemode hook from executing.

[Stickly Man!]

Hmm, that's an interesting finding. I'll query Megiddo for clarification on the matter- it could be an oversight or a deliberate design choice, as hooks that return non-nil values have a history of causing conflicts between addons.

EDIT: Okay, I was just reading the code incorrectly.

Our hook does behave the same as GMod's hook system in terms of return behavior. The ONLY difference you're seeing with using ULib's hook is that the ORDER of hooks are being changed. Your code snippet above works with the standard GMod hooks likely because it's being called later.

Try moving your BreakPointshop hook INSIDE of Pointshop's code itself, directly before they add their PlayerInitialSpawn hook. I'm willing to bet that if yours gets added (and then run first), then it will break regardless of whether or not you're using ULib's hook.lua.

Megiddo made a good point to me: The fact that you're having these sorts of issues in the first place is a good indicator of why we are using our Hook priority feature in the first place- There's absolutely no easy way for developers to ensure that their hooks are being called in a predictable order, thus resolving conflicts between two third party addons over a single hook is not possible.