[Question] Inconsistant behaviour with "minetest.global_exists"[Answered]

[sirrobzeroone]

Just seeing if anyone else is seeing odd behaviour with "minetest.global_exists"

Im on Win10, have both hudbars and 3d_armor in depends in optional depends.

Code: Select all

depends = 3d_armor
optional_depends = hudbars, mobs, mobs_monster
description = adds part hearts

Intrestingly I can get global_exists to return true/false with default, stairs, craftguide, mobs as soon as I try 3d_armor or hudbars they both return false even when enabled.

Even more intrestingly I can add mobs and mobs_monster to optional depends both enabled and Ill get mobs = true and mobs_monster = false the paths work fine.

Test code

Code: Select all

local test1 = minetest.global_exists("mobs") 
local test2 = minetest.global_exists("mobs_monster")		
local test3 = minetest.get_modpath("mobs")
local test4 = minetest.get_modpath("mobs_monster")

Debug output

Code: Select all

2020-12-26 12:02:08: [Main]: mobs: true path:C:\Users\sirro\Minetest\minetest-5.3.0-win64 (2)\bin\..\mods\mobs_redo
2020-12-26 12:02:08: [Main]: mobs_monster: false path:C:\Users\sirro\Minetest\minetest-5.3.0-win64 (2)\bin\..\mods\mobs_monster

I tried git issues search but nothing appears to come up:
https://github.com/minetest/minetest/is ... bal_exists

I did check the api as well and found:

Code: Select all

minetest.global_exists(name)
Checks if a global variable has been set, without triggering a warning.

I did checkout the global variable table using

Code: Select all

for n in pairs(_G) do minetest.debug(n) end

No sign of mobs_monster, hudbars in the output

Code: Select all

2020-12-26 12:18:01: [Main]: flowers
2020-12-26 12:18:01: [Main]: bones
2020-12-26 12:18:01: [Main]: assert
2020-12-26 12:18:01: [Main]: tostring
2020-12-26 12:18:01: [Main]: tonumber
2020-12-26 12:18:01: [Main]: io
2020-12-26 12:18:01: [Main]: rawget
2020-12-26 12:18:01: [Main]: PseudoRandom
2020-12-26 12:18:01: [Main]: dump2
2020-12-26 12:18:01: [Main]: PerlinNoise
2020-12-26 12:18:01: [Main]: ipairs
2020-12-26 12:18:01: [Main]: VoxelManip
2020-12-26 12:18:01: [Main]: SecureRandom
2020-12-26 12:18:01: [Main]: print
2020-12-26 12:18:01: [Main]: binoculars
2020-12-26 12:18:01: [Main]: pcall
2020-12-26 12:18:01: [Main]: fire
2020-12-26 12:18:01: [Main]: carts
2020-12-26 12:18:01: [Main]: rawset
2020-12-26 12:18:01: [Main]: WATER_VISC
2020-12-26 12:18:01: [Main]: vector
2020-12-26 12:18:01: [Main]: register_trapdoor
2020-12-26 12:18:01: [Main]: rawequal
2020-12-26 12:18:01: [Main]: _VERSION
2020-12-26 12:18:01: [Main]: next
2020-12-26 12:18:01: [Main]: os
2020-12-26 12:18:01: [Main]: load
2020-12-26 12:18:01: [Main]: string
2020-12-26 12:18:01: [Main]: type
2020-12-26 12:18:01: [Main]: VoxelArea
2020-12-26 12:18:01: [Main]: coroutine
2020-12-26 12:18:01: [Main]: core
2020-12-26 12:18:01: [Main]: Raycast
2020-12-26 12:18:01: [Main]: craftguide
2020-12-26 12:18:01: [Main]: Settings
2020-12-26 12:18:01: [Main]: hud
2020-12-26 12:18:01: [Main]: mobs            -- <<Mobs here 
2020-12-26 12:18:01: [Main]: farming
2020-12-26 12:18:01: [Main]: dye
2020-12-26 12:18:01: [Main]: xpcall
2020-12-26 12:18:01: [Main]: creative
2020-12-26 12:18:01: [Main]: xpanes
2020-12-26 12:18:01: [Main]: bucket
2020-12-26 12:18:01: [Main]: minetest
2020-12-26 12:18:01: [Main]: tnt
2020-12-26 12:18:01: [Main]: walls
2020-12-26 12:18:01: [Main]: doors
2020-12-26 12:18:01: [Main]: wieldview
2020-12-26 12:18:01: [Main]: debug
2020-12-26 12:18:01: [Main]: sethome
2020-12-26 12:18:01: [Main]: WATER_ALPHA
2020-12-26 12:18:01: [Main]: dungeon_loot
2020-12-26 12:18:01: [Main]: register_door
2020-12-26 12:18:01: [Main]: hb
2020-12-26 12:18:01: [Main]: setfenv
2020-12-26 12:18:01: [Main]: require
2020-12-26 12:18:01: [Main]: LIGHT_MAX
2020-12-26 12:18:01: [Main]: protector
2020-12-26 12:18:01: [Main]: stairs
2020-12-26 12:18:01: [Main]: DIR_DELIM
2020-12-26 12:18:01: [Main]: screwdriver
2020-12-26 12:18:01: [Main]: pairs
2020-12-26 12:18:01: [Main]: player_api
2020-12-26 12:18:01: [Main]: armor
2020-12-26 12:18:01: [Main]: PcgRandom
2020-12-26 12:18:01: [Main]: error
2020-12-26 12:18:01: [Main]: package
2020-12-26 12:18:01: [Main]: loadfile
2020-12-26 12:18:01: [Main]: dofile
2020-12-26 12:18:01: [Main]: AreaStore
2020-12-26 12:18:01: [Main]: setmetatable
2020-12-26 12:18:01: [Main]: dump
2020-12-26 12:18:01: [Main]: PerlinNoiseMap
2020-12-26 12:18:01: [Main]: give_initial_stuff
2020-12-26 12:18:01: [Main]: INIT
2020-12-26 12:18:01: [Main]: loadstring
2020-12-26 12:18:01: [Main]: collectgarbage
2020-12-26 12:18:01: [Main]: jit
2020-12-26 12:18:01: [Main]: table
2020-12-26 12:18:01: [Main]: math
2020-12-26 12:18:01: [Main]: LAVA_VISC
2020-12-26 12:18:01: [Main]: ItemStack
2020-12-26 12:18:01: [Main]: _G
2020-12-26 12:18:01: [Main]: select
2020-12-26 12:18:01: [Main]: getmetatable
2020-12-26 12:18:01: [Main]: unpack
2020-12-26 12:18:01: [Main]: getfenv
2020-12-26 12:18:01: [Main]: sfinv
2020-12-26 12:18:01: [Main]: default

So it would appear from the above not all mods when loaded set a global variable? Is this known behaviour and I've missed the doco somewhere? or have I stuffed something else up (more likely)?

Thanks again for the help.

Edit: Im asking as a number of mods use global_exists to confirm if a mod is enabled or not but this dosen't at the moment seem like a reliable way to me as the conditions around when a global variable gets set seem unclear to myself at the moment.

[ShadMOrdre]

The depends is correct, but not global_exist. Look for armor, not 3d_armor. There is no 3d_armor object.

Shad

[Skamiz Kazzarch]

So it would appear from the above not all mods when loaded set a global variable?

Exactly this. Since wheter a mod adds global variables (and which name they are gonna have) is completely in the hands of the mod maker.
There is convention that if you need a global table (for pasing around variables through your mod files or for stuff you want to expose to other mods) you use the same name as the mod which declares it, since it helps against mods unintentionaly interfereing with each other, but this is in no way enforced and completely in the hands of the writer of the mod.

One place where it might be usefull to check for the existance of a table, instead of checking for the mod, is when there are several mods which provide the same api. In that case you don't care if mod stairs_A or stairs_B is instaled, as long as both provide the function stairs.register_stair() it's all the same to you.

[ShadMOrdre]

There are countless mods where the mod name is not the name of the object created. 3d_armor mod makes armor object. It's best to at least "know" the code before coding against it. :)

Look at the furnace, it uses furnace_active and furnace_inactive, but provides default:furnace, or for a time, furnace:furnace. Horrible example, but still relevant.

Please mark this as solved. This type of info needs to make it into the wiki. Little inconsistencies that make for big headaches.


Shad

[ShadMOrdre]

One place where it might be usefull to check for the existance of a table, instead of checking for the mod, is when there are several mods which provide the same api. In that case you don't care if mod stairs_A or stairs_B is instaled, as long as both provide the function stairs.register_stair() it's all the same to you.

Even this is not reliable. I expect stairs.register to register a nodebox shape in the shape of "standard" stairs. But stairs_A might use this function for some other purpose, such as registering a schematic that may or may not contain stairs, or use it in any number of other purposes. I can village mods having a function name so that registers where stairs are for NPCs to find. The purpose and code of a function might entirely be misinterpreted.

I have purposely began to use a mod template, such as below:

Code: Select all

-------------------------------------------------------------
-- GAL (Game Abstraction Layer)  ©2020 Shad MOrdre (shadmordre@minetest.net)--
-------------------------------------------------------------
gal = {}
gal.name = "gal"
gal.version = "1.0"
gal.ver_max = 0
gal.ver_min = 1
gal.ver_rev = 0
gal.ver_str = gal.ver_max .. "." .. gal.ver_min .. "." .. gal.ver_rev
gal.authorship = "ShadMordre and others.  See credits.txt"
gal.license = "LGLv2.1"
gal.copyright = "2020"
gal.path_mod = minetest.get_modpath(minetest.get_current_modname())
gal.path_world = minetest.get_worldpath()

-- Intllib
local S
local NS
S, NS = dofile(gal.path_mod.."/intllib.lua")

gal.intllib = S

minetest.log(S("[MOD] gal:  Loading..."))

As an example, I can use a setup such as this to test for functionality within an object by using versions numbers, or testing if a specific function exists, within the object I intend to use, before I call the function. More code, but more robust.

Alternately, I simply code what I want, and ensure that all the other pieces work as expected. Either way, more work!

Shad

[sirrobzeroone]

Thanks both,

hmm that is an intresting and another thing I need to watch out for.

Now I see how it works I can see the global table hubbars creates as well - hb. I was foolishly making the asumption (hoping) the engine was just registering an empty global which equalled mod name for each mod loaded...

tagged as answered.