CompactBuilders and guide tips
#1
So i released my first plugin. It works okay. Though i imagine it's a huge mess to look at (e.g. settings hardcoded in lua) that is why I ask for style/programming tips and tricks.
It seems that a lot of stuff is saved in "*.ini" but there is also sql and xml and not a lot of examples (e.g. most lua api has one liners without any context on how stuff works) so which one is preferred? Also what is best way to debug plugins - web interface seems to take quite some time to reload them.

Also suggestions and criticism is welcome.
Reply
Thanks given by:
#2
I'll add even one more setting storage for you to consider: Lua source files (syntactically, doesn't matter what extension they actually use). I use those for my more complicated plugins.

Let's review each one, shall we?
INI:
+ Quite easy to read the file from the plugin (cIniFile class)
+ Easy to write to such a file, and contents such as comments are preserved (good when you insert defaults into settings)
+ Human-readable and -editable file
- Only simple values (numbers, strings) are supported, no support for structures or arrays
- Slight inconvenience with line-endings on Linux
SQLite:
+ Moderately easy to read and write from the plugin (lsqlite module)
+ Good for storing LOTS of data with the same structure, with great performance
- Bad for data with changeable structure
- Not human-readable file, need 3rd party tools for reading and editing
XML:
+ Moderately easy to read from plugin (lxp module)
+ Supports any structure of the stored data (values, structures, arrays)
+ Supports changing the structure between plugin versions (adding or removing a setting)
+ Somewhat human-readable and -editable
- No native support for writing, you need to write a serializer, which is a rather big piece of code
- A bit of a "cannon to shoot birds"
Lua:
+ Extremely simple to read from plugin (loadstring() / loadfile() functions)
+ Supports any structure of the stored data
+ Supports changing the structure between plugin versions
+ Allows dynamic calculations ("NumItems = Server:GetMaxPlayers() * 10")
+ Human-readable and -editable
- Doesn't support writing (would lose formatting, comments and dynamic calculations)

Based on these observations, my recommendations are these:
- For plugins that have very little settings of only basic types, use an INI file
- For all the rest, use Lua files
- Use SQLite for data, not for settings
- Use XML only when you need to consume it from an external source (Web API, for example)
(Note that these are biased by my personal opinion)

If you want some examples, have a look at the Gallery plugin - it uses SQLite for data storage and Lua-based config file:
https://github.com/cuberite/gallery
(Example config file: https://github.com/cuberite/gallery/blob...xample.cfg )
Reply
Thanks given by:
#3
As for debugging, are you using any IDE? I'm personally using ZeroBrane Studio and I have to say it is a lifesaver. Not only is it a nice Lua editor, we also managed to put together a really nice MCServer integration, so you can get code completion with real MCServer API and most importantly you get a Lua debugger, capable of breakpoints, watches, locals etc. while your plugin is running in the server. There's an article on how to set it up: http://apidocs.cuberite.org/SettingUpZeroBrane.html

Of course it has some shortcomings, it does have a few bugs, I've seen a few crashes, but overall it's the best Lua IDE I've worked with so far.

As for the workflow, I edit my plugin in ZBS, then start the server from there, which automatically attaches the debugger. When I find a problem, I just edit the plugin's source in the IDE and then use the server's console to execute the "reloadplugins" command - this reloads the new version of the plugin and everything keeps on going.
Reply
Thanks given by:
#4
(06-10-2015, 09:59 PM)xoft Wrote: As for debugging, are you using any IDE? I'm personally using ZeroBrane Studio and I have to say it is a lifesaver. Not only is it a nice Lua editor, we also managed to put together a really nice MCServer integration, so you can get code completion with real MCServer API and most importantly you get a Lua debugger, capable of breakpoints, watches, locals etc. while your plugin is running in the server. There's an article on how to set it up: http://apidocs.cuberite.org/SettingUpZeroBrane.html

Of course it has some shortcomings, it does have a few bugs, I've seen a few crashes, but overall it's the best Lua IDE I've worked with so far.

As for the workflow, I edit my plugin in ZBS, then start the server from there, which automatically attaches the debugger. When I find a problem, I just edit the plugin's source in the IDE and then use the server's console to execute the "reloadplugins" command - this reloads the new version of the plugin and everything keeps on going.

Give LuaGlider a try. (Free for non-commercial use)
http://www.mydevelopersgames.com/Glider/
Would be great if you guys made a package for that as well. This is the Lua IDE I use over everything and it works great.
Reply
Thanks given by:
#5
Glider doesn't seem to work on Linux and it is commercial; ZeroBrane is open-source and works everywhere where Lua + wxWidgets are supported (Windows, OS X, Linux, ...)
I'll give it a try anyway.

Jeez, 190 MiB fat installer, downloading at 140 KiB/secTongue
Reply
Thanks given by:
#6
Thank you xoft and Shadowraix for input. As for ide, i was using ZeroBrane for "standalone" lua coding long time ago. Though because most of my experience is with dfhack (which does not have debugging support) no longer used any ide.
I'll probably switch saving to ini (though i'm a bit biased against it because it's quite a legacy thing...) or just plain lua. But probably first will develop some disaster plugin (for the competition Smile )
Reply
Thanks given by:
#7
Sorry, I can't do it. The IDE eats up 700 MiB of my RAM, and hence renders everything else inoperable. I only have 2 GiB of RAM in my laptop (the maximum supported by its motherboard).
Reply
Thanks given by:
#8
Unrelated: thanks for using the plugin repository!
Reply
Thanks given by:
#9
(06-11-2015, 12:50 AM)xoft Wrote: Sorry, I can't do it. The IDE eats up 700 MiB of my RAM, and hence renders everything else inoperable. I only have 2 GiB of RAM in my laptop (the maximum supported by its motherboard).

Wow, only 2 GB? You really need an upgrade! I can barely stand 4 GB for what I use it with (Unreal Engine/Visual Studio 2012).
Reply
Thanks given by:




Users browsing this thread: 2 Guest(s)