Current state of text based levelformats

Discussion around programming R'n'D, its source code and its tools.

Moderators: Zomis, Flumminator

User avatar
LogicDeLuxe
Posts: 83
Joined: Sun Jun 04, 2006 9:23 pm
Contact:

Post by LogicDeLuxe » Fri Apr 25, 2008 6:31 pm

cirix wrote:yes, but this is meaningless for random elements, as different random seeds might place different elements there. the MAIN purpose of objects is to create parts of the cave which are similar on each levels... like the brick walls in good old bd1 cave a.

so making element_to_replace optional is pointless. anyway, some bdcff files would save a few characters with that... once ago we said that bdcff files are not about size but clarity. and here we are...
There ARE caves which don't use random elements, and in those, it is not exactly intuitive to have a second element to a flood fill instruction. It's not about size but readability. If there is only one element, you don't even have to think about which one is the fill element and which one the element to replace.

cirix
Posts: 31
Joined: Sat Feb 02, 2008 8:38 am

bdcff

Post by cirix » Sat Apr 26, 2008 10:21 am

LogicDeLuxe:

if you would ACTUALLY be writing a program to read and write this format, you would see these problems i'm talking about. but i think this is not the case, and it is very hard this way. some parts of the format impose unnecessary complications, while they seem to be nice.

one simple example, which has nothing to do with floodfills... highscores would also be lot easier to read, if they were "rank score name" instead of "rank name score".
just think about it. reading rank, reading score, reading name till end of line. nice.
the other one, reading rank, reading string, yes, it is a name. reading string, maybe still name, add to string. reading string and so on... then reading string, hey this is end of the line, then the latter was not the name, but a score. or something like that. many solutions, but all are more complicated that it would be when the format was rank score name.

and that's all.
cirix

User avatar
LogicDeLuxe
Posts: 83
Joined: Sun Jun 04, 2006 9:23 pm
Contact:

Re: bdcff

Post by LogicDeLuxe » Sat Apr 26, 2008 12:14 pm

cirix wrote:highscores would also be lot easier to read, if they were "rank score name" instead of "rank name score".
Since no one has implemented highscores yet, it is no problem using it this way. I have no objections. Rank could be left out altogether, though, as it is pretty much redundancy. So let's have just "score name".

This is what this thread is all about: Discussing the BDCFF format and make suggestions.

And of course, I think about machine readability. That's why optional parameters are always at the end, ie. you only have another parameter or end of line. Sure, strings are preferably at the end of a line or in its own line. The highscore thing I didn't notice yet, but the one actually implementing it first probably would have noticed anyways.

We also changed <level=n> to [level=n], restricted the version to a float number etc. in order to simplify parsing.

Unfortunately, we can't change the order of colors without breaking compatibility.

cirix
Posts: 31
Joined: Sat Feb 02, 2008 8:38 am

engine tag

Post by cirix » Wed Apr 30, 2008 9:08 am

if you think about machine readability, the first thing to delete is the "engine" tag. it complicates reading, as it is the first to read (and then set internal variables), only then should other variables be read. otherwise other variables would be overwritten by reading "engine=bd1".
for example, a bdcff file:
scrollpropertiessomething=asdf
enginde=bd1

and there it is.
you see, the bdcff specification did not state the ORDER of variables in the file. this makes the current format virtually impossible to read and parse line by line.

also, think about "computer writability". you have a cave editor, where every option can be set one by one. then it makes no sense to use an engine variable. how should it work? engine is set to bd1. then the user selects xyz=false and qwe=true, then the program should check if engine is to be changed to plck? why? for what? how is this less complicated than simply writing xyz=false and qwe=true to the file?

also, whomever would read and write bdcff files by hand? why is it less complicated to write "engine=bd1" or "engine=plck" by hand (using notepad, for example)? somebody authoring a bdcff file should know all default values for all engines by head. i want sloppy scrolling, then i write "sloppyscrolling=true", and that's it.
cirix

User avatar
LogicDeLuxe
Posts: 83
Joined: Sun Jun 04, 2006 9:23 pm
Contact:

Re: engine tag

Post by LogicDeLuxe » Wed Apr 30, 2008 11:03 am

cirix wrote:scrollpropertiessomething=asdf
enginde=bd1
Why should someone ever wanted to do that? It should be self explanatory to first set the default engine and then apply the tweaks you want. It really makes no sense the other way around.
We could add it to the docs that engine is to be set before any other engine specific settings, though.

cirix
Posts: 31
Joined: Sat Feb 02, 2008 8:38 am

gdash bdcff

Post by cirix » Sun Jun 08, 2008 6:06 pm

hi

and answers to gdash-20080605 bdcff-related issues in this topic.

currently, i'm not really sticking to the bdcff specification which is discussed here. this format is not currently specified correctly. also many properties defined by the current spec is awkward and pointless. at this time, my bdcff reading module already contains about 200 lines of code, which is required to solve the inconsistencies and not-very-well-specificatedness of bdcff.

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.

2) anyway, can somebody show me a bdcff file which uses the engine flag?

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.

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.

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). there, random elements AND map make sense. implementing that first-i-check-if-there-is-a-map-and-then-i-don't-save-random is again a waste of time and code, and an unnecessary complication. yet again, machine readability.

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.

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

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.
    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.
    Gravitation, left up right down, default to down.
    GravitationChangeDelay, seconds to wait after switch is used, defaults to 10.
i could not enter these, because of some ms jet error.

bye
cirix

User avatar
LogicDeLuxe
Posts: 83
Joined: Sun Jun 04, 2006 9:23 pm
Contact:

Re: gdash bdcff

Post by LogicDeLuxe » Mon Jun 16, 2008 8:04 pm

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.
Last edited by LogicDeLuxe on Tue Jun 17, 2008 6:43 am, edited 1 time in total.

cirix
Posts: 31
Joined: Sat Feb 02, 2008 8:38 am

Post by cirix » Tue Jun 17, 2008 6:01 am

Good point. Since PLCK is the most used engine, I would suggest to make that the default engine for BDCFF as of version 1.5 and make any other engine required to be set explicitly.
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.
again, this would need to read the file, store in memory, buffer it, read lines not in order, guess parameters, override parameters, do all the black magic.
so hereby i refuse to implement or support this.

and if you think of it a little, THAT would be the only case where the engine flag would make any sense.

imagine you create an editor with lots of cave switches and options and the like. you save that into a bdcff...
if you insist on using the engine flag, the save code looks like:

Code: Select all

if voodoo.option1=true AND voodoo.option2=false AND amoeba.option3=true AND amoeba.option4=true AND magicwall.option5=false then write Engine=BD1
else
if voodoo.option1=false AND voodoo.option2=false AND amoeba.option3=true AND amoeba.option4=false AND magicwall.option5=true then write Engine=BD2
else
if if if if if if
else
if if if
else
if if if if if
else
write voodoo.option1=...; write voodoo.option2=...; write amoeba.option3=...
and so on.
instead of just writing the last line.
does that make any sense?
cirix

User avatar
LogicDeLuxe
Posts: 83
Joined: Sun Jun 04, 2006 9:23 pm
Contact:

Post by LogicDeLuxe » Tue Jun 17, 2008 7:01 am

cirix wrote:again, this would need to read the file, store in memory, buffer it, read lines not in order, guess parameters, override parameters, do all the black magic.
so hereby i refuse to implement or support this.
You don't need to implement this. Just say that your engine is designed to read and write BDCFF version 0.5 in your documentary, so the user will know.
Your any2gdash.exe is required to detect the engine anyways, so it's no big deal to just write the appropriate engine attribute in the BDCFF file, so it goes conform with 0.5. In case it writes BDCFF files directly one day, as your internal formats are temporarily, as I understand it, it could just write that attribute by the same logic the file extension is chosen currently.

Existing BDCFF files do have some oversights unfortunately, and there is no easy way to solve those problems if at all. There are only those two options. Either ignore them and stick to the new 0.5 specs which solves those issues, or do extensive detection and guess work.
The problem attributes besides the engine defaults are the Size/IntermissionSize/InitialBorder relationship and the DiamondValue, where the latter one can't be solved at all.
If no version is given, you can assume 0.32.

Btw. I fixed the typo in the previous post. I didn't mean to jump to version 1.5.
cirix wrote:and so on.
instead of just writing the last line.
does that make any sense?
There sure is no need to do all those checks. This engine flag is meant for converted C64 caves. If new caves are designed in an editor which allows changing all those flags at will, you just save all those flags. Extra checks would be pointless in this case in deed.

User avatar
LogicDeLuxe
Posts: 83
Joined: Sun Jun 04, 2006 9:23 pm
Contact:

Post by LogicDeLuxe » Tue Aug 26, 2008 11:40 am

A revised version of my proposal for my upcoming engines are online.
This is not the complete list of BDCFF keywords, but it reflects mostly what is discussed here and what is done in Gdash for the most part.
Also very important, the cave object instructions, which seems to be the only up to date reference.
The coloring has different meanings now in regard to what can be expected in my upcoming engines, which is described at the beginning of that document.
http://www.gratissaugen.de/erbsen/bdcff.html

Steffest
Posts: 57
Joined: Thu Dec 06, 2007 9:27 pm
Location: Belgium
Contact:

Post by Steffest » Thu Aug 28, 2008 1:44 pm

Thanks Logicdeluxe

I'll get the specs at http://www.emeraldmines.net/BDCFF/ up to date as soon as possible.

I haven't really followed the discussion in this thread the last months as it seemed Boulderdash-centered (obviously), which I don't know much about.

Funny how everybody runs into specific niche hurdles when implementing the specs, it seems hard to tweak the specs to solve the hurdle without creating more problems for other type of implementations.

I must say for Emerald mines all bases seem to be covered, I have no troubles to convert 99% of all Emerald mines leves to BDCFF.
there's no engine that neeeds to implement ALL specifications, so if there are 2 settings that can't be used together in the fileformat, that's no big deal as the engine itself should have some common sense to get the level into its internal format.

regards,
Steffest

User avatar
LogicDeLuxe
Posts: 83
Joined: Sun Jun 04, 2006 9:23 pm
Contact:

Post by LogicDeLuxe » Thu Aug 28, 2008 4:37 pm

Steffest wrote:Thanks Logicdeluxe

I'll get the specs at http://www.emeraldmines.net/BDCFF/ up to date as soon as possible.
Good. While at it, could you also update the version to 0.5 in both in the header and in the code example to 0.5?

And don't miss the important sentence at the bottom:
Char codes should not include "&", "[", "]", "<" and ">", as well as no characters beyond the 7 bit ASCII table, since BDCFF files are supposed to work on parsers with HTML like character coding and stucture.
HTML support sure is not mandatory, but we should respect the rules and make no trouble to engines which do support it.

And due to the spam issue, could you make the database editable again after login? Accounts could be easily moderated, since supporters would be at least present in this or in the Boulder Dash forum, thus you can see if they are for real.

And do we finally get the objects tab, to make the database complete?
I haven't really followed the discussion in this thread the last months as it seemed Boulderdash-centered (obviously), which I don't know much about.
While the page I linked certainly is, your database isn't. And many of the specs is universal anyways.

cirix
Posts: 31
Joined: Sat Feb 02, 2008 8:38 am

flag used by gdash

Post by cirix » Mon Sep 01, 2008 11:54 am

hi

gdash is now capable of using milliseconds-based, bd1, plck and crdr7-like scheduling. (these are all different).

for this, i use the CaveScheduling tag, which can have the following values: ms, bd1, plck and crdr7. ms is default if frametime tag is seen. plck is default if cavedelay tag is seen, but no cavescheduling tag exists.


bye
cirix

User avatar
LogicDeLuxe
Posts: 83
Joined: Sun Jun 04, 2006 9:23 pm
Contact:

Post by LogicDeLuxe » Sat Sep 13, 2008 8:27 pm

What's the matter with that data base? I get only "The page cannot be found".

Daniel H.
Posts: 535
Joined: Sun Apr 02, 2006 7:13 pm
Location: USA

Post by Daniel H. » Sun Sep 14, 2008 6:59 pm

I am also getting this error.

Post Reply