Messages

Hey! We started using this in a major way on our most recent project, and it's the best thing ever! I do have one more request, if you'll indulge me.

Being able to generate voice acting scripts is a HUGE boon, but right now it generates every line for every character at one time. Would it be possible to generate specific reports, based on what is on screen? For example, right now we have a character that is mostly voiced. I want to generate a voice acting script based on whichever lines are still missing. I can get that up on screen easily enough, but it would be nice to generate the nicely formatted voice acting script as well. Would that be possible?

I have the exact same request.  This feature would be an amazing addition!

I'm finishing testing the plugin translation support. Once I release it this feature is the next things I plan to add.

Hey tzachs,

Great refactoring job, I managed to load the plugin and it loads without a problem.

I encountered a problem when closing a plugin window and trying to reopen it. The way it used to work was that AGS would not dispose the window when closing the document, essentially giving the plugin the choice of whether to destroy the window or just hide it. This allowed me to easily keep the GUI content the same (filter, scroll location, etc). Now I get this error so it seems the ContentDocument is disposed. Should I change anything or can you keep 3.2.1 behavior here too? This is the exception I get.

Error: Cannot access a disposed object.
Object name: 'DockingContainer'.
Version: AGS 3.2.2.112

System.ObjectDisposedException: Cannot access a disposed object.
Object name: 'DockingContainer'.
   at System.Windows.Forms.Control.CreateHandle()
   at System.Windows.Forms.Form.CreateHandle()
   at System.Windows.Forms.Control.get_Handle()
   at WeifenLuo.WinFormsUI.Docking.DockContentHandler.set_DockPanel(DockPanel value)
   at WeifenLuo.WinFormsUI.Docking.DockContentHandler.Show(DockPanel dockPanel, DockState dockState)
   at WeifenLuo.WinFormsUI.Docking.DockContent.Show(DockPanel dockPanel, DockState dockState)
   at AGS.Editor.DockingContainer.Show(IDockingPanel panel, DockData dockData)
   at AGS.Editor.TabbedDocumentManager.SetActiveDocument(ContentDocument pane, Boolean updatePaneOrder)
   at AGS.Editor.frmMain.AddOrShowPane(ContentDocument pane)
   at AGS.Editor.GUIController.AddOrShowPane(ContentDocument pane)
   at AGS.Plugin.SpeechCenter.SpeechCenterComponent.AGS.Types.IEditorComponent.CommandClick(String controlID)
   at AGS.Editor.ProjectTree.ProcessClickOnNode(String nodeID, MouseButtons button)
   at AGS.Editor.ProjectTree.projectTree_NodeMouseDoubleClick(Object sender, TreeNodeMouseClickEventArgs e)
   at System.Windows.Forms.TreeView.OnNodeMouseDoubleClick(TreeNodeMouseClickEventArgs e)
   at System.Windows.Forms.TreeView.WndProc(Message& m)
   at System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m)
   at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)
   at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)

After trying to restart I get an error that prevents from loading the editor:
System.InvalidOperationException: Invalid Content: ActiveContent must be one of the visible contents, or null if there is no visible content
(this is from Loadlayout while reading xml and exception is in DockPane.set_ActiveContent)

Something else which is odd when I keep the windows open, sometimes when I double click the plugin icon (while its pane is open, but another one is currently displayed) it doesn't focus on its pane. It's not simple to reproduce, I need to open many other documents and switch between them to make this happen. I didn't debug it to see if the plugin is called, but what I do is call IAGSEditor.GUIController.AddOrShowPane with the existing content document in IEditorComponent.CommandClick for the root node id, so maybe the event is not called or AddOrShowPane changed.

Since I played with the editor a little, here are a few notes:

• 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
• I would try to make the docking tool window header (Explorer Window, Properties, Output, etc) maybe 1-2 pixels smaller in height, the header is usually less important, but currently it's the same size as any other GUI element
• 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 think it's better to have the output window default layout docked at the bottom of the content documents and not the main window to allow the properties and project tree more space. Anyway, if you move that output docking window it's very difficult (maybe impossible) to return it to dock at the full width of the main window so it makes sense even from that aspect to change the default

I ran ApiChange on AGS.Types.dll and these are the problems I see:
Changes that will definitely break backwards compatibility

• ContentDocument 2 constructors now have an additional parameter. Need instead to keep existing constructors and add new ones, plugins will almost always create such a class.
• EditorContentPanel change base class. As I mentioned in previous message this is a major problem. I believe it should still derive from UserControl and if we want to add docking functionality to documents, the editor should use another class that contains the EditorContentPanel which implements the docking. Also note that the dll you used is MIT licensed, which is fine, but requires copyright notice. It's better to have only the editor depend on it and not AGS.Types so it will be easier to include AGS.Types with plugins and also it sounds to me like a better design to refrain from adding specific editor GUI elements to this DLL

Changes that may break backwards compatibility

• Removal of RoomList - I'm not sure this is really in use since it doesn't really have a lot of functionality, but if plugins do use it they'll break
• Change BaseListSelectTypeConverter<T> to BaseListSelectTypeConverter - this affects this type and several derived types. Again, I understand why the change but if any plugin does anything related to this class or derived classes then it may break
• BaseFolderCollection - change in generic parameter names to something more descriptive, maybe it will be ok (didn't test), but it is possible it breaks compatibility, needs to be tested with a plugin that uses this class
• IToXml - use in Character, GUI, Script, InventoryItem, UnloadedRoom - I really don't know if keeping the method name but just changing it to be from an interface breaks anything (didn't test) and it's possible a plugin really has to call this method which is rare. Still worth verifying

So in short, I think the first 2 items are definitely a priority to fix before merging and the rest should be tested
Here are the full results of the run.

AGS.Types.dll has 76 changes
   Removed 2 public type/s
      - public class AGS.Types.BaseListSelectTypeConverter<T>
      - public class AGS.Types.RoomList
   Added 11 public type/s
      + public class AGS.Types.BaseListSelectTypeConverter
      + public class AGS.Types.DialogFolder
      + public class AGS.Types.CharacterFolder
      + public interface AGS.Types.ISourceControlProvider
      + public class AGS.Types.UnloadedRoomFolder
      + public class AGS.Types.GUIFolder
      + public class AGS.Types.ScriptFolder
      + public class AGS.Types.InventoryItemFolder
      + public class AGS.Types.DockData
      + public class AGS.Types.ScriptAndHeader
      + public interface AGS.Types.IGlobalVariablesController
   public class AGS.Types.UnloadedRoom
      + interface: AGS.Types.IToXml
      + interface: System.IComparable
      + public virtual void ToXml(XmlTextWriter writer)
      + public virtual int CompareTo(Object other)
      - public void ToXml(XmlTextWriter writer)
   public class AGS.Types.FontTypeConverter
      Base type changed: AGS.Types.BaseListSelectTypeConverter`1<AGS.Types.Font> -> AGS.Types.BaseListSelectTypeConverter
   public class AGS.Types.BaseFolderCollection<T,U>
      + protected List<TFolder> _subFolders
      + protected List<TFolderItem> _items
      - protected List<U> _subFolders
      - protected List<T> _items
      + public TFolder CreateChildFolder(String name)
      + public virtual IList<TFolder> get_SubFolders()
      + public IList<TFolderItem> get_Items()
      + public IEnumerable<TFolderItem> get_AllItemsFlat()
      + public void Clear()
      + public bool MoveFolderUp(TFolder folder)
      + public bool MoveFolderDown(TFolder folder)
      + public int GetAllItemsCount()
      + public void Sort(Boolean recursive)
      + public void RunActionOnAllFolderItems(Action<TFolderItem> action)
      + public void .ctor(XmlNode node,XmlNode parentNodeForBackwardsCompatability)
      + protected TFolder CreateFolder(XmlNode node)
      + protected TFolderItem CreateItem(XmlNode node)
      + protected virtual string get_RootNodeName()
      + protected virtual void FromXmlBackwardsCompatability(XmlNode parentNodeForBackwardsCompatability)
      + protected void Init(String name)
      + protected TFolderItem FindItem(EqualsDelegate<TFolderItem,TFolder,TId> isItem,TId id,Boolean recursive)
      - public virtual IList<U> get_SubFolders()
      - public IList<T> get_Items()
      - protected U CreateFolder(XmlNode node)
      - protected T CreateItem(XmlNode node)
   public class AGS.Types.ViewFolder
      + public virtual AGS.Types.ViewFolder CreateChildFolder(String name)
   public class AGS.Types.EditorContentPanel
      Base type changed: System.Windows.Forms.UserControl -> WeifenLuo.WinFormsUI.Docking.DockContent
      + protected virtual void OnClosing(CancelEventArgs e)
   public class AGS.Types.AudioClipTypeConverter
      Base type changed: AGS.Types.BaseListSelectTypeConverter`1<AGS.Types.AudioClip> -> AGS.Types.BaseListSelectTypeConverter
   public interface AGS.Types.IAGSEditor
      + public void set_SourceControlProvider(ISourceControlProvider value)
   public class AGS.Types.Character
      + interface: AGS.Types.IToXml
      + public virtual void ToXml(XmlTextWriter writer)
      - public void ToXml(XmlTextWriter writer)
   public class AGS.Types.GUI
      + interface: AGS.Types.IToXml
   public class AGS.Types.AudioClipTypeTypeConverter
      Base type changed: AGS.Types.BaseListSelectTypeConverter`1<AGS.Types.AudioClipType> -> AGS.Types.BaseListSelectTypeConverter
   public class AGS.Types.Script
      + interface: AGS.Types.IToXml
      + public virtual void ToXml(XmlTextWriter writer)
      - public void ToXml(XmlTextWriter writer)
   public class AGS.Types.InventoryItem
      + interface: AGS.Types.IToXml
      + public virtual void ToXml(XmlTextWriter writer)
      - public void ToXml(XmlTextWriter writer)
   public class AGS.Types.RoomListTypeConverter
      Base type changed: AGS.Types.BaseListSelectTypeConverter`1<AGS.Types.Font> -> AGS.Types.BaseListSelectTypeConverter
   public class AGS.Types.ContentDocument
      + public AGS.Types.DockData get_PreferredDockData()
      + public void set_PreferredDockData(DockData value)
      + public string get_TreeNodeID()
      + public void set_TreeNodeID(String value)
      + public string get_IconKey()
      + public void set_IconKey(String value)
      + public void .ctor(EditorContentPanel control,String name,IEditorComponent owner,String iconKey)
      + public void .ctor(EditorContentPanel control,String name,IEditorComponent owner,String iconKey,Dictionary<string,object> propertyGridObjectList)
      - public void .ctor(EditorContentPanel control,String name,IEditorComponent owner)
      - public void .ctor(EditorContentPanel control,String name,IEditorComponent owner,Dictionary<string,object> propertyGridObjectList)
   public class AGS.Types.Dialog
      + interface: AGS.Types.IToXml
      + public virtual void ToXml(XmlTextWriter writer)
      - public void ToXml(XmlTextWriter writer)
   public class AGS.Types.AudioClipFolder
      + public virtual AGS.Types.AudioClipFolder CreateChildFolder(String name)
   public class AGS.Types.Game
      + public AGS.Types.CharacterFolder get_RootCharacterFolder()
      + public AGS.Types.DialogFolder get_RootDialogFolder()
      + public AGS.Types.ScriptFolder get_RootScriptFolder()
      + public AGS.Types.InventoryItemFolder get_RootInventoryItemFolder()
      + public AGS.Types.GUIFolder get_RootGUIFolder()
      + public AGS.Types.UnloadedRoomFolder get_RootRoomFolder()
From 1 assemblies were 2 types removed and 17 changed.

Not sure I completely understand the question. You can indeed type the translated text in the grid.
If you wish to set the font, I didn't add that, but if you are referring to a Windows font then that's something I can add. If you are referring to an AGS font that will be very difficult.

Hope I covered your question, but if misunderstood then I'll be happy to answer it if you can clarify.

Oh yes.your answer was exactly my question.i want change font in translating column for see real texts.because i made a special font(ttf).is it possible?

Yes, I'll add it to the next release.

Great additions!

However, I tried loading my plugin with it and it doesn't work so your changes break backwards compatibility.

Certainly part of the problem is changing EditorContentPanel base class, it's now not UserControl and obviously plugins depend on it (since they also implement panels that derive from it). Some of the base methods don't exist now and this will require some code changes to keep the plugins compatible (I know my plugin will).

Are there any other changes that break backwards compatibility? While it's fixable, the main problem this will create is the requirement to maintain a different version of the plugins for different AGS versions. It may make sense in a major release (version 4), but not when we talk about 3.2.1 vs. 3.2.2.
So I think it's important to make sure only new methods are added and not change plugin exposed base classes or existing available methods.

Besides the technical difficulty this creates, why do we really need the document windows to be dockable? I understand why the other Windows should be, but why all the ones showing content? Note that if the goal is to mimic VS then the content Windows do not dock the same way as the other Windows. So if we really think it's needed, I'd go the same direction Microsoft did.

Looks great!

Two comments-

1. I can understand that you made it a stand-alone tool so that translators will be able to use it seperately than AGS (which is good), but it shouldn't be too hard to make it a tool and a plugin combined (basically moving the entire code to a dll instead of exe, replacing the form with a control, implementing the plugin interface, and adding an exe that will open a form with the control docked to it).

Yes, I was thinking of making it a plugin, not too difficult. The first thing I'm planning is to add in-place editing for translations in Speech Center plugin. Which means that you can view the speech lines and edit the translations in that context. It won't cover some of the translations (the plugin doesn't cover GUI elements at the moment, although that can change). If I add the second plugin I'll have to make sure the plugins lock the file for write before editing, but that's not too difficult either. However, there may be some less trivial aspects of refreshing the data, I'll have to cover some use cases here to prevent potential data loss. So for the start I'll give editing option in the existing plugin and then start handling the rest. Speech Center plugin still doesn't have in-place editing for scripts and dialogs, that's more difficult because AGS editor doesn't lock the objects or exposes an interface to the plugin to query which files are open, but translation editing is a step towards that goal.

2. Can you align the Hebrew to the right? 

Certainly. It wasn't a priority because as far as I know Hebrew and Arabic use in AGS games is uncommon, but knowing someone needs this changes the priority.

Not sure I completely understand the question. You can indeed type the translated text in the grid.
If you wish to set the font, I didn't add that, but if you are referring to a Windows font then that's something I can add. If you are referring to an AGS font that will be very difficult.

Hope I covered your question, but if misunderstood then I'll be happy to answer it if you can clarify.

[Updated in 2.0.0]

Hello all,

Updated in 2.0.0: Changed layout to display original above the translated line.

Download

While working on translation support for the Speech Center plugin I thought that it may be useful to have an independent tool to edit .trs files. The reasoning to make this independent is to allow game translators to work on the file in a graphical interface, but not requiring game developers to send the entire source or asking translators to learn AGS.

The theme of the tool is keeping things simple. Line numbering in AGS, for example, "&3 Welcome", will by automatically display as "Welcome" and, by
default, the "&3" text will be added automatically to the translated text. Furthermore the program supports infinite undo/redo, copy and find.

Here's a screenshot


Feel free to contact me on any questions or comments.

Have fun!

Hello there,

I've done most of the work for supporting translations with my plugin, but I'm looking for actual .trs files to test my code. Are there any open source games that have this?

Would anyone be willing to share translation files so I can test it? I can promise I'll use it only for testing purposes and unless I get your express permission I won't forward the file to anyone else.

Many thanks.

I agree with Monkey on the simplicity. The fact that the framework is OO (events and predefined types) but doesn't force a user to learn OOP is a plus. Based on the previous discussion, I think we need to separate features for game developers and features for module writers. The former (usually) need the language to remain simple and the later may need improvements and can work with them. I don't think this means a full new language, but we need to agree which minimum constructs will help.

I think the language is closer to C# than Java (despite their own similarities), the element that really seems redundant in the language is the '*' for object reference, not sure why it's needed (did anyone intend to pass structure by value?). The biggest advantage of other languages is their existing libraries, but I don't see it likely that AGS will run JVM or .Net IL in the near future, so it doesn't matter. The only thing is what syntax we'd like to  borrow from those languages to AGS.

As for imports, the ability to deduce the function without the 'import' directive would simplify the work of game developer. It's not a simple task for the code interpreter and compiler because it would mean adding a linking stage, but I don't see the use case that 'import' helps to develop a game if this can be done automatically. In fact, it's very likely that this change can be done without touching the engine, just need to create the correct import reference in the compiled code.

Only a question: I didn't menage to mark the correct rows. Does this work only if there is a file associated?

You'll need to number the lines to mark them. It's ok if the file is not there, but the lines do require a number. You can set numbering in AGS by selecting "Auto-number speech lines" in the file menu
(it'll add a '&' sign and a number for each line in all the source files when the wizard finishes)

The plugin uses this number as one of the keys for comparison during refresh in order to know whether the text changed.

You can number a few lines manually and then refresh the plugin to see if it works well before numbering the whole project.

The plugin collects all the text as requested and you can quickly jump to the location by double-clicking the location (and then edit). Furthermore, if the lines have numbering, then you can mark whether the text is correct or not. You can also sort, filter the lines and find text.

I haven't added in-grid editing yet, so it will require to double-click in order to fix the text. Editing requires covering many use cases (the editor doesn't help much here since there is no option to know if it has pending edits or even if the script is open), but it's certainly possible. I simply assumed that if someone proof reads, the majority of the text is correct and therefore there won't be that many double clicks. However, if that feature is of more use I can work on getting that earlier than translations.

thiezar, I suggest you give me feedback as to whether the existing features are helpful enough (I know of at least one other person who used the plugin for proof reading purposes). If you find yourself with many edits and therefore the current method slows you down, I'll switch priorities.

How about this plugin?

PS - Monkey, I'm working on adding translation support too.

The big advantage I see with AGS is that it's relatively easy for someone with little programming experience to create a game. I think the goal should be to make it easier for those people, not add more complex language structures or more languages (unless they are necessary or cause things to be obscure today).

The ironic perversion is that lack of support for function and structure pointers and many of the other language features conspire to make things more difficult for inexperienced programmers.  For example, would make it possible for a predefined module to call later/user defined functions, for predefined modules to be dynamically/programtically bound to gui controls, to have call back functions, to create event handling modules, as well as jump tables and other higher level, easier scripting gadgets as Crimson describes.   The kinds of things we are talking about here would allow more functionality to be encapsulated into predefined modules that hide the underlying complexity from the module user. 

Ok, if the main users of these language features are module developers then this makes a lot of sense. Thanks for clarifying.

I still don't fully understand what problems are we trying to solve here. Can anyone provide the use cases that are not possible or difficult with today's scripting language? Meaning, not in the language itself, which is obvious, but for game developers, actual use cases.

The big advantage I see with AGS is that it's relatively easy for someone with little programming experience to create a game. I think the goal should be to make it easier for those people, not add more complex language structures or more languages (unless they are necessary or cause things to be obscure today).

I believe language changes like that require careful planning, otherwise it will create backwards/forwards compatibility problems.

Planning, yes. Hesitance, no.

Not advocating hesitance, but don't want to pay the price of easily avoidable mistakes. If you create a 'new' keyword for objects, constructors and destructors easily come to mind, which of course further complicate things.
As for garbage collection, I didn't check, but does the current garbage collector handle loop reference? For example object A references object B and object B references object A (or something more elaborate)? I didn't check, but maybe this wasn't a concern for the current use case and if we start adding data structure library (which is a good idea) this has to be handled. The template option (or generics) is also an important subject. Anyway, all this is much more work than simply sending a struct as a function parameter, essentially all these things drive the script language to C#-like language. Most importantly, this has to remain optional for advanced developers, it's best that most AGS users can just start without knowing too much programming.

I thought a bit about the pointer thing, in AGS '*' actually acts as a reference & in C++ and not pointer, so it might be ok, as long as you can simply assign struct instance to struct reference. Another possibility is to define that this operator is optional for parameters, because objects are always passed by reference.

ArrayList.

I think the goal should be to create an environment in which you can effectively code your own array list rather than just exposing one from the layer below.

I looked at the code, I don't think that adding a struct as pointer parameter is that complex, just a matter of loading the address to SREG_MAR. However, that's far from being able to do an ArrayList because you'll quickly need the ability to create a new object in the heap. Then of course you run into the question of deleting the object.

Furthermore, should the syntax have struct* and if so how do you pass the address of struct as parameter? (and do we really want the C notion of pointers in scripts?)

I believe language changes like that require careful planning, otherwise it will create backwards/forwards compatibility problems.

Is there any place where we can see all the features requests and their status?
I'm very interested to know this, and may implement some. This question also applies to the engine, I'm actually a C++ programmer, .net is just extra

New version available with a new feature - export voice acting scripts
Here's a sample output.


It also includes settings to control the output format. As always, please let me know if you run into any trouble.

The output format is similar to the one used by the sqvsb guys, I found it very readable and useful.

Thanks, I can confirm the compiler ignores this error. I assume it just discards the rest of the line, and compiles the rest as intended, but I didn't check. I think it should be fixed since it is an error and the rest of the editor functions don't cope with this.

The real problem is the extra quotation mark which causes all the lines up to 5 (or 777) to be considered as a single string, and "And I can" is parsed as commands. The apostrophe doesn't parse correctly since it expects it to be 't', because again, it's not parsed as part of the string. BTW, the parser does pick up the original error for me, the lines are not sorted and that text box doesn't have a scroll bar, but if you use the keyboard to scroll through you should see line 774 as well. I'll add the scroll bar in the next release.