Messages

Yes, only it's not simple to compare the source to view what was changed in AGS since I'm not sure we know the version that was taken (and it's possible Scintilla skipped some tags).

Anyway, I agree with you it's not trivial, but on the other hand it's also quite isolated from most of the code.

If it seems not feasible by the time of the release we could consider adding to the interface an init function. it would mean a code change for anyone using the interface, but at least it would be relatively simple. Still, it's better if someone had the time to upgrade this component.

In my latest implementation I started to using IScriptEditorControl to display the current script. This works fine in 3.2.1
I tested the plugin with the 3.2.2 branch and it seems once you move the pane out, the script edit control loses all the syntax highlighting. I checked this and it appears that when the handle is recreated the Scintilla control gets WM_DESTROY which causes all the settings to be lost.

In the editor there's a hack that calls ReInitializeScriptEditor so essentially it just recreates all the data. In the plugin interface it's much more difficult since here is no option to re-initialize everything. I tried looking for a solution, but it would be much more hacky than the editor solution and hardly maintainable. So IScriptEditorControl is basically broken.

Finally, I tried to see if anyone handled this in ScintillaNet and my first search brought this https://scintillanet.codeplex.com/workitem/11811

So if I compare the code it seems AGS uses a very old version of ScintillaNet, probably before they fixed this bug. It's possible we won't need the hack in the editor if there is a newer implementation. Unfortunately we don't use the ScintillaNet dll, but rather embed their code in AGS.Controls and beyond that they seemed to change the interface so it's not backwards compatible.

If this is not solved in the editor the real solution in the plugin would be to ignore the editor interface and just use a new version of ScintillaNet directly, but I think it's better the editor would migrate to the latest version since it would solve more problems.

Incidentally, their accompanying app references the same docking window suite you used, so it probably means there's support for that.

I'm assuming that .Net 4 is supported by mono but it needs to be verified before the transition.

Yep, pretty much. http://www.mono-project.com/Compatibility
We would have to instruct developers to refrain from those few red and yellow items, but I doubt many of them would go that path anyway.

Does this mean one have to have Visual Studio 2010 to build Editor?
Does VS2010 Express edition allows to build mixed-code projects? I may be mistaken but I have vague memories someone told me it can't; do not know if that's true.
Question is, will there be any problems building AGS.Native library?

Yes, VS2010 would be required for .net 4. VS2010 express doesn't support mixed code projects, neither does 2008 express or 2005 by the way, but surprisingly 2012 express supports this.
You can compile to previous .net version quite easily. You can also compile to previous C++ compilers, but for that you may need to install the previous build tools if you don't want to upgrade all the way to 2012 and have it compile to the previous version. So there is no problem to use either 2010 or 2012, but there may be some manual work there.

@Sslaxx - I think .net 4 and not 4.5 would be fine, I didn't yet encounter features in 4.5 that are crucial. I only tried to compile it with 4.5 to see if there are any technical difficulties with the latest.

@tzachs - Yes, stats would be useful, but really in the worst case we can always provide the .net distribution as part of the installation (I don't think it's mandatory but it's just a better install practice to provide this with the installer or download it if it's missing).

I just encountered a case where I wished I could write a feature in a plugin using .net 4, but the editor is still using an older version of the framework. Are there any plans to migrate?
The editor seems to compile and run without any code changes even for .net 4.5, but I didn't test it thoroughly.

I'm very happy to announce a new version of the Speech Center plugin. This release includes major changes:

• Edit mode, now there's support for in-place text editing
• Ability to add missing speech line numbers for the displayed lines
• Display the script and highlight the line within the script of the current selected speech line
• VA Scripts


• Export only displayed lines
• Option to group VA script lines by code block rather than by function
• index.html is now created together with the voice scripts
• Significantly improved refresh performance
• Line info is displayed in the AGS properties window when selecting the line in the grid
• New icons

It took a lot of effort to test this and to provide the best experience possible. Please let me know if you encounter any trouble. I also took many precautions in the edit feature and tested it with any source I could find. I still recommend you backup your game before editing, especially when using the feature for the first time.

The plugin is available here

As usual, please provide any feedback you'd like. Many of the features here are the direct result of the posts in this forum.

Enjoy!

No pressure or anything, but this will come very useful in about two weeks when I get back from vacation to finish the rest of the VO acting on my game.

I think it will be sooner than that, but worst case drop me a note and I'll find a solution.

Hello everyone,

I've been busy with changes to the plugin and while I'm still testing these changes, I wanted to share with you a screenshot of what's coming up. Most of the feature requests that came up here are going to be implemented. Of course, comments and questions are more than welcomed.

I basically meant a function to dump all found dialog into a txt -file, for easier grammar/spell check or printing or whatever.
VA scripts is a bit above my level of expertise.

It's not complex to add export functionality in a different format, but I would like to understand what one would get from this on top of existing capability (The VA scripts are meant to be human readable). Perhaps an example output could make this clearer.

Furthermore, is grammar/spell checking your main use case or is it just a theoretical example?

I would consider separating as much as possible Allegro from the data structures. For example, all the GUIs are dependent on it because they don't only hold this info, but also draw it.
This makes the Native dll is also dependent on Allegro. Thus, separating the underlying data and creating a different presentation layer would bring value.

This doesn't mean ability to replace Allegro (I think that's much more difficult and not sure if it's needed at this point), but it will be a step towards a better design.

My understanding: yes, the reason is that there is character array in AGS scripts. Although it's not in agsdefns.sh you can see that it's injected to the header in C# Tasks.AppendCharactersToHeader

Code: C#

sb.AppendLine(string.Format("import Character character[{0}];", characters.Count));

and in load_game_file in the engine you have

Code: C++

ccAddExternalSymbol("character",&game.chars[0]);

So, someone could write in the code character[EGO] and that would work. It relies on the size because it's simply defined as an array. There's also some code generated in agsnative that references this array, but I think it's related to old interaction scripts (however, I didn't check this thoroughly).

Another question is whether or not a plugin will depend on the size of this structure. I think it should be fairly safe for most implementations, but need to check this.

Done, uploaded version 1.1.1
It was a quick change, so there are the standard sizes available. I may provide option to input the size as text as soon as I find the time.

Hi all.
Any progress on adding an 'export to text file' function?
Or is this a feature already?

Do you mean VA scripts or something else?

There's a feature to export VA scripts to HTML files (one per character). I'm going to improve it a bit to cover Dave Gilbert's request and a few other improvements I have in the backlog.

Also, AGS already supports exporting VA scripts in text format.

Compiling Lua to a bytecode IL in the editor removes some of the benefits of Lua (runtime reloading of scripts for instance).
It also raises the level of entry for new language implementations.

Also, surely keeping the language implementation as close to the official release is better since new versions can be dropped in on release.

It's true, but there's more than one option here (I mentioned 3 and there are probably more). Let's cover what are the requirements before jumping to the solutions (so sorry for doing that earlier)

Here are some features that we need to decide if they are required (not saying they are, just questions I have here and the list of feature requirements should be longer eventually):

• Clear interface to support additional languages vs. single language


• If multiple languages are supported, can one project easily host multiple languages or do you choose a language at the beginning
• If single language, what is the existing games migration path
• Easy to learn (newcomers learning curve)
• Integration within dialog scripts
• Backwards compatibility
• Double click on room event and reach the actual code (and not AGS script that calls another language)
• Debugger
• If done via plugin interface, is integration between different plugins required? (not necessarily plugins that introduce scripting language)

This plugin is certainly possible thanks to both AGS and Lua's flexibility and of course ingenuity.

I believe the remaining limitations here occur because both AGS and Lua compile to different intermediate languages. Meaning, if we were to make sure all languages can compile to the same intermediate language then we'll have total flexibility on this. It would make the engine agnostic to the actual language.

I see here 3 routes:

• Examine if Lua can be compiled to existing AGS IL. This would make it an editor change and not an engine change. I already studied some time ago the code that runs the engine and understand it quite well. The IL seems rather general so it's a possibility.
• Adjust the AGS IL to fit requirements by Lua and other scripting languages. This is an hybrid approach. Meaning we make some changes to the IL, but keep the basic core.
• Change the IL completely to something else, maybe Lua's IL, maybe a different one. This is the most risky approach, it requires verifying backwards compatibility can be maintained.

Another part is making sure the editor allows different languages, this is much easier to do once we have a documented IL that has been proven to work with more than one language. One possibility is to extend the plugin interface to support this and allowing the editor to have a standard interface to all its scripts regardless to their language.

Anyway, this requires technical analysis, I'll be happy to take part. My relevant background is C, C++, x86 assembly, text parsers and more recently, C#.

Following your requests, here's a new release which includes:

• Right-to-left support
• Ability to choose the translated column font

Hope it helps!

There's still one odd problem. If I use the filter in my plugin and I close and reopen the window, the filter appears as if it's there, but the grid displays all the lines. This is not what's happening in previous AGS. I couldn't find an obvious place in my code where I'll do that behavior, but obviously there is some kind of event chain that will. Are you sending any events when reopening and what is the difference here and with AGS 3.2.1?

Hmmm, it's very hard to tell. There's a Refresh called on the form that happens when you show it that I think wasn't there before, but I tried to remove it and it didn't seem to solve the issue.
Also, I don't call Show on the form, but on the DockContent which is implemented in the Docking Suite, I don't know how it works there.
When closing I just hide the form, which as far as I know is how it worked in previous versions...

Ok I checked this further, the UserControl Load event seems to be called, obviously I can add a flag to protect this case, but this event should be called only once so I'm worried that the fact that this event is called again will have other negative effects.

My guess is that somehow the control is closed or moved to a closed state, causing another load when displayed. However, the inner controls instances seem to be the same, so they are not completely destroyed, maybe the window handle is recreated or maybe just the event is called, not sure.

EDIT: According to MSDN this event can be called again when it's an MDI child or when someone calls RecreateHandle. So I'm guessing it's probably a call to RecreateHandle. It would be best if you can verify this is the cause, meanwhile, I'll add a boolean in my code.

I encountered a problem when closing a plugin window and trying to reopen it.

Fixed.

There's still one odd problem. If I use the filter in my plugin and I close and reopen the window, the filter appears as if it's there, but the grid displays all the lines. This is not what's happening in previous AGS. I couldn't find an obvious place in my code where I'll do that behavior, but obviously there is some kind of event chain that will. Are you sending any events when reopening and what is the difference here and with AGS 3.2.1?

Some Windows: output, find results and call stack have an 'x' to close that pane info (was there before the change), but the docking window already has this, so I don't think it's needed, the whole gray band can be removed and provide more screen real-estate

Removed the extra header. For some reason when you start it, there's still an empty line there, but once you dock it out and in again it goes away.
I have no idea why, might be a bug in the docking suite.

Sounds like a resize problem, did you try to anchor the inner control instead of docking?

Scripts - It's a good idea to group the script and header. I think it's better to have the script open when double clicking the parent (and then not expand when double clicking). In the majority of the cases developers would like to edit the script and could expand to edit the header now there's an extra step to reach it.

I didn't find a simple way to do this. I could open up the editor but not avoid the expand. The problem is that the OnBeforeExpand event is triggered before the double click event and doesn't have a distinction between an expand caused by a double click and a regualr expand. So it's either going with windows messages (and I don't want to go there due to Mono compatability issues) or using timing calculations, or detecting the click location and deducting if the + was clicked or not, all of those are messy hacks and I didn't think the feature was important enough to justify it.

I hear you, very annoying GUI stuff. I just think you'll need to at least open the script on double click even if you do expand. Maybe it's best if you get game developers to review this, I think they won't like the extra step required to reach the script.

One other addition that would be useful to me (and perhaps others) is to have the plugin automatically number lines that are not numbered.  The auto script generator that is built into AGS will redo all numbered lines when it is run.  This can destroy work that was done previously.  It would be a great help if we could have lines that lack numbers get numbered by Speech Center while leaving all other previously numbered lines unchanged.

Yes, this was requested before. I'll try to get to it once I add full editing support.

I'm very happy to announce a new version with the ability to view translations per speech line.

Download here

In order to view existing translations, make sure to refresh the data and you should have all your translations listed. All features available for original text apply to translations, with the addition that once you select a line, you will see the original text at the bottom.

There's also an option to edit translation files with the same interface. To do this you must explicitly enable this from the preferences. I've used AGS functions to store the files, so it should be quite safe, but still, to be on the safer side it's best to backup your translation files before trying this.

Additional changes:

• Added last refresh time to make it clearer whether the information is up to date
• Added speech function column, so you can now know if Display, Say or a custom function was used (note that refresh is required to populate info)

Edit: Combined double-post (difference between posts was 18 minutes, so there was no need for a bump-post)