Exporting variables?

[jimbus]

I'm using Modules on 3.0 delta and I'm excited for modules! I'd posted something on this functionality recently, not knowing it was in the new version (I still haven't been able to find a list of changes for 3). It seems the process is to export a package and import it as a module, then delete the original instance. Has been a bit dirty getting started across multiple characters in multiple states, learning by feel, but I'm getting there.

The only issue I have so far is it doesn't seem that variables export. You can export them, but the xml file it creates is empty. I've put all of my character traits that I want to track in a list called, oddly enough, charTraits. I've tried highlighting the list, unchecked and checked and highlighting the main variable entry and it creates a 0 length file.

Am I missing something?

Humbly your,

JimB

[SlySven]

I know what you mean - and I am one of those trying to improve the code!

I have found the hard way that toolbars really need some work in this area - they do not handle wrapping up in a module properly - but there is already some other aspects of toolbars & buttons that need some TLC right now!

The exporting a module, removing the source and then importing the module to use it in the originating profile is a bit cludgy IMHO also...!

Variables are a bit of an oddity to me also - I don't have a full handle on how they are handled!

Is it the existence of variables in the module or their value that is not being exported? I think the former can be taken care of with script in the top level script folder (not the brown "module" with the module "name" one but the one below that) that checks for a valid value and then creates and initialises the variable if it isn't there is I think done with something like:

Code: Select all

local myStringVariable = myVariable or "The string I want it to be if it has just been created"
local myNumericVariable = myNumericVariable or 42
local myTable = myTable or {}

In code that is currently in the GitHub repository and which will be the preview 3.0.0-epsilon or the 3.0.0 release version there is mapUserData and areaUserData map elements - and the first may be useful to stash such details in - if you are sharing a map between profiles.

I have prototype code (not ready for public use yet) that improves such sharing so that the player location is saved separately for each profile and attempts to preserve it when copying between profile - but I have recently become aware of an algorithmic problem if the map is not pushed out from the "master" profile to the "slaves" in the same order each time.

Note that each profile in a "multi-playing" Mudlet is isolated from all the other profile that are loaded - getting information between them will require some file jiggery-pokery (does the Lua File System "lfs" work with "named pipes"?)

In that vein, I did experiment a while back with a sysProfileInterlink Event that would pass a signal with a (variable: originally string or numeric but would probably also handle booleans now) argument to all the other profiles in strict sequence so that the sending profile got the event last after it had done the rounds to the others. This showed promise but needed further work to handle variable numbers of supplied arguments - again I do not know how relevant that is to your desires but might be useful once I get it done...