General > Developers Corner
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
--- Quote from: Stickly Man! on April 07, 2015, 10:39:43 AM ---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)
--- End quote ---
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
Navigation
[0] Message Index
[#] Next page
Go to full version