eTools Patch and Source Code
- Thread starter Therigwin
- Start date
You are correct. There are differences between "coders" and "engineers". Usually they are very different in their approach to software development. However, there are more than enough companies out there that have a large proportion of their engineering staff that are gamers.
The next step should be the Red Hat approach, IMHO. Take the source thats there, and release it as open source for download. Make changes or incorporate community changes as needed. Sell a version packaged with instructions and an install CD in stores for the less technical minded.
A couple of advantages here:
1) A large portion of the bugs can be fixed by the community at large (a good many are engineers)
2) the software can still be sold, with a decent profit margin, to the non-savvy computer folk
3) The community at large will offer a great deal of your technical support
Disadvantages
1) You have to review other peoples code
2) You have to do documentation (blah I hate writing this crap)
3) Bandwidth, at least initially
4) Access license
I expect that community would quickly convert the access portion to MySql if they had to pay for licenses...
Just more thoughts,
Arnix (tm)
The next step should be the Red Hat approach, IMHO. Take the source thats there, and release it as open source for download. Make changes or incorporate community changes as needed. Sell a version packaged with instructions and an install CD in stores for the less technical minded.
A couple of advantages here:
1) A large portion of the bugs can be fixed by the community at large (a good many are engineers)
2) the software can still be sold, with a decent profit margin, to the non-savvy computer folk
3) The community at large will offer a great deal of your technical support
Disadvantages
1) You have to review other peoples code
2) You have to do documentation (blah I hate writing this crap)
3) Bandwidth, at least initially
4) Access license
I expect that community would quickly convert the access portion to MySql if they had to pay for licenses...
Just more thoughts,
Arnix (tm)
Luke said:
Loremaster is a bit complex but not impossible, after all PCGen has already done this. Here is a rough idea of how I would do it, using key words and flexible fields in the database:
(SpellSchoolDivination Level>0) and
(SpellSchoolDivination Level>0) and
(SpellShoolDivination Level>2) and
(KnowledgeAny Rank > 9) and
(KnowledgeAny Rank > 9) and
(FeatTypeMetaMagic or FeatTypeItemCreation) and
(FeatTypeMetaMagic or FeatTypeItemCreation) and
(FeatTypeMetaMagic or FeatTypeItemCreation) and
(FeatSkillFocus Knowledge)
Luke said:
Yes, and it was for the most part datadriven. It is now d20 compliant and although it doesn't include .lst files for WOTC splatbooks it does include other 3rd party material; all without scripting. I also, believe that it is possible to create your own .lst files for the present version that will allow for the inclusion of WOTC splatbooks. They just are not distributing them due to license reasons.
Let me clarify. I am saying that scripting and hardcoding is not necessary for a d20 character generator(license issues aside). You can do everything via keywords in your data. However, if you want a program to use at the table I believe that scripting would be the best way to go.
Arnix said:
Maybe...
Sure, I suppose that works. As long as the core team develops the software via standard industry engineering principles. And that any "fixes" from outside the core team are scrutinized before being applied to make sure that they are appropriate. There are open-source examples of this too; JBOSS and NetBeans that have worked well.
One problem with this... if you distribute MySQL with software you have to buy a license for it.
If you made the user download your software and then download MySQL and set it up, run some data import scripts, then no license.Vpenman said:
"No Prob Bob"
Let me clarify my felling on using Access. If you do not inlude GUI for people to make drastic changes then a non-proprietary database is very good idea. I agree that the product should have included a way for the average non-tech savy user to manipulate it. If you did provide a GUI to edit the database than its not as important.
However, it is still a good idea to use Access. First of all it will save you development time. Secondly, 3rd party software developers can easily 'plug into' this database and use the data in it to go beyond what the original product could do. I believe that Luke originally intended to do just that with RPM. I know that I had intended to use Master Tools database to read information from and randomly generate an NPC(I have never been satisfied with anyones implementation of random generated NPCs) and then write it back out in a form that Master Tools could read.
If Master Tools had been a completly database driven product with a non-proprietary database backend; 3rd party developers could have driven secondary sales of the product. There are a large number of people who are interested in developing d20 software. If WOTC could have produced a Core Rules Software package that was open for development they could capitalize on these developers just as the Core Rules books capitalize on the 3rd party d20 publishers. As it is now I think that PCGen, RPM, and TwinRose are going to fill this void.
Hollywood said:
One problem with this... if you distribute MySQL with software you have to buy a license for it.
I don't belive so. Last time I looked, it appeared that to distribute MySql with your code, you had to distribute the MySql source, your source, and any linking source. To do otherwise in in violation of its "licensing". See the court case (name paraphrase) MySql vs Nusphere. Similar to Linux. If you distribute it, you must provide the source.
IANAL btw, so I could be wrong...
Arnix (tm)
smetzger said:
Continuing with an alternate view point here...
If the Core Rules Database had been open, someone would have done something bad with it. I am thinking of creating "items" that really didn't work with the program or that overwrote existing, legitimate items.
These would have been distributed by various means. People's programs would have stopped working as they expected. Some of these people would have blamed us. Certainly there would have been a customer service problem that would be costly to address.
The costs to product reputation and of additional customer service would not, in my opinion, have been offset through increased sales due to 3rd party development. I believe what we did in Core Rules where the program handled the database operation, including the transfer of data among systems, was the best solution for the overwhelming majority of our customers.
Also, we know from experience, that the ODBC problems many have had with Access are not uncommon. (Although our install program would have checked for these and offered to install the current ones if it did not find those on the target system).
I believe an open database would have benefitted very few customers and had the potential to cause harm to a great number.
This pretty much explains why we went the custom database route, even though Access would have been less expensive to develop. We believed, and I continue to believe, the custom database was the best solution for the majority of our customers.
Victor
smetzger said:
Boy, that looks just like scripting to me, and nothing like a purely data-driven solution. That is one big *expression*.
Now, you call these "flexible fields", but they're pretty much *variables*, and they pretty much feed into an scripted
expression.
You might be thinking to use some kind of database that supports this kind of approach, but what you're actually proposing here is a database that supports a scripting capability.
If you've worked with "pure" SQL before, its extremely likely that you've encountered the expression "SQL scripts" before.
The word "scripts" is used because it refers to *expressions* that the database supports.
Take a look into the E-Tools Access database, and see if that's how E-Tools works. It isn't.
Well, I did ask that nobody publicly include a counter example, and warned that just because Wizards don't pick a technical problem doesn't mean that technical violations aren't there. I hoped that the thread wouldn't lead to the following...
Here goes an interesting turn:
Yes, there was a big public announcement about how PCGen was OGL/D20 compliant, and how they were the first to do it.
I was curious on how they achieved this so quickly, and went to have a look at the release to see how they had achieved it.
They hadn't. They still very clearly violated. I assume that the work of satisfying wizards is still quietly happening. I also think that possibly Wizards are understaffed expert pen-and-paper publishers, who are rapidly developing expertise in this area...
I'm no expert on on the lst files, but I had a decent look at them, and tried to figure out how certain things were achieved in them. I don't know if the situation has changed much, but certainly a short while ago, what was in the lst files was *not* the full story.
There are certain things that you need to calculate expressions for, and the lst files simply do not (or did not) carry the ability to perform those calculations.
After lots of head scratching, I realized that its an open-source project with the source code available, so I went and had a look at that. Guess what I found? Key SRD mechanics expressions were actually compiled into the core program!
What the lst files seem to do is similar to what RPM does with its "Modifiers" mechanism for items, feats, abilities etc. You can pass batches of modifiers through a generic algorithm that simply adds things together, grouped by stacking type. For added legal safety, RPM implements the generic algorithm in script (rather than the executable), since the "Stacking" part could lead to argument that the generic algorithm is an SRD derivation.
Sure, modifiers/tags does a lot of the work, but it's still only solves *part *of your needs.
Perhaps one day the lst files will be capable of making PCGen genuinely compliant. If that happens, they'll have effectively expanded its capabilites to practically include a comprehensive enough scripting capability.
I don't think there are any other software examples of how you legally do anything significant without scripting. I've had brief looks at other solutions [Hey, this stuff is what I do...]
- DMs Familiar: As far as I know, it doesn't do any kind of mechanics for you. You need to precalculate everything for your character/creature, and it simply shows it back to you.
- DM Genie: [Warning: I took the briefest of looks, and could have it wrong here]. Very dicey for my taste. There's a Rules.txt file that seems to contain the parameters for common mechanics formulae. Ultimately, the expressions are all hard-coded away in the binary, except for the parameters, which are named on specific lines of a text file. I gather that the hope is that legal issues are avoided because the parameter names are held by proxy in an openly readable text file. For my money, Wizards can crack down on it if they feel so inclined. Ultimately, the actual expressions which do the work are still SRD derivations, and are hidden away in compiled code.
I *think* DMGenie does EL, or XP calculations, and I'm pretty sure that the code for it isn't even in the rules.txt file.
To my mind the big fallacy here is a belief that because the SRD mechanics are broken up into a readable and a non-readable part, the license is satisfied because the mechanics aren't wholly in compiled code. This isn't what the license is actually about. What the license is about is this: You accepted the SRD information as an open system, and the license says that you must keep it open. If you break it up, and hide part of it in compiled code, then it is no longer open, and you have violated the license.
[Remember: briefest of looks, and I could have the implementation of DM Genie wrong]
- Campaign Suite: Never looked anywhere near closely enough at it. Maybe I should.
DMGenie and PCGen both have something in common: They were given 30 day warnings by Wizards, and then came up with relatively quick fixes. I think they both still have issues. I think that they've thrown up something complex to Wizards to demonstate how they solve *part* of their license issues, but I also think that they fail with a complete solution under close examination.
The PCGen guys are pretty honest, and, I assume, working well with Wizards. I suspect they would publicly back up my suspicions of their solution.
I believe implementing scripting is the only *safe* route.
Jamis Buck and Robert Korzac of RealmsCrafters understood this quite well. Unfortunately, I believe that the effort of their approach in doing an RPG scripting solution from the ground up (was it called Medusa?), was too much effort, and the project never gained enough momentum as time passed. Arrival of new family for Jamis and other pressures for Rob were sadly, ultimately, too much.
Bottom line:
You *need* scripting. Don't assume that because PCGen claims its OGL/D20 compliant (ie. snuck it past Wizards in round 1), that they've proven scripting isn't needed.
Remember, I originally indicated that scripting was necessary for any sigfificant software. Sure, you can do little bits and pieces without it. You can present useful databases of RPG information to people. You do, however, *really* stuggle to do any decent 3rd edition mechanics. As you noted Scott, its especially obvious for at-the-table software, but I believe that any very decent creature/character generator also faces these issues.
Hope nobody is offended by any of this. If it ruffles your feathers, I hope you can take it in the intended spirit - something helpful to assist with avoiding pitfalls, and planning for the future (or even avoiding wasted effort up front). We RPG developers don't like to hear about the challenges the licenses create - but it is what it is. I think we'll see an update of the license that more clearly explains the issues for software, but don't expect the rules themselves to be relaxed.
WotC has been through tough layoffs, and I think Wizards are currently under-resourced. My experience in dealing with Wizards is that they are very committed to enforcing the rules, and if we're currently "getting away with it", that will change.
[... am I really going to press the "Submit Reply" button on this???. Oh shoot...]
Regards,
Last edited:
Leopold
NKL4LYFE
smetzger said:
We'll do what we can with what we got. Anyone can pick up a copy of PCGen, grab a d20 book and code away making their own files. Flexibility, expandability, and portability (shame Etools wasn't for MAC or *NIX) is all part and parcel making a good product. Etools is windows based as the majority of people use and run winderz, can't blame them, i stilll want to run it on my IPAQ though dangit!
If this sourcecode release is true then that will be a HUGE step for the community and I applaud fluid for doing it. This will expand the amount of stuff people build for it and probably increase the patch and build functionality linux style. Good move! I hope it's true!!
Similar Threads
