What is defined as a user-friendly menu?

[Nevander]

I've always preferred menus of the older games. Simple lists that you click or press enter on. Like the good 'ol days. Fancy menus and stuff we get nowadays is a bit much sometimes.

[Arctangent]

The last obstacle is the inverted mouse, the only thing I've been able to find so far is just a button that toggles it to the correct state. I know that you can detect for this via getcvar but that's a singleplayer only kind of feature.

I'm pretty sure inverted mouse is a user cvar. You can get the user cvars of a specific player, so it shouldn't actually cause conflict in multiplayer if you only check the menu user's cvar.

[edward850]

I'm pretty sure inverted mouse is a user cvar. You can get the user cvars of a specific player, so it shouldn't actually cause conflict in multiplayer if you only check the menu user's cvar.

It isn't, and never has been, a user cvar. Even the wiki page expressly says this. I would also like to know where people keep getting the idea that interface cvars exist as userinfo keys. It feels like I have had to keep repeating this detail, and I'm honestly not sure why.

[wildweasel]

Well, what alternative do we have, then?

[edward850]

Creating an arbitrary custom cvar, or simplifying fake menus, or not creating fake menus.
No really I'm getting serious déjà vu from this. I feel like we've had this exact discussion before.

[Nash]

Well, what alternative do we have, then?

It's actually possible to make the mouse invert cvar a net-safe, Edward just likes to be a bitch about it. Can't wait for someone to do it (maybe me in future when I'm done with my album projects) and submit it to the Github so he can STFU about it

[edward850]

Sorry, an interface cvar will never be tied to something outside the interface, and especially the network/demo stack. And no, Nash, that's not bitching, it's simply common sense.
As an example; What would you think would happen if somebody played back a demo with an inverted mouse setting? The consoleplayer keys get replaced, right? That's already beginning to sound like a problem.
Furthermore, the network stack is the last thing that should have any control over which way your mouse provides input. That's a disaster waiting to happen.

[wildweasel]

Okay then...so why not take it from the top? What is a mod to do if it needs players to be able to, say, spend experience points on things? What is the most stable, least sync-breaking way to do that, that doesn't require the player to do crazy shit?

[phantombeta]

I'm guessing it's doing it the way DoomRPG does it. From what I've seen/heard DRPG is pretty stable on MP.

[GooberMan]

What is the most stable, least sync-breaking way to do that, that doesn't require the player to do crazy shit?

Request a UI layout engine.

Not trying to sound like a dick or anything. It is the only real solution though. The UI's state should be a completely a client-side thing, and anything that has a chance of affecting the network simulation shouldn't be explicitly included. ACS callbacks or something like that on click can modify the simulation state, but not the UI itself. Whether a player is in a UI or not is also something that does not need syncing across the simulation.

(The plus side is that it would also force mod authors to consider screen resolutions that aren't their own.)

[Nash]

I'm all for a proper solution but we all know that's not going to happen so is it really right to talk down people like me and Kyle and countless others for just using whatever is available (which happens to be ACS)? If a proper UI API gets implemented, I'd be more than happy to tear everything down and do it the right way. I really hate ACS for doing non-ACS things, believe me.

[GooberMan]

For reference, I've written a fancy-pants ACS UI for Prime Directive and ZKart... and I can't think of a way to make it network friendly. I had to fudge values just to make mouse movement feel right.

So let's turn this thread in to a force of good. Randomly requesting a UI layout engine is guaranteed to get a [No] resolution. The solution? Spec it out.

Which will need to be done in a few phases:

• User stories - basically a list of potential use cases. Go wild.
• High level spec - something that serves all of those user stories.
• Tech spec - someone with technical know-how takes that high level spec and says how it should be implemented.
• Feature request
• User-friendly documentation

[edward850]

For reference, there's already a network spec for a UI; Strife's dialogue scripts call page codes, but is otherwise just another menu definition. The only real job here is a concept, syntax, and most importantly a universal standard that can be shared by any type of current and future input.

I'm immediately reminded of winforms enforced tab methods and flow-layout controls, somehow. Probably because winforms can be designed dynamically and can be controlled with even a simple keyboard.

Also because I have been working with them so much lately, that when I close my eyes I see winforms. D:

[Nash]

ACS for menus is actually so horrible by design. Can you imagine having to recompile ACS everytime just to change something on the menu? You COULD go fancy and externalize moddable values to the LANGUAGE lump or something but that's just so hacky and disgusting. :D Modern engines have XML files and stuff so users can reskin and mod their UIs.

I think in a ZDoom context, a C-like syntax is always the best.

I think the biggest problem though is allowing this imaginary UI engine to have access to ACS-created variables (which, I'm guessing 90% of the time is the whole point anyway). Otherwise users would have to resort to an intermediate variable <-> inventory item step which again is hacky. I know SBARINFO can read inventory item data which is why I brought this in.

Another issue is... what kinds of features would be allowed? I mean even if this thing was implemented... would I be able to recreate this?

[edward850]

I'm already going to bet no. Not to that effect, anyway (i.e I don't think emulating it would be out of the question). Also, anything created would need to work with any input method, otherwise the whole system would be missing the point from the start.