Messages

[Programming]

Programming
Rooms, GUIs, minigames, anything you need.

Examples:
Reproducing commercial game GUIs
Confirmation GUI Module
Saves List with Screens GUI Module
Unreleased Keyboard GUI and Animated GUI modules

Translating
Native Portuguese (Portugal) speaker, can translate between English and Portuguese. Full game translations can take a few months, specially if they're long or got a lot of complex vocabulary.

Examples:
Quest for Yrolg
OpenTTD
Piwik

Beta-testing
Experience with testing freeware and commercial games, checking reproducibility and being thorough.

Examples:
Alien Breed: Impact
Worms Reloaded

Web-coding
Experience with HTML/CSS/PHP/mySQL. Not good with actual design, just coding. Can turn an existing design into an actual website, install website software or implement content management systems.

Examples:
Jump Leads
Dream17

You can contact me through PM or my profile.

Default one, DX5 driver. Doesn't seem to happen with the D3D driver.

Even with Mouse.Visible=false, the mouse cursor pops up when dialog options are displayed at the bottom of the screen, although it won't move. It goes away again after an option is picked.

I've reuploaded it for you.

It should still work with AGS 3.0, I don't think anything drastic changed regarding GUIs, but I haven't tried it myself. If it doesn't I can upgrade it.

[DELETED]

Put up two new versions:

v1.2: Updated for AGS 2.72 (and I completely forgot to post back in 2007 )
v2.0: Updated for AGS 3.0

Please do not mix v1.x with v2.x, only use the one for your version of AGS! If you've got an old version, I recommend removing it (script and GUI) before importing the new one to prevent conflicts. (function calls are still the same).

Actually the return's aren't necessary since you're using an if-else chain there, which will already skip any other tests once one condition is met.

Well currently I just need to get the position of the text cursor (SelectionStart, SelectedText, etc). Being able to access the text as lines (Lines property) or format bits of text might also be handy in the future.

While I'm at it, is there any way to take advantage of the script editor's auto-complete to automatically figure out what function/property/etc. the text cursor is on, or is it better if I code that on my own?

I created a IScriptEditor control through GUIController.CreateScriptEditor, but there isn't much I can do with it aside from placing it in my panel and changing its content. Is there any way to be able to get text selections and other user input from it, like a TextBox? I can't cast the control since it's a custom type.

Code: ags

Error: Ya se agregó un elemento con la misma clave.
Version: AGS 3.0.1.28

I really question the value of localization of internal error messages. I think it gets more difficult to get support from the authors, which may not understand the error, or even to google for it, since the solutions may not be available in the same language as the error. Anyway, it's just my personal view.

Well they're .NET Framework errors, which usually follow the Windows language. Not every developer is english.

Non-english users can just translate them for english developers, like Sadistyk did.

Actually that's because of how Windows multiple-selects files, the file you select last is placed first, so they'll come out the reverse order you selected them in.

You selected TalkR_P01_A01 and shift-clicked on TalkR_P01_I03, putting it before the rest. Either select them one by one or just manually change the order in the Filename box.

- 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?

A simpler approach would be to just add Script Folders so everyone can organize their scripts however they wish.

Though at this rate we're gonna end up with folders for everything!

Well for most cases, if it'll run on DOS, it'll run on DOSBox, and AGS is no exception. (only the really really old AGS versions won't run)

(AGS 2.62 default game, needs CWSDPMI.EXE to run)

And yes, what runs on DOSBox for Windows should run on DOSBox for every other platform. The only downside is DOSBox is an emulator so the system requirements are much steeper than a native port, and there's probably features that DOS doesn't support. (otherwise we could've stayed in the 90s )

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.

[Introduction]

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.

- Double-clicking on an event editbox doing the same thing as the "..." button (it's just faster )
- Properties panel not getting reset whenever you edit an event

You have to put the code inside an event function, like "Enters room after fadein". Also, to have it go right-to-left, you need to switch some stuff around:

int xpos = 484;
while (xpos > 60) {
  SetViewport(xpos, 140);
  Wait(1);
  xpos--;
}
ReleaseViewport();

This would scroll the viewport from X=484 to X=60.

I think the installer is mostly to make it look more professional and prevent typical zip-failures (running from zip, unproper extraction, etc). Not sure how much work it would be to provide both Installer and ZIP versions.

Regarding the shiny new installer goodness, I'll leave the following notes (which might not be bugs but still stuff people should be aware of):
- Do not install over an older AGS 3.x installation. The installer might not properly update all the files and you'll end up with a nicely bugged AGS.
- If you already have an AGF assocation, remove it. At least for me, the installer screwed up my existing AGF association and made it not work, so I had to manually remove it through registry and reinstall to fix it.
- The DemoQuest shortcut will bring up errors if AGS has any editor plugins (probably because the shortcut uses the DemoQuest folder as the working path and it'll try finding the plugins there and fail)

I'd like to see an option to clear the Recent Games list, since it can easily add up over-time.