List of Possible Replacements for Lua formspecs

Post Reply
User avatar
ThomasMonroe
Member
Posts: 286
Joined: Tue Apr 04, 2017 16:21
GitHub: ThomasMonroe314
IRC: ThomasMonroe TMcSquared
In-game: ThomasMonroe TMcSquared
Location: Wherever I am at

List of Possible Replacements for Lua formspecs

by ThomasMonroe » Post

Ok so i was having a discussion with rubenwardy, nerzhul, sfan5, and twoelk about possible replacements for the current lua formspec strings.

so here is a list of the ones i have found:
nuklear
Pros:
  • Focus on portability, efficiency and simplicity
  • No dependencies (not even the standard library if not wanted)
  • Low memory footprint with total memory control if needed or wanted
  • Fully skinnable and customizable
  • Lua bindings already builtin
Cons: none that i can find

clutter
Pros: i have no idea
cons: gnome-based

Rexx
pros:
  • fast, native to OS/2
cons: less themeable
I don't make messes, I just, er...disturb the local entropy!

User avatar
v-rob
Developer
Posts: 970
Joined: Thu Mar 24, 2016 03:19
GitHub: v-rob
IRC: v-rob
Location: Right behind you.

Re: List of Possible Replacements for Lua formspecs

by v-rob » Post

Replacing formspecs would break every mod that uses them. Bad idea, because there are many mods people use that are not developed.
Core Developer | My Best Mods: Bridger - Slats - Stained Glass

User avatar
rubenwardy
Moderator
Posts: 6972
Joined: Tue Jun 12, 2012 18:11
GitHub: rubenwardy
IRC: rubenwardy
In-game: rubenwardy
Location: Bristol, United Kingdom
Contact:

Re: List of Possible Replacements for Lua formspecs

by rubenwardy » Post

v-rob wrote:Replacing formspecs would break every mod that uses them. Bad idea, because there are many mods people use that are not developed.
No it won't, formspecs would just be deprecated but still work. Replace is probably a misleading word

Here's the issue about it: https://github.com/minetest/minetest/issues/6527
Renewed Tab (my browser add-on) | Donate | Mods | Minetest Modding Book

Hello profile reader

User avatar
TumeniNodes
Member
Posts: 2941
Joined: Fri Feb 26, 2016 19:49
GitHub: TumeniNodes
IRC: tumeninodes
In-game: TumeniNodes
Location: in the dark recesses of the mind
Contact:

Re: List of Possible Replacements for Lua formspecs

by TumeniNodes » Post

Then, every mod which uses them will need to be updated or replaced.
This has been a plaguing issue for a long time, and the only resolution seems to be a complete replacement, and since Minetest is heading into "breaking" development ground for the next big release, this is the time to do it.

Nuklear looks to be the better option but, that is only going by a quick glance. There are some questions

edit: heh, nvm..., Rubenwardy has explained the "replacement" concerns, above
A Wonderful World

User avatar
celeron55
Administrator
Posts: 532
Joined: Tue Apr 19, 2011 10:10
GitHub: celeron55
IRC: celeron55

Re: List of Possible Replacements for Lua formspecs

by celeron55 » Post

My opinion has always been that we should have our own pure Lua toolkit. Expose some 2D drawing primitives from core to client-side Lua, and let it do the rest.

It could also be published as a stand-alone library for others to use. AFAIK there is no pure Lua toolkit available at all currently.

User avatar
Wuzzy
Member
Posts: 4786
Joined: Mon Sep 24, 2012 15:01
GitHub: Wuzzy2
IRC: Wuzzy
In-game: Wuzzy
Contact:

Re: List of Possible Replacements for Lua formspecs

by Wuzzy » Post

It would have been better if MT started with using a tried and tested GUI toolkit from the start instead of using its own. But now it's too late to cry.

Now a switch WILL of course be very painful, but it would also solve many problems with the current system. But we have to throw away a ton of mods, obviously. Such a hard switch would probably not work. Not just from a technical standpoint, but also from a social one. Many modders might feel alienated.
My opinion has always been that we should have our own pure Lua toolkit. Expose some 2D drawing primitives from core to client-side Lua, and let it do the rest.
Oh god, please, no. Please don't outsource everything to Lua just because the engine is lacking features.

This would make mods even more bloated and complicated, forcing them to replicate the same core functionality over and over again. There is going to be a huge amount of reundancy if the engine does not even offer even the most basic widgets like labels, buttons, etc.

I wonder what's next? Outsourcing the rendering routines to Lua? xD This “let Lua do everything” mentality has to stop.

It would also be bad for usability because the widgets which mods come up with are doomed to be inconsistent like hell.


ACTUAL problems with formspecs:
- Coordinate systems are inconsistent and weird
- Missing documentation on coordinate systems
- Very incomplete documentation on the returned fields in the *_receive_fieds callbacks
- Not very flexible

All of these could theoretically be fixed without starting over from scratch.

What's NOT a problem with formspecs:
- That it's string-based. Don't waste your time here, we have much bigger problems



I have a compromise idea: Include a GUI toolkit as suggested, but make this only an internal change. The Lua API stays the same and the formspec strings are then just parsed and translated by the engine to the GUI toolkit calls. This would make the transition 100% backwards-compatible.

Whether to phase out the formspec strings entirely needs to be decided later. Currently, I don't think the string-based system is really a big problem. The messed-up coordinates are much worse.

User avatar
ThomasMonroe
Member
Posts: 286
Joined: Tue Apr 04, 2017 16:21
GitHub: ThomasMonroe314
IRC: ThomasMonroe TMcSquared
In-game: ThomasMonroe TMcSquared
Location: Wherever I am at

Re: List of Possible Replacements for Lua formspecs

by ThomasMonroe » Post

Wuzzy wrote: I wonder what's next? Outsourcing the rendering routines to Lua? xD This “let Lua do everything” mentality has to stop.
Heh, I agree.

Also I had an idea for a CSS Grid type approach, which would be string-based.
I just don't get why CSS is so taboo around here
I don't make messes, I just, er...disturb the local entropy!

User avatar
Linuxdirk
Member
Posts: 3218
Joined: Wed Sep 17, 2014 11:21
In-game: Linuxdirk
Location: Germany
Contact:

Re: List of Possible Replacements for Lua formspecs

by Linuxdirk » Post

Wuzzy wrote:Now a switch WILL of course be very painful, but it would also solve many problems with the current system. But we have to throw away a ton of mods, obviously. Such a hard switch would probably not work. Not just from a technical standpoint, but also from a social one. Many modders might feel alienated.
MT could have two GUI toolkits for some time. One modern and feature-rich new one that is actively developed and looks shiny and stuff, and the one that is currently the default. This could be marked as legacy for a few rleases, and then outdated (spam warnings) and then it could be disabled by default and later it could be removed.
Wuzzy wrote:Please don't outsource everything to Lua just because the engine is lacking features.
It already happens in so many places :( Most of the Lua stuff should be done in C++. Lua should only be used to call stuff from the API and not be used as API itself.
Wuzzy wrote:I don't think the string-based system is really a big problem.
Id like to see objects instead of strings. Strings always feel "last century" to me. :)

asanetargoss
Member
Posts: 42
Joined: Sun Apr 26, 2015 03:10

Re: List of Possible Replacements for Lua formspecs

by asanetargoss » Post

Formspecs are one of the two things I've found that sucked most when I was modding minetest.

There are no conventions. Any time a mod wants to draw an inventory formspec, they have to take into account the possibility that the player inventory may not be the default size. Any time a mod wants to draw a chest formspec, they have to take into account any gui elements that would normally be added to the default minetest chest but may not be included on modded chest formspecs. And so on for any gui elements on other things. It's simply not sustainable to have each individual mod do compatibility checks for every single other mod that adds inventory-related things. Perhaps some sort of gui group system, a way to append/prepend elements, and a way to define containers into which other sub-guis could be placed?

There is also a lack of flexibility. There are so many use cases for dynamically displayed images and text, such as smoother inventory animations, real-time updating stats to reflect crafting costs or machine processing, and responding to user text input. Scroll bars could work as a canned solution for inventories as well as available for more advanced gui containers, as a way to manage the amount of content on the screen. Drawing additional gui elements outside the main formspec rectangle, and taking into account the dimensions/aspect ratio of the screen, would also be highly desirable for utility-type mods. Having the hud and the inventory constructed with the same api could also be interesting.

I don't think a desktop-style gui toolkit is going to be adequate, but abstracting away manual string parsing would be a step in the right direction. What really matters is how existing gui capabilities are augmented to fit common gameplay scenarios and ease mod intercompatibility.

Side note, render hooks need not be outsourcing, but one possible tool in the box. In some cases, all that is needed is for a resource to be dynamically generated at runtime and then cached, other cases it's just a matter of putting an image at a certain formspec coordinate or text on a sign. Drawing lines in 3d space would be very useful for debugging, and render hooks in general would allow for testing novel ideas.

User avatar
duane
Member
Posts: 1715
Joined: Wed Aug 19, 2015 19:11
GitHub: duane-r
Location: Oklahoma City
Contact:

Re: List of Possible Replacements for Lua formspecs

by duane » Post

Slightly off-topic:

Several of our folks need to get over their issues with lua. First of all, formspecs (and a lot of other functions run in lua) aren't a huge consumer of cpu time or memory, so optimizing them isn't really an issue. Second, the only time lua is inefficient is when you have to make loads of calls to C. (Ok, a primitive drawing api would qualify, but again, speed is not an issue here.) As for "bloat," there's going to be code either in C or lua or both. There won't be any more bloat either way. Just because you don't see it, doesn't mean it's not there.

If any part of the game doesn't require optimization, putting it in lua just makes sense since it makes the code more accessible. This is minetest's greatest strength, and should never be understated. I would never have bothered with this game if I hadn't seen so much work being done in a high-level language. Your points about standardizing interface features is well taken, but you don't want to limit modders' creativity either.

Also, let's stop worrying about mods getting deprecated by the switch. If something isn't being developed, someone will just have to step up and develop it. Besides, we've already been told that this isn't being done in one fell swoop.

I like celeron55's idea of a centralized lua library for the gui elements. You won't have any code bloat, because you won't be copying the library to your mod, though you could if you wanted to change a lot of it. (And I realize I'm not one to talk about C vs lua given my recent activity, but you'll notice that I offloaded a lot of the work to lua even in my latest project.)
Believe in people and you don't need to believe anything else.

User avatar
sorcerykid
Member
Posts: 1841
Joined: Fri Aug 26, 2016 15:36
GitHub: sorcerykid
In-game: Nemo
Location: Illinois, USA

Re: List of Possible Replacements for Lua formspecs

by sorcerykid » Post

It already happens in so many places :( Most of the Lua stuff should be done in C++. Lua should only be used to call stuff from the API and not be used as API itself.
I disagree. Unless there a proven bottleneck to the existing Lua libraries, then I don't see any benefit of porting all that code to C++. Yes, there is certain core functionality (like those builtin Lua routines that execute every server tick), that probably would fare better if they were incorporated into the engine, but otherwise the strength of a high-level scripting language like Lua is that it is significantly easier to maintain in the long-term. Don't toss out the baby with the bathwater.

Sokomine
Member
Posts: 4276
Joined: Sun Sep 09, 2012 17:31
GitHub: Sokomine
IRC: Sokomine
In-game: Sokomine

Re: List of Possible Replacements for Lua formspecs

by Sokomine » Post

Is diskussion/development of improvements to formspecs or even the discussed new lua library plus its C++ api making any progress? Improvements would certainly be welcome, no matter which language they are implemented in.

Formspecs in their current form do have quite a lot of problems and need improvements. What bothers me most of the time - apart from finding fitting coordinates for the inventory slots and other elemets - is that string/text elements are not supported very well. A diffrent font or a diffrent size for the font will have huge influence on the labels. Such a simple task as "let this mob/sign/whatever show the player a short text" becomes less than trivial. What I miss is a formspec element that takes a position, relative dimensions plus a text, and then renders the text so that it will fit into the given area. If needed, line breaks need to be inserted automaticly (optionally manually). And, most important: The font size the player selected does not have any influence here. It would seldom fit anyway. If the player changes from a small window to fullscreen, the text ought to stay in the same (now enlarged) area, with the same line breaks, and just get rendered bigger. Likewise, if the player shrinks the game's resolution, the text needs to shrink. That's very basic for any hopeful gui elements but sadly not really supported by formspecs.
A list of my mods can be found here.

User avatar
jan6
Member
Posts: 64
Joined: Wed Dec 02, 2015 17:58
GitHub: jan69
IRC: jan6
In-game: jan6
Location: Estonia

Re: List of Possible Replacements for Lua formspecs

by jan6 » Post

I'd say *allow* modders to do anything, but also provide a simple standard way, that's sufficient for most cases...the scrollbars are a nice idea (preferably reskinnable/textureable, along with the rest of the inv)...
and I also prefer the phasing out instead of "poof, ur mod iz brok", maybe make the new system default but allow formspecs as-is for a "porting and updating" period...

too bad I'm not a real programmer or modder, so I can't say anything new here...
I know everything, exept what I know...
I have a secret..it's so secret even I don't know what it is

Byakuren
Member
Posts: 818
Joined: Tue Apr 14, 2015 01:59
GitHub: raymoo
IRC: Hijiri
In-game: Raymoo + Clownpiece

Re: List of Possible Replacements for Lua formspecs

by Byakuren » Post

Wuzzy wrote:
My opinion has always been that we should have our own pure Lua toolkit. Expose some 2D drawing primitives from core to client-side Lua, and let it do the rest.
Oh god, please, no. Please don't outsource everything to Lua just because the engine is lacking features.
I think that it would be useful to have lower-level drawing commands available for custom stuff, but I agree that an implementation of most common GUI elements (including everything normally needed for formspecs) should be included with Minetest if that route is taken. It may also be a good idea to reimplement formspecs in the new API, as a usability test.
Every time a mod API is left undocumented, a koala dies.

Post Reply

Who is online

Users browsing this forum: No registered users and 3 guests