Access _G super-variables without a module?

Solar2D Lua Language
#1

After a few lengthy topics on the subject of regular globals vs. _G super-globals, I thought I understood how this stuff worked. But clearly, I’m mistaken.

Basically, I have an important game-wide table in main.lua:

\_G.importantstuff = {}

However, it seems that when using Beebe’s external modules tutorial…

local M = {} M.functionName = functionName return M -- etc etc

I can’t access the _G.importantstuff table in my other lua files unless I use the module seeall function that the tutorial was specifically written to avoid.

So…am I missing something obvious here? Or does this method just exclude the use of globals reaching outward? I’m just now sure how to pass information without seeall…

[import]uid: 41884 topic_id: 19836 reply_id: 319836[/import]

#2

Okay, I guess I just don’t get it. It seems to work for some things but not for others - is there a really small limit on the size of super-globals?

[code]–main.lua

_G.worldSettings = {
tileSize = 64,
rows = 32,
columns = 8,
}

_G.tileTypes = {}
tileTypes[1] = { name=“dusty floor”, id=17 }
tileTypes[2] = { name=“volcano”, id=31 }
tileTypes[3] = { name=“shoebox”, id=42 }
tileTypes[4] = { name=“elsewhere”, id=12 }

– Note that it doesn’t seem to matter if you say _G.tileTypes[1] or tileTypes[1]. Not sure why…[/code]

Now if I try to refer to these in an external module without …seeall,

[code]
– Near the beginning of the lua file
print(_G.worldSettings) – comes up as nil.
print(_G.tileTypes) – comes up as nil.

– Later on
locationText.text = tileTypes[1] – success, prints out “dusty floor”[/code] [import]uid: 41884 topic_id: 19836 reply_id: 76957[/import]

#3

Talking to myself, I know…

  1. So the problem is solved by stating the table BEFORE including the module. I’ve never heard of needing to do things in this order before, but I guess that’s how it works.

  2. What has become really unclear to me is when “_G” must be specified. My external modules seem to be working fine when I forget to add the _G. Is there any benefit to stating it for a lookup? [import]uid: 41884 topic_id: 19836 reply_id: 76959[/import]

#4

No, Richard, you are not talking to yourself. I’m listening.

About the point #2, I’m just as puzzled. I thought we’d always need to add _G. if/when the global variables are declared with _G. (i.e., local myVariable would be local, but myVariable without local in front would be global and _G.myVariable would be super global.)

I’m wondering if you tested a case where you have an external module that uses regular global variable (i.e., myVariable without local in front) while in your main.lua, it is always declared and referenced as super global (i.e., _G.myVariable). Does it really work?

Naomi [import]uid: 67217 topic_id: 19836 reply_id: 76962[/import]

#5

What I found that works great for me that I’ve been using for a while that does not use globals or modules w/seeall is using the power of ‘require’. I’ve only used this with ‘Director’ but I’m sure it’ll work without it.

First create a file that will be used as a ‘carrier’ for your variables that you want to share throughout the program.

-- myGlobals.lua  
--  
-- My global variables  
--  
local myGlobals = {}  
  
-- create whatever variables you want to share  
myGlobals.score  
myGlobals.currentPlayer  
myGlobals.currentLevel  
  
-- make sure you return your global table  
return myGlobals

Now you want to include this file in every module you want to share your global variables starting in ‘main.lua’. You can also set a default value for each variable.

  
-- main.lua  
  
local myGlobals = require("myGlobals")  
  
-- read and write the variables as you wish  
  
myGlobals.score = myGlobals.score + 100  
myGlobals.currentPlayer = "Player1"  
myGlobals.currentLevel = 2

In another file you have access to the same variables because when you ‘require’ the module/file again, Lua see’s the module/file is already loaded in memory and just returns the reference to the already loaded module/file. Just make sure to use the same file and variable names throughout your program.

  
-- game.lua  
  
local myGlobals = require("myGlobals")  
  
print(myGlobals.score)  
myGlobals.currentLevel = 3

You can also use json coding and save/restore your globals to a file.

I may be missing something but it’s been working great for me. Hope this helps.

Jeff

[import]uid: 14119 topic_id: 19836 reply_id: 77003[/import]

#6

Naomi , the “talking to myself” bit was not a cry so much as noticing I’m answering my threads right away. As per usual with past-midnight threads I do figure out a solution, usually right after posting. :wink:

(I specifically remember your super-thread on super-globals!)

The problem was, as mentioned, that Corona runs a check on any included modules before progressing forward, so I had to move all of my tables before my includes. I’ve seen a lot of Corona code examples that put includes first but that will no longer be the case for me.

Speaking globals theory…

I think that Corona is probably using the same upwards lookup it uses for locals vs. globals. That is, when I look for the variable “funtime” and the only one running is _G.funtime, it goes with that. But check this out:

[code]-- in main.lua
_G.funtime = 73
_G.salsa = 1000

local tacotime = require “tacotime.lua”

– in tacotime.lua
salsa = 1234

– test funtime
print(funtime) – 73
funtime = funtime + 2
print(funtime) – 75

– test salsa
print(salsa) – 1234
print(_G.salsa) – 1234[/code]

Basically, Corona can’t distinguish between normal and super globals. Once you set _G.salsa, you can no longer make a seperate instance of salsa unless it’s local. So no, you don’t need to specify _G after the 1st time. Nifty.
Jeff , that’s a phenomenal idea. I think I’ll go with that and see how long it works out. I’m not really sure what you mean by JSON coding (I haven’t done any of that yet, not sure if it’s needed) but yeah, I can’t see anything preventing that from working with sqlite or some other method of saving. [import]uid: 41884 topic_id: 19836 reply_id: 77041[/import]

#7

Hey, Richard, thanks for the detailed post on how super global works with & without _G. Wow, that is super interesting and darn important to keep in mind. (And LOL about your mention of super-thread on super-globals – I think I know which thread you are talking about.

And, Jeff, thanks for posting how you set up myGlobals.lua file. Actually, I used to have gamedata.lua file that worked exactly the same way as myGlobals.lua – but after a while I realized I don’t need as many global variables as I originally thought I would and decided to switch over to _G. That said, when I start a new project after the current game is done (and now that I have a better feel for things), I’ll probably go back to myGlobals.lua method.

Cheers,
Naomi [import]uid: 67217 topic_id: 19836 reply_id: 77108[/import]