Re: SRD 3.5 XML and MySQL Database and HTML Offline Searchable SRD 3.5 v1.2
- Two things I would like to work on are:
1. The GUI front end. Part of the GUI work should be making it very
easy for people to new classes, feats, etc. If we can make it easy to
add that information the buy in for this program will be fairly quick...
2. Switching out MySQL for Derby (What Cloudscape became when it was
open sourced). I don't think that Derby is better the MySQL but it IS
a java program. People wouldn't have to download and install MySQL to
get things to work...just a Java VM would be enough.
Thoughts? Opinions about where I should put my time at first?
--- In email@example.com, "andargor" <andargor@y...> wrote:
> SRD 3.5 XML and MySQL Database v1.2 Released
> MySQL and XML data from the D&D 3.5 SRD, with full text. Includes Epic
> and Psionic data with the XPH errata.
> This was extracted directly from the RSRD, and is what I used to do my
> Currently included:
> * Classes
> * Feats
> * Monsters
> * Powers
> * Skills
> * Spells
> * Classes in spell levels converted to long names
> * Added spell_stat and spell_type fields to classes
> * Removed stray anchor tag in full texts
> * Fixed monster stat blocks
> * Miscellaneous data fixes
> There is no pretense at a "good" XML format, it is mainly a flat
> format suitable for databases. But it makes parsing easier. Some
> fields actually have HTML in them, but it's well-formed XML as well.
> HTML Offline Searchable SRD 3.5 v1.2 released
> Pure XML version is also available.
> Changes in 1.2
> * Dragons fully statted.
> * XPH errata included.
> * Skills were combined into a single document, including Epic use
> of skills.
> * Many data errors fixed.
> * Added indices: spells by level, powers by level, monsters by CR,
> monsters by LA.
> Changes in 1.1
> * The search function has been revamped. It should be a lot more
> accurate now.
> * Bookmark functionality has been added. However, this is HIGHLY
> security setting makes saving bookmark data very difficult. The script
> may ask you to allow to save to file, if cookies are not available. If
> so, your bookmarks will be saved under the menu directory, in
> bookmarks.txt. In any case, use at your own risk. I'll try to
> stabilize the feature in the next releases
> Bookmarks support drag and drop. Just drag a bookmark image
> under another, and it'll be moved.
> * Some UI changes, as you may have noticed. You can hide the stuff
> you don't use, but those settings are not saved
> * Miscellaneous content fixes were performed
> * Keyword hyperlinking is (hopefully) more accurate. Instead of
> 75% accuracy, it's now around 90%.
- --- In firstname.lastname@example.org, ysgarran@c... wrote:
> Thoughts? Opinions about where I should put my time at first?Well, Frugal's got the "heart" pretty much done. I would guess that
> Brian F.
the GUI would be important. No offense to Frugal, but it's nice to
have a focus on one aspect, and the demo was focused on the engine
The idea would be to decouple the GUI from the engine internals. Just
have calls to the the engine. Certainly not any GUI code in the
enigne. This allows other plugins as well. I've only glanced at the
source code, so I don't know if it's possible.
On my side I'm still working on data. I don't know to what extent
Frugal has used it, or what's needed. He's written some XSLT/Java to
convert my data, but I guess my aim would be to streamline that
process and perhaps break down the data to "program friendly" level.
> The idea would be to decouple the GUI from the engine internals. JustDefinately, keep the two clearly seperated. The worst case would be
> have calls to the the engine. Certainly not any GUI code in the
> enigne. This allows other plugins as well. I've only glanced at the
> source code, so I don't know if it's possible.
an extra layer to keep the two seperated...even then it would be worth
while to keep the Model-View-Controller (or something else, as long as
the view code is does not become intertwined with the model code).
- andargor wrote:
>Well, Frugal's got the "heart" pretty much done. I would guess thatAre you implying that the GUI I have thrown together is not the
>the GUI would be important. No offense to Frugal, but it's nice to
>have a focus on one aspect, and the demo was focused on the engine
>The idea would be to decouple the GUI from the engine internals. Just
>have calls to the the engine. Certainly not any GUI code in the
>enigne. This allows other plugins as well. I've only glanced at the
>source code, so I don't know if it's possible.
prettiest, most useful thing you have ever seen ;O)
There are a couple of things I wanted to try to imlpement. I am very
pleased with the skills tab, it is much more obvious what has been spent
where. I also like the bonus tab, where you can see exactly what goes to
make up any given bonus in the system.
- --- In email@example.com, Frugal <frugal@p...> wrote:
> andargor wrote:Yes. :P
> Are you implying that the GUI I have thrown together is not the
> prettiest, most useful thing you have ever seen ;O)