Menu

Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Show posts Menu

Messages - SpeechCenter

#41
Editor Development / Re: .NET version
Tue 16/09/2014 20:27:29
Just a quick note, you can still compile the C++ portions with VC++ 2008 compiler while using newer VS IDEs. All you need is to install both VC++ 2008 and the newer VS. Then set the C++ projects to use the older compiler.

I've been using VS 2013 express for some time, including for privately testing my code against AGS compiled this way and it works just fine.
The downside is that it will require two installation of Visual Studio until those native projects will be upgraded. The upside is that the IDE is much better and the express version supports compiling both C# and C++ in the same solution. This was very useful on multiple occasions.

If, however, the consensus is to stay with VS 2008 IDE, moving to .net 3.5 is a good step forward.
#42
Removing the headers is a good idea, but what about existing code? Will it continue to function or require conversion?

As for keywords, I would try to stick to C# as much as possible, as long as it makes sense. So perhaps 'public' can still be used.
(another reason to restrict the number of new keywords is that it increases the possibility someone uses this keyword in existing code and then the code won't compile)
#43
Quote from: Crimson Wizard on Fri 04/07/2014 18:05:14
Quote from: monkey_05_06 on Fri 04/07/2014 16:11:28
* The new keyword internal should be added for structs that cannot be instanciated using keyword new
* internal structs should have access to a protected constructor, and should be able to return managed instances of the class by invoking it (e.g., via a static Create method, where appropriate)
AFAIK in C# (if we take one for analogies) "internal" structs are those that cannot be used by external module. Here we have a struct that may be used externally (in scripts) but cannot be created with "new" by scripts.
Also, as Gurok mentioned above, protected members should be (are?) accessible in extender functions.
Should not constructor be "internal" instead?
That would be confusing indeed. In C# static classes mean they cannot be instantiated (http://msdn.microsoft.com/en-us/library/79b3xss3.aspx). So either support that or define private/protected constructor.
#44
Given the many additions to the language specification, I suggest you keep a list of those changes either in the original post or a separate wiki page so it's easier to go through the final result.
It's also important to review those final decisions to ensure future compatibility.

By the way, I would still consider changing the classes to static to indicate classes that cannot be instantiated, assuming backwards compatibility can be maintained. Hence it would allow using a static class modifier in the language.
#45
Version 2.0.4 is out and available here.
Fixes a parsing error in some specific scenarios.
#46
For external editing see if this tool helps http://www.adventuregamestudio.co.uk/forums/index.php?topic=46417.0
The Speech Center plugin also has translation editing, amongst other things http://www.adventuregamestudio.co.uk/forums/index.php?topic=45622.0
#47
General note:
If you are using the AGS 3.3.0 beta and the plugin, please make sure to use beta 12 (build 3.3.0.1152) or above.
This release should fix any compatibility issues associated with editor plugins that existed in some earlier beta versions.
If you do find any problems with the plugin while testing the beta release then let me know.

If you are using the current release version (AGS 3.2.1), no action is required at this time.
#48
Editor Development / Re: Transition to .net 4?
Sat 28/12/2013 22:56:31
Quote from: Crimson Wizard on Sat 28/12/2013 22:45:21
Quote from: SpeechCenter on Sat 28/12/2013 22:26:54
Windows XP will reach end of support on April 2014, well before any expected release of 3.4.0, therefore I do not believe it's a concern any longer
Well, this does not mean people will stop using it...
On other hand, it is still possible to use previous version of AGS to create games. I heard some still use 2.72 :).
Your fallback is to not go beyond 4.0, but I think we are talking about far enough to the future to even consider going all the way. In any case, .net 4 can be done even if XP remains.

Quote from: Crimson Wizard on Sat 28/12/2013 22:45:21
Quote from: SpeechCenter on Sat 28/12/2013 22:26:54
  • Ability to compile the entire solution with one instance of Visual Studio Express
We would need to break ties with precompiled allegro libraries to switch from MSVS 2008 completely.
I don't think there are other technical issues.
True, but it's something that needs to be resolved anyway.
#49
Editor Development / Re: Transition to .net 4?
Sat 28/12/2013 22:26:54
Given that 3.3.0 hasn't changed the .net version, I would like to propose this would be included in 3.4.0.
Windows XP will reach end of support on April 2014, well before any expected release of 3.4.0, therefore I do not believe it's a concern any longer (someone can be even brave and consider .net 4.5). Also transitioning to the latest IDE has its merits.

Advantages:

  • More modern IDE and compiler
  • Ability to use newer capabilities in .net
  • Ability to compile the entire solution with one instance of Visual Studio Express

Can we make sure this is included in the feature list of 3.4.0?
#50
Not sure it's related, it sounds more likely a problem with different runtimes that were used in the engine and the plugin. If that's the case you can expect many different types of problems.
#51
Yes, makes sense.
Currently the actual file per character does display the duplicate lines differently, but the index is just the total of all the lines.
It shouldn't be difficult to add to the index that since the information is already generated.

As a workaround you can filter duplicate lines in the plugin and export only the displayed line. It should generate the index file with the correct number of lines.
If you want to have the full scripts with the index file just copy the file to the same directory as the other scripts. The two options should generate the VO scripts in different folders so you don't need to rename things between the two actions.

Please see if the workaround gives you what you need.
#52
To view what's in there start with an hex editor and see what you have there, if you see content it's possible to fix it to open with a text editor. Sometimes text editors don't show something with binary content, although it's more likely your file just contains zeros.

If you are using Windows 7 or above try to right click on the file, and choose "restore previous version", it may take several seconds until you see something. This has a chance if you worked within "my documents". You can also check previous versions for Game.agf.bak.
#53
It depends on the software that adds the file, any file can be marked with a different zone which will pop up the security warning if attempting to open it.
See this very thorough answer here http://superuser.com/questions/323933/how-does-windows-security-warning-do-you-want-to-run-this-file-work
#54
The steps are:
1. open the project without the numbering and translation
2. Open Speech Center plugin
3. optionally filter out lines you don't want to number
4. Go to edit mode
5. Choose to number lines without numbering
6. Save game
7. Update translation file

Thinking about it a bit, if you have done all steps till 6 and closed the project then it's possible that when opening it again this new translation information was not saved because the file was not updated. Will have to check that.
If there's another reason it doesn't display the translation anymore need to understand what was done, it worked in my tests.
#55
Hey Mods,

AFAIK, AGS uses the full text with the &number as the key in order to determine the translation. If the original file does not contain the number in the original (Italian) line then it won't find the correct English line. So what needs to be done is to update the translation file (from AGS, not the plugin). I make sure to copy the translation with the new number into the translation data structure so when you update the translation it should be in there with the correct values. After that it should work.

You will actually see after updating that the translation file that it contains two sets, the original ones and the numbered ones (probably the original in the beginning and the numbered in the second half). This is an AGS behavior, it would be the same if you were to go to the script manually and change the line numbers on your own. It's not something major, it just means your translation file is bigger and has irrelevant lines. I think the right place to add cleanup is in the translation component since it's the one generating the file. It's probably possible to think of a script that removes the unnecessary lines in your specific case.

Still, it should work after you update the translation file, so it's best to start by verifying that.
#56
I don't think having a public property for enumeration is obfuscation. There's no requirement that the class implementing the content also implement the iterator interface.
There are various ways to implement iteration. What if you wanted a collection with forwards and reverse iterator? And what if you had a tree structure implementing both DFS and BFS iteration? Would having two properties that return the enumeration be obfuscation? I seriously doubt that. It's ok to separate implementation into multiple classes if there are multiple usages, and here there are two ways to iterate the scripts. So I would even add a second property that returns a script enumeration, showing that there are indeed two legitimate iteration scenarios and keep the interface as-is using the obsolete attribute.

Also, using your cast method would hide the obsolete warning. Who would remember that there's a possible change in the future? Plus you are still forcing code change to run, because no one would cast in the foreach statement in existing code.

Game.Scripts doesn't represent only the scripts component, it is the main way to access the scripts in the game from the plugin - that means other components use it as well, since plugins are components. The thing about backwards compatibility is allowing existing code to work. You only rely on the fact that I changed the code now to use enumeration, before that I used Count and Item, both of which are absent now, so there are additional compromises there.

But if you keep insisting that in iteration one must always pass the container and not its properties (I'm still not sure what software design principal this derives from), there's actually a third option similar to my second proposal. You could still have the Scripts class remain with exactly the same interface as before, but instead of adding/removing to its own list it adds to another instance which is the ScriptAndHeader collection. As described before, you'll have two properties in Game: Scripts and ScriptAndHeader. Scripts will continue to hold just the last header to support add/remove and have the same obsolete attribute for these methods (iteration could still be regarded as non-obsolete given that it works correctly, for example if I don't care whether the script is header or code and want the similar iteration here and when iterating room scripts)

I believe this option answers your requirement to always implement enumerable on the main class with the internal item it contains and my requirement for backwards compatibility.
#57
Quote from: tzachs on Fri 11/10/2013 23:34:34
Quote from: SpeechCenter on Fri 11/10/2013 13:55:51
The new enumerator still changes the signature.
public IEnumerator GetEnumerator() and IEnumerator IEnumerable.GetEnumerator() are different.

I created a pull request to fix that.
Well, if I understand correctly, you returned the previous enumeration and created a new ScriptAndHeaderEnumerator for the new enumeration of ScriptAndHeader. But didn't monkey use the new enumeration with the previous signature? You didn't change any class except Scripts, so you didn't fix those cases (unless there aren't any? If that's the case then I guess the pull request is fine if monkey has no objections).
You understand correctly. I did test it, TDD proved itself useful on more than a single occasion, so I ignored that comment on testing, but it could have been more serious testing. By the way AGS.Native didn't compile before my change because the Script enumerator doesn't work, which is part of the compatibility problem.
Also didn't find any usages in the editor code with the enumerator, other than the AGS.Native part which wasn't changed. In all instances I found foreach goes for the AllItemsFlat which I don't think is related, but if I missed anything there then that should be fixed.

monkey_05_06 and I discussed the change over at github, he doesn't seem to like it, but with the current structure change I don't see much of a choice.
Another proposal I made was to have 2 structures, one for Scripts and the other for ScriptAndHeaders and two getters. The Scripts is built upon call and ScriptsAndHeaders returns the actual member. Scripts would then become immutable, so some compatibility is lost, but it may be ok.

I still think the change on the structure itself is least intrusive at this point, or as CW suggested, the whole change made by monkey_05_06 may be too risky if it may affect many places which weren't sufficiently tested.
#58
The new enumerator still changes the signature.
public IEnumerator GetEnumerator() and IEnumerator IEnumerable.GetEnumerator() are different.

I created a pull request to fix that.
#59
Quote from: monkey_05_06 on Thu 10/10/2013 21:11:21
You could always abandon older versions. There's no practical reason to not upgrade once 3.3.0 is released.
But as evident there are those who use the beta and the plugin. Someone reported a problem in the beta. Also, it would be nice to give people time to transition from 3.2.1 to 3.3.0 once it's released.
My suggestion is to keep the interface that returns scripts in the enumeration. I can live with the change that for add and remove accepts a different type since I don't call it, but I don't see why it can't enumerate the scripts as it was and force me to know the internal implementation.
#60
Quote from: monkey_05_06 on Thu 10/10/2013 07:48:43
Quote from: SpeechCenter on Thu 10/10/2013 07:13:19methods assume the header always comes before the script

That's actually something that's always kind of bothered me, that implementation detail. It's functional, but it's easily error-prone. I wonder how hard it would be to just introduce a new type to wrap a script and its header together and have the scripts collection hold objects of that type... Hmm...

Edit: It appears there already is a type for that... I'd guess it was added when script folders were added. And in fact, AGS.Types.Scripts is storing them as such, but indexing them separately. I think it would make more sense for Scripts to be updated to just be a collection of ScriptAndHeaders instead of the way it is now (which is why Scripts.Count is returning what it is).
It's not my intent to double post, but I've seen the post in the plugin thread first, but this is probably the right place to discuss a solution. So I just said that the change that was made today to the class breaks too much for the plugin interface. AGS.Types is exposed to the plugins and should be regarded as an interface. I would ask not to have the code as-is, it would make it very difficult for me to maintain the plugin.
SMF spam blocked by CleanTalk