i loaded a level i had been making in 4.4.0.5. the falling nitro pack had turned into a falling grass ball, and the falling diamonds had been turned into "unknown BD element".
attached is the level and screenshots of the objects in question in 4.4.0.5 and 4.4.1.0
BD levels made in 4.4.0.5 load with wrong elements in 4.4.1.0
Moderators: Flumminator, Zomis
BD levels made in 4.4.0.5 load with wrong elements in 4.4.1.0
- Attachments
-
007.level- (799 Bytes) Downloaded 20 times
-
- rndshuffle_4410.png (6.38 KiB) Viewed 993 times
-
- rndshuffle_4405.png (5.96 KiB) Viewed 993 times
Re: BD levels made in 4.4.0.5 load with wrong elements in 4.4.1.0
I have to apologize for this hair-raising bug! It should never have happened (and wouldn't if I had read my own comment at the exact line in the code where I introduced this bug by changing game element codes that are stored in level files; maybe I shouldn't have marked them as "runtime elements", which is not exactly correct here).
This bug is fixed now in the latest version 4.4.1.1 now (and also should handle levels with those elements correctly that might have already been created with version 4.4.1.0).
Thanks a lot for quickly reporting this terrible bug!
This bug is fixed now in the latest version 4.4.1.1 now (and also should handle levels with those elements correctly that might have already been created with version 4.4.1.0).
Thanks a lot for quickly reporting this terrible bug!
Re: BD levels made in 4.4.0.5 load with wrong elements in 4.4.1.0
Holger,
I have noticed what seemed to be some funny corruptions in old levels of mine, made a year ago, i.e. after starting to use a version containing the Boulder Dash engine, but I wasn't 100% sure that these were real - thinking maybe I had made a mistake when originally creating the level.
So I am interested in the situations when the game decides to translate what you call 'element codes' and I call 'byte pairs', either when reading or when writing.
eg there are a few 'always translated elements':
BytePairExpected BytePairActual Token
5 32 key_1
8 80 player_1
119 616 em_key_1
207 617 em_key_2
208 618 em_key_3
209 619 em_key_4
210 0 empty_space
296 620 envelope_1
But these seem to be about antique elements from long ago, whereas the recent complaints are about elements belonging to the new Boulder Dash engine.
Question: is there auto-translating that goes on after the user changes the game engine from the 'suitable one' [= engine in which the elements are natively found] to a 'less suitable one'?
eg Make a level with RND elements, eg mole, biomaze etc. Save. Change engine to Boulder Dash engine. Save[?]
eg Make a level with elements from Boulder Dash engine, eg cow, skeleton, pot, water. Save. Change engine to RND engine. Save[?]
???
Big ask - when you have time oneday, could you post the lines of code that are involved with mapping between elements, and provide commentary?
John
I have noticed what seemed to be some funny corruptions in old levels of mine, made a year ago, i.e. after starting to use a version containing the Boulder Dash engine, but I wasn't 100% sure that these were real - thinking maybe I had made a mistake when originally creating the level.
So I am interested in the situations when the game decides to translate what you call 'element codes' and I call 'byte pairs', either when reading or when writing.
eg there are a few 'always translated elements':
BytePairExpected BytePairActual Token
5 32 key_1
8 80 player_1
119 616 em_key_1
207 617 em_key_2
208 618 em_key_3
209 619 em_key_4
210 0 empty_space
296 620 envelope_1
But these seem to be about antique elements from long ago, whereas the recent complaints are about elements belonging to the new Boulder Dash engine.
Question: is there auto-translating that goes on after the user changes the game engine from the 'suitable one' [= engine in which the elements are natively found] to a 'less suitable one'?
eg Make a level with RND elements, eg mole, biomaze etc. Save. Change engine to Boulder Dash engine. Save[?]
eg Make a level with elements from Boulder Dash engine, eg cow, skeleton, pot, water. Save. Change engine to RND engine. Save[?]
???
Big ask - when you have time oneday, could you post the lines of code that are involved with mapping between elements, and provide commentary?
John
Re: BD levels made in 4.4.0.5 load with wrong elements in 4.4.1.0
There are indeed a few "obsolete" game elements, which are defined in "src/main.h", as follows:
They are mapped to the currently used game elements in function "getMappedElement()" in "src/files.c", like this:
Hope that helps! 
Code: Select all
...
#define EL_KEY_OBSOLETE 5 // obsolete; now EL_KEY_1
...
#define EL_PLAYER_OBSOLETE 8 // obsolete; now EL_PLAYER_1
...
#define EL_EM_KEY_1_FILE_OBSOLETE 119 // obsolete; now EL_EM_KEY_1
...
#define EL_EM_KEY_2_FILE_OBSOLETE 207 // obsolete; now EL_EM_KEY_2
#define EL_EM_KEY_3_FILE_OBSOLETE 208 // obsolete; now EL_EM_KEY_3
#define EL_EM_KEY_4_FILE_OBSOLETE 209 // obsolete; now EL_EM_KEY_4
...
#define EL_ENVELOPE_OBSOLETE 296 // obsolete; now EL_ENVELOPE_1
...
Code: Select all
int getMappedElement(int element)
{
// remap some (historic, now obsolete) elements
switch (element)
{
case EL_PLAYER_OBSOLETE:
element = EL_PLAYER_1;
break;
case EL_KEY_OBSOLETE:
element = EL_KEY_1;
break;
case EL_EM_KEY_1_FILE_OBSOLETE:
element = EL_EM_KEY_1;
break;
case EL_EM_KEY_2_FILE_OBSOLETE:
element = EL_EM_KEY_2;
break;
case EL_EM_KEY_3_FILE_OBSOLETE:
element = EL_EM_KEY_3;
break;
case EL_EM_KEY_4_FILE_OBSOLETE:
element = EL_EM_KEY_4;
break;
case EL_ENVELOPE_OBSOLETE:
element = EL_ENVELOPE_1;
break;
case EL_SP_EMPTY:
element = EL_EMPTY;
break;
default:
if (element >= NUM_FILE_ELEMENTS)
{
Warn("invalid level element %d", element);
element = EL_UNKNOWN;
}
break;
}
return element;
}