Ask about ACS, DECORATE, ZScript, or any other scripting questions here!
Moderator:GZDoom Developers
Forum rules
Before asking on how to use a ZDoom feature, read the ZDoom wiki first. If you still don't understand how to use a feature, then ask here.
Please bear in mind that the people helping you do not automatically know how much you know. You may be asked to upload your project file to look at. Don't be afraid to ask questions about what things mean, but also please be patient with the people trying to help you. (And helpers, please be patient with the person you're trying to help!)
Graf Zahl wrote:Don't do that! 'Close' performs some necessary bookkeeping when closing the menu.
But what if I just want to really zip out of there? Instant close it all?
Nash wrote:Major Cooke, if you have time - can you post a minimal example on how to safely manipulate the player with the recent systems and restrictions.
Perhaps just a simple menu that changes the player's health when you click on a button?
Thanks!
Let there be mocha.
You do not have the required permissions to view the files attached to this post.
I've been struggling to come up with a proper purchase menu. Honestly I feel like I've wasted the last two weeks of my time trying to come up with something proper.
Graf, given the current state of ZScript with 2.4, how would you do it, roughly? I ask because I've tried to come up with several ways whose cons prove to be too large to properly deal with.
By storing items per menu. Works, but there's lots of repeating code, is horrendously ugly, not to mention transferring of items from parent menu to sub menu can be a pain in the ass. Cannot rely on inheritance due to needs of inheriting from menus and items, making maintenance a complete pain in the ass.
By storing them in a struct. By attempting to make my own copy functions in the struct, proved to be absolutely futile. The struct didn't remember a thing.
By storing them in a UI object. Until I realized that such a command like 'closemenu' exists, which means the object will accumulate as a memory leak.
So what would the best way to handle this be? I'm stumped.
Major Cooke wrote:
Until I realized that such a command like 'closemenu' exists, which means the object will accumulate as a memory leak.
It may look that way. Menus, like all other objects are garbage collected so it may take some time before it disappears completely. For an object to actually leak there needs to be some stale reference to it in an object that cannot be GC'd.
Does the 'closemenu' command have every menu call OnDestroy()? Because if it does, then I don't need to worry, I'll just have the very base menu destroy it.
Which means I should avoid doing all the item exchanges via the object's destruction and let the menu do so instead.
But since they're not thinkers, can they be searched for by chance? If not that means I'll have to plant a big fat "Please use the official shortcut" sign over whichever menu people try to open with the console.
The engine only has one menu - the one you get by calling GetCurrentMenu. Each menu also has a link to its parent. There is no global store for menus and what cannot accessed through this chain should be considered non-existent, because if a menu gets closed it gets destroyed.
And what you try with shuffling items around sounds like stuff the menu system was never designed for. Normally each menu which doesn't use a static list of items is responsible for its own contents. You can pass pointers to items around, though but it's entirely up to you to handle the maintenance.
Apparently you try to cast a menu item into a menu. Both classes are unrelated. A menu item is not a menu, even if it will open a menu. The item is just the widget on the first menu that triggers the opening of the child menu. The child menu is not created before it is opened.