> Sometimes when you are developing something like this you get lost and forget about what you where trying to do.
I know, having another person comment from a different angle is very useful.
> I got inspired to do this when i first saw the tables made by your scripts in Masterwork's manual.
Heh, nice to know. It also shows how much I neglected my project over the past year, if you managed to do all this and I'm less than halfway done.
> You have lots of experience doing parsers.
Not really. I haven't read any books on the subject and don't even know how things like Parse::RecDescent or yacc work. All I did was parse some text with regexps and put the results in nested arrays and associative arrays. Technically this is fairly easy, but it is a lot of butt in the chair work and a lot of code. Magmawiki was pretty helpful with which tokens are the most important, but I'm partly walking in the dark here. For me, actually knowing the RAWs is a more critical skill for my (and this) project than slicing it up with regexps.
> You are more than welcome to join the project if you would like to create parsers in PHP that could extract data from the raws to an associative array.
Nah, IIRC you already got a Perl teacher who is way ahead of me on the team. Besides, I have little time and motivation these days, never even touched PHP and would rather finish my own version.
If you see anything in my scripts that you'd like to copy, feel free to do it.
My idea for a parser has evolved from full frontal spaghetti code into more modular approach:
* One function to get next token. It is a bottleneck and should be fast, preferably even not based on using a regex to fetch stuff inside [] or the thing that unget token put back. It takes care of opening slurping and closing input files, so tokens are seen as a continious stream with some special tokens "__EOF__" in between.
* One function to unget a token, so that get_token returns it next - this is a very useful feature for backtracking.
* One hash (associative array) of "Master Tokens" - things like PLANT CREATURE ITEM_... and so on.
* One master function to read data. It looks for master tokens, then calls a specific function to read a plant, animal, creature or whatever.
* A number of functions to read specific RAW items, like a plant or a trap component. They return (or store in a global array) associative arrays filled with data from RAWs. These functions should be in their respective modules/classes, along with functions for printing, storing in databse or whatever else you need. They can call some other specialized functions, like "read weapon attack" or "read interaction".
* Since there are so many DF tokens and I'm lazy, I don't read them all. Instead, the "Master function" ignores everything that's not a master token. Specialized functions ignore unrecognized tokens, but on an end of file or a master token unget that token and return so that master can sort things out.
* Avoid regexps where a simple string comparison will suffice. Also, part of the token before the first colon can be obtained at the beginning of a switch statement, then compared multiple times.
* I'm not using a database and you might have some trouble with this approach, because some things I print as columns are actually made of arrays, associative arrays, or multiple scalars under different names, which in a DB this is solved by throwing more tables at the problem.
* I considered writing a function to print a table from an associative array, but it proved to be too much work, compared to every item type having it's own function to print a table without translating it to some intermediate representation first. Those functions use a bunch of global configuration variables that tell them how to begin table, separate columns, etc.
> I am struggling to choose where this thread belongs... It started in the Creative Section, then moved here... hahaha
The most intuitive place for me is "Utilities and 3rd party applications", since that's what this is. I only managed to find it, because of the link in your old thread.
I complain a lot, but I like how pretty and user friendly your tables are (and on a web server, which I don't know how to set up), but not the amount of info provided. Tools to give advice on what is good and what can be worn with what would be great.
Another useful feature would be for items to have links to other items, for example an interaction or reaction chain would be easily navigable with just relative links and anchors on IDs. (I insist on listing IDs in my scripts because then are very useful to modders / advanced users).
> I find that in the current version relevant elements stand out more and the data is thus easier to read. The new interface is a bit too plain or generic.
It is Windows 8 ugly, but functional. I assume there will be a graphical overhaul, but I'd rather see more info in general and no row limit than prettier icons.
Author
Topic: DFDB Remake (moved) (Read 3390 times)