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

Reply to thread

Message: <blockquote data-quote="SaiZai" data-source="post: 499748" data-attributes="member: 2538">As you probably know by now, there is one main sticking point for making software that WotC won't sue over (or threaten to): "human readable".By WotC's interpretation - which I disagree with, but they have more lawyers than I so that's moot - this means "scripted".The question for me is: how to proceed?Scripting per se on the Palm platform is, simply put, impractical. It would require an engine, text files, and more processing power than is available, resulting in an extremely slow and bloated program. This, on a platform where the expectation is for instant reaction speeds and <100kb programs.So these are my [viable] options as I see them:1. Make PF "dumb"... in that it would not calculate anything whatsoever. IOW, you would have to enter strength bonus seperately from strength proper, manually recalculate and enter things, etc. This is not far from what many people have asked me for already, but means that it would be primarily a read-only program.This also means that dice rolls would not be allowed within the program.On the up side, it would result in a usable program in the shortest possible time.2. Make PF a "zombie" program: controlled by another, PC-based, fully legit and scripted program(e.g., Luke's RPM)This would presume some sort of connection between the two - either an IR port (if your PC has one), or the cradle. Both options are limited by Palm's API; it has only limited support (especially pre-OS 3.5) for GUI created on-the-fly. [Translation for non-techies: all buttons, boxes, and everything else are normally made with the program. On-the-fly means the program can say "put a button here, with these properties" while running.]Variant 1: pure zombieThis would make PF an extension of RPM, displaying, querying, etc., at the main program's behest, and reporting all responses immediately back. Somewhat like a telnet client, with GUI.It's not very practical - being tied to a PC somewhat nulls the point of having a Palm in the first place - but would allow high level scripting stuff that couldn't be done locally. Would still be the slowest method, though.Variant 2: one-time load zombieThis would be like the first option (dumb program), with RPM handing PF *compiled* rules, which presumably are then legal. This is a somewhat gray area, though, and would still require at least a basic scripting engine within PF.It would however be the closest thing to the original intent of PF - that of an independent, fully-calculated character sheet.3. Allow the user to define the interrelationships manually, within the programThis is a variation on "dummy program" and "one-time load". It is NOT scripting.To elaborate: you would somehow, while running PF, say "this field, 'StrBon', equals (('Str' - 10) / 2)."Problems with this:1. would have to be reentered every time you install PF on a new Palm2. potential for user error3. designing a good, usable interfaceThis would, however, completely sidestep the legality issue; I don't think there is any way that WotC can say that my allowing *you* to enter game mechanics is illegal.4. PluginsThis would mean starting with a dummy program - or possibly one of the other versions above - and allowing third-party plugins to modify it and provide extra features. Just what they would be capable of would depend on how much time I spend developing the API. It would however mean that I would not be responsible by possible OGL violations in the plugins themselves.So...The question is: which of the above should I go for?Sub-question: which of the above would you pay for?If you need me to elaborate on any, just ask (as always).</blockquote>

Verification