EDITOR PLUGIN: Simple Scripter 0.01 (for AGS 3.0)

[SupSuper]

Introduction
Ever since it was announced that AGS 3.0 wouldn't have an interaction editor, I've been fiddling around with an alternative, since not everyone is experienced with scripting. However, being a scripter myself, I have no idea what non-scripters would find easier, so I figured I'd post my plugin here to get some feedback, even though it's far from complete.


Click to view the demo video. (5MB)

What is it?
Simple Scripter is a bit of an indirect approach to scripting. Instead of writing the code yourself, you just add functions, properties, etc, but Simple Scripter writes the code for you. Just right-click a script and select "Simple edit". The script is displayed in a listbox on the bottom, and the top area lets you change the line in question. For example, if you select a line with a Say function, Simple Scripter will give you boxes for the Character Script-O-Name and Message, and automatically update the script below with any changes you make. You can also add lines from a list of functions, remove them, copy them, shift them around, etc.
I guess the big challenge here is not only does Simple Scripter turn an "interaction" into script, it also does the opposite.

What I'm looking for
Mainly I'm looking for what people would like to see in a "interaction editor replacement" and if this comes any close. Bug reporting at this point is rather futile since I'm aware of lots of issues and things still left unsolved. The plugin works with a rather strict coding style (only one expression per line) and will probably fumble anything else, the script reference isn't complete, there's no validating, etc. Just let me know if you would like to see this developed and what you would like to see in it.

Download
v0.01 (1 Feb 2008)
Just put it in your AGS folder and run. You can probably goof around with this as much as you want since any changes you do to your scripts won't be saved unless you press the plugin's Save button. (not the AGS Save button) But still, I'm not responsible for any damage that you might somehow possibly manage to cause with it.

[Ghost]

Personally I don't miss the IE- I only ever used it to create a run script command. But from the video demonstration, I would say it surely looks useful for newcomers who are uncomfortable with the "total scripting approach" of 3.0, or who just do not know the complete list of commands.
I can see that it'll make scripting more accessible,  so I think there is some justification to make this project real. Plus, it's really looking professional how it simply snuggles inside the AGS IDE, just like a Xenomorph queen inside of Ripley.

Look and feel is really very good- again, judging from the video alone. Superior to the old IE window because it's part of the IDE and also because it has (as shown with the Say/Display command) separate slots to enter values directly. Nifty work.


BTW: You allow players to *BURN* characters in your script! Shame on you 

[monkey0506]

Okay, one of the first things that I questioned was the purpose of the "Syntax" option. I see you're trying to implement a bit of explanation of some common scripting elements, but currently it seems the tab can only be used for getting the description of certain syntactical elements, and then only by moving the mouse over them. The "Variables" option seems to offer similar usability.

So I opened up one of my scripts using your plugin. For some reason at the end of every single line I see one of those horrible boxes that certain fonts use in place of unrenderable characters. I'm not sure whose fault this is, but it looks terrible.

The next thing I noticed was that you can only have one script open at a time for "Simple" editing.

As I was intentionally trying to see just how far along this plugin was, I tried reviewing one of my modules. One thing I noticed was that any if- or while-statements generated an "Unrecognized expression". I was really hoping to see something along the lines of the "help-box" listing the description of what an if/while statement is and then a textbox with a title of something such as "condition" where I could type out the condition.

In fact, I was thinking that maybe it could be made so that if I click on "if" I can insert an if-statement. Then I would be presented with a textbox with the title of "condition" where I can type the condition for the statement. Following the textbox there would be a drop-down box, defaulting to, maybe just a blank area representing the end of the condition where I could select something such as "and" or "or" which if selected would add another textbox for a further condition. Perhaps a drop-down before the condition could allow me to select "not". This could assist users in "building" the statement in a more graphical manner.

Regarding functions, there's a list of the parameters, but this editor system can't modify the function name. I think that could be beneficial, and then instead of just listing the parameters as "0, 1, etc." you could put "parameter 0" or some such.

I think that the title for comment textboxes as "text" can be somewhat counter-intuitive in cases. I think "comment" would be better here.

I think it would be good (though perhaps not feasible) if the "Variables" section could have a list of currently available variables that could be used. That would be a huge task to try and parse for all those variables, so it probably isn't a reasonable idea.

One thing I would like to see, though you did already mention, would be the ability to have multiple different items per line (i.e., a Character.Say message and a comment on the same line).

Something else I would like would be the possibility of actually intercepting the built-in script editor, and applying your pane at the top. The purpose of this being the syntax-highlighting of the built-in editor and also the ability to directly modify the line in the script.

This plugin is a huge undertaking in and of itself and I wish you the best of luck in this project. When completed I'm sure it will be a great assistance to AGSers new and old alike who have never tread the murky waters of scripting.

[RickJ]

SupSuper, what you have so far is impressive and I'm sure that everyone is grateful that you have taken this on.   If you want to know what beginner scripters want it probably wouldn't hurt to ask them. Maybe start a thread in the beginners forum and ask them what kinds of things they find difficult or found difficult when they first started scripting.   I would be cautious about asking what people want because they (all of us, not just beginners) usually don't know what they really want.  It's better to try to determine what people need, IMHO. 

The one concern I have with your approach is that it seems like it will be difficult to maintain and keep current with the AGS scripting language and programming environment.   I suspect, this is pretty much why the Interaction Editor and it's predecessor, Graphical Scripts, have went by the wayside.   If this is so then your hard work and efforts are likely to eventually have the same fate.   

There a few thing you may want to consider with the above in mind.  Instead of making an alternate script editor consider making a supplement to the existing one.   I think the thing that intimidates beginners the most is that blank page they get and the not knowing what to type.   If your plugin were to simply insert it's results into the current script editor, that would be enough help to get beginners comfortable with scripting. 

I think that once code is pasted into the file that people will be able to go back and make changes easily enough.  It's that initial blank page that is intimidating.   With this in mind it's worth asking how useful or necessary it is to parse existing code?   The additional complexity and difficulty in maintaining the plugin that this brings needs to be weighed against any benefits.   IMHO, it's not a necessary or a realistic goal.   Of course a good discussion with actual beginners would be very beneficial in deciding this point. 

Under this scenario there could simply be an edit bar across the top of the script editor's window.  This bar would contain several drop-list widgets that perform the same/simliar functions os your current tree widget. and a few toolbar buttons (i.e. insert, cancel, undo,help).   Going from left to right the first drop list would contain "Syntax, variables, Characters, ...".  If Character is selected then the next drop list would contain a list of characters "player, "cPrecipie, etc ...".  The next drop list would contain functions/methods of the character object/class.   This would be something similar to a small talk environment and the user would be able see the command being built up as selections are made.   The buttons could be at either to the left or right of the drop lists.   

When a selection is made in the first drop list an edit window would drop down similar to the one you already have.  Function  parameters could be filled out as you are doing now, each one listed down the page with appropriate dat input widgets.  If it were something the user had to type then it would be a text input field.  If the parameter expected an internally defined enum then there could be a drop list with the selection appropriate for that parameter.

The command(s) being built by your would need top be shown somewhere in the edit window, perhaps above  the parameter list.  If it were multiple lines then perhaps only a couple lines would need to be shown and/or they could be scrollable to see the rest.  The script editor would be in the bottom window with the cursor shown.  Then there would just need to be an insert button that would paste the command buffer into the script below.

To keep everything easily maintainable the help text could be extracted from the help file so there would be no duplication or required updating.  The next thing would be to grab as much definitions as possible from the same place that the auto-complete get's it data.  Again no duplication of info and no maintenance required.   And for whatever is left, those things need to be defined in an XMLish or TXTish config file(s) so that they are easily changed.

The other thing that I believe would be helpful, and that appears you are planning on, is the ability to drop in multiple line constructs, such as if-then-else, function, struct, enum, etc definitions.  If these things were created from easily editable txt/xml template or config files then I think even advance users would also find your plugin useful (if of course it were just a supplement to the script editor rather than a replacement).   For example whenever I define a function I usually add a banner comment opening /closing braces, etc.  If your plugin would allow me to drop in my very own template that would be way cool and I would use it.

In summary, I would seriously consider dropping the requirement of parsing existing code and instead try to integrate your plugin into the existing script editor.   I would also make maintainability and user configurability requirements.   Again nice work so far.   I hope you find my comments helpful in some way.  There will be many grateful people when this gets finished in one form or another.

Rick

[Groogokk]

I'd highly appreciate it if there was a replacement for the old interaction editor.
I'm not much of a programmer myself and I don't want to go bug-hunting for hours because of a bracket that has been put in the wrong place, and neither do I want to keep looking up functions and properties in the documentation. Without an IE, I'll very probably stick to 2.72. Or Game Maker 7.0 (*ducks and runs for cover*)

[Pumaman]

Nice work, this is certainly a very worthy project

As Rick says I think the most important point at which people need scripting help is when creating their first event handlers -- eg. creating that "hDoor_Look" event for the first time, and getting an empty "function hDoor_Look" block of script and feeling lost.

So perhaps some sort of interface that listed all the available functions in the file and the user had to choose one to edit first, before being presented with that part of the script (along with an additional interface for out-of-function variables I guess) and then adding/updating as they can now, might work well.

You've made a good start here, thanks for taking on this job

[subspark]

Brilliant SupSuper! Your plugin is very important to me. Keep this thing alive!
Brilliant work mate!

Cheers,
Paul.

[SupSuper]

Massive quoting ahead!

Personally I don't miss the IE- I only ever used it to create a run script command. But from the video demonstration, I would say it surely looks useful for newcomers who are uncomfortable with the "total scripting approach" of 3.0, or who just do not know the complete list of commands.
I can see that it'll make scripting more accessible,  so I think there is some justification to make this project real. Plus, it's really looking professional how it simply snuggles inside the AGS IDE, just like a Xenomorph queen inside of Ripley.

Look and feel is really very good- again, judging from the video alone. Superior to the old IE window because it's part of the IDE and also because it has (as shown with the Say/Display command) separate slots to enter values directly. Nifty work.


BTW: You allow players to *BURN* characters in your script! Shame on you 

Thanks, I decided to remake the interface from scratch since even the IE got on my nerves in my pre-scripting days.

And if the player wants to play with matches, I'm not gonna stop him.

Okay, one of the first things that I questioned was the purpose of the "Syntax" option. I see you're trying to implement a bit of explanation of some common scripting elements, but currently it seems the tab can only be used for getting the description of certain syntactical elements, and then only by moving the mouse over them. The "Variables" option seems to offer similar usability.

The "Syntax" option is there to allow users to add common elements like if, else, while, and so on. Likewise, "Variables" provides variable declarations. However, support for "Syntax" elements is pretty much non-existant (I said it was incomplete!) and they were there mainly as placeholders, sorry.

So I opened up one of my scripts using your plugin. For some reason at the end of every single line I see one of those horrible boxes that certain fonts use in place of unrenderable characters. I'm not sure whose fault this is, but it looks terrible.

Huh, can't say I've experienced this. Though I've noticed scripts in the Script Editor don't always look exactly the same in the Simple Scripter It's something to look into.

The next thing I noticed was that you can only have one script open at a time for "Simple" editing.

Whoops, I'll try to fix that.

As I was intentionally trying to see just how far along this plugin was, I tried reviewing one of my modules. One thing I noticed was that any if- or while-statements generated an "Unrecognized expression". I was really hoping to see something along the lines of the "help-box" listing the description of what an if/while statement is and then a textbox with a title of something such as "condition" where I could type out the condition.

As I mentioned above, at the moment they're unsupported, but I am working on this so it will work as you mentioned.

In fact, I was thinking that maybe it could be made so that if I click on "if" I can insert an if-statement. Then I would be presented with a textbox with the title of "condition" where I can type the condition for the statement. Following the textbox there would be a drop-down box, defaulting to, maybe just a blank area representing the end of the condition where I could select something such as "and" or "or" which if selected would add another textbox for a further condition. Perhaps a drop-down before the condition could allow me to select "not". This could assist users in "building" the statement in a more graphical manner.

Well for starters I'll just provide a "condition" box, since conditions can get very nested and complex, but I'll keep this in mind when I flesh it out into some kind of Condition Editor.

Regarding functions, there's a list of the parameters, but this editor system can't modify the function name. I think that could be beneficial, and then instead of just listing the parameters as "0, 1, etc." you could put "parameter 0" or some such.

Thanks, I've changed it accordingly.

I think that the title for comment textboxes as "text" can be somewhat counter-intuitive in cases. I think "comment" would be better here.

Also changed.

I think it would be good (though perhaps not feasible) if the "Variables" section could have a list of currently available variables that could be used. That would be a huge task to try and parse for all those variables, so it probably isn't a reasonable idea.

Well the AGS Editor does keep track of all user variables for AutoComplete so it might be something I can support in the future. Another one for the "planned" list.

One thing I would like to see, though you did already mention, would be the ability to have multiple different items per line (i.e., a Character.Say message and a comment on the same line).

Technically, the plugin would have no problem in interpreting various expressions in one line. It's more of an interface problem. How would the plugin display them all?!?

Something else I would like would be the possibility of actually intercepting the built-in script editor, and applying your pane at the top. The purpose of this being the syntax-highlighting of the built-in editor and also the ability to directly modify the line in the script.

Being able to attach my Simple Scripter to the Script Editor would probably be a big improvement, I'm just not sure if AGS supports it. Some of the interface would have to be changed accordingly, but there might be more pros than cons.

This plugin is a huge undertaking in and of itself and I wish you the best of luck in this project. When completed I'm sure it will be a great assistance to AGSers new and old alike who have never tread the murky waters of scripting.

Thanks.

SupSuper, what you have so far is impressive and I'm sure that everyone is grateful that you have taken this on.   If you want to know what beginner scripters want it probably wouldn't hurt to ask them. Maybe start a thread in the beginners forum and ask them what kinds of things they find difficult or found difficult when they first started scripting.   I would be cautious about asking what people want because they (all of us, not just beginners) usually don't know what they really want.  It's better to try to determine what people need, IMHO.

Well at the moment the plugin is rather incomplete and I worry that beginners will get too carried away with it and damage their games. However, I'll be sure to post there once the plugin is better developed.

The one concern I have with your approach is that it seems like it will be difficult to maintain and keep current with the AGS scripting language and programming environment.   I suspect, this is pretty much why the Interaction Editor and it's predecessor, Graphical Scripts, have went by the wayside.   If this is so then your hard work and efforts are likely to eventually have the same fate.

It might not look like it but I did try to keep maintainability in mind, don't worry, I saw the IE's fate. The plugin is designed so that it's easy to update (specially because I'm lazy in the long run ). For example, AGS probably has hundreds or thousands of functions, but they're all written in exactly the same way: function_name(type1 param1, type2 param2, ...). So the plugin just has to know how to interpret Functions, and I can externally add hundreds of functions with hundreds of parameters and it'll keep on interpreting them all without any change to the code.

I did plan to have it pull the expressions right out of AGS, so it'd stay updated with it, but there's currently no support for it. I'm sure CJ will eventually add it but he's a busy man and I didn't wanna waste time, so I just wrote up the plugin relying on an external XML which contains some expressions to work with as a proof-of-concept. I obviously don't want to write up a full AGS reference myself, so this will be replaced when it's possible.

There a few thing you may want to consider with the above in mind.  Instead of making an alternate script editor consider making a supplement to the existing one.   I think the thing that intimidates beginners the most is that blank page they get and the not knowing what to type.   If your plugin were to simply insert it's results into the current script editor, that would be enough help to get beginners comfortable with scripting.

Again, this is something I don't know how I would implement, but it definitely would be a better approach. That way people could jump to functions and edit scripts as always, instead of having to take extra steps for a supposedly "simpler" approach.

I think that once code is pasted into the file that people will be able to go back and make changes easily enough.  It's that initial blank page that is intimidating.   With this in mind it's worth asking how useful or necessary it is to parse existing code?   The additional complexity and difficulty in maintaining the plugin that this brings needs to be weighed against any benefits.   IMHO, it's not a necessary or a realistic goal.   Of course a good discussion with actual beginners would be very beneficial in deciding this point.

Personally I don't find parsing scripts all that difficult to support. C# supports Regular Expressions which make it much easier to find and interpret common scripting patterns. Of course scripts can be written in all manners and ways, but this is meant for beginners which would probably stick to simple coding styles. At minimum, the plugin should be able to interpret its own scripts, since it makes editing on-the-fly much easier for beginners, not having to worry about accidentally deleting a comma or missing a semicolon.

Under this scenario there could simply be an edit bar across the top of the script editor's window.  This bar would contain several drop-list widgets that perform the same/simliar functions os your current tree widget. and a few toolbar buttons (i.e. insert, cancel, undo,help).   Going from left to right the first drop list would contain "Syntax, variables, Characters, ...".  If Character is selected then the next drop list would contain a list of characters "player, "cPrecipie, etc ...".  The next drop list would contain functions/methods of the character object/class.   This would be something similar to a small talk environment and the user would be able see the command being built up as selections are made.   The buttons could be at either to the left or right of the drop lists.   

When a selection is made in the first drop list an edit window would drop down similar to the one you already have.  Function  parameters could be filled out as you are doing now, each one listed down the page with appropriate dat input widgets.  If it were something the user had to type then it would be a text input field.  If the parameter expected an internally defined enum then there could be a drop list with the selection appropriate for that parameter.

The command(s) being built by your would need top be shown somewhere in the edit window, perhaps above  the parameter list.  If it were multiple lines then perhaps only a couple lines would need to be shown and/or they could be scrollable to see the rest.  The script editor would be in the bottom window with the cursor shown.  Then there would just need to be an insert button that would paste the command buffer into the script below.

What you're basically suggesting is a Simple AutoComplete. It's a pretty good idea but I have doubts on the difficulty of implementation. While the plugin wouldn't need to interpret anything and instead just turn user input into script, the dynamically-changing interface would be more of a nuisance. I might end up using it as an extra feature or extra plugin for those that don't like the current approach, but feedback seems positive so far so I think I'll stick to it.

To keep everything easily maintainable the help text could be extracted from the help file so there would be no duplication or required updating.  The next thing would be to grab as much definitions as possible from the same place that the auto-complete get's it data.  Again no duplication of info and no maintenance required.   And for whatever is left, those things need to be defined in an XMLish or TXTish config file(s) so that they are easily changed.

Again, being able to extract text from the help file would be handy but I don't think it's supported. I'm not even sure how one would go about interpreting CHM files.

The other thing that I believe would be helpful, and that appears you are planning on, is the ability to drop in multiple line constructs, such as if-then-else, function, struct, enum, etc definitions.  If these things were created from easily editable txt/xml template or config files then I think even advance users would also find your plugin useful (if of course it were just a supplement to the script editor rather than a replacement).   For example whenever I define a function I usually add a banner comment opening /closing braces, etc.  If your plugin would allow me to drop in my very own template that would be way cool and I would use it.

This seems very useful, I'll definitely consider featuring templates in the future.

In summary, I would seriously consider dropping the requirement of parsing existing code and instead try to integrate your plugin into the existing script editor.   I would also make maintainability and user configurability requirements.   Again nice work so far.   I hope you find my comments helpful in some way.  There will be many grateful people when this gets finished in one form or another.

Rick

Thanks for your feedback.

Nice work, this is certainly a very worthy project

As Rick says I think the most important point at which people need scripting help is when creating their first event handlers -- eg. creating that "hDoor_Look" event for the first time, and getting an empty "function hDoor_Look" block of script and feeling lost.

So perhaps some sort of interface that listed all the available functions in the file and the user had to choose one to edit first, before being presented with that part of the script (along with an additional interface for out-of-function variables I guess) and then adding/updating as they can now, might work well.

You've made a good start here, thanks for taking on this job

I could probably add some kind of function-goto like the Script Editor has, and only show that relevant function, though it would make saving changes more difficult.

Based on the feedback, I have some suggestions for the plugin API:
- Exposing some kind of AGS expression reference so that the plugin can keep up with the AGS scripting language. The AutoComplete seems to do this so it must be in there somewhere.
- Something similar for the help file, to be able to display the respective entry for the respective expression, would also be handy.
- Being able to modify the existing Script Editor or "attach" the plugin to it, so as to provide better usability without having to intercept every different call to the Script Editor from the AGS Editor, as well as make use of the Script Editor's already great functionality.

As well as some issues:
- Currently I load scripts into the plugin by getting the Script.Text property and splitting it by newlines. However, the script doesn't always seem to come out the same way it's displayed in the script editor.

I'd highly appreciate it if there was a replacement for the old interaction editor.
I'm not much of a programmer myself and I don't want to go bug-hunting for hours because of a bracket that has been put in the wrong place, and neither do I want to keep looking up functions and properties in the documentation. Without an IE, I'll very probably stick to 2.72. Or Game Maker 7.0 (*ducks and runs for cover*)

Brilliant SupSuper! Your plugin is very important to me. Keep this thing alive!
Brilliant work mate!

Cheers,
Paul.

Thanks for the positive feedback.

[GarageGothic]

This is looking very promising. I always thought the interaction editor should have been like this, to get newcomers introduced to scripting right from the start without intimidating them. The older versions of AGS always had this huge, horrifying gap lurking within it, which less experienced users would be exposed to when the interaction editor was no longer enough to achieve what they wanted. This seems a very good compromise. Great work!

[Pumaman]

- Exposing some kind of AGS expression reference so that the plugin can keep up with the AGS scripting language. The AutoComplete seems to do this so it must be in there somewhere.

If you just want a list of valid functions, then use the IAGSEditor.GetAllScriptHeaders command and iterate through the scripts, scanning their AutoCompleteData.

Something similar for the help file, to be able to display the respective entry for the respective expression, would also be handy.

Sounds reasonable to me.

- Being able to modify the existing Script Editor or "attach" the plugin to it, so as to provide better usability without having to intercept every different call to the Script Editor from the AGS Editor, as well as make use of the Script Editor's already great functionality

Hmm yeah, I'm not sure how to go about this. What about an event hook to allow you to get the Panel control of a newly created script editor pane, which would allow you to add your own top-docked control to it?

There is already the IGUIController.CreateScriptEditor method to allow you to embed a script editor in your own pane -- however, this probably doesn't provide all the methods you'd need to interact with it.

- Currently I load scripts into the plugin by getting the Script.Text property and splitting it by newlines. However, the script doesn't always seem to come out the same way it's displayed in the script editor

In what way is it different? There should only be a difference here if there are unsaved changes in the script editor, since they will not have been written back into the Script object.

[monkey0506]

Okay, one of the first things that I questioned was the purpose of the "Syntax" option. I see you're trying to implement a bit of explanation of some common scripting elements, but currently it seems the tab can only be used for getting the description of certain syntactical elements, and then only by moving the mouse over them. The "Variables" option seems to offer similar usability.

The "Syntax" option is there to allow users to add common elements like if, else, while, and so on. Likewise, "Variables" provides variable declarations. However, support for "Syntax" elements is pretty much non-existant (I said it was incomplete!) and they were there mainly as placeholders, sorry.

Not a problem here, I just wasn't entirely clear what they were there for as they don't currently seem to offer any functionality. I do of course realize this is a very early version and there's still a lot to be done here.

So I opened up one of my scripts using your plugin. For some reason at the end of every single line I see one of those horrible boxes that certain fonts use in place of unrenderable characters. I'm not sure whose fault this is, but it looks terrible.

Huh, can't say I've experienced this. Though I've noticed scripts in the Script Editor don't always look exactly the same in the Simple Scripter It's something to look into.

I think it has to do something with the \r\n or \n\r characters...whichever order it's supposed to be in. I've found similar...visual results...when working with Files using AGS and mixed up the order of the \r and the \n...though if you're just reading the script back I don't see why or how it could be in the wrong order...if you're unsure what I'm talking about I could post a screenshot.

The next thing I noticed was that you can only have one script open at a time for "Simple" editing.

Whoops, I'll try to fix that.

Nice! It would be good to have multiple scripts open for simple scripting. One thing I didn't mention...IIRC it's possible to have the same script open in the AGS script editor and your "simple" editor. I might be recalling incorrectly, but otherwise it would probably be best to avoid this (presumably the ability to dock your control to the window that CJ mentioned perhaps implementing would take care of the issue).

As I was intentionally trying to see just how far along this plugin was, I tried reviewing one of my modules. One thing I noticed was that any if- or while-statements generated an "Unrecognized expression". I was really hoping to see something along the lines of the "help-box" listing the description of what an if/while statement is and then a textbox with a title of something such as "condition" where I could type out the condition.

As I mentioned above, at the moment they're unsupported, but I am working on this so it will work as you mentioned.

In fact, I was thinking that maybe it could be made so that if I click on "if" I can insert an if-statement. Then I would be presented with a textbox with the title of "condition" where I can type the condition for the statement. Following the textbox there would be a drop-down box, defaulting to, maybe just a blank area representing the end of the condition where I could select something such as "and" or "or" which if selected would add another textbox for a further condition. Perhaps a drop-down before the condition could allow me to select "not". This could assist users in "building" the statement in a more graphical manner.

Well for starters I'll just provide a "condition" box, since conditions can get very nested and complex, but I'll keep this in mind when I flesh it out into some kind of Condition Editor.

Regarding functions, there's a list of the parameters, but this editor system can't modify the function name. I think that could be beneficial, and then instead of just listing the parameters as "0, 1, etc." you could put "parameter 0" or some such.

Thanks, I've changed it accordingly.

I think that the title for comment textboxes as "text" can be somewhat counter-intuitive in cases. I think "comment" would be better here.

Also changed.

I think it would be good (though perhaps not feasible) if the "Variables" section could have a list of currently available variables that could be used. That would be a huge task to try and parse for all those variables, so it probably isn't a reasonable idea.

Well the AGS Editor does keep track of all user variables for AutoComplete so it might be something I can support in the future. Another one for the "planned" list.

Thanks for looking into these. I'm sure it will greatly improve the plugin once you've got these worked out.

One thing I would like to see, though you did already mention, would be the ability to have multiple different items per line (i.e., a Character.Say message and a comment on the same line).

Technically, the plugin would have no problem in interpreting various expressions in one line. It's more of an interface problem. How would the plugin display them all?!?

I was thinking it could just list them all as different textboxes or whatever respective display the line would generate, in much the same way multiple function parameters are listed.

This plugin is a huge undertaking in and of itself and I wish you the best of luck in this project. When completed I'm sure it will be a great assistance to AGSers new and old alike who have never tread the murky waters of scripting.

Thanks.

You're welcome. I'm really getting somewhat excited about this plugin. It looks like it's coming along great.

One other thing I don't think I mentioned is that the plugin misinterprets functions that specify a return type as variables of that type. For example if I have a function to return a String like this:

Code: ags

String MyStringFunc() {
  // blah
}

It interprets it as a normal String variable. Based on your comment about parsing the script using regex functions, it hopefully won't be hard to fix.

[SupSuper]

- Being able to modify the existing Script Editor or "attach" the plugin to it, so as to provide better usability without having to intercept every different call to the Script Editor from the AGS Editor, as well as make use of the Script Editor's already great functionality

Hmm yeah, I'm not sure how to go about this. What about an event hook to allow you to get the Panel control of a newly created script editor pane, which would allow you to add your own top-docked control to it?

There is already the IGUIController.CreateScriptEditor method to allow you to embed a script editor in your own pane -- however, this probably doesn't provide all the methods you'd need to interact with it.

This sounds good, if it gives me access to both the panel to attach my controls to, and the ScriptEditor to read the script from.

I tried using IGUIController.CreateScriptEditor but I couldn't get it to show up on the panel and I didn't seem to have much control over it anyways.

- Currently I load scripts into the plugin by getting the Script.Text property and splitting it by newlines. However, the script doesn't always seem to come out the same way it's displayed in the script editor

In what way is it different? There should only be a difference here if there are unsaved changes in the script editor, since they will not have been written back into the Script object.

Well things like whitespace (tabs, spaces, etc.) and linebreaks occasionally differ. Maybe the ListBox and ScriptEditor display text in a different way.


I've been working on having the plugin pull the AGS functions from AGS itself through IAGSEditor.GetAllScriptHeaders. So far so good, but I've run into a few issues:

- How do I tell apart old-style functions from new-style functions? It's nice that I can support both styles, but currently they're being mixed together.

- The "StrLen(const string)" function doesn't have a parameter name. I know this is a minor quibble but it confuses my plugin and I don't wanna have to write special rules.

- I was picking up on variable types by using the crude method of assuming anything called "cXXX" would be a Character, "dXXX" would be a Dialog, and so on. However, this restriction seems to have gone in AGS 3. Is this true? I assume I can just "properly" look up the variable type for whichever variable is selected, but isn't this kinda slow?

[Pumaman]

- How do I tell apart old-style functions from new-style functions? It's nice that I can support both styles, but currently they're being mixed together.

Well, the ScriptFunction class has two properties called IfDefOnly and IfNDefOnly, which will be set to "STRICT" or "STRICT_STRINGS" depending on what you want to check.

- The "StrLen(const string)" function doesn't have a parameter name. I know this is a minor quibble but it confuses my plugin and I don't wanna have to write special rules.

Well, this isn't just StrLen -- there's loads of functions (most of the Str* functions in fact) that are like this, and it should be relatively simple to parse around it.

- I was picking up on variable types by using the crude method of assuming anything called "cXXX" would be a Character, "dXXX" would be a Dialog, and so on. However, this restriction seems to have gone in AGS 3. Is this true? I assume I can just "properly" look up the variable type for whichever variable is selected, but isn't this kinda slow?

The script editor already has the functionality to determine the type of a variable, so I'll see how I can integrate it into the plugin API.