Could you be a bit more explicit concerning the getter and setter for the variable? (Small example of how to use them maybe?) 
Yeah multitouch must definitely be added when export for mobiles will be supported.
For multitouch support I think making special event would be kinda confusing. I propose following thing (which doesn’t make sense under normal circumstances - PC):
Left button is pressed
Mouse is at X:200 Y:100
Mouse is at X:300 Y:12
- this will check if player touches both X:200 Y:100 and X:300 Y:12
Also:
Left button is pressed
Mouse is over object Enemy
Mouse is over object Fire
Will check if players touches both object Enemy and object Fire.
Hmm… seems reasonable. I might give that a try. Thanks for the suggestion 
Yeah Surely.
For example If you want to pass a value to the game from outside or communicate this value externally, it would be one really helpful and useful feature. This could be used to do what not with other APIs. Suppose I have made a kongregate game, then I can use a getter for a certain variable(lets say score) and check with the high score on kongregate. If this does not exist set as highscore, if it exists; check if highscore is not more than equal to current and hence set it as highscore.
I’m looking for getters and setters paticularly for android stuff. If you can do something about it(not in an update, right now) then I would be grateful.
When I choose conditions or actions the window for them often is moved down a bit so I can not press “OK” button without moving the window up a little. It would be helpful to show those windows with button “OK” accessible.
Initial position of the window:
After moving the window:
If you want to select all available extensions you need to check every of them by hand. What about button: “Select all”?
Both should be relatively easy to implement. If Florian won’t ninja me on that, I’ll implement it (along with few other fixes such as setting OK to default button in every dialog box, so you can exit it by pressing enter) as soon as I get my hands on GD code.
It would be great and will prevent users to close the window without actually applying any changes to it because of forgetting about this invisible “OK” button. And about Extensions it will save user’s time too.
I would like to select “Random color” instead of typing this expression: ToString(Random(255))+";"+ToString(Random(255))+";"+ToString(Random(255))
And after choosing a color it would be helpful to show it too, not only RGB values of it.
I like GD, but creating actions and events are hard for me to learn and understand
I’m with bluberblabber. It is hard for beginners to learn with so less resources. There are only a few tutorials. I figured it out quickly because I learned coding, but for other people, it is much harder to understand. A better wiki could help this.
Would like to have a detailed manual with examples of using all features. Plus more tutorials too. For now can use manual, tutorials and examples of Construct2 because it’s similar to GD and there are a LOT of them .
Hi
Wouldn’t it be more convenient to place all variable actions/conditions in a single category?
Variables:
- Global Variable
- Global Variable string
- Scene Variable
- Scene Variable string
- Private/Object Variable
- Private/Object Variable string
Searching private variables in All Objects category confuses me every time.
Object’s variable are in “All Objects > Variables” because it’s related to objects.
But it relates to variables too So maybe it will be more convenient to have them all in one place, as Daisbarg says.
I’m getting confused with searching events for Objects and Sprites, which can be in one of this topics and even in both of them (like ‘Collision’, for example). I think maybe to unite Objects and Sprites in one group because Sprite object is by default already in use by program, so it doesn’t need apart topic as other extensions like ‘Text entry’ or ‘Tiled Sprite’.
Those are two different collision detectors, the “For all object” collision detection uses the collision masks (all object types have collision masks), the sprite collision detection is a per-pixel-detection (only supported for sprites)
It doesn’t mean that every object type derives from Sprites , e.g. the Sound object is not derived from Sprite, and probably would be a high, unnecessary, memory and performance consumption to remember things like sound’s angle, image, flip, blend mode… pixel-perfect collision detection? 
But the Sound object, as every object, can be created and destroyed, and has a position, actions and conditions placed in the “All objects” section
I’m talking about this:
Red points shows repeated topics.
I think it’s totally safe to merge these two groups in one. The group ‘All objects’ or just ‘Objects’ will include all conditions of the group ‘Sprite’.
As Lizard-13 explained, the actions or conditions in the Sprite category are specific to sprite and can’t be applied to other objects. So they have to remain separated, otherwise the user could be confused why some actions applies to some of its objects but not to some others.
Removing where to save project from new project window. Seriously, I often forget to set this so I’ve ended up having directories like “my project 6”, etc. Instead, after clicking OK in that window standard Save As dialog should show up.
I don’t know, it adds another window that should be completed before having the game created and I want to keep the creation of a new game as lightweight as possible.
Agree with Darkhog, it sometime happens to me as well.
Really, if anybody wants to develop a game, by end of the day need to deal with folders and need to know anyway where the project files are located on the computer, so not a big deal to force people to create folder and select folder where to store the project files. But if you want to keep it lightweight for new users to jump in to game development easily when using GD, how about my very first suggestion to improve GD usability?
If you don’t remember it was something like this:
GD could use a temp folder to create a temporary project at start to have a fresh empty project ready to use on every start. This folder would be wiped out on every start. Also, users should be able to add new objects by simply drag 'n drop them from folder straight in to the scene. This way users don’t have to create a new folder, enter path and copy sprites, sounds in to that folder manually only to test few things and play around with an idea. If user would like to keep the “temp” project, can save it and enter name for the project and store it in a default location to keep it simple, or save it as and choose folder/location in that case and also platform but ideally, we should choose platform only when we are about to compile the project. To run preview we could set a default platform in options to make it easier to use a temp project. Of course, user could also create new project the “traditional way” as it is now, but user would be forced to select folder in such case. To have a temp project at start and to be able to drag 'n drop objects from folder in to the scene/project would make development and testing very convenient in my opinion.