With 3.2.3-1 (the latest release), playing World Making Challenge levels is impossible because of the "Internal Error! Element custom_6 causes endless loop! quit the game?" message that appears everytime you go to another room. And if you choose "No" then no more custom_6 elements is created anyways so the new room will look like a mess.
World Making Challenge level used to find this bug:
http://www.zomis.net/rnd/download.php?id=614 (Level works fine with the pre-release 3.2.3-0)
Small crash limit in 3.2.3-1
Moderators: Flumminator, Zomis
Thank you very much 
There is no other solution besides using a fixed maxloop constant I guess? (not that it's a bad solution - with a big enough constant - I'm just curious)
I haven't understood what exactly that caused the crash brefore this constant was inserted, does it really consume that much memory?
There is no other solution besides using a fixed maxloop constant I guess? (not that it's a bad solution - with a big enough constant - I'm just curious)
I haven't understood what exactly that caused the crash brefore this constant was inserted, does it really consume that much memory?
> There is no other solution besides using a fixed maxloop constant
> I guess?
It depends. In the case which you reported, the loop may be caused by a bug that could be fixed.
But it may well be possible that you can design endless loops on purpose by "clever" CE "programming".
> I haven't understood what exactly that caused the crash brefore this
> constant was inserted, does it really consume that much memory?
A program caught in an endless loop that involves recursive function calls consumes an infinite amount of stack memory and is therefore either terminated by the operating system or crashes it as a result of eating up all available memory.
> I guess?
It depends. In the case which you reported, the loop may be caused by a bug that could be fixed.
But it may well be possible that you can design endless loops on purpose by "clever" CE "programming".
> I haven't understood what exactly that caused the crash brefore this
> constant was inserted, does it really consume that much memory?
A program caught in an endless loop that involves recursive function calls consumes an infinite amount of stack memory and is therefore either terminated by the operating system or crashes it as a result of eating up all available memory.
Would this be considered a type of infinite loop?
The H. World levelset can be downloaded from http://www.bd-fans.com/RnD.html -- search The H. World on that page.
Then I wonder what caused this bug: viewtopic.php?p=8952#8952 (with the playfield size 128x128), since it's proven to not be infinite, just quite big.Holger wrote:A program caught in an endless loop that involves recursive function calls consumes an infinite amount of stack memory and is therefore either terminated by the operating system or crashes it as a result of eating up all available memory.
> Then I wonder what caused this bug: [...], since it's proven to not be
> infinite, just quite big.
Not sure what you mean by "proven to not be infinite" here... As far as I can see, the level mentioned/linked indeed causes an endless loop in the game engine, and this is the cause why it "crashes" the program (or causes the operating system to stop/abort the program, to be more precise).
In fact, I think that this level is a good example for such an endless loop.
This is a different one:
> World Making Challenge level used to find this bug:
It needs a recursion depth of 130. In 3.2.3, it stops at 128. Ouch!
> infinite, just quite big.
Not sure what you mean by "proven to not be infinite" here... As far as I can see, the level mentioned/linked indeed causes an endless loop in the game engine, and this is the cause why it "crashes" the program (or causes the operating system to stop/abort the program, to be more precise).
In fact, I think that this level is a good example for such an endless loop.
This is a different one:
> World Making Challenge level used to find this bug:
It needs a recursion depth of 130. In 3.2.3, it stops at 128. Ouch!
Oh, sorry. I forgot to say that the above mentioned level should be tried with the pre-release 3.2.3-0, not the latest 3.2.3 version.Holger wrote:As far as I can see, the level mentioned/linked indeed causes an endless loop in the game engine, and this is the cause why it "crashes" the program (or causes the operating system to stop/abort the program, to be more precise).
Just my luck...Holger wrote:It needs a recursion depth of 130. In 3.2.3, it stops at 128. Ouch!
Other questions about this,
What are the steps of the recursion?
Are a recursion depth of 130 "endless"? When testing that above level with pre-release, you can modify the playfield size to get different recursion depths - are those endless?
> What are the steps of the recursion?
It's mainly running around in CheckElementChangeExt() and CheckTriggeredElementChangeExt(), which are repeatedly called in a deep recursion loop. Not an endless one, as I have to admit after I tested it with the last pre-release version.
> Are a recursion depth of 130 "endless"?
Definitely not!
> When testing that above level with pre-release, you can modify the
> playfield size to get different recursion depths - are those endless?
No, indeed. Although I first thought that it really would have been a true endless loop! I removed the recursion depth limitation for a test, and tracked the recursion depth. For the mentioned level, the recursion depth was somewhere around 10.000, and caused the game to be "freezed" for around one minute (on my 3 GHz Athlon with Debian Linux), which I think is definitely too deep/long for a normal level. And apparently it caused the game to be terminated on your system ("crashed"), which shows that something should be done to prevent such deep recursion.
I now changed the maximum recursion depth from 128 to 1280 -- this stops/interrupts the above level after a few seconds (on my system) of being "freezed". This should be better than either stopping too early or letting the game be freezed for a long time (or crashed, depending on the "fault tolerance" of your kernel, which also "thought" that something is going wrong on your system).
It's mainly running around in CheckElementChangeExt() and CheckTriggeredElementChangeExt(), which are repeatedly called in a deep recursion loop. Not an endless one, as I have to admit after I tested it with the last pre-release version.
> Are a recursion depth of 130 "endless"?
Definitely not!
> When testing that above level with pre-release, you can modify the
> playfield size to get different recursion depths - are those endless?
No, indeed. Although I first thought that it really would have been a true endless loop! I removed the recursion depth limitation for a test, and tracked the recursion depth. For the mentioned level, the recursion depth was somewhere around 10.000, and caused the game to be "freezed" for around one minute (on my 3 GHz Athlon with Debian Linux), which I think is definitely too deep/long for a normal level. And apparently it caused the game to be terminated on your system ("crashed"), which shows that something should be done to prevent such deep recursion.
I now changed the maximum recursion depth from 128 to 1280 -- this stops/interrupts the above level after a few seconds (on my system) of being "freezed". This should be better than either stopping too early or letting the game be freezed for a long time (or crashed, depending on the "fault tolerance" of your kernel, which also "thought" that something is going wrong on your system).