Source.Python forums

How do I get the currently open menu for a player? If it isn't possible this can be useful if you are running multiple plugins (some you haven't made yourself), so your own plugin can close the menu and display another, since I don't have access to the other 'menu object'

velocity wrote:How do I get the currently open menu for a player? If it isn't possible this can be useful if you are running multiple plugins (some you haven't made yourself), so your own plugin can close the menu and display another, since I don't have access to the other 'menu object'

Hm. To be honest, I tend to be against that suggestion. By making the global queues public and documented, you are telling users that it is "okay" for plugins to modify them while I personally don't think they should. The current implementation is ensuring a good relationship between plugins since the menus are being displayed in the order they are being sent meaning that as soon the players are making a selection into the menu currently displayed for them, the next menu in queue is being sent, etc. That being said, you technically could access and edit the queue of a specific player via <menu class>.get_user_queue(index) but that is more meant to be for reading purposes over editing.

I have been playing CS:S for about 9 years and CS:GO 3-4 years, in all that time I've had a server and in addition to that, people have been complaining about the menus being queued up (form ES and SP), maybe from a developer point of view this sound more convenient or smart, but from players, this is annoying as f**. I usually implement my own fix since you can extend the class and so on... which is great! But when you start running other peoples SP plugins, I don't wanna go into their source code and modify everything just to make the menu close when my plugins need to display a menu.

...meaning that as soon the players are making a selection into the menu currently displayed for them, the next menu in the queue is being sent, etc.

Also note, that this is rarely the case usually the menu is returned after making a selection, so the menu stays sticky because of the way 'that specific' plugin works... There could be many reasons for that.

Having a menu queue is like being at the supermarket waiting for your turn to buy your groceries, if you remove the queue, you remove the wait. People don't like waiting they never did and never will.

velocity wrote:I have been playing CS:S for about 9 years and CS:GO 3-4 years, in all that time I've had a server and in addition to that, people have been complaining about the menus being queued up (form ES and SP), maybe from a developer point of view this sound more convenient or smart, but from players, this is annoying as f**.

I've played CS:S since 2005, ran dozens of servers for it over the years, and for me it always been the opposite. I remember in the old MAP days how annoying it was for it to overwrite the menu I currently had displayed when a vote was starting. Not only that, but since both were clashing to be in front, it was confusing the menuselect listeners since both were assuming the selection to be for them and not the other.

velocity wrote:I usually implement my own fix since you can extend the class and so on... which is great! But when you start running other peoples SP plugins, I don't wanna go into their source code and modify everything just to make the menu close when my plugins need to display a menu.

If that is what you want on your server, you could simply overwrite _BaseMenu.send to remove the queuing but as an API standpoint, I think it is preferable to ensure plugins are not clashing with each others.

velocity wrote:Having a menu queue is like being at the supermarket waiting for your turn to buy your groceries, if you remove the queue, you remove the wait. People don't like waiting they never did and never will.

If you remove the queue, you allow other customers to get in front of you before the cashier processed your groceries. This makes angry customers, as they gets out of the supermarket empty handed.

Here is some other things I find weird:
In a PagedMenu if I add Text( it counts as an option which means the numbers get weird. I don't know if I'm doing it wrong.

I'm actually realy interested in knowing if the current opened menu object for a player is stored in the client data.

Personally, I had problems with sm and sp menus where they stack on each other while the active listener is still on the hidden menu.

Edit:

Dont hold my words for correct, but I can actually remember something from Ayuto, that he told me once if I return the menu object, it overwrites any currently opened menu. Not sure how that would work, but thats the way I'm using it right now without having to use "queued menus"

velocity wrote:Here is some other things I find weird:
In a PagedMenu if I add Text( it counts as an option which means the numbers get weird. I don't know if I'm doing it wrong.

Yes, that's the intended behaviour.

decompile wrote:if I return the menu object, it overwrites any currently opened menu. Not sure how that would work, but thats the way I'm using it right now without having to use "queued menus"

It doesn't really overwrite any menus. The returned menu just gets added to the first position of the queue.