Visions of Aestia

Since we decided that feat-per-level works nicely, I’ve decided to go back and simplify the preqs for feats. When people are having to make the feat decision every level, it’s philosophically better to avoid complicated preqs.

So what’s my criteria for simplifying?

• Eliminate preqs that require only a +1 ability or +1 bonus. So, Power Attack and Quick Draw feats can now be taken by anyone.
• Eliminate preqs that don’t relate to the activity (Pincer and Tails doesn’t actually build on any of its preqs).
• Eliminate all inherited preqs - people are perfectly capable of following feat chains themselves. So, Improved Cleave only lists Cleave in preqs; Cleave in turn lists Power Attack. Easy enough to follow that chain and greatly simplifies presentation.

• This may be overdoing it, but frankly my philosophy is that feats that nobody takes might as well be cut. And by simplifying and eliminating preqs, you’re encouraging people to think about feats they might otherwise ignore.

  In the process, it turns out Blue Rose used much the same criteria - looking at their feat list, I’ve discovered the same sort of process has been undertaken. Like the title says, more goodness.

I need to find (or write) a plugin to make WordPress validate my posts - I had to edit my last post twice because of typos. Forgetting to close an attribute tag is something that should be flagged before publishing the post.

UPDATE: And should not allow you post the empty form; I just hit “Save” followed by “Publish” - oops!

OK, I’ve been monitoring feedback and testing things out, and I think I’ll actually get another Win32 release of Redland out this week. I’ve been notified that MySQL support was not enabled in the binaries, asked to produce Ruby bindings, and need to write a set of tutorials for C#, VB.NET and Python users.

What I have planned includes:

• Binary development packages for people who need to write C/C++ code or language bindings; this will have the header files, libs, and debug symbols.
• Source development packages; this will have the patched source, solution files, and a list of other packages used to build the code.
• A signed .NET assembly. Will need to either get an existing Mono binary, the private key used to sign the Mono binaries, or generate a new key pair for the Win32 stuff.
• Binary Ruby bindings, preferably with whatever ’standard’ installation method Ruby uses.
• Updated binaries and Python bindings with MySQL support turned on.
• Python unit tests, initially based on current test script. If nothing else it’ll help me maintain consistency from release to release.

I’ll try hard to get this put together this week, but don’t be surprised if it takes a little longer - I am doing this in my spare time, after all.

One thing I will not be doing is packaging stuff from CVS. I’ll wait for Dave to make a new release before repackaging things.

Long-term, I’d like to make the Python bindings work a little more closely with standard python libraries; it would be nice to pass a file object to the parser (instead of restricting/forcing it to parse out file names), or pass in an existing MySQL connection to a Storage object. Of course, that means reading up on the C/Python interfaces and figuring out SWIG.