Local variables

Deadeye: There is no 'problem' with using a buffer sprite if you think about it that way, but it definitely is a somewhat hacky way to do it. Because it's a workaround by definition. We don't have local variables, so we use bufferSprites to simulate local variables = Workaround.

If you use global variables for things that are global, why shouldn't it make sense to implement local variables that'd apply to layouts only?

Sure it's good that Aeal has done it, I just wanted to emphasize the point that this IS a workaround and someone who's completely new to Construct (and as it seems a lot of new people are joining now), using buffer sprites to store local variables would probably not be the first thing on their minds - So you have a steeper learning curve, cause you need to know this workdaround in order to make use of a local variable.

Maybe I'm a little too worried about this, but I've seen this same thing happening with Maya, where Alias (and now Autodesk) started explaining workarounds to their users that at first seemed perfectly fine, but once you start repeating this method over and over again, you'll end up with a huge chunk of workarounds for things that could be implemented natively, so that it would actually make a lot of sense. If you always know 10 workarounds for various tasks, good for you, but in an application that's decidedly non-techy, it's probably not what you want to do looking forward.

Again, I'm not out to piss on anyones boots or introduce egos here, I just want the app to grow into the right direction. Maybe the way I see it is bullshit as well, but I do think that this is a clear case of "Hey, it'd be cool to have this feature natively in Construct, so we don't have to use a workaround all the time!"

Potential feature creep.

There is one problem with local variables - what if you want to read a variable of another layout? That is right, you cannot, because it is local. Like you want to check if the door was opened in another layout, but there is no way to see that until you get there.

Construct has several data plugins - Hashtable, Array etc. - you could make a global data object and store layout variables there that you can access from anywhere. They'll also be neatly organized into one bunch that you can easily browse.

I wish there were more types of data objects, though; a stack, a custom data structure (for characters for example) and so on.

Urgh, Mipey posted before I finished writing, but I'm posting anyway even though he mentions feature creep, which I also mention bleah whatever:

I guess I just don's see it as a "workaround." If there were a Layout Variables feature, and it didn't work properly, then you'd be forced to do a "workaround" such as making your own variable holder object.

Since there are no Layout Variables, then making your own variable holder object isn't a workaround. It's not a hack, it's a technique. It's not a bandage for a broken feature, it's a method to a means. Where you see a workaround, I see a clever solution to a problem.

I'm sorry, but I feel pretty strongly about this sort of thing. If you can do a task easily with a couple of clicks or few events, then a full-blown feature that does that exact same thing is largely unnecessary, isn't it? I'm not against adding new features at all, but if a feature is to be added then let it contribute to productivity in some significant manner.

And quite frankly adding little, single-task features like this, over time, will just lead to feature creep, or software bloat, or however you want to term it. Slippery slope? Maybe. But a sprite or a text object is a multi-tasker. You can do the same task without adding a new feature. And keeping out unnecessary features keeps Construct lean.

So if you have to perform some task in Construct, ask yourself... is it hard to do? Is it laborious? Does it involve complex math? Will an alternate method markedly increase development speed or productivity? Will an alternate method markedly increase runtime performance? Does a means to do it simply not exist? If so, then request away. Otherwise, ask yourself if it's really necessary. And I simply fail to see how Layout Variables are necessary.

No offense, Aeal

If there's a guy that'll come to conclusion "Oi! I need local variables" faster than noticing "Sprite object has private variables" then I'll be surely surprised.

The more ACEs or Plugin duplicating the existing ideas, the bigger mess you get in ACE list / Plugin list.

Edit:

I mean, I don't mind you guys making plugins. But if you won't make really helpful one, then nobody will bother downloading it. And even if some novice guy will use it, but he'll later encounter a problem and send up Needing-Your-Plugin CAP file, I won't be bothered searching for CSXes or even installing provided one. That'll make mess in my nice and tidy Construct Sanctuary and will force me to get to know new solution's I won't use (what for?).

If you consider what a workaround really is:

"A workaround is a bypass of a recognized problem in a system."

"Typically they are considered brittle in that they will not respond well to further pressure from a system beyond the original design."

Then it's clear that using organised methods to hold your game data - such as a hash table or array - which can be saved to disk properly, unlike layout variables would potentially be able to - are neither a workaround nor tough solution, but a genuinely superior one for many uses.

Layout variables are a feature I can see some people using, but ultimately sometimes causing themselves more organisational or hassle as a result of, when there's easier solutions out there! The only caveat is that initial values for hash tables/array can't be set; this can be remedied via some very simple additions to the SDK. If a dev wants to take it on I can send them the sources for either.

Just to clear this up:

Aeal: Your plugin isn't really well designed. It's the same thing that deadeye suggested, it's just an object with private variables - so that doesn't make a lot of sense. I could use a sprite, use my own icon and fill it with a private variable.

What I was thinking about is a local variable that's based on your layout. So you'd be able to click on your project and set global variables and you'd be able to click on each layout and set local (layout) variables.

Rich: A workaround is not just something you do in order to steer around a bug. A workaround is also a solution you use, because a certain feature that you want is not implemented in the application yet - so you come up with your own little idea that might work, cause the program is complex enough.

I'll give you one example - In Maya, you were never really able to store assets properly. So people just started creating 'groups' and deleting all the shit in it, so they ended up with a completely empty node and filled that node up with custom attributes (like private variables) - tada, we got an asset node.

Now, in a recent release, Autodesk actually created a feature called 'assets' that handles this for you without the workaround that's using empty nodes and it's a lot more comfortable because it aids the user as well. It's easier to set-up, it's easier to organize, it is its own entity specifically designed for a certain task that users used all the time anyway - but they had to fake a method up until that point.

We have global variables. If I have 300 levels and I want to use a variable for each level to control a certain event, I could just use a layout variable and wouldn't have to clutter up my global variables.

[quote:31h9775w]The only caveat is that initial values for hash tables/array can't be set; this can be remedied via some very simple additions to the SDK. If a dev wants to take it on I can send them the sources for either.

I'd fucking love that!

Aeal: Your plugin isn't really well designed. It's the same thing that deadeye suggested, it's just an object with private variables - so that doesn't make a lot of sense. I could use a sprite, use my own icon and fill it with a private variable.

Nope its not badly designed, it is exactly what I wanted. If you bothered to read through the other posts you would have seen I have no problem with using a sprite to hold "Local variables" for now, I just didn't like the thought of wasting Vram. And since I very rarely share caps of a game that I am working on with people I wont have a problem with the "Plugin not Avalible".

Its exactly what I wanted. If I can easily make it easier to link them to the layouts then fine i will but as for now its an easier solution for me to open the sdk set a few properties and compile my own solution. I really dont care if any of you think its a bad Idea then don't use the plugin, I made it for myself and I just decided to share it with you if want to use it.

The SDK can't do what I think some of you propose, which is to have the variables in layout properties.

Also, there is no definition I can find of workaround which doesn't mean working around a problem or broken feature; in this case there is neither, as better solutions than the supposed 'workaround' exist .

Aeal: It's cool, didn't want to piss you off. I just thought your plugin isn't what you suggest on the thread. I always thought you were talking bout layout variables.

The only way we can really get the feature that Im talking about would be to build it into the IDE. Since there is no point in modding the IDE I made a plugin that will do the same thing without taking up vram

Aeal: It's cool, didn't want to piss you off. I just thought your plugin isn't what you suggest on the thread. I always thought you were talking bout layout variables.

Yeah, that cannot be done with the SDK...

a 2x2 png takes up 148 bytes. i think 2x2 is the minimum that can be loaded into vram, since its the smallest multiple of 2.

i seriously doubt 148 bytes is going to make your game have any loss in performance, the implementation of layout variables would probably use more power than the sprite anyways.

would a game really need that extra space?

Aeal i think youre a lil too paranoid about performance in that sense. if you really wanted to be making youre games that effecient why even use construct, technically its making youre game alot slower than it needs to be? why not use C++? well you dont really have to, do you?

This isnt a workaround, it really wouldnt be all that usefull to have layout variables, they're a very negligible feature, i much rather the devs spend times fixing bugs than implementing things which have a very small advantage (148 bytes of vram) over a technique extremely easy to set up.

not that its a stupid idea, but having them really has no strong advantages.

Not in the way this plugin works - cause it's essentially just a sprite with a private variable, but without the memory footprint.

But I still think it'd be cool to have a local variable that's based on layouts without having to use sprites as buffers.

The first problem with this topic is calling "using Sprite's PVs" a workaround. This is so intuitive and easy to handle local variables that it doesn't even deserve to be called "a workaround".

Please don't add unnecessary ACEs to "System" object. Construct needs compromise between number of ACEs to master and their power. The more there are ACEs, the harder is Construct to learn.

Quazi I hope you don't get serious Aeal's talking about "saving VRAM". He can't be serious ^^.

But seriously, what's a small 2x2 or even 4x4 sprite going to do? heck, use a text object with no text! (or does that use vram in some weird rendering way?). You guys can't seriously be annoyed at using 148 bytes of Vram? That's BYTES! One nice fat texture in your game and those bytes just fade away up in the memory useage that one texture takes. There's practically no point to layout variables. Why not just use a global variable and tell it to change on the start of each layout you want it to change in?