http://www.zomis.net/rnd/download.php?id=622
Any ideas why this happen?
I haven't investigated this much myself, maybe I'll do that sometime. But now it's time to sleep.
Move and crash RnD
Moderators: Flumminator, Zomis
Move and crash RnD
It seems like I found a serious bug when playing around with the world making challenge:
http://www.zomis.net/rnd/download.php?id=622
Any ideas why this happen?
I haven't investigated this much myself, maybe I'll do that sometime. But now it's time to sleep.
http://www.zomis.net/rnd/download.php?id=622
Any ideas why this happen?
I haven't investigated this much myself, maybe I'll do that sometime. But now it's time to sleep.
That's (probably) unrelated to the problem, as that warning probably always appears, right, Sascha?
The H. World levelset can be downloaded from http://www.bd-fans.com/RnD.html -- search The H. World on that page.
Well, not all problems have error messages that can be dumped to the error output. 
The H. World levelset can be downloaded from http://www.bd-fans.com/RnD.html -- search The H. World on that page.
> It seems like I found a serious bug when playing around with the world
> making challenge:
Checked that level -- yep, this level "freezes" the game.
> Any ideas why this happen?
Yes: "custom_6" changes to itself (by overwriting a 3x3 area with itself) when "custom_6" is created. This causes an endless recursion loop in the game engine, which probably should not happen.
> "cannot load file editosetup.conf"
This has absolutely nothing to do with this bug, which can be seen by the fact that it happens with each and every level set that has no "editorsetup.conf" file, and that it only produces a "warning", but not an error. But yes, I should probably suppress these warnings even when running in verbose mode (which is the default for the Windows version), as it seems to only confuse newbies...
> Well, not all problems have error messages that can be dumped to the
> error output.
Exactly. The bug that Zomis reported causes an endless loop that freezes the program -- and apparently causes an abnormal program exit by the operating system after some time (to be precise: when the stack overflows), which looks like a "real" program crash, although it "only" runs out of system resources (memory) here.
I haven't looked deeper into the precise reason for this specific bug yet (which has the same characteristics as the "player gets killed when player dies" bug, which I fixed), but I wrote some workaround code that catches this program in a generic way, asking the player if he/she wants to quit the game because of "element XYZ" causing an endless game engine loop. This prevents the game from "crashing" and gives the level designer a hint which element caused the problem.
Additionally, I should try to fix the problem also in a specific way for exactly this case that was triggered by Zomis' test level, but it may well be possible that there will be special cases left that cannot be fixed in a satisfying way, but have to be handled by clever CE "programming" (by the level designer). For these cases, the problem will now (hopefully) be eliminated by the current generic workaround that will be available in version 3.2.3 (which I will try to release this week).
> making challenge:
Checked that level -- yep, this level "freezes" the game.
> Any ideas why this happen?
Yes: "custom_6" changes to itself (by overwriting a 3x3 area with itself) when "custom_6" is created. This causes an endless recursion loop in the game engine, which probably should not happen.
> "cannot load file editosetup.conf"
This has absolutely nothing to do with this bug, which can be seen by the fact that it happens with each and every level set that has no "editorsetup.conf" file, and that it only produces a "warning", but not an error. But yes, I should probably suppress these warnings even when running in verbose mode (which is the default for the Windows version), as it seems to only confuse newbies...
> Well, not all problems have error messages that can be dumped to the
> error output.
Exactly. The bug that Zomis reported causes an endless loop that freezes the program -- and apparently causes an abnormal program exit by the operating system after some time (to be precise: when the stack overflows), which looks like a "real" program crash, although it "only" runs out of system resources (memory) here.
I haven't looked deeper into the precise reason for this specific bug yet (which has the same characteristics as the "player gets killed when player dies" bug, which I fixed), but I wrote some workaround code that catches this program in a generic way, asking the player if he/she wants to quit the game because of "element XYZ" causing an endless game engine loop. This prevents the game from "crashing" and gives the level designer a hint which element caused the problem.
Additionally, I should try to fix the problem also in a specific way for exactly this case that was triggered by Zomis' test level, but it may well be possible that there will be special cases left that cannot be fixed in a satisfying way, but have to be handled by clever CE "programming" (by the level designer). For these cases, the problem will now (hopefully) be eliminated by the current generic workaround that will be available in version 3.2.3 (which I will try to release this week).
Oh, good. I'm happy to hear that.Holger wrote:[...] version 3.2.3 (which I will try to release this week).
The H. World levelset can be downloaded from http://www.bd-fans.com/RnD.html -- search The H. World on that page.
I don't believe that alone causes the problem, since I've used that element to clear the playfield in all my versions of World Making Challenge.Holger wrote:> Any ideas why this happen?
Yes: "custom_6" changes to itself (by overwriting a 3x3 area with itself) when "custom_6" is created. This causes an endless recursion loop in the game engine, which probably should not happen.
> I don't believe that alone causes the problem, since I've used that
> element to clear the playfield in all my versions of World Making
> Challenge.
Hmm, interesting... I also was surprised that this element was involved in the problem (thinking that this should not happen). But indeed the endless loop function call always used that certain element, trying to check for further element changes which could be triggered by that element change.
At least it does not cause the program to hang/crash anymore... :-/
I'll further investigate this...
> element to clear the playfield in all my versions of World Making
> Challenge.
Hmm, interesting... I also was surprised that this element was involved in the problem (thinking that this should not happen). But indeed the endless loop function call always used that certain element, trying to check for further element changes which could be triggered by that element change.
At least it does not cause the program to hang/crash anymore... :-/
I'll further investigate this...
A little investigation told me that CE2 page 11 is not innocent. Instead of player enters "room elements" it's player enters "empty space" on that test level. So when player enters empty space, CE2 page 11 is triggered, which in turn triggers CE12 page 1 (special steel wall changes to empty space).
And CE12 page 1 is also triggered when CE2 page 1/2 is triggered, so the steel wall disappears when the room creation progress reaches the right/bottom border.
And because the outer playfield is so big, CE6 has so many creations to make, which causes an "endless" loop (but I'm pretty sure that it isn't endless, but somehow it's wasting resources.)
I have another level here which proves this:
http://www.zomis.net/rnd/download.php?id=623
EDIT: The level should be tried with the pre-release 3.2.3-0
Enlarge playfield to 128x128 to make RND crash
Make the playfield smaller (like 18x18) to see that the creation goes much faster (which is natural, of course) and that Rockford responds more quickly when you press a key to turn him around.
Another interesting bug which can be seen in the level above:
Turn off the "creation of" condition for CE1, and change replace when to "destructible" and you will see that only 4 rows of CE1s will be created, the first 2 rows will have 8 CEs and the next 2 will have 6 CEs. This is probably because the elements overwrite each other when changing, but I still think that it's quite odd behavior... but I don't know how to make a workaround for this (except making the element indestructible or change replace when to something less than "destructible").
EDIT: The level should be tried with the pre-release 3.2.3-0
And CE12 page 1 is also triggered when CE2 page 1/2 is triggered, so the steel wall disappears when the room creation progress reaches the right/bottom border.
And because the outer playfield is so big, CE6 has so many creations to make, which causes an "endless" loop (but I'm pretty sure that it isn't endless, but somehow it's wasting resources.)
I have another level here which proves this:
http://www.zomis.net/rnd/download.php?id=623
EDIT: The level should be tried with the pre-release 3.2.3-0
Enlarge playfield to 128x128 to make RND crash
Make the playfield smaller (like 18x18) to see that the creation goes much faster (which is natural, of course) and that Rockford responds more quickly when you press a key to turn him around.
Another interesting bug which can be seen in the level above:
Turn off the "creation of" condition for CE1, and change replace when to "destructible" and you will see that only 4 rows of CE1s will be created, the first 2 rows will have 8 CEs and the next 2 will have 6 CEs. This is probably because the elements overwrite each other when changing, but I still think that it's quite odd behavior... but I don't know how to make a workaround for this (except making the element indestructible or change replace when to something less than "destructible").
EDIT: The level should be tried with the pre-release 3.2.3-0