cirix wrote:1) the engine flag is still unnecessary. ok, i implemented it, but it required to load the complete text file, see if there is an engine flag, and only then to process others. (instead of being able to parse the file line-by-line, without the requirement to be able to jump around in it)
also, for example it is not told what to do here:
Code: Select all
[game]
voodoo.diamondcollector=true
[cave]
name=abcd
engine=plck
no sense to use this.
As far as I know of, there is no file using the engine attribute, yet. Reading the file out of sequence is pointless, though. I really can't think of a reason why anyone should set specific details first and then the engine in general. The engine is meant to set all the default, so it always should be set first. This really should be mentioned in the specs, but isn't yet.
Setting specific things like voodoo.diamondcollector=true in the game section also doesn't make sense, imho. Such parameter is meant for newly made caves which doesn't strictly follow any C64 engine, and thus really belongs to a cave section, unless it is meant to be the same for all caves, but then you wouldn't use engine=plck in the cave section anyways. So you really are interpreting too much into it. Some constellations really don't make sense and can be dismissed and assumed that no one want to use it that way anyways.
2) anyway, can somebody show me a bdcff file which uses the engine flag?
I don't think there is one yet. Just assume that this attribute comes before any attributes which would override its properties.
3) i don't see why maps and objects couldn't be used together. currently i implement this as:
- 1. draw random elements OR map
2. draw objects.
why couldn't i draw objects over a map? it is very clear what to do.
While it would be obvious, it sure would break compatibility, as the specs told not to mix them from the beginning.
As we need the starting position be added anyways, due to Rockford's extension in the BD2 format, which basically implements a map object (the bitwise one), I defined a map object. And since it's there, I can't think of any reason not to use it. We don't need to think of downward compatibility in this case, as Rockford's extensions are incompatible to previous BDCFF specs anyways, unless you convert it to a map, but you would loose the level feature then.
3a) i use maps for crazy dream 7, where there are copy and paste object codes, which are not documented anywhere. or are they? whenever my code finds a paste object, i flatten the objects to a map, and do the copy and paste there.
I noticed this, and I completely forgot about that feature, as CD7 is the only engine using it anyways. But why not just implementing copy and paste objects for them? It could be used copy sections of the random objects, so you can have repeating patterns which are different for each level. A feature you can't have otherwise, unless you have a separate map for each level.
4) saving random things for mapped caves is again a don't-care thing. if there is a map, draw it. if there is no map, default to random elements. also, one could imagine a map which has holes... (like bitmaps in profi boulder).
That's one of the reasons I defined a map object. It has an optional element parameter for this reason. And with the random object, you could also place random objects on top of a map object.
Both are not used yet, so if you feel there is a need to refine the parameters, fell free to try things out and make suggestions. We probably would accept them, if they proved useful.
The random attribute specified in a map based cave is not really useful, but shouldn't be a problem either, as it would be either ignored or completely overdrawn by the engine. It's merely a bit dirty to have it there.
5) also, random and maps are not that simple. for map-based caves, the predictable random generator has to be set to 0x00, 0x1e. this is not specified anywhere. messing around with disabling random for mapped caves would also change something here.
In deed, I also encountered that particular problem while thinking of my next C64 engine. How about defining
SlimePermeabilityC64.seed for this? There would be either one seed specified, or one for each level.
6) every option should have a REAL default value. currently defaults are only specified for different engines, but the spec does not say anything about the values, when there is no engine tag at all. (that is 100% of the current bdcff files.)
Good point. Since PLCK is the most used engine, I would suggest to make that the default engine for BDCFF as of version 0.5 and make any other engine required to be set explicitly.
(Edit: typo fixed. I didn't mean to jump to version 1.5)
For previous versions, you have to assume BD1 when objects are used and BD2 when the raster object or add object is used as well in any cave. I know, a bit awkward, but this is in deed one of the oversights in the older versions.
7) new properties suggested:
- PneumaticHammer.frames, number of frames for the hammer to work. default 5.
PneumaticHammer.wallsreappear, if hammered walls reappear, default false.
PneumaticHammer.wallsreappearframes, the number of frames for them to reappear, deafult to 100.
I have no objections.[/list]
BD1Scheduling, true or false, true for using bd1 scheduling (my best shot is 88ms + 3.66ms*ckdelay + animation&elements induced delay), false for using ckdelay (i use 65ms+elements OR ckdelay*20ms, whichever is bigger). default to false.
Default should be set to true for BD1 and false for any other engine. And the engine really should have a default, as I said above.
- Gravitation, left up right down, default to down.
GravitationChangeDelay, seconds to wait after switch is used, defaults to 10.
For consistency, I would suggest Gravitation.direction and Gravitation.ChangeDelay instead. The defaults are fine to me.
i could not enter these, because of some ms jet error.
Indeed, this really needs to be fixed. And we still need the Objects-tab.