cirix wrote:if you want unpredictable slime, you write SlimePermeability=0.05.
if you want predictable, you write SlimePermeability=3.
No, you won't. You write SlimePermeabilityC64=3, whereas 3 is a byte variable which has the bit pattern the C64 engines use.
Both can coexist, as both should be processed by a BDCFF compliant engine. Using both at the same time is a bit silly, though.
but you MUST write one of them, or it won't be trivial if predictable or unpredictable slime is to be used. common sense would dictate that any value can be missing from the file, if it is to be set to some default, but this is not true for this case, as any explicit value also sets type.
Yes, it is, since both default to no delay at all (which is very predictable, of course), ie. SlimePermeability=1.0 and SlimePermeabilityC64=0
this one also applies to cavedelay and frametime. if we have some default, we should state how many the default is, and WHICH the default one is.
200 ms is default for Frametime. I know, having Frametime and cavedelay is somewhat redundant, but one is an exact timing, while the other merely represents a byte from the PLCK. Cavedelay has no default since Frametime already has a default value. Cavedelay is more complex to implement, as it depends on the time the code take for all the different elements. If both are given, the engine should use Cavedelay if it supports emulating C64 timing, and Frametime if it doesn't.
hereby i also suggest removing the engine flag, as any property of the engine can be specified explicitly, and this way it just makes confusion.
Not a good idea. As it is for readability, and also a simple way to set defaults to a certain engine. You are free to set all attributes explicitly anyways.
the definition of enemydirection should state if time is frames or seconds.
type should use boolean values instead.
It is in seconds, since 1stB synchronized all timers to the cave time.
So we might revise EnemyDirection to:
time is given in seconds. If time=0, no auto direction changes occur. (default time=0)
startbackwards does just that. (default=false)
changeathatching is only affective if time>0. (true for 1stB, false for CrLi)
The timer does not start before the hatching.