Upgrade your account to a Community Supporter account and remove most of the site ads.

Reply to thread

Message: <blockquote data-quote="Luke" data-source="post: 458795" data-attributes="member: 602">What you showed was a piece of text that represented an algorithm to execute on variables. If its not compiled, then its a script.What you describe is effectively building a type of scripting engine, via database configuration. Its a direct parallel to what they call "ladder logic" in the process control world. It has the advantage of being reasonably easy to configure very simple expressions in a controlled manner without exposing the complexities of a scripting engine, and on the other hand its a lot more cumbersome, especially for non-trivial expressions.Essentially you're building a database tree that passes through an iterim stage of being put together just like a script, just before you actually execute it.I don't see any legal problem with it. The only problem I see is it possibly being relatively slow and simplistic in power. You're effectively building your own scripting interpreter.In RPM for example, casting a Cat's grace (or equipping gauntlets of dexterity to keep it out of the in-game area), causes a massive number of recalculations. The type of stacking modifier needs to be measured against all other current dexterity modifiers to come up with a new dexterity which recalcs dexmod, reflex, AC, all dex based skills, all ranged weapon attack bonuses, etc etc.The variables being open was never in question. Its the *algorithms* that are in question. Use of clever compiled generic algoithms that aren't specifically derived from the SRD are not a problem. That's where most of the work is done ( adding stacked modifiers). The issue is when SRD derived algorithms are required, and they are put in compiled code because the lst/tag system isn't sophicated enough (or too slow, or whatever) to cope.What I'm saying is that if Wizard's *know* where that's going on, they'll say *no*.Perhaps there won't be much difference between your system and PCGen's at the end of the day...Ultimately the database configuration route is going to be more complex and slower than a compact scripting language, for the bits that go beyond stacked modifier addition. Its an age-old argument of simplicity and safety vs speed and power.You can probably break an RPG app down into 3 distinct parts:1. The textual part (such as a skill name and description)2. The data you need (such as the modifiers to skills for the Alrtness feat).3. The algorithms that combine the data mathematically to produce the required calculations.As long as all 3 of those parts from the SRD, or derived from it, are all openly human readable, you're okay.Its part 3 that causes all the problems, and which is addressed most easily by scripting (since a script, by definition, is a readable piece of text that calculates a result).Getting back to the very original point about ETools being limited due to lack of scripting:The algorithms in ETools are hard-coded into the app, and hence open D20-style expansion is extremely limited. ETools doesn't have scripting, and it also doesn't have the method you describe of flexible algorithm building via a database tree.</blockquote>

Verification