How To: ZSCRIPT MENUS?

[ZZYZX]

Child menu should take things from parent one on construction.
I remember you are supposed to have link to the parent...

[Major Cooke]

Piss waffles... precisely what I was hoping to avoid. Ah well.

[ZZYZX]

You are consistently trying to avoid the best ways to do things.

[Major Cooke]

Not really. OnMenuCreated was made for 2.5, not 2.4. Init functions for items don't work like regular menu init.

Also not having to splatter copy/paste code everywhere is certainly much nicer...

[ZZYZX]

If you can have that in base class for your submenus it's probably not copy+paste? idk. I haven't seen any menu code ever.

[Graf Zahl]

If you have to to weird stuff, create your own widget that does not rely on stock code to create the submenu. In that case you'd have full access to it and can transfer whatever you wish. If you need to transfer content you won't be able to do it without some special coding.

[Major Cooke]

If you have to to weird stuff, create your own widget that does not rely on stock code to create the submenu. In that case you'd have full access to it and can transfer whatever you wish. If you need to transfer content you won't be able to do it without some special coding.

I'm not even ready to tackle that yet. That'd take doing all the screen resizing and resolution calculations and... I'm only knee-deep in the menu code at the moment.

At first I thought OnMenuCreated was called internally, then I realized it was just a ZScript exclusive. So I got that taken care of and now it works.

Now the next big thing I have to do is figure out how to make nice tiers like this work in just one menu instead of three. Should be interesting:

[Ed the Bat]

ZScript menus are quite over my head, at this point. But the possibilities have me quite interested. I don't suppose it would be feasible to try to make a grid-like selection menu, perhaps for a player select?

[Major Cooke]

Yes, that is possible. And yes, ZScript menus are truly insane in terms of flexibility and making things work. Why you could even have it, say, prompt a password for a door if you want. Or use it as a journal for discovering different things. That is, when Graf changes Menu.SetMenu to clearscope.

[Ed the Bat]

I've wanted a player select menu like that for years. But I worry it will be a long time before I can understand it well enough to create that on my own.

[Major Cooke]

This is where knowing some Java/C++ pays off. This whole concept was based around the UnrealScript idea, though Graf most likely will have taken many of his own liberties.

Anyway... The easiest method I can advise people is, either use VS2015 where all the .cpp files and text is easily searchable, or you can extract all the ZScript menu code from gzdoom.pk3. It's under zscript/menu. I do it with VS2015 since the search capability allows finding things really easily.

[ZZYZX]

Is there a way to require mouse for a specific menu?

edit: nevermind x2, my guessed way didn't do it.
Also, I'd like to not only require it, but also hide the default cursor to draw my own.

edit: nevermind x3, apparently I can use the InputEvent for when the mouse is off.
Ok, now, is there a way to DISABLE mouse for my menu so that I can always receive InputEvent instead of UiEvent?

Also how do I prevent closing the menu by escape? (I mean I already can spawn the same menu in OnDestroy, but that'd be a dirty hack and I'm looking for a valid way, and also one that wouldn't crash my executable...)
I want a main menu that opens automatically on startup (can do that already I think) and can't be closed (???)

Oh, alsoalsoalso can we get a GenericMenu in MENUDEF? Right now I need to inherit ListMenu or OptionMenu even if I intend replacing 100% of the functionality from scratch and it's not a menu at all.

My current implementation of a god mode menu looks like this: http://www.mediafire.com/file/8qo5iejb3 ... m3Menu.pk3
I'm thinking of implementing a windowing system in ZScript that has everything disconnected from specific rendering/input backends and in theory can do things like rendering via DrawPowerup and receiving input via event handlers, as well as rendering via menus and receiving input via menus. And of course have it's state disconnected from menus so the menu can be killed as many times as you want, the state will stay.
It should also work with either InputEvent or UiEvent for mouse... because apparently in menus anything can happen.
Wrappers rule
(also, HOERS-related)

[Major Cooke]

Yet another exploit that needs shooting apparently. And yes, HOERS related.

[ZZYZX]

Hey that's not an exploit — that's legit usage of ZScript features that exist at the moment, with no unwanted side effects (well except that you can't start a game, but that's temporary).
If Graf allowed RenderOverlay, it'd be an overlay on a TITLEMAP, with MainMenu calling Destroy on Init if not in GS_LEVEL. But as there are no overlays...

Besides, Doom 3 menu should not close by escape, unless it's in the game. But I didn't implement that part yet — in fact nothing is implemented at all for now

[Nash]

Alt + F4 and "delete WAD to Recycle Bin" always works unconditionally, so this fearmongering of unclosable menus is just exaggeration. ZZYZX already gave realistic use cases.

I can make a WAD even more annoying that calls new(someThinker) in a never-ending while() loop...