eTools Patch and Source Code

Vpenman said:
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.

Yes, true.

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.

Yes, there would be problems and the blame would be on the publisher/developer, and incorrectly. Most EULAs state that they essentially will not support any "hacks", i.e. 3rd party tinkering. So customer service would just politely ignore the service request.

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.

Sure, no one is saying its not. And thats a failing of eTools. However, having access to the underlying data store for advanced users is an added bonus. Anything created by these users as 3rd party material is used by the end-user without any support from the original publisher/developer.

This is exactly what happens in the game world of Quake, Unreal, half-Life, et al. and all their variations. People produce mods or maps or other 3rd party content [I happen have done so for UnrealTournament] but in no way are id, Valve, Epic, etc. responsible for any 3rd party material.

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).

Thats not a fault of Access. Thats a fault of the execution of the installation prodedures.

I believe an open database would have benefitted very few customers and had the potential to cause harm to a great number.

Thats fine, your belief.

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.

We? I assume that means you were part of the CoreRules development team?

Frankly, I think you are off-base with your assumptions. My philosophy is fairly technology agnostic. I use the best technology possible to fit the project and end-user needs and to meet design and development schedules. Frankly, since the % of users who are Access wizards is low [but I don't agree as low as some people think] in the community of D&D gaming end-users, I don't perceive that there is a problem using a proven technology such as Access as a data store rather than designing a custom solution [or using a properitary format when accepted non-proprietary formats are available].

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.

I have to disagree. To me Mac or *NIX support is meaningless, I don't run them so using software designed for cross-platform unless its been optimized for each platform [i.e. games like Quake3 and UT2003]. PCGen isn't. To me, I find that the use of their own proprietary, and poorly thought-out, storage format for the data is a drawback entirely. The things that are part and parcel of making a good product are the same things that make up "software engineering" and unless they are applied, you don't have a great 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!

Well, I do believe that Wizards did a marketing survey, not sure how extensive, etc. But I'll bet it showed that a great majority of the gamers that responded use Windows. Thats born out time and time again in various surveys. Windows is the dominate consumer OS. Period. And consider it was WotC's first product in this area, I'm all for choosing one platform and going with it to produce the product. After all, look how questionably [depending on your side of the fence] eTools is?


If this sourcecode release is true
Where did you hear that? All I heard was that the sourcecode had been delivered to WotC. Nothing further. Although not sure I'd be all that interested in their source than I am with PCGen's source. I'd be much more interested in what Luke is doing under the covers [Sorry Luke, I still don't like your UI :)].
 

log in or register to remove this ad

I didn't see the Licensing agreement on mysql.org or mysql.com but did see a mention that it falls under the GPL. If I understand correctly, that means what I mentioned above. That may be what they mean when they say you "License" it from them. They can revoke your license if you do not comply with the GPL rules (similar to OGL, but for software, for those who haven't read/don't understand the GPL).

They do offer "packages" with support tied to them that you can purchase. i'm sure that those have some licensing rules tied to them as well.


Arnix (tm)

[Edit here]

Found what you mentioned, I think:

"You need to purchase commercial non-GPL MySQL licenses:

If you distribute MySQL Software with your non open source software,
If you want warranty from MySQL AB for the MySQL software,
If you want to support MySQL development. "
- http://www.mysql.com/downloads/index.html


So it seems you only need to purchase a license if your source if not open, or you want a warrantee, or you want to support the development.
 
Last edited:

Luke 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.

It may be bordering on scripting; especially the way that I presented it. To be more precise you would have a table with a Key and a value and then the code would construct the logical statement by combining Keys and Values. It gets a little more complex than that when you consider some weirder rules and 'Ors', but that is the basic idea. I have currently done Feat prereqs that way and it is working out quite well so far.

PCGen uses "Keys" or "Tags" in their .lst file and this is how they are designating OGC (everything in the .lst is OGC while the actual program is PI). Until I hear differently from WOTC I am assuming that they use of "Keys" in the database that represent the rules is a viable way of complying with the d20 license. I agree that this is shaky ground, but if WOTC says its Ok then its Ok.
 

Hollywood said:


Where did you hear that? All I heard was that the sourcecode had been delivered to WotC. Nothing further. Although not sure I'd be all that interested in their source than I am with PCGen's source. I'd be much more interested in what Luke is doing under the covers [Sorry Luke, I still don't like your UI :)].

ooopss thought it was a full sourcecode disclosure to the masses. My mistake..
 

Luke said:
Boy, that looks just like scripting to me, and nothing like a purely data-driven solution. That is one big *expression*.
Well, I actually designed a DB upgrade for E-Tools that would have supported almost anything directly in the DB without using anything that would likely be called scripting. It was based on a lists-of-lists approach, but it's a little complicated to go into here.

But this "competition" is not really important (to me), as I don't think a scripts-vs-database argument is too important or useful. Like computer languages in general, I think each has its place and can do most any job with varying degrees of ease. It mostly depends on which you prefer for a particular task at hand.

<shrug>
 

Luke said:
Take a look into the E-Tools Access database, and see if that's how E-Tools works. It isn't.

Smart move actually. I recently ran across a very large-scale [or so they hope] enterprise app that I sat in on technical briefs as a tech advisor for. The developer had placed all business logic in the stored procedures. Well, even with an enterprise database like Oracle, the language available to you with stored procs is not very robust. Thankfully the business rules and logic for this system are fairly simple so that it won't completely flop.

Yes, there was a big public announcement about how PCGen was OGL/D20 compliant, and how they were the first to do it.

Frankly, I'm not sure why they necessarily want to be d20 complaint anyways.

Wizards are understaffed expert pen-and-paper publishers, who are rapidly developing expertise in this area...

I'd say that they aren't gaining expertise at all. Maybe there are beginning to understand some central concepts, but not any viable form of expertise.

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.

No, you are right... lst files are quite confusing and would have been better in a better format, such as XML format that contained even scriptlets for each piece of data if calculations needed to be performed.

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!

Well, I dunno... didn't take too much headscratching as after all anything hosted at SourceForge MUST be open-source. :)

And yes, key SRD mechanics are expressed in SOURCE CODE as per the OGL license. Since those same source files are available [although they should be made available as a 4th zip file] and are human readable they fall under the OGL license just fine. Just as if you had translated the SRD into native Navajo; how many folks outside the Navajo reservation really know how to read their language? :)

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.

That'd be a bogus arguement since its already been establish via prior art that algorithms are not copyrightable. Only the implementation/expression of the algorithm. A generic "stacking" algorithm is nothing more than an expanded addition algorithm... so I suppose if Wizard wants to try and take ownership they can fight the entire computer [and math] industry and academia. :)

But yeah, I could see WotC arguing that expression in source of an OGL specific mechanism must be in human-readable form as per the OGL license. If the source has been compiled into machine code, its no longer readable by humans.

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 completely disagree. PCGen, while I do not believe its well engineered in any form, is still completely human readable. Anyone can get the source and discern what is contained in the OGL'd SRD by reading the PCGen source and lst files. Therefore its compliant. It doesn't need to expose small snippets of scripting, all its "scripting" is already exposed. With RPM or TwinRose' software or other software that anyone can not get the source to, then scripting is the only alternative to expressing the SRD's mechanics, that are not generic software engineering algorithms, as the script can be exposed externally to anyone while still maintaing the intergrity of the software's base code such as UI, printing, reporting, etc.

Although unless WotC is going to employ some software engineers to perform code reviews on closed-source code, like Redblade, RPM, TwinRoses stuff, etc. they will never be truly certain, even if the software exposes scripted mechanics, that there isn't some SRD mechanics that are in the closed-source portion of the code base. They'll just have to take it on "faith" [by George Michael of course!]

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.

Yes, thats my interpretation of it with the exception that "human readable" means that you must have knowledge of the language they are written in, whether it be English, Armanian, Pascal, Cobol, or even as a musical score. And to me these mean the following:
a) Have the data store open and available. This probably means storing all base source material in flat files. A database or other data store may be populated from these files for better performance and ease of manipulation, but still the root of the source must be in human-readable format.
b) The source that translates the OGL'd SRD mechanics must be available in human readable format.
c) The translate source of course could appear as hard-code in an open-source project where all the source is open, as scripting code thats pre-compiled/interpreted by a closed or open-source compiled program at run-time, open-sourced source that can be pre-compiled and executed by the program, etc. Plenty of ways to do that.

I believe implementing scripting is the only *safe* route.

Yes, its probably the most forward way to do so if attempting to implement the open SRD mechanics in a closed-source solution. Matters not whether the script is pre-compiled, and uses the solutions native language, or intrepreted.

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.

I disagree with your statements concerning OGL compliance. However, I don't understand how they can be d20 compliant when the d20 license states that anyone using the d20 license can NOT duplicate/translate/provide character creation and leveling mechanics.

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.

Yes, I expect to see new revisions of the OGL and d20L. And I suspect that they will attempt to more clearly state WotC's software policy, however will be completely inept at doing so mainly due to Hasbro's lawyers.

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.

As they should, but I think that if they do so with too much fantasism they will drive people away from the OGL's SRD; not necessarily open source gaming, but at least away from WotC's brand of it.

There is a line thats hard to tread and easily overstepped on both sides of the fence.
 

Hollywood said:

...
Yes, there would be problems and the blame would be on the publisher/developer, and incorrectly. Most EULAs state that they essentially will not support any "hacks", i.e. 3rd party tinkering. So customer service would just politely ignore the service request.


In many instances the person having the problem won't know it is due to importing hacked database items. Not knowing, he won't be able to make that clear to the customer service representative who will spend a lot of time just trying to figure out what is going wrong.

Ignoring customer service concerns, even ignoring them politely, is just not providing good customer service. If the representative can figure out what is going wrong, he should at least attempt to politely explain the problem to the customer. Of course, some customers won't believe that explanation and assume there is a bug in the program nobody wants to fix.

In many instances, at least initially, the customer service representative will assume there is a bug in the program and pass it along to the developer to fix.

As a matter of policy, when we receive a report of a problem with our program, we assume it is our bug and our fault, unless we have reason to believe otherwise. Evermore spent a lot of time (which means money) running down problems that had nothing to do with bugs in the Core Rules programs.

Unhappy customers are unhappy customers, even if the reason they are unhappy is not your fault. Where it is foreseen a course of action will lead to unhappy customers, it is wise to pursue a different course.

Ignoring unhappy cusomters or simply stating "don't blame me" is not good customer relations.


Hollywood said:

We? I assume that means you were part of the CoreRules development team?

Yes.


Victor
 

Arnix said:
I didn't see the Licensing agreement on mysql.org or

<snip>

So it seems you only need to purchase a license if your source if not open, or you want a warrantee, or you want to support the development.

Here we go: :)

If your application is licensed under GPL or compatible OSI license approved by MySQL AB, you are free and welcome to ship any GPL software of MySQL AB with your application. By "application" we mean any type of software application, system, tool or utility. -- http://www.mysql.com/support/arrangements.html

But that seems to conflict with this:
As long as you never distribute (internally or externally) the MySQL Software in any way, you are free to use it for powering your application, irrespective of whether your application is under GPL or other OSI approved license or not. -- http://www.mysql.com/support/arrangements.html

So dunno, probably best just to ask them if one was going to proceed with an eTools replacement that is GPL'd and is going to distribute MySQL [instead of Access] with it. :)
 

Vpenman said:
In many instances the person having the problem won't know it is due to importing hacked database items. Not knowing, he won't be able to make that clear to the customer service representative who will spend a lot of time just trying to figure out what is going wrong.

Yes, but all the customer service rep has to ask is this: "Did you install any 3rd party additions to the program?" If the answer is yes, then the rep says "I am sorry, I can only help you with the standard program."

Go buy a copy of Q3 or UT/UT2003 and create a small mod that totally hoses things... an infinite loop is a good thing in UT/UT2003 as the engine will handle it and throw kick out via the assert() method. Then call up the customer support with Atari [the publisher for UT2003] and ask them with help on why UT2003 crashes. They will ask if you installed any 3rd party mods or maps and then decline you help. :)

Talk to Bioware or Papyrus about the editor programs people put together for their software. Their cusomter support will absolutely no deal with any issues if you have used any "hacking" program on their software, period.

Call Microsoft up too if you've installed some odd-ball plugin to an MS Office app. They won't support it. :)

Ignoring customer service concerns, even ignoring them politely, is just not providing good customer service.

Perhaps, but thats pretty industry standard.

Evermore spent a lot of time (which means money) running down problems that had nothing to do with bugs in the Core Rules programs.

Did your support reps, or anyone attached with Evermore actually ask the enduser if they had used 3rd party apps? Once you do so, you pretty much violate the santity of the application, unless it was through a support plug-in, application addition, upgrade, etc., and its not your support issue.

Where it is foreseen a course of action will lead to unhappy customers, it is wise to pursue a different course.

I disagree. It depends on why the customer is unhappy. If they are unhappy because they installed a bunch of plugins or additions or used some hacked up tool, then they have taken a risk on themselves by using a non-supported addition to modify the original program in some manner. That is completely out of your hands. Period.

However, if you provide tools, such as any FPS' mapping tools or scripting languages, Bioware's NWN Aurora tools, or even eTools use of an Access database, you are allowing people to modify your software to do possibly unintentioned things with it. If you care to do so, then the EULA [which all users must agree too and should always be available to them to be read before installation is finished] should state that any modifications of the original program are NOT supported under the support agreement for the software.

Ignoring unhappy cusomters or simply stating "don't blame me" is not good customer relations.

Nor is providing programs which, have grand marketing slicks, but their limitations far outweight their benefits.


Ah. If you don't mind my asking, what was your role on the project or at Evermore?
 

Hollywood -
First of all there is no requirement in the d20 license that OGC be in a human readable format. The requirement is to clearly mark OGC. In the FAQ human readable format is one way that they suggest that software could be clearly marked.

Secondly - point 2 of the OGL says that you cannot restrict any OGC with any other licenses and you can only release OGC under the OGL. PCGen distributes the code under GPL. Because of this PCGen is not supposed to put any OGL material into their GPL code.

*:> Scott
 

Remove ads

Top