I have a few ideas for Construct 2. I have only a basic idea of how the compilation and parsing in construct works, so I'm not sure how difficult or plausible any of the immediate following is, but this would be awesome, and if any aspect of it is possible, it would be worthwhile. Also, if the SDK were designed so that creating a plugin that does any of the following, that would be just as good. I apologize for the wall of text, but I have alot of ideas, and it's better to get em out now, than after the groundwork is laid, so read this as your leisure.
- a debug mode where you could step through the event sheet. Event by Event, or tick by tick.
- finer granularity of stepping down to subevents, conditions, and actions.
- the ability step through python lines.
- when cap is run without stepping, being automatically directed to the lines of python errors
- rewind to the last action, condition, subevent, event, tick, or python line
- rewinding to several levels
- being able peek into variables, including private and global variables and python variables.
- being able to pause the layout and drag and drop objects.
data and variables:
- object and object type variables
- arrays of all current types, plus the object and object types.
- arrays integrated directly with construct as opposed to a separate object the way private and global variables are.
- global arrays of all aforementioned types
- arrays being 0 - indexed, it isn't just about noncoder vs coder, there is alot of math that works on 0 indexing, especially when working with arrays.
- a native way to create more complex data containers, that can contain other data containers and any of the previous types of variables and arrays,
- being able to define these data containers for later iteration. being able to create arrays of these containers.
- previously stated debugging ideas would apply to these data containers as well
- being able to pick object variables in all the same dialogs as objects and families
- being able to save any data container to an encrypted file, or load from
- the ability to save different event sheets or layouts to separate files, to be loaded when the primary exe has started so there isn't just one large exe. This would also allow downloadable content to be automatically possible with no special provisions other than the ability to load them
- a callback function (or something) to allow triggered conditions in python
- search and replace
- being able to export non python event sheets into python code
- being able to import python into the event structure if python consists purely of ACE calls.
- autocomplete for variables
- right click: goto function definition
- A way of creating edittime functions in python that can be accessed through the ACE Table like: (python example code)
then being able to access an object bearing the name of the event sheet (where it is possible to access a system object) and use acetables created in this way
- being able to define the tabs , and subcategories for ACE'd python functions within the ACE dialogues
the previous features combined with the next would basically give any user the power to create plugins whether they were familiar with python, or event-exclusive users
cap files,event sheets, and system actions
- being able to do the same ACE related thing with events. Perhaps on special edittime event sheet you would have a way to define the ACE Table, to correspond with the variables(including object variables, and the other new ones) in the Special event sheet. then on the normal events sheets you could choose from these addition ACE table objects as well
- search for all occurrences of an object in the event sheet
- being able to copy and paste events and objects between caps.
- a 'copy to new cap' option to be able to export selected portions of a cap and paste to a new cap as a shortcut to creating a new cap, and then pasting.
- when copying and pasting between caps or to new caps,for objects referred to in any A,C, or E's:
- the option to copy the object as well, if an object of the same name is present, to overwrite, rename, or skip.
- the option to replace all references to each object with a variable, of the same name as the object, with the option to change.
- the option to simply not copy the action, expression, or condition containing the reference to the object
- System actions to modify the SOL in arbitrary ways like a plugin can
- a SOL index for all object dialogues so you can specify separation of picking of a single object, for instance, assuming there is only one Sprite type and the index :
On Sprite collision with Sprite
like the family picking trick, but more direct
SDK (including integration with aforementioned event and python ACETABLE features)
- the way defining an equivalent python command in every ACE Table entry is a requirement is brilliant. I think the same should so of callfunction(), and getdata() in runtime. Of course it wouldn't be those two functions, but I think each plugin should be able to access and trigger all actions, conditions, and expressions of another type plugin the way python can. That way you can make plugins that enhance other plugins.
- the sdk was designed to complete plug into a very modular c2, thus enabling any of the aforementioned possible through a plugin with the same seamless integration
- all basic UI controls such as text boxes, drop down boxes, file dialogues, buttons, sliders, radio buttons, pop windows, etc to be able to easy add custom UI and dialogues for behaviors, objects, and any extra plugins created for the construct ide.
- basic graphical elements such as line, point, icon
- being able to create dialogues from construct layouts
- being able to to use any of the aforementioned custom controls and dialogues for Action and Condition dialogues, and property panels
- zoom in and out of event sheets and python
- edittime z_distance