minetest-mods / qa_block Goto Github PK

If there is a string variable with line breaks, it is displayed incorrectly in the list; the list looks broken in this case because text gets written “over” other text.

This can be easily tested by adding any global multi-line string variable in any mod.

A possible solution would be just to eliminate all newlines before they get printed on the list and by replacing them with a literal “\n”.

As of Minetest commit cc7c31a5bc44ab0010997e86c0a8c9f5f832b398, qa_block does not work. When I start the world, I immediately get this error:

2016-12-21 13:11:01: ERROR[Main]: ModError: Failed to load and run script from /home/wuzzy/src/minetest/git/minetest/bin/../mods/qa_block/init.lua:
2016-12-21 13:11:01: ERROR[Main]: .../src/minetest/git/minetest/bin/../mods/qa_block/init.lua:63: bad argument #1 to 'ipairs' (table expected, got string)
2016-12-21 13:11:01: ERROR[Main]: stack traceback:
2016-12-21 13:11:01: ERROR[Main]: 	[C]: in function 'ipairs'
2016-12-21 13:11:01: ERROR[Main]: 	.../src/minetest/git/minetest/bin/../mods/qa_block/init.lua:63: in function 'print'
2016-12-21 13:11:01: ERROR[Main]: 	.../src/minetest/git/minetest/bin/../mods/qa_block/init.lua:138: in main chunk

This mod does not work if the setting secure.enable_security is activated.

In 0.4.14, this was disabled by default, but in the next Minetest release, mod security will be activated by default. Which means in the next Minetest release this mod will break.

Read more about mod security here:
https://forum.minetest.net/viewtopic.php?f=18&t=12471

Hi,

can you change print function minetest.chat_send_all(outsting) to minetest.log(outsting)?

The reason is, that .log is logged into the debug.txt by default. It's easier to analyze it.

I suggest to add help texts for the QA block by supporting the doc_items mod.

Support is very simple, you don't need to depend. You just need to add
_doc_items_longdesc = "<long description of what the QA block is good for goes here>"
and
_doc_items_usagehelp = "<explanation on how the QA block can be used goes here>"

to the node def. of the QA block. There is no length limit.
The QA block is quite complex now, so I (and especially other users) would appreciate a good and understandable explanation. :-)

You can test the help entry by installing the Help modpack:
https://forum.minetest.net/viewtopic.php?f=9&t=15912

In the Globals tab, you can double-click booleans which opens the editing menu. But if you save, the variable becomes a string.
You can also overwrite an userdata variable like this and accidentally turn them into a string.

I think the editing menu should only open for strings and numbers, but not for any other data type because it is only able to save values of these types.

I suggest to use color coding for the list of variables in the Globals tab.

Use a different color for different variable types.
For example:

• Cyan for functions
• Purple for strings
• Yellow for numbers
• White for tables
• …

I don't care much about the actual colors, what is important they are easy on the eye and easy to distinguish.

qa_block pollutes the global namespace with the variable smartfs_enabled but I think it should be made local.

The global variables check complains about the bit table looking suspicious but this one is part of the official Lua API now for bit operations (see lua_api.txt).

So please add bit to the accepted global variables.

In the globals tab, there are many variables which come from the core APIs.

I mean global Lua variables like:

• _G
• _VERSION
• string
• math
• xpcall
• dofile

And global Minetest variables like:

• minetest
• core
• dump
• dump2

It is not really useful to have these in the list as they just clutter the view IMO. I am mostly interested in the globals which come from mods.

I like to have a checkbox which allows me to filter out anything which comes from the core APIs (either Lua or Minetest).

Activating the checkbox should filter out:

• Functions which have “=[C]” as the source (this automatically means they come either from Lua or Minetest)
• Functions in the path of builtin (more Lua API stuff)
• For the remaining variables which are not functions:
  • All top-level globals defined in http://www.lua.org/manual/5.1/ (e.g. _VERSION)
  • All top-level globals defined in lua_api.txt (e.g. minetest, core)

The first 2 checks can be done automatically. The non-function variables can be filtered out by a hard-coded list.