AGS 3.1.0 Final - World's Heaviest Bridegroom Edition

[Pumaman]

I'm pretty excited about the new custom dialog system. It seems like it might be a bit complicated for the end-user (say if they want a scrolling dialog), but modules could be written to encapsulate and simplify the code...provided the dialog_options_* functions are available from scripts other than the global script (not yet tested).

Yeah, the scripting involved is relatively complex; but what it does is provides the ability for module authors to create an icon-based dialog system / scrollable dialog / etc, rather than having to wait months for me to get around to adding support into AGS itself.

When a text is displayed in a textwindow (Display("asdf") you can erase the dialog gui.

I'll update the docs to mention this -- basically the four custom dialog functions all run on the rep_exec_always thread which means they shouldn't call any blocking commands. The mouse_click one for example should only really be used to update the way the options are displayed, not to try and do any game tasks.

That Display() call in the example is just a placeholder line that you'd replace with your own code.

[GarageGothic]

I can confirm that the debugger related crashes no longer occur in beta 9. I also experience less of a framerate drop when running with the debugger than I did before, but perhaps that's just my imagination. Anyhow, great work, CJ!

Wow, the new dialog option display system looks great. Just the kind of customizability I've been hoping for almost since I started using AGS. Would it be too much to ask for a similar feature covering the actual execution of the dialog? Such as:

Code: ags

on_character_say(Character* Char, String dialog)

That would, for instance, let you display each dialog lines in any way you like, change talking views to reflect emotion (you would need some special functionality to play back the talking animation lipsynced though) or parse dialog to a conversation log - the main reason that I currently use my own Say function and don't benefit from the built-in dialog scripting, since every topic would just contain a dialog_request call anyway.

[RickJ]

It's not possible to filter on the "No more files" message, because on non-English versions of Windows that message will be localized.

Smiley sent me the following PM today likely in response to your comments ...

since I think it's a WinAPI error, it might be possible to get an error code from GetLastError() and use this to filter it. Sorry for not thinking about that before.

http://ueberlicht.googlepages.com/test.exe
Same procedure: insert the path to the share into the textbox.

You should get a message box with an error code.
(I hope it's '18', because that's the error code for ERROR_NO_MORE_FILES.)

I tried his test and indeed it returned an error code of 18 as he expected it to do.  So perhaps this is the solution you seek?   

Again hope this is helpful...

[Lt. Smash]

Here are two suggestion for AGS 3.1:
- Seperation of gui-, character- and global script. Only virtually for the user to be in an extra page. Actually the codes ARE in the global script but the user can't see them, as they are only shown in the EDIT GUI SCRIPT/EDIT CHARACTER SCRIPT panes. (more info here: link)
- To make translation easier there could be a table in the AGS editor (similar to General Settings). On the left side original language, to the right the translated version. Just as a simple replacement of the "Currently you cannot edit translations within the editor..."

[RickJ]

- Seperation of gui-, character- and global script. Only virtually for the user to be in an extra page. Actually the codes ARE in the global script but the user can't see them, as they are only shown in the EDIT GUI SCRIPT/EDIT CHARACTER SCRIPT panes. (more info here: link)

This was discussed in the following thread:
http://www.adventuregamestudio.co.uk/yabb/index.php?topic=35370.0

[Dusk]

- To make translation easier there could be a table in the AGS editor (similar to General Settings). On the left side original language, to the right the translated version.

Mmmm often who translates is not part of the development team of a game, so it's a good thing that he doesn't need AGS nor the source of the game to do the translation, but only a text editor.

A step forward regarding translations would be maybe changing the file format so that you could use some popular software internationalization tools to handle them.

Collaborative translation web-apps, for example, might speed up the translation of big games.

Just an idea, absolutely not a feature request

D.

[Pumaman]

I can confirm that the debugger related crashes no longer occur in beta 9. I also experience less of a framerate drop when running with the debugger than I did before, but perhaps that's just my imagination. Anyhow, great work, CJ!

Excellent, glad to hear it!

By the way, if anyone has any problems with the debugger in this beta, please do report them so I can make sure it's all working properly

it be too much to ask for a similar feature covering the actual execution of the dialog? Such as:
on_character_say(Character* Char, String dialog)

Yeah, this is certainly a possibility for the future. It's more complicated though, and I'd have to plan out how to fit it into the system.

(I hope it's '18', because that's the error code for ERROR_NO_MORE_FILES.)

I tried his test and indeed it returned an error code of 18 as he expected it to do.  So perhaps this is the solution you seek?   

Thanks, I'll look into that.

- To make translation easier there could be a table in the AGS editor (similar to General Settings). On the left side original language, to the right the translated version. Just as a simple replacement of the "Currently you cannot edit translations within the editor..."

Well, as Dusk says it's not normally the game author who does the translating, but it could be useful just to use for reviewing the translated lines.

A step forward regarding translations would be maybe changing the file format so that you could use some popular software internationalization tools to handle them.

If you can point me towards what the most popular tool(s) are for this, I can investigate compatibility with them.

[Dusk]

A step forward regarding translations would be maybe changing the file format so that you could use some popular software internationalization tools to handle them.

If you can point me towards what the most popular tool(s) are for this, I can investigate compatibility with them.

I found an interesting list of tools here.
It seems that the most popular formats involved in software localization (and supported by most tools) are PO and the XML-based XLIFF.

bye

[Rulaman]

Look at
http://www.adventuregamestudio.co.uk/yabb/index.php?topic=33293.0

This is no automatic translation program, but you can get a good overview over the progress.

[Dualnames]

Ok, well, I found this weird thing. My resolution is 640x480.

However I'm using low-res coordinates(320x200).
When I imported the game from 3.02, all walk-behinds were disabled(not actually, but that was what you saw). Ok so i disabled low res, then walk behinds worked but GUI's and characters were placed in the wrong place.
So I went at the original (3.02) changed res to 320x200 and imported with beta 9. That worked.(low res coordinates true).

So why do I have to do that? Can't I just stick to 640x480? If I transpose the game to 320x200 it will not allow it to be played to windowscreen. And I want to upgrade to 3.1 because I want to use change translation feature. So any chance that I could still use 640x480? I'm thinking that some of those filters could do the trick..

[Pumaman]

I found an interesting list of tools here.
It seems that the most popular formats involved in software localization (and supported by most tools) are PO and the XML-based XLIFF.

Thanks. Realistically, this probably isn't something I'll be adding to AGS with a high priority, however.

Look at
http://www.adventuregamestudio.co.uk/yabb/index.php?topic=33293.0

This is no automatic translation program, but you can get a good overview over the progress.

Good work there, looks like a really useful tool

However I'm using low-res coordinates(320x200).
When I imported the game from 3.02, all walk-behinds were disabled(not actually, but that was what you saw). Ok so i disabled low res, then walk behinds worked but GUI's and characters were placed in the wrong place.
So I went at the original (3.02) changed res to 320x200 and imported with beta 9. That worked.(low res coordinates true).

Can you explain that again, in more detail? I'm not sure what you mean.

What do you mean by "all walk-behinds were disabled(not actually, but that was what you saw)"?

So why do I have to do that?

You shouldn't have to do anything, it should just work.
So, if there's a problem, I need to investigate it.
Therefore, please provide more details about the problem. If it's possible to upload a sample game that demonstrates the problem when imported into the beta, that'd be really useful.

[Dualnames]

Ok, well the game is using 640x480 resolution at AGS 3.02.

When I import at the beta all the walkbehinds change position.

This is happening, my guess, because almost all the game backgrounds and sprites use the 320x200.
So, when I change the value of -use low coordinates- to false, the GUI's mess up and the characters as well.

However if I change the original's reso to 320x200 and import to the AGS beta, everything is solved but sorta doesn;t make the game so easy to play on window mode.

[GarageGothic]

Since there won't be a major overhaul of the translation feature any time soon, I have one small suggestion:

When I worked as a professional localization tester, we were constantly running into problems of strings not having unique IDs. For instance a simple adjective like "New" could be re-used multiple times in the English GUI text, but in French or Italian it would need different forms depending on what it's referring to (new game, new player profile etc.). Since AGS directly translates strings based on content, there's really no way of distinguishing between these. So, what I'd like to suggest would be a new - and fully documented - masking symbol that would allow you to insert comments/IDs into strings, which wouldn't be displayed in-game and would be ignored in String.Length and GetTextWidth calculations. For instance:

Code: ags

lblNewGame.Text = "New^MAINMENU^"

and

Code: ags

lblNewProfile.Text= "New^PLAYERPROFILE^"

would become two unique Strings in the translation source despite displaying the same text in-game.

[Pumaman]

Ok, well the game is using 640x480 resolution at AGS 3.02.

When I import at the beta all the walkbehinds change position.

This is happening, my guess, because almost all the game backgrounds and sprites use the 320x200.

Ok, here's what I tried:
1. Created a new 320x200 game in 3.0.2
2. Imported a background and set up some walk-behinds in a new room.
3. Changed resolution to 640x480
4. Ran game (all fine)
5. Imported game into 3.1 beta 9
6. Opened the room
7. All walk-behinds look fine

Would you be able to upload the 3.0.2 version of the game that's causing the problem so that I can investigate it?

So, when I change the value of -use low coordinates- to false, the GUI's mess up and the characters as well.

Yes, I would expect that to happen. If you change that setting, then obviously all the X/Y/Width/Height values will change their meaning, so you'd have to adjust all your scripts to compensate.

However if I change the original's reso to 320x200 and import to the AGS beta, everything is solved but sorta doesn;t make the game so easy to play on window mode.

If your game is designed for 320x200, then you should leave it set to 320x200 in AGS, and use the Graphic Filter option in Setup to play it in a larger window.

When I worked as a professional localization tester, we were constantly running into problems of strings not having unique IDs. For instance a simple adjective like "New" could be re-used multiple times in the English GUI text, but in French or Italian it would need different forms depending on what it's referring to (new game, new player profile etc.). Since AGS directly translates strings based on content, there's really no way of distinguishing between these. So, what I'd like to suggest would be a new - and fully documented - masking symbol that would allow you to insert comments/IDs into strings, which wouldn't be displayed in-game and would be ignored in String.Length and GetTextWidth calculations. For instance:

lblNewGame.Text = "New^MAINMENU^"

I don't think there's any need for a special feature here, really. You could use that script with the ^ characters in, and then create two translations, English and French.

In the English translation you'd simply translate that line to "New" and leave the rest of the lines blank.
In the French translation you'd translate all the lines into whatever they needed to be.

[Dualnames]

It seems that well, I'll just downgrade the reso to 320x200 whenever 3.1 becomes stable.. Thanks for taking time to answer my questions Chris. Well, for the feature of translation and other goodies it's definetely worth doing so.

[Pumaman]

Well, the problem is that if problems are reported but I'm not able to solve them, then 3.1 will never become stable. So would you mind uploading the 3.0.2 version of the game so that I can investigate the problem?

[RickJ]

Nested While Loop Check
I don't know if this is known or not so I thought i would report it just in case.  I had situation where I called a function from within an infinite while loop (unintentionally of course  ).   The function that was called also contained a while loop but this while loop worked just like it was supposed to and did not have any problems. 

The infinite loop (in MyFunction) caused a run-time exception as one would expect, however, the editor pointed me to the while loop, that was working correctly, an located in the called function (dosomething).   I stared at the dosomething() code for a long time thinking there must be something really obvious wrong  .

I finally took a break and went for a walk with my cat who told me that if there aren't any birds in the tree you may as well hunt somewhere else.   So that's exactly what I did when I got back to the computer.  I looked at the place from where dosomething() was called and lo and behold it was being called from within a sometimes infinite while loop.

There error message was correct but it pointed to the wrong place and was therefore confusing.   I should have known better I guess but I always suspect my self first and the compiler last.   Anyway here is an illustration of the situation. 

Code: ags

function dosomething() {
     int i = 0;
     while (i<SOMETHING)( {
          // Do something here
          i++;
     }   // Game aborts with infinite loop message and opens editor on this line
} 

function MyFunction() {
     int i = 0;
     while (i<SOMETHING)( {
          // Do something here    
     }
}

I'm one beta version behind so I didn't have the benefit of the call stack but I pretty much knew where dosomething() was being called from.   There is not much that can be done to makeup for programmer stupidity but perhaps this info will help you think of something.   

[Dualnames]

Well, the problem is that if problems are reported but I'm not able to solve them, then 3.1 will never become stable. So would you mind uploading the 3.0.2 version of the game so that I can investigate the problem?

Referring to my condition, I'd like to say that concerning game backgrounds, everytime I imported one of them , I set the resolution at 320x200 and then changed to 640x480. And all sprites are 320x200. Does, that give any ideas? Try doing so. And if walkcycles are working fine on 3.1 I'll send you the version.

[monkey0506]

Nested While Loop Check

I think that the real problem here is that AGS doesn't have an actual check for infinite loops, per se, it only checks that the game is allowed to update at least once every 150,000 loops. Generally this is a reasonable exception.

In your specific case, it would seem, the 150,000 loop without an update is actually occurring within the dosomething function which is where it crashes, as opposed to MyFunction which is the real culprit for what would otherwise run smoothly.

The only way that I can think of that might make it possible to detect the correct function would be for AGS to check that the condition of the while statement has changed since the last loop. However, that would make a loop such as this not work properly:

Code: ags

bool break = false;
while (!break) {
  // some complex conditions and things
  // if (blah) break = true;
}

The function may not have to use an integer index to run the internal conditions. For example, if I have a function set up to parse a String and each time it's called return some portion of the String until it reaches the end of the String. It's not necessarily the greatest example because I could set up the loop differently, but I have found cases where it is simplest to use a break flag as the condition of a while loop.

So, given that I would say the best solution is the call stack which we now have available...

[Pumaman]

The infinite loop (in MyFunction) caused a run-time exception as one would expect, however, the editor pointed me to the while loop, that was working correctly, an located in the called function (dosomething).   I stared at the dosomething() code for a long time thinking there must be something really obvious wrong  .

Interesting point. The way AGS checks for infinite loops is simply to count up the number of times a while loop jumps back to the start, resetting its counter when the screen is updated. Therefore if you had several nested while loops, the actual code location where it broke would just depend on where the script happened to be when the counter ticked over 150000.

Changing the way that this detection works would be a fair effort, and for now it doesn't seem worth the effort. Thanks for raising this though, it's something I'll consider when I update the scripting system.