Current state of text based levelformats

[cirix]

hi,

is there any reason why the format uses <level=x> instead of [level=x]?
the bracket variant is used for any other tags, like [game], [cave] and so on.

bye

[LogicDeLuxe]

is there any reason why the format uses <level=x> instead of [level=x]?
the bracket variant is used for any other tags, like [game], [cave] and so on.

I don't remember. Probably not. If no one can think of a reason, we really might change this to be consistent with the other sections.

[HerzAusGold]

I changed the name for RnD element 68 from LAMPsocket to SOKOBANFIELD.Please check, if this is all correct now!

Yep, it's correct now.

[LogicDeLuxe]

Like cirix has discovered, there is a difference in explosions between BD1/BD2/PLCK and 1stB/CrLi, thus I added one more attribute.
ShortExplosions=true|false
If set to true, the engine will skip EXPLOSION1 and DIAMONDBIRTH1 starting the sequence right with EXPLOSION2 and DIAMONDBIRTH2.

[LogicDeLuxe]

Some older attributes were missing:

I added the Colors attribute, which is already in use by existing BDCFF files around from the beginning.

I added the AltDirt attribute, which was already in my proposal, and is now in need by cirix's new gdash.

[LogicDeLuxe]

Suggestion:

Concerning MagicWallType
A better proposal:
MagicWallProperties.waitforhatching=true|false
MagicWallProperties.convertamoeba=true|false
MagicWallProperties.breakscan=true|false
If waitforhatching=true, the timer does not start befor the guy's hatching, even in case the Magic Wall is activated before this happens. (true for 1stB, CrLi, false for BD1, BD2, PLCK)
If convertamoeba=true, the Amoeba will convert to Diamonds the moment a Boulder is dropped into a Magic Wall, placement and state of the Magic Wall or the Amoeba don't matter for this to occur. (cave dependent for 1stB, CrLi, false for BD1, BD2, PLCK)
If breakscan=true, the engine emulates the buggy timing behavior in BD1 on the C64 which many caves require to work properly. This also has the side effect of converting Amoeba under certain conditions. (true for BD1 C64, false for all other engines, including the Atari version of BD1)


Concerning AmoebaType
A better proposal:
AmoebaProperties.waitforhatching=true|false
AmoebaProperties.immediately=true|false
If waitforhatching=true, the timer does not start befor the guy's hatching, even in case the Amoeba is free to grow before this happens. (true for 1stB, CrLi, false for BD1, BD2, PLCK)
If immediately=true, the timer does start immediately, no matter if the Amoeba is activated or still inactive. If immediately=false, the Amoeba timer does not start before the Amoeba comes to life. (true for BD1, false for all other engines)

Concerning BorderProperties
A better proposal:
BorderProperties.scan=true|false
BorderProperties.effect=true|false
BorderProperties.wraparound=true|false
BorderProperties.lineshift=true|false
BorderProperties.perfectwrap=true|false
If scan=true, Inbox and Outbox will work on upper and lower borders, things can move from those borders and Amoebas are counted. (true for BD1, 1stB and CrLi, false for PLCK)
If effect=true, the effect table is processed in the upper and lower border. If set to false, element which move to those borders are stuck there forever and Explosion sequences aren't executed either. (true for 1stB, CrLi, false for BD1, BD2, PLCK)
If wraparound=true, elements leaving the upper or lower border appear on the opposite border. (true for 1stB, CrLi, false for BD1, BD2, PLCK)
If lineshift=true, elements leaving the right border reappear one line lower at the left, and elements leaving the left border reappear one line higher on the right. This also affects cave objects. (true for all C64 engines)
If perfectwrap=true, upper and lower wraparound is calculated with redirection. If set to false, only movements are redirected, but interaction is implemented with copying the borders above/bellow the cave between scan intervals, which is faster, but has side effects which needs to be emulated. (false for all C64 engines).
Note that wrapping left/right is always possible as C64 engine merely see a continues array in RAM.

Concerning InOutBoxType
A better proposal:
InOutBoxProperties.forceflashing=true|false
InOutBoxProperties.hatchpattern=true|false
InOutBoxProperties.synchronous=true|false
If forceflashing=true, flashing is forced by alternating the state of the first box in cave on each scan. If set to false, boxes won't flash in case there is an even number of them. (true for 1stB, CrLi, false for BD1, BD2, PLCK)
If hatchpattern=true, the guy's hatching can only occur from the empty state of a box, which result in a pattern of appearance. (true for all C64 engines, but here since many clones don't do it this way)
If synchronous=true, all boxes are drawn in the same state (full/empty) on one scan. (false for all C64 engines, but here since many clones work this way)

[cirix]

hi,

i think i suggest a simple boolean, yes or no altdirt property.
any program importing a bd2 cave, for example, can check if there is an amoeba, and then set the flag accordingly, and is therefore fully compatible. this way the "altdirt=amoeba" and "altdirt=amoeba slime" settings are simply redundant.
(anyways, those are also a logical error. altdirt=amoeba, it says that alternative dirt graphics if amoeba is present. but during play, dirt graphics won't change back if you suffocate the amoeba...)

if that is a simple yes/no option, which does not check amoeba presence, the user is allowed to set it on his own, enabling it also in non-amoeba caves for some reason.

i might even suggest using "dirtlookslike=altdirt" for this purpose.

bye

[cirix]

also, the dirt looks like and expanding wall looks like properties are missing, which were supported by diego effects in bd.


i think i would also remove cavesize and intermissionsize properties, and require those to be set explicitly in every [cave] section. that few bytes don't really matter.

[cirix]

is the Scrollproperties flag used for any particular reason? i think emulating the buggy bd1 scrolling routine (which, as a matter of fact, fails for multiple players in a cave) is futile.

suggest an ActivePlayerIsFirst flag, which sets if the active and to-be-followed-by-the-scrolling player is:
- the lower right one (false, can be used for bd1, plck)
- or the upper left one (true, can be used for 1stb and up).
and this is not only for scrolling, as the suicide key kills the active player, and chasing boulders also follow the active player, so it affects cave events! (it was not supported by older engines, but this way it can be logically extended. i think no one would kill his active player if he can not see it on the screen.)

by

[LogicDeLuxe]

hi,

i think i suggest a simple boolean, yes or no altdirt property.
any program importing a bd2 cave, for example, can check if there is an amoeba, and then set the flag accordingly, and is therefore fully compatible. this way the "altdirt=amoeba" and "altdirt=amoeba slime" settings are simply redundant.

"altdirt=amoeba slime" makes it possible to simply set a global behavior, which we do with many other attributes as well, ie. in a [game] section, but outside a [cave]-section. But if we don't want a global setup for this, we could set this for every single cave using a boolean, of course. Is this what we want?

also, the dirt looks like and expanding wall looks like properties are missing, which were supported by diego effects in bd.

The converter could just insert eatable walls when the "dirt looks like wall" effect is used. It would require that eatable walls behave exactly like dirt, though, which includes eaten by biters and consumed by amoeba. Do we want this?
On the other hand, if we don't want eatable walls behaving exactly like dirt, we should add DIRTLOOKSLIKEeffect and (H/V)EXPANDINGWALLLOOKSLIKEeffect to the Bdin elements. Then the question remains, shall the EXPANDINGSTEELWALL be indestructible (in contrast to a regular expanding wall which merely looks like steelwall)?

i think i would also remove cavesize and intermissionsize properties, and require those to be set explicitly in every [cave] section. that few bytes don't really matter.

This sure would break compatibility. And you are free to use the Size attribute in every cave anyways.

[LogicDeLuxe]

is the Scrollproperties flag used for any particular reason? i think emulating the buggy bd1 scrolling routine (which, as a matter of fact, fails for multiple players in a cave) is futile.

We certainly won't emulate the bug. Emulating the multiple players behavior is simple, though. All you need is count the steps in a singed byte variable and let it over/underflow. And since there are many caves relying on this, we really need this.

suggest an ActivePlayerIsFirst flag, which sets if the active and to-be-followed-by-the-scrolling player is:
- the lower right one (false, can be used for bd1, plck)

It's not that simple. In BD1 BD2, the game initially scrolls where the last Inbox is drawn with a Point object. In PLCK, it initially scrolls to the last Inbox found when expanding the caves to the byte array. Scrolling is simply counting the steps in BD1/BD2/PLCK. There is no routine checking the position of active players in those engines.

For the 1stB/CrLi scroll routine, we might extend this with a Scrolltofirstguy attribute to make it possible to do the opposite, but we don't need this for C64 compatibility.

[cirix]

"altdirt=amoeba slime" makes it possible to simply set a global behavior, which we do with many other attributes as well, ie. in a [game] section, but outside a [cave]-section. But if we don't want a global setup for this, we could set this for every single cave using a boolean, of course. Is this what we want?

Of course. The easiest and most simple way to do this. Also the setting can be easily understood by users not knowing the internals of original BD.

The converter could just insert eatable walls when the "dirt looks like wall" effect is used.

Very bad design. What if dirt looks like steel wall? what if dirt looks like a firefly? What if dirt looks like space?!! How do you convert between formats if you lose this information, the difference between "invisible dirt" and space? This is a visual setting only, and has nothing to do with cave internals.

This sure would break compatibility.

Removing the cavesize and intermissionsize properties? Why?

We certainly won't emulate the bug. Emulating the multiple players behavior is simple, though. All you need is count the steps in a singed byte variable and let it over/underflow. And since there are many caves relying on this, we really need this.

Which ones?

[LogicDeLuxe]

So we need DIRTLOOKSLIKEeffect and (H/V)EXPANDINGWALLLOOKSLIKEeffect in the Bdin element list. Should be no problem. And since I've been asked to have two versions of dirt graphics in the same cave like I did in Crazy Dream 7, we could also define DIRT2 to the Bdex element list.
That way, we archive several goals in a simple way:
- Fully covering the "looks like"-Diego effects.
- Having a simple way to use Altdirt, ie. Effect=DIRTLOOKSLIKEeffect DIRT2
- Beeing able to have both dirts in the same cave.

Removing the cavesize and intermissionsize properties? Why?

Obviously, since this was the standard for years, tools expect it to be this way.
For instance, your Gdash apparently don't know them. Take a look what it does to the intermissions in this version of BD1: http://www.boulder-dash.nl/down/bdcff/B ... rLiepa.zip

Emulating the multiple players behavior is simple, though. All you need is count the steps in a singed byte variable and let it over/underflow. And since there are many caves relying on this, we really need this.

Which ones?

I don't have a list, but virtually all caves using those engines with multiple Inboxes are affected.

[cirix]

I don't have a list, but virtually all caves using those engines with multiple Inboxes are affected.

An example would be needed. Not to see how this affect DISPLAY, but how it affects GAMEPLAY.

Obviously, since this was the standard for years, tools expect it to be this way.
For instance, your Gdash apparently don't know them. Take a look what it does to the intermissions in this version of BD1: http://www.boulder-dash.nl/down/bdcff/B ... rLiepa.zip

yes, that one assumes 40x22 and 20x12, those can be default. but it DOES NOT CONTAIN either the cavesize, or the intermissionsize tags, which could be easily removed. i just haven't come across any bdcff which had that. Not mentioning, that BD1 intermissions ARE NOT 20x12, they are 40x22 with upper-left 20x12 visible. We would rather need a Size=40 22 and Visible=0 0 20 12 for this.
and as you mention "standard for years", i don't know ANY tool which reads bdcff correctly.

[LogicDeLuxe]

Some scroll critical caves:
Remixdeluxe 2 Cave 18, Cave 19
RTA Dash 05, Cave 6

And while looking for critical caves, I found a game which interestingly does scroll to the lowest active Rockford: Matthias Steiner's Boulder Dash+ 3 uses a modified PLCK engine. Take a look at Cave 3. So we need that option after all.

Some thoughts to a revised Scrollproperties. How about:
Scrollproperties.activeguyscan=true|false
Scrollproperties.counteroverflow=true|false
Scrollproperties.activeguyisfirst=true|false
If activeguyscan=true, the engine looks and remembers the position of a guy in order to scroll to it. If set to false, the engine merely counts the steps and scrolls this far. (true for 1stB, CrLi, false for BD1, BD2, PLCK)
If counteroverflow=true, the exact scroll behavior of the C64 is emulated, which has only a singed byte to count the steps and thus can overflow which results in scrolling to the opposite end. This variable is only effective if activeguyscan=false. (true for all C64 engines where applicable)
If activeguyisfirst=true, the engine looks for the first Inbox/guy to scroll to. If set to false, it scrolls to the last one. If activeguyscan is set to false, this variable is only effective for Inboxes. (true for 1stB, CrLi, false for PLCK, not applicable for BD1, BD2)

A special case is when activeguyscan is set to false and an Inbox is places with a Point object. This overrides the position scan if Inboxes and uses the coordinates of the Inbox which is places last (thus no activeguyisfirst default for BD1 and BD2)

Eventhough counteroverflow is not as important than the other variables, as I don't exactly remember a cave requiring this. It should be there to tell the software whenever a cave was made without that limitation in mind.