ULX priorities

[Buzzkill]

Was just chasing an issue down with URS and noticed some changes to ULib (which I haven't pulled from Github yet).  Am I right when I say it looks like you've reduced the priorities from -20 through 20 to -2 through 2?  This limits the granularity that was available in terms of making sure certain hooks get run before others.  Was this a change for performance reasons?

Thanks.

[Buzzkill]

Ugh... I'm really confused. It looks like -2 and 2 are now the read-only priorities.   It also looks like Ulib is clamping priorities > 2 and < -2 to 2 and -2 respectively.  This means (if I'm right, which I'm probably not), that legacy hooks that used, say a -10 priority and were NOT read-only will become a -2 and read-only.  This seems like it'll break any addon that uses priorities beyond -2 through 2 and expects to return a value that's honored by the hook chain.

[JamminR]

Yes, they've changed.
I didn't go read our latest (team only) design docs to fully understand how or why to answer your range questions and will have to let SticklyMan or Megiddo answer those (or perhaps MrP if he's been keeping up).
I do know we're looking to get our hook priority system into Gmod.
Though Stickly Man's posted that general info a few various chat areas, he mentioned it in a conversation you started in this post

If you are using the latest SVN of ULX/ULib, we've changed hook priority to be a set of constants, so you'd want to use HOOK_MONITOR_HIGH and HOOK_MONITOR_LOW for better results.   (Also, we're petitioning to get this hook library implemented in Garry's Mod by default... hopefully)

I figure DbugR distracted you there.

[Buzzkill]

Got it -- yes, I understand they've changed.  When I first posted I was sensing an issue that I clarified a bit more in my second post.  It looks like the new implementation is poised to break some functionality.   For example, a current -10 read/write hook will get clamped to a -2 read-only hook. This can be mitigated somewhat (I posted a ticket to GitHub), but there are still some nasties that can't be coded away.  For example, anyone unfortunate enough to have used -2 or 2 as a hook priority in legacy code and expected to be able to issue a return from their function will be stuck in limbo (the hook will be read-only with no way of sensing the true intention).

I realize not every legacy edge case can be incorporated into backward compatibility, and I may be pointing out things that were addressed and dismissed long ago.

[Aaron113]

I've been dealing with the aftermath of the hook changes for quite some time haha... example... https://github.com/Aaron113/urs/issues/21

[Buzzkill]

psst.. ascentechit = me.   

[Aaron113]

Heh, either way both of you seemed to have issues with the hook priority stuff.

EDIT:  And you're not the first.

[Buzzkill]

Is there any way to get ULib's hook table?  I'm looking through shared/hook.lua, and it looks like we override GetTable() to return the legacy (pre ULib) table.  I'd like to interrogate the current hook table from ULX in order to build a utility function to return all active hooks and their priorities, but I don't see how I can get at Hooks from outside hook.lua.

Thanks.

[Megiddo]

You can read more on the issue here -- https://github.com/Nayruden/Ulysses/issues/448

Buzzkill, our intent is to propose the ULib hook module as the official hook module going forward (GetTable() would change to return the regular table at that time), but I've added GetULibTable() to hook.* in the meantime.

[Buzzkill]

Thanks Megiddo!

BTW -- that ascentechit fellow is incredibly insightful and well-spoken.