Add a new global variable, _S

Feature Requests Studio Features
#1

For use in the command bar or scripts ran in Studio, _S would be the same as writing game.Selection:Get().

  • Yea
  • Nay

0 voters

1 Like
Allow plugins to access the command line environment
#2

I don’t see what this could hurt. _S={} could also become game.Selection:Set({})

#3

I sorta disagree. I don’t think it’s right to create a global variable just for this purpose. Global variables should be used for more important things.

6 Likes
#4

This is the kind of thing plugins are for. Just made this real quick.

1 Like
#5

This is what Plugins are for, sorry, but I think this is an waste of the global environment.

#6

NO!

I hate global values.

6 Likes
#7

If it is only limited to the command bar, then thats fine. I mean, the command bar should be a quick way to do some short script snippets, so there should be lots of shortcuts available.

If its an actual script or a plugin, then readability and such are more important, its more practical to make a module or your own shortcuts, and the relative cost of typing out the full statement is lower. So only for command bar.

2 Likes
#8

The underscore makes it look like a hack, and the name is just a single letter which doesn’t really describe the global. math, shared, etc are self-descriptive global names. Also I don’t see any use case for this in production environment, seems it’s most useful for plugins and command bar.

#9

The problem I see with this is that it adds unnecessary redundancy and clutters the global scope

5 Likes
#10

we don’t want rbxlua to become PHP tyvm

4 Likes
#11

Does loadstring work for plugins? If so, maybe its easiest to just write a custom command line plugin?

Also, why wont my stupid toolbar auto-minimize so I can post this message, how do I force it…
googles
Ok, had to right click all the minimized tray icons one by one and then it closes. Makes sense. Not.

#12

Global variables kill. Just ask a certain car manufacturer…

6 Likes
#13

If not this, at least allow us to keep the same environment in the commandline…
Having an option “Keep environment” would be ideal.
(especially if it also adds a rightclick option ‘Create new environment’ for when env is screwed)

#14

Perhaps this is a better solution?