Global/world Var list.

ID:95523
 
May 15 2010, 12:32 pm
Resolved
world.vars and global.vars lists have been added.
Applies to:DM Language
Status: Resolved (512.1386)
This issue has been resolved.
A variable list for world and global variables, to accompany the variable lists for datums (sound stuff, atoms, and everything else)
It'd totally be awesome, so we can have like...a world edit! omg gasp.
May 15 2010, 6:18 pm
I'd like this too and I've looked into it in the past, but unfortunately it's not at all simple.
Oct 19 2015, 11:21 am
Bump.
Oct 19 2015, 12:49 pm
Yes, I would love to have this!

It's the only thing that stops me from having complete control over my worlds at runtime. You could use a global datum, but that kind of defeats the purpose of just using global vars.

It seems like the world object has some issues. Compare it with a client object, which isn't a datum either, but it still has a vars list.

DM just isn't complete without global.vars and world.vars.
Aug 7 2016, 6:56 am
Note: I thought there was a feature request for this already, but I can't seem to find it. I may be thinking of my 'global' bug report, which contained a potentially-expected behaviour similar to this.

Currently, there is no way to find what global vars have been defined dynamically; if you don't have a reference to a global var somewhere, it's like it doesn't exist.

I'd like to suggest a vars list on the global pseudo-object, used in the same way as the vars list on every datum.

For example, the following would print "G = 4":
var/global/G = 4

/world/New()
    for(var/v in global.vars)
        world.log << "[v] = [global.vars[v]]"


Alternatively, global.vars above could just be global, and global.vars[v] could be global[v]; since neither of these constructs are currently useful (see the bug report I linked earlier), this avoids conflict with any code that currently defines a global var vars, though introduces differences with the datum vars list.
Aug 7 2016, 8:16 am
In response to GinjaNinja32
This would be very useful sometimes.
Dec 11 2016, 5:53 pm
Bump
Dec 11 2016, 11:10 pm
The primary reason this can't be easily done, is because global vars are resolved at compile time and stored in a simple array with indexes but no name.

That being said, parallel arrays are a thing and a parallel array of names (string id) could work.
Dec 12 2016, 8:45 am
Basically, to do this I'd have to alter the .dmb format to save a list of global vars. (Also I'd want to finally differentiate between static and global for that purpose; the same flag is used for both.)

This is something I've wanted myself for quite a long time. I think it's probably doable now. The downside is that if I add it, it's a hard compatibility limit on new .dmb files.
Dec 19 2016, 12:32 pm
If anybody's wondering about this, I do have a solution for this, but it's far from pretty.

https://github.com/PJB3005/vgstation13/blob/globals/tools/ gen_globals.py
https://github.com/d3athrow/vgstation13/blob/Bleeding-Edge/ code/__HELPERS/globalaccess.dm

The script generates a couple procs: _readglobal(name) and _writeglobal(name, value) using a giant switch(). It also generates a global variable called _all_globals which is a list of global variables, by string.

Because -code_tree is kind of awful and I couldn't be bothered to make it perfect, it chokes on a couple things, namely root level variables that have /global in them (which doesn't do anything), there's a set you can edit in the code to exclude any strings that seem to be screwing things up though, if they happen to arise.

Oh and yes, it needs Python 3.
Dec 19 2016, 1:05 pm
Couldn't you just do this and access the datum's vars like you would an object?

var/GLOBAL_VARS/gvars = new

GLOBAL_VARS
    var a
    var b
    var c

proc/DisplayVars()
    for(. in gvars.vars)
        world << "var [.] = [gvars.vars[.]]"
Dec 19 2016, 1:41 pm
You could use a global datum, yes. It should be noted however that accessing a global var directly is quicker than accessing a datum var, and the datum method has a lookup for the datum itself plus a lookup for its var. It's good for situations where you need something like this, and of course there are other good reasons for global datums, but as a general solution it's only so-so.
Dec 19 2016, 2:40 pm
Yep, and let's not forget that if you've got a couple hundred global variables nobody wants to go and refactor all of them.
Jun 29 2017, 2:19 pm
Added world.vars and global.vars for 512. I need to test var writes, and then document, but otherwise this is in place.
Sep 25 2017, 11:55 am
Lummox JR resolved issue with message:
world.vars and global.vars lists have been added.