List of Possible Replacements for Lua formspecs

User avatar
ThomasMonroe
Member
 
Posts: 184
Joined: Tue Apr 04, 2017 16:21
GitHub: ThomasMonroe314
IRC: ThomasMonroe TMcSquared
In-game: ThomasMonroe TMcSquared

List of Possible Replacements for Lua formspecs

by ThomasMonroe » Fri Oct 13, 2017 13:11

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
My home Server: MM-Survival
My New Server: Legends Of Survival.
I don't make messes, i just, uh, make disturbances in the local entropy.
I dont think, I KNOW "God's Not Dead"
 

User avatar
v-rob
Member
 
Posts: 352
Joined: Thu Mar 24, 2016 03:19

Re: List of Possible Replacements for Lua formspecs

by v-rob » Fri Oct 13, 2017 15:21

Replacing formspecs would break every mod that uses them. Bad idea, because there are many mods people use that are not developed.
 

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

Re: List of Possible Replacements for Lua formspecs

by rubenwardy » Fri Oct 13, 2017 15:29

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
 

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

Re: List of Possible Replacements for Lua formspecs

by TumeniNodes » Fri Oct 13, 2017 15:39

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
Reckless disregard for the truth -- will not be protected by a qualified privilege.
 

celeron55
Administrator
 
Posts: 443
Joined: Tue Apr 19, 2011 10:10

Re: List of Possible Replacements for Lua formspecs

by celeron55 » Fri Oct 13, 2017 20:41

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: 2839
Joined: Mon Sep 24, 2012 15:01
GitHub: Wuzzy2
IRC: Wuzzy
In-game: Wuzzy

Re: List of Possible Replacements for Lua formspecs

by Wuzzy » Mon Oct 16, 2017 20:10

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.
I'm creating MineClone 2, a Minecraft clone for Minetest. I made the Help modpack, adding in-game help to Minetest.
 

User avatar
ThomasMonroe
Member
 
Posts: 184
Joined: Tue Apr 04, 2017 16:21
GitHub: ThomasMonroe314
IRC: ThomasMonroe TMcSquared
In-game: ThomasMonroe TMcSquared

Re: List of Possible Replacements for Lua formspecs

by ThomasMonroe » Fri Oct 20, 2017 12:49

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
My home Server: MM-Survival
My New Server: Legends Of Survival.
I don't make messes, i just, uh, make disturbances in the local entropy.
I dont think, I KNOW "God's Not Dead"
 

User avatar
Linuxdirk
Member
 
Posts: 1072
Joined: Wed Sep 17, 2014 11:21
Location: Germany
GitHub: 4w
In-game: Linuxdirk

Re: List of Possible Replacements for Lua formspecs

by Linuxdirk » Fri Oct 20, 2017 13:28

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: 37
Joined: Sun Apr 26, 2015 03:10

Re: List of Possible Replacements for Lua formspecs

by asanetargoss » Thu Oct 26, 2017 19:55

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: 1241
Joined: Wed Aug 19, 2015 19:11
Location: Oklahoma City
GitHub: duane-r

Re: List of Possible Replacements for Lua formspecs

by duane » Thu Oct 26, 2017 22:03

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: 566
Joined: Fri Aug 26, 2016 15:36
Location: Illinois, USA
In-game: Nemo

Re: List of Possible Replacements for Lua formspecs

by sorcerykid » Sat Oct 28, 2017 00:32

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: 3367
Joined: Sun Sep 09, 2012 17:31

Re: List of Possible Replacements for Lua formspecs

by Sokomine » Thu Nov 23, 2017 20:34

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: 63
Joined: Wed Dec 02, 2015 17:58
Location: Estonia
GitHub: jan69
IRC: jan6
In-game: jan6

Re: List of Possible Replacements for Lua formspecs

by jan6 » Fri Nov 24, 2017 19:23

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
 


Return to Feature Discussion



Who is online

Users browsing this forum: No registered users and 2 guests