Thank you for the invite. When (if?) this works, it should make my own scripts (almost?) obsolete, which is fine. After I'm done with all of them (and am doing other stuff IRL now, so no progress), a logical step was to do something to bind them all, like a master CGI script or somesuch and I just mentally cringe at all the work it would take to rip my scripts to modules, glue them back together, add links everywhere and write a manual explaining how to set up a web server on a home computer.
I won't be joining your team, but by the looks of it, you're better off with MagmaMcFry anyway.
I didn't use databases in my scripts and kept everything in memory in lots of arrays and hashes, but I imagine at some point using a database pays off by actually being less complex and faster, even for non-persistent data.
I didn't use objects because I wanted all my scripts to be single files. It lead to some redundancy and while I'm fine with procedural programming, McFry's approach of making lots of small modules is more professional. Personally I'd go for fewer and bigger modules, but "there is more than one way to do it".
Overall I think that I suck at perl, am unfamiliar with the rest of your toolchain and don't have anything meaningful to contribute to this project (at least not with very significant effort on my part), but if you need some code from my scripts, just take it. I had to solve some problems to make them work properly, so looking at my code may help when you bump into the same problems. Maybe.
http://www.bay12forums.com/smf/index.php?topic=126953.0 If you have any doubts, just ask your programmer how horrible my code is and how much !fun! it would be for him to work with me
> - upload a php website so visitors can query information from the database
I'm surprised you're planning to use perl for reading data and php to show it. I think it would be more consistent to just use perl for both. CGI has been around for a long time.
> I ask this because when we import the RAWs into mySQL we can add some Rules. Right now i am creating
> if it must be mandatory for a ranged to have skill and ammo.
My approach would be not to stop reading data on errors such as negative VALUE (even if it can be negative, what's the point? cursed items?) or missing attack values, but to produce a list of problems and present it to the user. In case of say, a weapon with no ATTACK, add that to warnings and display " " or "
ERROR" in the attack column. Or just have on top of the first page "Readnng done: NO ERRORS" or "ERRORS" with a link to a page with the list of issues.
Use perl and not the database for error detection (or php, whatever), because database will just refuse to insert / edit something that won't pass validation and you probably still want to show even incomplete data, so it is easier for the modder to figure out what went wrong. So basically, this:
> I'd say that the modder would find stuff like that out by himself. How about you just don't make
> anything mandatory that could ever possibly be omitted, so we can load any kind of raws
> into memory that don't have a tag format error when initially parsed.
I'd say focus on getting it to work at all and not on robust error detection at this point. Because working on something that works and you can see the results of small changes instantly is invaluable for programming. Don't be overly ambitious. Even getting some of the functionality to work is more useful than getting bogged down by code and quitting.
I think Dragons have SIZE 25M, so the limit would be a 32 bit integer. In general, assume most numbers are 32 bit integers. So the limit would be 2^31-1 = 2147483647.
> I want easy access to information, and reading over 30 wiki pages is not fast.
Even more to the point, you can have instant information for any mod. And data in tabular form. That was my motivation for writing my scripts.
> What people would like to search
Plants (mainly crops), creatures, items (mainly weapons and armour), syndromes and interactions, reactions (preferably sorted by building), buildings. Bonus points for adding links with IDs, so a table of plants has links to detailed information about them, chains of syndromes and interactions are linked, you can click for details on syndromes or interactions from creatures and so on. Reactions can have links to products and reagnets, items to reactions they're made with. It gets tangled pretty quickly if you try to do it right.
> People telling me what they are going to search most ( so i can create better indexes )
I don't think speed is going to be a concern with the size of a database from DF RAWs. At least for me the slowest thing was reading the data.
> I'd say that you always use the same table for objects that have the same object constructor
> (object constructors are [ITEM_WEAPON:], [REACTION:], [BODY:], [ATTACK:], [SYNDROME], etc.).
I second this and this is what I did. For example IIRC the only difference between Ranged and Melee weapons are presence or absence of RANGED and AMMO. So just have those columns, fill them with NULLs for melee and when you need to query for just ranged or just melee weapons, return only those that have / don't have a NULL.
Furthermore for some things you may want to not read all the tokens, because there are just so many that aren't relevant for displaying data in a table. In those cases instead of a white list (that is a list of all the valid tokens), I used a blacklist (that is read tokens, process relevant ones from a whitelist, stop processing, store result and unget token on any from the blacklist. If you make your blacklist contain things like EOF, ITEM_, REACTION and so on, this works.
> I can fully read (and reproduce, for testing) all [OBJECT:BODY] raws.
Hm, not the thing I'd start with, but it may be kind of useful to see how all the body parts are connected. I guess.
Oh and this tread might be better off in the "Utilities and 3rd party applications" subforum.
