You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jul 30, 2020. It is now read-only.
Data Structures interface should be more universally accessible.
Using the DS interface as it is now will probably be most useful for interface building (like creating new extensions).
As far as exposing variables that are part of a script, that should be done from the script editor.
For code mode, use metadata (try to make it concise). (This will require a lot of documentation.)
For design mode, have a similar interface built-in to the attributes pane.
You can also write freeform code to create classes and structures, and tie those to data structure definitions.
The text was updated successfully, but these errors were encountered:
This will work well when Design Mode can be abstracted away from the context of behaviors.
On the Stencyl side, I'm currently working on a number of changes on this front, such as reading blocks from an xml palette, and giving each individual block a context, so it knows where it can/can't be placed. When all is said and done, I hope that I can leverage Design Mode + Data Structures so that normal users can easily code their own Dialog plugins.
We already have a pretty wide range of control of the code generated from Design Mode, given the "custom import" and "custom code" events, and the inline code blocks. The next step in a more freeform Design Mode would be to allow...
custom package organization (but maybe one could argue against the need for this when using an IDE like Stencyl)
classname
superclassing
implementation
...where superclassing and implementation are directly tied to what events and what blocks are available for use.
For those who prefer coding in Haxe over design mode, I guess the best thing would be to use a system similar to Stencyl's current use of metadata.
@dsProps
{
/** Some comment. **/
var fieldName:Int = 20;
//same as <field name="fieldName" label="Field Name" type="Integer" editor="Simple" hint="Some comment." default="20"/>
//Using further metadata, individual fields can be overridden
@editor("Spinner")
var field2:Int;
}
Having the Dialog Extension enabled when creating a new code resource could make a "new dialog extension plugin" option available, which would fill in all the needed presets (basically just set the superclass to DialogExtension, and maybe do some things with the constructor, add some templates for new commands).
Data Structures interface should be more universally accessible.
Using the DS interface as it is now will probably be most useful for interface building (like creating new extensions).
As far as exposing variables that are part of a script, that should be done from the script editor.
For code mode, use metadata (try to make it concise). (This will require a lot of documentation.)
For design mode, have a similar interface built-in to the attributes pane.
You can also write freeform code to create classes and structures, and tie those to data structure definitions.
The text was updated successfully, but these errors were encountered: