Rocks'n'Diamonds

the two different values for slime permeability are also inconsistent. the current bdcff has: if you want unpredictable slime, you write SlimePermeability=0.05. if you want predictable, you write SlimePermeability=3. but you MUST write one of them, or it won't be trivial if predictable or unpredicta...

the current spec states that pushing boulder probability should be 0.25 and 1.0. shouldn't this be 0.125 and 1.0?

i would rather specify an element to which acid converts, it is more generic.
i would even
acid.spreadratio=xxx
acid.convertsto=yyy
and the like. nopuff is the most inconsistent possible.

bye

we have a problem, houston :) we decided that cave size always defaults to 40x22, with 20x12 visible for intermissions. but this way, the bdcff files on arno's site are incompatible with the spec. for example, bd1 intermission 1: [cave] Name=Intermission 1 ... size defaults to 40x22, visible to 20x1...

LogicDeLuxe: you wrote this in the other topic: $17 Bit 2: if set, Acid's original position converts to explosion puff during spreading. Otherwise, Acid remains intact, ie. it's just growing. (unused in the original BD1) so a boolean flag should be added to acidproperties, as bdcff should also suppo...

Do we still need IntermissionProperties.scroll=true|false?

I think no. Defining visible sizes is cleaner; it does not depend on the actual window size the player chooses!

hi i received requests to support atari colors. as naming all colors there makes no sense, i suggest to extend the colors the following way: if the bdcff is a c64 file, or has c64 colors, the program should use names, for example colors=orange gray1 white. (this way, the programs loading bdcff can u...

Hi

With the rightmost rockford, you must only make moves to definite barriers to guarantee the safety of the 3 rockfords you can't see.

that's what i referred to as being a puzzle

yes, but that one should restrict this possibility to intermissions only, and i think cave could also have this. a possible cave buildup (i've seen this in intermissions): there is a large maze in the invisible area. fireflies go into the maze, and you cannot see them, you don't know where they are....

i just can't get the idea, i simply do not understand, how that ("buggy") scrolling makes any sense. how it would enhance game experience. take rta dash cave 5 for example. it is a nice puzzle, you have to find a way which is good for all 3 rockfords on the left, and the one on the right. ...

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 Gdas...

"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 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: - ...

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.

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" setti...