I've just noticed that the latest (...probably latest) 'world making challenge' level by Zomis doesn't work in version 3.2.3, printing an "internal error ! element custom_6 caused endless loop !" when the player moves to another room.
The element in question:
After creation of custom_6
- Changes to 3x3 target full of custom_6 (r.w.destructible)
After CE delay 1 frame
- Disappears
EDIT: I meant version 3.2.3, not 3.2.4. My mistake!
'World making challenge' internal error in 3.2.3
Moderators: Flumminator, Zomis
'World making challenge' internal error in 3.2.3
Last edited by Tomi on Tue Aug 21, 2007 6:40 pm, edited 1 time in total.
Yeah, I'm also aware of this.. :/ I thought Holger already fixed it, but apparently he hasn't... (or did you try the latest pre-release?)
The thing is that to prevent endless loops in the game engine, Holger set a recursion limit, this limit was unfortunately a little bit too low, so the World Making Challenge level doesn't work. This recursion limit will be increased in a future version so that the World Making Challenge levels work.
The thing is that to prevent endless loops in the game engine, Holger set a recursion limit, this limit was unfortunately a little bit too low, so the World Making Challenge level doesn't work. This recursion limit will be increased in a future version so that the World Making Challenge levels work.
This was already mentioned somewhere else.
The H. World levelset can be downloaded from http://www.bd-fans.com/RnD.html -- search The H. World on that page.
I think there may be two bugs, actually - even if one answers no (don't quit game) to the question, the game doesn't work as intended, and puts the player into the same room.
By the way, would the fix (supposing it works for WMC) work for a bigger WMC, e.g. 60x60 in size? Well, 60x60 is probably crazy, but you get the point. The fix should be future-proof.
By the way, would the fix (supposing it works for WMC) work for a bigger WMC, e.g. 60x60 in size? Well, 60x60 is probably crazy, but you get the point. The fix should be future-proof.
The fix isn't completely future-proof. But probably enough future-proof for all our WMC needs so far. Remember that a 60x60 size would require... uuum... what was that formula again...? 60*60/9 = 400. That's 400 sections. 400/32 = 12.5. That's 13 CEs per room. 256/13 = 19.7. That's 19 rooms.Tomi wrote:I think there may be two bugs, actually - even if one answers no (don't quit game) to the question, the game doesn't work as intended, and puts the player into the same room.
By the way, would the fix (supposing it works for WMC) work for a bigger WMC, e.g. 60x60 in size? Well, 60x60 is probably crazy, but you get the point. The fix should be future-proof.
Of course, if unlimited number of change pages for a CE becomes reality one day (which I really hope, for the sake of WMC creation), You'd just need 1 CE per room, even though it's 400 sections! Now imagine if we make even bigger rooms, why not 120*120? Then it's still only one CE per room, that's like a whole map fit into a CE
(That's 1600 change pages for a 120x120 room btw...)What did you say? Oh, a CEs change pages is limited to 32? Oh well...
Tested it in 3.2.4-1: WMC really does appear to be fixed and the limit is enough for my needs (for now). So this part of the bug can be closed.
However, answering no to the "quit the game" still leads to buggy behavior. It seems the change doesn't complete, or something. (Example level: CE1 changes to 3x3 CE1s when pressed by player or after creation of CE1. Even if one answers no, CE1s don't fill the whole level.)
> The fix isn't completely future-proof. But probably enough future-proof for all our WMC needs so far.
> [...] That's 400 sections. 400/32 = 12.5. That's 13 CEs per room.
Or not?
However, answering no to the "quit the game" still leads to buggy behavior. It seems the change doesn't complete, or something. (Example level: CE1 changes to 3x3 CE1s when pressed by player or after creation of CE1. Even if one answers no, CE1s don't fill the whole level.)
> The fix isn't completely future-proof. But probably enough future-proof for all our WMC needs so far.
> [...] That's 400 sections. 400/32 = 12.5. That's 13 CEs per room.
Or not?
> Tested it in 3.2.4-1: WMC really does appear to be fixed and the limit is
> enough for my needs (for now). So this part of the bug can be closed.
Very good to know! Thanks a lot for the test and confirmation!
> However, answering no to the "quit the game" still leads to buggy
> behavior. It seems the change doesn't complete, or something.
Exactly true! It's just stopped halfways -- that's why you are asked to stop (and fix) the level, as an infinitely deep CE change recursion (or very large depth of it) is considered buggy engine behaviour that should be fixed or worked around (at least it may pause the level for a long time, which is usually not what you want, and will be considered as a "crashed application" by most players anyway).
Therefore, if you continue a level that was stopped due to too deep CE change recursion, it will always result in unpredictable, buggy behaviour. Solution: Change the level to prevent such a deep recursion.
Another thing is the built-in recursion depth: If there is a level that just reaches the maximum recursion depth (being only a few recursions too deep), it is no problem to make this maximum value a little bit larger, of course (by doubling it, for example). This is exactly what happened with Zomis' level, so I set the maximum to a higher value to make it work again.
> enough for my needs (for now). So this part of the bug can be closed.
Very good to know! Thanks a lot for the test and confirmation!
> However, answering no to the "quit the game" still leads to buggy
> behavior. It seems the change doesn't complete, or something.
Exactly true! It's just stopped halfways -- that's why you are asked to stop (and fix) the level, as an infinitely deep CE change recursion (or very large depth of it) is considered buggy engine behaviour that should be fixed or worked around (at least it may pause the level for a long time, which is usually not what you want, and will be considered as a "crashed application" by most players anyway).
Therefore, if you continue a level that was stopped due to too deep CE change recursion, it will always result in unpredictable, buggy behaviour. Solution: Change the level to prevent such a deep recursion.
Another thing is the built-in recursion depth: If there is a level that just reaches the maximum recursion depth (being only a few recursions too deep), it is no problem to make this maximum value a little bit larger, of course (by doubling it, for example). This is exactly what happened with Zomis' level, so I set the maximum to a higher value to make it work again.