AGS 3.1.0 Final - World's Heaviest Bridegroom Edition

[RickJ]

Thanks monkey, your explanation of the loop check helps make sense of what I observed.  I think the confusing part is that the error message seems so damn sure of itself and where the problem is.   

Perhaps, instead of implementing a more elaborate loopcheck, the error message could just include a disclaimer such as "inifinte loop may be in calling function, check call stack" and include some additional information in the manual under the :while" function, explaining how the loop check is done and how to disable it with the noloopcheck keyword etc.

... I have found cases where it is simplest to use a break flag as the condition of a while loop.

I usually just set the iterator to it's max value to break a loop, this however, usually requires that the value of the iterator first be copied another variable.   I prefer this method because I can  use/reuse single character  variables for iterators and meaningful intuitive names for specific iterator values.  It also makes for somewhat simpler conditional expressions.

I do agree  that the break keyword is sorely missed and I hope that it will be added to the language in some future version of AGS.   

[Snarky]

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.

There's a fundamental theorem of computer science that proves that there's no general, surefire way to tell whether a program has gone into an infinite loop. So an "actual" check for infinite loops is probably not the right approach to the problem.

[RickJ]

There's a fundamental theorem of computer science that proves that there's no general, surefire way to tell whether a program has gone into an infinite loop.

I don't see what that has to do with what's being discussed here.   As a practical matter, for most all applications  it's possible to determine a time limit;  it's done all the time and is referred to as a Watchdog Timer.  The cited article talks mostly about hardware but the same techniques are also used in software, especially where multiple computers are communicating real-time data over a network.   

The AGS loop check, as I understand it uses a similar technique, substituting iterations for the time limit.   As you correctly point out someone may (and they have already) create a program that legitimately executes more than 150,000 iterations and so there is a noloopcheck keyword that can be used to surpress  the error. 

But all of this is completely irrelevant to the discussion because we were not talking about detecting infinite loops but instead were discussing how the current loopcheck rather authoritatively declares that there is a problem in a particular place in the code when in fact it is somewhere else.  It is entirely possible to determine which loop has exceeded the allocated time/iteration slot but it's apparently not easy to implement at this point in time. It's something that will be considered and possibly dealt with in the future.   It was suggested that additional information in the actual error message and in the description of the "while"keyword would be helpful and perhaps adequate. 

[Snarky]

I don't disagree with that. I was responding to a specific comment that implied that the ideal way to solve this problem would be a real and accurate test for infinite loops. Since that is impossible, improving the intuitiveness of the current approach is a completely reasonable strategy.

[monkey0506]

BUG: I appear to have inadvertently tricked the autocomplete calltip. By typing something such as this:

Code: ags

if (blah) {
  then this
}
else some_int = the_other;

While hovering the mouse over later instances of some_int the calltip shows, "else some_int". I also see some_int listed in the autocomplete twice, once with a blue box, and once with a green box.

[Dualnames]

Sorry, If someone has said about this or I'm wrong, but isn't there the ability to use noloopcheck to avoid that?

[monkey0506]

If you're regarding the infinite loop issue Dualnames, you're correct that noloopcheck can be used to by-pass the 150k loop check (as noted). However that's not really what the issue was. The issue was that RickJ forgot to update his iterator for one of his while loops that he was using, but the loop check was flagging a different loop. Simply using noloopcheck would result in an infinite loop which is not what was intended, and would cause errors in the game (presumably forcing the user to manually abort from the OS).

[naltimari]

Infinite loop watchdogs are a good thing, IMO. Occasionally, when I'm coding, I forget to increment the loop index inside the loop, and then the watchdog bails me out. 

The discussion seems to be around when there are nested while's, currently it appears that the watchdog binds to only one of them (the outermost?). I can't think of another solution than to implement a stack of watchdogs...  :

On a side note, I find 'noloopcheck' a very dangerous keyword to use. 150000 iterations without checking for user input is likely to be something that would freeze the interface, at least for a while (no pun intended). Instead of using 'noloopcheck', I prefer to 'WaitMouseKey(1)' inside the loop. This way, you don't freeze the interface and you can always interrupt the long operation should the user chose to cancel it.

[Lt. Smash]

BUG: I appear to have inadvertently tricked the autocomplete calltip. By typing something such as this:

Code: ags

if (blah) {
  then this
}
else some_int = the_other;

While hovering the mouse over later instances of some_int the calltip shows, "else some_int". I also see some_int listed in the autocomplete twice, once with a blue box, and once with a green box.

something similar accoured when I wrote something like:

Code: ags

int i,j,k;
i = 10;
j = 20;

only i is shown by the calltip.

[Pumaman]

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.

Hmm, that's basically what I tried, though I have to ask why you were doing that? Why not just have the game at 320x200? Still, it shouldn't cause corruptions in 3.1, so if you would be able to upload the 3.0.2 version of the game that would be appreciated.

Perhaps, instead of implementing a more elaborate loopcheck, the error message could just include a disclaimer such as "inifinte loop may be in calling function, check call stack"

Sounds reasonable, I'll do this.

While hovering the mouse over later instances of some_int the calltip shows, "else some_int". I also see some_int listed in the autocomplete twice, once with a blue box, and once with a green box.

Well spotted thanks, I'll get it fixed.

something similar accoured when I wrote something like:
int i,j,k;
i = 10;
j = 20;
only i is shown by the calltip.

I can't replicate this. I tried it, but it showed i, j and k in the autocomplete.

[Lt. Smash]

something similar accoured when I wrote something like:
int i,j,k;
only i is shown by the calltip.

I can't replicate this. I tried it, but it showed i, j and k in the autocomplete.

ok, then this:

Code: ags

int i = 1,  ypos = 0;

edit: and I meant the calltip, not the autocomplete

[Shane 'ProgZmax' Stevens]

This isn't anything major, but after leaving ags open for about a week and then closing it, for some reason the help file stayed open.  This hasn't happened before, so it could be something you did for this version on purpose?  One thing that might have caused it is when I was closing ags reminded me I had not backed up my game and the confirmation box may have prevented it from closing the help file.

[Dualnames]

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.

Hmm, that's basically what I tried, though I have to ask why you were doing that? Why not just have the game at 320x200? Still, it shouldn't cause corruptions in 3.1, so if you would be able to upload the 3.0.2 version of the game that would be appreciated.

Ok, I'll send it as soon as possible via PM, if it's no trouble.

[Pumaman]

ok, then this:
int i = 1,  ypos = 0;

edit: and I meant the calltip, not the autocomplete

What do you mean by "calltip"? The function calltips display the parameters to the function that you're calling, so I wouldn't expect it to display local variables in that anyway.

This isn't anything major, but after leaving ags open for about a week and then closing it, for some reason the help file stayed open.  This hasn't happened before, so it could be something you did for this version on purpose?  One thing that might have caused it is when I was closing ags reminded me I had not backed up my game and the confirmation box may have prevented it from closing the help file.

Hehe, I hadn't even noticed that closing it normally shuts the help file. It's not a deliberate feature of AGS ... maybe this time you opened the help file from the Start Menu link rather than from within the editor?
Either way it's not something I plan on investigating in-depth!

Ok, I'll send it as soon as possible via PM, if it's no trouble.

Thanks!

[monkey0506]

Regarding opening the help file from within the editor, I do have one major annoyance but I understand if it's not something that can be easily fixed. When opening help from the editor, it apparently becomes impossible to switch back to the editor without first either manually minimizing the help file or closing it.

If this has to do with the way it's being opened and can't really be fixed that's fine, but I just wanted to put it out there that it has annoyed me for some time.

[RickJ]

While upgrading some things from V2.72 to the current beta I found an interesting behavior of the ListBox control.   The code snippet below  is contained within a function that implements a drop down list that is dynamically sized and positioned.   

This seemed to work just fine in V2.72 but in the current beta I get  an infinite loop error at  runtime.  The obvious next debugging step is to put a display statement inside the loop to look at ItemConut and RowCount.   With a display statement inside the loop or just before it, the problem does not occur.    Placing a Wait(1) statement just before the loop also prevents the problem from occurring.   

Code: ags

	MyListbox.Height = 0;
	while (MyListbox.ItemCount>MyListbox.RowCount) {
		MyListbox.Height = MyListbox.Height+5;
	}

A display statement just before the loop shows ItemCount=10 and RowCount=0 both of which which are correct.   The only thing seems to makes sense is that the RowCount is not being updated when the Height is changed in the current game cycle but is being updated in subsequent game cycles. 

My code is long and complicated so there are plenty of opportunities for this to be the result of some embarrassing bit of programming on my part.   Since I am almost always guilty of such things I am the first one I suspect.  I don't have any code running in any repeatedly_execute() handler anywhere so I don't think it's possible for there to be any kind of race condition in the script.   I can't think of any other way that I could have blundered.

I didn't like the looping algorithm for setting the height anyway and have replaced it with a calculation that works just fine and is a better solution.   So this behavior is no longer a problem for me but I  thought it may be of some interest as it may be an indicator of other more sinister things lurking about. 

[Shane 'ProgZmax' Stevens]

When opening help from the editor, it apparently becomes impossible to switch back to the editor without first either manually minimizing the help file or closing it.

This doesn't happen for me.  CJ seems to have the help file set to 'Always on top' when it's open.  It stays on the screen when I click back into the editor but I'm able to use the editor just fine.  I do this quite often when I'm checking ascii values, in fact.

[Pumaman]

Regarding opening the help file from within the editor, I do have one major annoyance but I understand if it's not something that can be easily fixed. When opening help from the editor, it apparently becomes impossible to switch back to the editor without first either manually minimizing the help file or closing it.

I don't get this problem most of the time but there was a bit of wierdness going on, so I've changed the way it loads the help file for RC1 -- let me know if this fixes the problem.

This seemed to work just fine in V2.72 but in the current beta I get  an infinite loop error at  runtime.  The obvious next debugging step is to put a display statement inside the loop to look at ItemConut and RowCount.   With a display statement inside the loop or just before it, the problem does not occur.    Placing a Wait(1) statement just before the loop also prevents the problem from occurring.   

Where is this code, is it in game_start? I don't think anythign around that area has changed since 2.72 so it's a bit strange, I'll see if I can reproduce the problem though.


Anyway, RC 1 is now up. This fixes various things in preparation for the final release.

Those of you out there who are still using 3.0.2 and haven't tried 3.1 yet, please give it a go because I want to make sure that the native hi-res co-ordinates hasn't got any issues remaining.

[monkey0506]

The fix for the help file is perfect. I didn't realize it wasn't something everyone was experiencing or I might've spoken up sooner. But it works great now so thanks Chris.

Also, I'm glad to see that Display will now work in games without any GUIs. That one's bothered me before...

[Pumaman]

Glad to see that's working for you.

Now, one thing I forgot to mention was the new Tip Of The Day area. Currently it's only got three tips (well, two really) -- so any suggestions for tips to put in there would be appreciated.

Generally I think Tip Of The Day tips should be related to "hidden" AGS features, ie. things that aren't obvious and that people could easily miss and not realise that you could do -- so if anyone can think of any, please do post them!