Construct 2 - what would you take away?

"Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away." - Antoine de Saint-Exuper

In light of this, what shouldn't Construct 2 have that Construct 0.x has? I thought this would make an interesting question rather than "what features do you want?". What would you take away?

Persist files. Please make them part of the project file.

Aside from that, tho... hmm.

Mmmm... maybe the image editor? At least in my case I prefer to use the gimp or others to paint or draw... mmm... but then how to make control points and those things?... mmm...

I would take away the distinctions and syntactical differences between variables and expressions, also the need for the global qualifier for globals, unless this would slow down the expression interpreter

so instead of accessing private variables like this

mysprite('myprivatevariable')[/code:1fv0onq6]
it would just be 
[code:1fv0onq6]mysprite.myprivatevariable[/code:1fv0onq6]

it would be up to the user to make sure they didn't name their variable something like 'x', or z_elevation.  I've always thought the (' ') format was kinda tedious

and with globals, instead of 
[code:1fv0onq6]global('myglobal')[/code:1fv0onq6]
it should just be 
[code:1fv0onq6]myglobal[/code:1fv0onq6]
again making it the users responsibility to not name their global 'timedelta' or anything of the sort

also, the array object,
arrays should be just as integrated into the rest of the system as pv's and global's are
and even though it's not used in C1, it would be better as [] instead of {}
if arrays could be used as private variables, again no special qualifier to access them just
[code:1fv0onq6]mysprite.myarraypv[10][/code:1fv0onq6]

When using an object's actions/conditions, you can use 'variable' instead of sprite('variable') already.

How about the modal dialogs?

ribbon

Random crashes, project file corruption.

The 3D box and 3D object, as for how they are they're mostly useless and maybe even the ribbon object.

Would probably be nice to place objects from the Object folder on the right and not have the Objects window in layouts and event sheets.

I would also say ribbon - it's not cross platform

the properties bar in the event editor, i mean its pretty useless to have there and just takes up space.

the properties bar in the event editor, i mean its pretty useless to have there and just takes up space.

it's useless, but it wouldn't be if you could still select the objects in the objects bar

I've always wanted that feature

it's useless, but it wouldn't be if you could still select the objects in the objects bar

I've always wanted that feature

Oh I second, third and fourth that!

I also think if we could make the project window be able to work like the object window, namely: select objects and get the properties window to change to that object (in both the event and layout editor) and place objects from the project view list to a layout, we could do away with the objects bar altogether. Since the project list could offer the same functionality but with much better overview while also freeing up some screen real estate.

I think the objects bar is a slightly unnecessary mainstay from the TGF days, although it might be useful for complete beginners. Heck even if you keep it and get the functionality I mentioned into the project list I could just close the objects bar myself.

I'd keep the properties bar, as I find it useful to read values that I need to use while I write events.

However, not being able to pick objects makes it pretty useful, so I'd like that.

The object bar is now taking up space and duplicating the function of the objects folder in the project panel, as they're usually both visible (but you can't drag objects out of the project panel!)

So:

-remove object panel.

-allow properties to be shown for an object clicked in the project bar, even while editing properties.

-allow objects to be created by dragging out of the project bar into the design area.

whee! more design space!

Also: the ribbon might not be portable, but I don't think IDE portability is a goal anway, just runtime. The former would be a TON of work.