If memory serves me well, there are some EM caves that use the explosion object in designtime.
E.g. it can be used to delay a falling boulder for 1 frame.
But that would be an execption offcourse ...
For the delay the elements have a delayed property, like "BOULDERfd"
Which stands for Boulder Falling Delayed.
An explosion should not used for a frame delay.
Explosions are a special object, a yamyam can explode and create different things.
Don't know what is the best if they exists as object in other levels they should be in the BDCFF list.
On the other side they are more "effect" specific, so they should be a attribute, so even a butterfly can explode to stones.
To avoid confusion we should not include explosions at the moment.
But as I think abount that, in my opinion, maybe its a better approach to define the behaviour of "shared" items as a property instead of defining different objects. (just like the border property)
Like when the target engine is "BD1" boulders should be BD-boulders, diamonds should be BD-diamonds, Amoeba should be BD-style amoeba, explosions should be BD style explosions ....
switching the target engine to "EMC6" would result in boulders becoming EM style boulders etc ...
Offcourse this would be troublesome if several kinds of boulders are combined in 1 and the same level, but does this ever occur?
Internally an engine like RnD still would see them as different objects, but maybe in the levelfile they could be respresented by the same objectcode, with a property what kind of internal object is meant.
(e.g. in Supaplex, bombs can be stacked on top of each other and have a slower chainexplosion then in EM)
(I just thought of this, but I think this would simplify lots of things in fact ...)
Here I go with LogicDeLuxe. It should be allowed to use different types of bombs, emeralds in a level.
On the other side I go with Steffest. The default behaviour of the BD elements (and only this) should be depends on the engine. Cause of this I want the engine attribute.
Hm. Difficult. The best is to use it as is!! They should be different types of elements, like LogicDeLuxe say!
If a author want to force some element - a different section like the map code section should exists, so not only "Ws=Wall" should be possible, Even "DIAMOND=EM_DIAMOND" should be
possible. (like done in my bdcff.conf file).
Small remark here: I changed naming from "key_red" to "key_1" etc. in the past because "red" is just a property of the currently used graphics set that may change (and does for different EMC level sets).
So using numbers instead of properties like colours seemed to be more abstracted and flexible for element names to me. But probably this doesn't matter that much...
No problem that both can coexists. But "key_red" is more readable, even if a grafic set make it a invisible door.
Dave wrote something about EMC and it behaviour in his and original engine...
The process of the proposal was first intended to cover EM elements. Steffest add than some Supaplex elements and other.
Now we are at RND and any possible elements.
May be we are too fast and it should be more discussed what BDCFF should cover...
But I think if we included all the elements this is the end and we have very flexible way to define elements in BDCFF.
To sum it up, we have the EM elements EM_BOULDER and EM_DIAMOND which don't need a properties attribute.
And we have the BD elements BOULDER and DIAMOND with behavior depending on the engine attribut,
ie. behave exactly like in BD when a BD engine is specified,
and behave the way they do in RND when the RND or a similar engine is specified.
Hm, at the moment only RND can cover this?
The only way to solve it for all games (progs) is that unknown elements should be ignored or mapped to a existing element.
And if a prog exists which cover all elements, than it should take it as is. (RND is close to be it).
Hm, you mean if eninge=BD is defined - all "treasure" should mapped to BD_DIAMOND?
*edit: But what if engine=EMC?
Mutant stones? Bladders? Sounds scary!
I have never heard of them until today. (I though they where new additions to your Crazy Dream 9)
Never saw such elements.
Btw. all elements in my BDCFF extension for Crazy Dream PC proposal exist in some C64 BD.
In C64 BD ? - This is crazy.
Somewhat related, maybe I should allow equations for some arguments where those "true" and "false" arguments don't tell anything.
DummyProperties collect_diamonds=false penalty=false destroyable=true
Yes this is usefull!
explosion codes in caves is definately a bug
I don't know the RND internals, but if they in fact initiate an useless loop, it probably can be considered a bug.
But in BD it is very legitimate to use them in BD1, BD2, 1stB and CrLi.
In PLCK, it's not possible as only one nibble per element tightly limits the possible to place elements.
Hm. Dave mention only that this leads to a loop in KingSoftPlayer.
Don't know the behaviour in RND.
BDCFF should be a common file format. So if we are ready here there should be only one BDCFF file format exists.
If needed add the "EXPLOSION" again (or a related effect) - Exact way should be discussed later (when BDCFF gets finished).
And the answer is ... 42 !