Local variables

Variables local to the layout would be awesome. It would really help clear clutter from global variables and you could edit them during the edit time. They would be extremely useful.

I want it too, Layout Variables will be useful and awesome

Do not want it. This is just another source of data (we have PVs, Hash Tables, Arrays, Global Variables at the moment, it's much enough). And it'll take some more ACE entries.

just use an invisible sprite, theres not really a need for this

Do not want it. This is just another source of data (we have PVs, Hash Tables, Arrays, Global Variables at the moment, it's much enough). And it'll take some more ACE entries.

You dont have to use them.Hash tables cannot be editied in the editime only in the runtime. But as for arrays you can edit data in the edit time but it would be easier to access a specific name variable.

just use an invisible sprite, theres not really a need for this

Invisible sprite will take up Vram and that is a waste of memory no matter how small it is. Why waste the Vram?

1x1 sprite will only take 1 byte of VRAM. In theory.

Yeah I tend to use small invisible sprites off the layout for holding variables (a single sprite with a small image will use a negligable amount of VRAM, don't worry about it). Layout variables would be a good idea, but it'd be complicated to add now. It'll probably have to wait till Construct 2.

I know it uses a negligible amount of Vram but why waste it when there is no need to?

It still represents a decent solution till 2.0, for 1 byte of VRAM .

Applying Local Variables mechanism would take much more memory than single small sprite Aeal, believe me.

Or I could just make a quick plugin.

Get It Here

404'ed.

Do not want it. This is just another source of data (we have PVs, Hash Tables, Arrays, Global Variables at the moment, it's much enough). And it'll take some more ACE entries.

Wow. I won't ever understand this idea. Just because there are workarounds for a problem doesn't mean that the problem is fixed (and your suggested workarounds are far from being as convenient as a local variable).

Say you have certain effects that will only apply to a level (layout) and that you'd like to take control of by using a variable - since you might not want to use a global variable for every single level you build (the bigger the games become that we build in Construct, the more painful it'll be to do everything with gvs), and you want to keep the game logic 'logical' (maybe so that someone else could understand it as well) a local variable would be perfect.

We had a similar argument on the chat yesterday as well. There's this notion here that the solution to a problem (if a feature doesn't work or the app isn't yet feature complete or production ready) is not that important if there's already a workaraound available.

I think that it's very short sighted to rely on your users using workarounds for problems. I've seen that over the years happening with complex 3d apps, where some things are now really hard to learn for students, cause they just don't get the workaround that was introduced 3 years ago to 'solve' a problem that was never fixed because it would've been too complex to do at the time. So since the problem was 'somewhat solved', the developer never went back to solve it properly - probably because fixing bugs isn't sexy on release lists.

Just because something is theoretically possible doesn't mean it's practical. Construct, just as 3d applications, is (going to be) a complex piece of software that a huge chunk of people with no technical background will use to create amazing stuff - and that's the beauty of it. But the more you ask them to use workarounds that often need you to think in very technical terms, the more you alienate users that are probably more interested in just making their art come to life.

It's not that Layout Variables are necessary to avoid workarounds, it's that the same exact thing can be achieved with very little effort and very little overhead, as compared to the effort needed by the developers to implement a feature such as this.

In other words, if you can easily do the task another way (and in this case, you can), then the feature being requested is pretty much useless, so why bother debating a whole new method of doing things? (Especially when the developers themselves have said "not bloody likely?")

Using a sprite, or even a text object, to store variables isn't hacky, it isn't cumbersome, it's not some outrageous or radical idea, and it would have just about zero impact on your game performance, so... what's the problem again?

It's all rather beside the point anyway since Aeal has already made a plugin that does this very thing, and actually has more functionality than Layout Variables because you can have more than one object per layout to store your variables in if you wanted to.

On the other hand, Aeal's plugin is a third party creation that not everyone is going to have, so it's just going to cause problems down the line if your .cap uses it and you need assistance in Help/Tech or something, because people will just be confused about why they can't run your .cap and then they'll have to go download the thing and install it and blah blah blah... or they just won't bother.

Long story short... there's not a single thing wrong with making a separate sprite or text object that stores certain variables for you, I do it all the time in my projects. It makes the whole concept of Layout Variables rather pointless if you think about it.

Classic, open source working the way it's supposed to.

Devs make what is absolutely necessary, third party's come along and add to it.

Its a great little system, not perfect, but it works, and the reason it works is because it leaves room for these differences of opinion. In other words if you don't like something... change it. If someone else doesn't like the change they don't have to use it.