# eTools Patch and Source Code



## Therigwin (Nov 2, 2002)

First, read this news from EN World - http://enworld.cyberstreet.com/news...e=article&sid=445&mode=thread&order=0&thold=0

So, does this mean that Fluid is done with eTools since they delivered their source code to Wizards?

How long do you think Wizards will sit on the Patch?


----------



## BluWolf (Nov 3, 2002)

My prediction??

They will release the patch relatively soon and then shelve the source code.

Consider this product at the end of its life cycle.

Game over.


----------



## Sam (Nov 3, 2002)

$30 gone pretty quick.  I can't say enough how disappointed I've been with eTools.  Between Hero Forge, RPM & Campaign Suite, they all do such a better job than eTools!  The only think I liked eTools for was monster advancement, but it sure wasn't worth 30 bucks.  

I agree that this is likely the end of the product.  If WotC & Fluid had some falling out, WotC is likely going to just let this one die a slow, painful death.

--Sam


----------



## theoremtank (Nov 3, 2002)

Why do I get the feeling that if a patch is released for eTools, it won't be comprehensive enough to fix all the known problems.  And after hearing that Fluid turned over the souce code, I don't think we will be seeing the necessary remaining patches.

And the loser is.....the eTools consumer!


----------



## Luke (Nov 3, 2002)

Sam said:
			
		

> *Between Hero Forge, RPM & Campaign Suite, they all do such a better job than eTools!  The only think I liked eTools for was monster advancement, but it sure wasn't worth 30 bucks.
> --Sam *




Thanks Sam. There's an interesting recent feature in RPM for monster advancement, and its beyond HD/Size advances.
An RPM race can specify which "new race" it becomes.
This means, for example, that when their HD are high enough, dragons automatically move up their age categories, as do the elementals etc. There's a lot more to this than just size issues, since abilities, features and all sorts of factors might start coming into play (especially as dragons advance).
Fortunately, I built in the capability to change a creatures race and templates around very easily, and fully recalculate them.


----------



## Dustin Clingman (Nov 3, 2002)

I all truth this could mean that they intend to open source the application. Shelving the source code won't do anything. Perhaps they might open certain portions.  Either way, turning the source code over is really common when a product is finished.  It's usually accompanied by a certain amount of technical support. When that support runs out, that' s it baby. 

Dustin


----------



## Veander (Nov 3, 2002)

Could it not just be that WotC wants a copy of the source for their records and this is all just nothing other than that?

Veander


----------



## Sam (Nov 3, 2002)

Veander said:
			
		

> *Could it not just be that WotC wants a copy of the source for their records and this is all just nothing other than that?
> *




Could be, but it doesn't sound like that.  "Turning over" the source code sounds like Fluid won't have anything to do with the project anymore.  Otherwise, you'd think they would say that they are delivering a copy of the code to WotC for archival purposes or some such.


----------



## kristov (Nov 5, 2002)

*Bah*

Its for the best. Fluid is a crappy bunch of programmers who siphoned away a ton of money and produced jack as a product.

I am a programmer - and I can spot it a mile away - happens all the time.

Im sure they went through so many design changes and re-dos of the product and finally gave up because Fluid couldnt deliver the goods on time as originally promised and kept asking for more money.

Gotta lay the blame where it lays - WOTC/Hasbro just did what they had to do from a business perspective because the group they hired to work on the project was a dud.

-Kristov


----------



## KnowTheToe (Nov 5, 2002)

Veander said:
			
		

> *Could it not just be that WotC wants a copy of the source for their records and this is all just nothing other than that?
> 
> Veander *




No, we want doom and gloom here buddy.  None of your positive thinking.  Why don't you take that crap to Nutkinland.


----------



## Fast Learner (Nov 5, 2002)

*Re: Bah*



			
				kristov said:
			
		

> *Its for the best. Fluid is a crappy bunch of programmers who siphoned away a ton of money and produced jack as a product.
> 
> I am a programmer - and I can spot it a mile away - happens all the time.*



Yup, programmers always think that. Spend a decade in application design and project management and you'd be surprised what you learn about failed software projects. 

Changing requirements and unclear requirements are the primary reason software projects fail, _by far_. Lousy programming has very little effect because programmers are so easily replaced when they're doing a poor job. Contrary to what most programmers think.


----------



## kristov (Nov 5, 2002)

*Ok*

Well I havent done design work for decades - only a few years and im quite good at it.

I know all about changing specs and dealing with the business and end users in a project.

I generally handle small and medium sized business projects and usually handle both the lead programming slot as well as the analyst - most analysts are idiots as well and dont know what they are promising or explaining.

You have to know the job and what the goals are in and out - my guess is the Fluid people also couldn't figure out what D20 Dungeons and Dragons was about and how to work the mechancics of it for it to have come out to be such a sloppy piece of (you fill in this blank).

Like all jobs - you have skilled people and you have idiots who have jobs.


-Kristov


----------



## Fast Learner (Nov 5, 2002)

Then perhaps we're in synch and you're just unfamiliar with the history of the product. (Just for reference I have 25 years in programming, the last 10 of which included a great deal of architecture, design, and project management, including many stints as lead programmer, so it sounds like our experience is similar but for the lengths of time.)

You do know that the initial requirements were focused on a 3d mapper, animated monsters with sound, and online roleplaying, right? And that licensing changes completely messed that up, that requirements sat up in the air for many months (nearly a year), that when new requirements finally came down they were of the "what can we salvage out of this with the budget nearly gone" variety? (With the addition of a new very tight time constraint.)

And you blame the resulting product on lousy programming?

Surely your experience indicates otherwise.


----------



## KnowTheToe (Nov 5, 2002)

Fast Learner said:
			
		

> *Then perhaps we're in synch and you're just unfamiliar with the history of the product. (Just for reference I have 25 years in programming, the last 10 of which included a great deal of architecture, design, and project management, including many stints as lead programmer, so it sounds like our experience is similar but for the lengths of time.)
> 
> You do know that the initial requirements were focused on a 3d mapper, animated monsters with sound, and online roleplaying, right? And that licensing changes completely messed that up, that requirements sat up in the air for many months (nearly a year), that when new requirements finally came down they were of the "what can we salvage out of this with the budget nearly gone" variety? (With the addition of a new very tight time constraint.)
> 
> ...




I would agree.  I to am a programmer, but i don't have your experience.  Once, when I was a kid I programmed simple math algorythyms and even made small pictures on my Apple.

Anyway, from following the software I believe it was a lack of a disdinct vision of the product.  The loss of the mapper, refocusing of product, not setting up measurable expectations.  This whole project was almost a secret.  They put little to nothing out on their websites.  That is unheard of nowadays.  You can read about a video game two years before it comes out.


----------



## Vpenman (Nov 5, 2002)

Fast Learner,

If you look at what actually happened, I believe you will find that Hasbro announced it was going to sell off its electronic gaming rights in Dec. of 2000 and then announced it had sold those rights in Jan. of 2001 (www.corporate-ir.net/ireye/ir_site.zhtml?ticker=HAS&script=461&layout=-6&item_id=148123).  

The press release makes it clear this included the rights to Wizards of the Coast intellectual property.  It is not credible to believe the people working on Master Tools were unaware of this sale. However, at least until June, 2001, updates continued to be released that reported work being done on the mapping utility, monster scans, etc. It was not until sometime in July that somebody said "Wait a minute".

Clearly WotC retained the rights to do a 3rd Edition D&D utility or else E-Tools would not have been released. I suspect, but do not know, that when this was allowed in the Infogrames deal, the lawyers involved reviewed the pertinent contract and specifications for Master Tools and gave their okay to them.  I admit this is speculation on my part, but I believe this is much more likely than Infogrames saying, "Yeah, go ahead, you can do a utility" without bothering to find out what would be in that utility.

I was at Gamma in March, 2001, when TSR told the distribubtors Master Tools would be released at GenCon. This was two months after the Infogrames sale. A press release was issued promising an August ship of Master tools, and, as I said, the project updates continued to sing that product's praises into June.

In August, I was at GenCon 2001 and saw a demonstration of the character generation utility. That character generator was no where near being ready to be shipped at that time. 

Personally, I believe something happened in the June - July, 2001, time frame that revealed that project was neither as far along as had been reported and was not the project Hasbro/Wotc thought was being developed.

I admit this is speculation on my part, but I believe it is unusually accurate speculation.

BTW: I have been developing software projects for over 20 years myself and, in addition to a wide variety of games on a number of platforms, these include the Dungeon Master's Assistant program (published by SSI), the original Core Rules CD program (published by TSR), and the Core Rules 2.0 and its Expansion programs (published by WotC).

Victor


----------



## kristov (Nov 5, 2002)

*Project Changes..*

I am aware of the many changes in scope and direction that Master Tools undertook before finally being released as the unsuable E-Tools.

However most people point the finger at Hasbro and WoTC - when the more than likely (and my belief) is that the work being done the entire time by Fluid was extremely sub-par and probably way off of the time table they expected and im sure agreed to.

This was probably caused by them making promises and setting time lines they were completely unable to keep - and had to ask for more and more money.

Hasbro/WoTC finally had to quit burning money on what was obviously a bad choice of developers and bail out of the bigger goals and finally just get them to give them something... anything... to put out.

FYI - I personally hate Hasbro - they are the reason WoTC is crumbling and has been sucking for so long - they will probably lead them back into a TSR like state of coma where thier products are all shelved for the purpose of protecting "intellectual license" for products they will never even touch again. 

I realize hate is a rather emotional word - but from a gamers point of view - thats how i feel. From a real world point of view - where money talks - they are doing what they feel they gotta do for the bottom dollar.

So im not trying to defend them - BUT - i definately think the problem was in the choice of developers they chose who didnt deliver a product they had agreed on originally within the time frame and within budget.

-Kristov


----------



## Fast Learner (Nov 6, 2002)

*Re: Project Changes..*



			
				kristov said:
			
		

> *This was probably caused by them making promises and setting time lines they were completely unable to keep - and had to ask for more and more money.
> 
> Hasbro/WoTC finally had to quit burning money on what was obviously a bad choice of developers and bail out of the bigger goals and finally just get them to give them something... anything... to put out.*



Hmm. Do you think this project wasn't contracted on a fixed bid? If WOTC actually had a project concept in mind then there's no reason the project wasn't fixed. What makes you think they asked for more money?

Vpenman: I agree that something funky happened in that time frame. I have no reason to believe, though, that Wizards wasn't telling Fluid to go ahead with development throughout the Infogrammes deal, since the updates certainly indicated that they were still doing the Arcanum/mapping/monster stuff throughout that period.

The focus clearly was on the pretty stuff throughout that time period. That's no surprise, especially since that's the kind of programming Fluid does. Was that potentially bad project design and management? Absolutely.

It had nothing to do with bad programming, though.


----------



## herald (Nov 6, 2002)

> FYI - I personally hate Hasbro - they are the reason WoTC is crumbling and has been sucking for so long - they will probably lead them back into a TSR like state of coma where thier products are all shelved for the purpose of protecting "intellectual license" for products they will never even touch again.




If Hasbro has been "making them suck" for so long, I hope they keep on making them suck. I personally have enjoyed almost every single product released under 3e. 

Just call me a sucker!


----------



## Vpenman (Nov 6, 2002)

*Re: Re: Project Changes..*



			
				Fast Learner said:
			
		

> *
> .... Was that potentially bad project design and management? Absolutely.
> 
> It had nothing to do with bad programming, though. *




I agree with your assessment.  Since I never got my hands on Master Tools, I have no basis for evaluating what was actually programmed.

Victor


----------



## Chaz (Nov 6, 2002)

*Re: Re: Re: Project Changes..*



			
				Vpenman said:
			
		

> *
> Since I never got my hands on Master Tools.....
> Victor *




And thats a shame IMO. Ive said it before, and I say it again here, I wish you guys had been able to make the 3rd Ed program for WotC. This has nothing to do with what I think of fluid... The Core Rules & Core Rules 2 (& CR2ex) were some of the best programs I ever bought. I realy liked them. Still do. Who knows I may go back to 2nd Ed someday soon........

Anyway just wanted to add my 2 cents worth.


----------



## ddavison (Nov 6, 2002)

I followed the initial Master Tools development religously until I realized that a watched pot never boils...  After checking back 3-4 months later, I didn't see a whole lot of tangible progress and I thought I remembered seeing something about staff turnover for the project.  I personally think the developer turnover had the largest effect on the end product.  After all, you had a fairly nice looking, intuitive product that shipped along with the PHB -- and then you ended up with a cumbersome, clunky application called eTools.

IMO, the dramatic shift in program design could mean one of two things:

1. The initial design, while aesthetically pleasing, didn't scale properly and needed to be scrapped.  If this is the case, then the initial programmer didn't do his job right.

2. The initial programmer either left or was replaced and a new lead programmer took over the project.  As is often the case, most developers think their vision is better and choose a complete re-write instead of working from the existing structure.  If this is the case, then the 2nd lead programmer was insufficient (or maybe they weren't properly motivated).

I am also a full-time developer who has worked under, with, and as a lead to other programmers.  Some people can design, implement, and manage while others can only do one of them.  For this complex of an application, you really need someone leading the team that can do all three.  (S)he doesn't necessarily have to do all three, but they should definitely be capable.


----------



## Fast Learner (Nov 6, 2002)

That particular change was brought about by user request. Tons of people complained about the UI in the thing that came with the PHB and cried "Make it a basic Windows UI!" Et voila. Personally I liked the previous interface quite a lot. Alas.


----------



## ColonelHardisson (Nov 6, 2002)

OK, you guys seem to know what you're talking about when it comes to programming. I know nothing about programming, so this isn't an ironic or sarcastic question - I genuinely want to know: Would it have been a prohibitive amount of work for E-Tools to have Templates (Vampire, etc.)? Also, is it at all possible that the patch will add Templates (I doubt it will, just a hunch, but I thought I'd ask)?


----------



## Luke (Nov 6, 2002)

ColonelHardisson said:
			
		

> *I genuinely want to know: Would it have been a prohibitive amount of work for E-Tools to have Templates (Vampire, etc.)? Also, is it at all possible that the patch will add Templates (I doubt it will, just a hunch, but I thought I'd ask)? *




Now there's one of the big questions.
I'll speak as somebody whose done it (in RolePlayingMaster).

For me, adding a template to a Race is pretty much a case of applying more than one race definition to a creature. It's not *that* hard - at least with the environment I built up as an RPG engine.

I suspect that one of the big issues is that Fluid went for a total data configuration solution, as opposed to a combination of database configuration with scripting.
I suspect that this is an issue because up until you start looking at prestige classes and templates, the rules seem to be reasonably coherent, and capable of being expressed as data (as opposed to script code).
Prestige classes are, by the way, the other big hole.

  Certainly there are some clear reasons why Fluid may have opted for a database configuration:
- Its easier for them. Throwing scripting in complicates things siginificantly more than building user interfaces around a database.
- Its easier for users. Joe Average user is more likely to avoid trouble adding database fields through a user interface, than if he tries his hand at a scripting language. That said, I'll wager that Joe Average Pen-and-paper user would be statistically more adept then Joe Average NeverWinterNights players (which also offers scripting).

  Certainly, without scripting, I don't think that E-Tools was ever going to live up to (perhaps unfair) expectations:
- E-Tools barely copes with straight, core D&D. If you think it'll handle generic D20 well, you'll be sticking to a very limited subset of whats available.
- The more loose the rules become (prestige classes and templates as an example), the more complex the database structures and relationships you need to evolve to cater for them. You reach a point of diminishing returns, where it becomes more complex than a simple script. I'll bet the qualifying criteria for the LoreMaster prestige class is hard-coded into E-Tools. So, if LoreMaster wasn't part of core D&D, and you tried to enter it as a D20 prestige class, you're stuck.

Will templates be in the patch?

Possibly. Fluid have the ability to hard-code in any of the hard bits, and they've also had time to extend their database configuration structure to cope with a specific set of templates (ie. the core ones).
If templates are in the patch, it'll be a test, to a degree, of how committed the product owner is to the future of E-Tools. A hard-coded solution is easier, but a dead-end to the product's future (since it only handles core D&D). Taking the high road of extending the database structures (which probably creates backwards compatibility work for current E-Tools owners) shows a commitment to opening up capabilities for D20.
To be fair about being dedicated to the product's future, there probably hasn't been enough opportunity to do the fully half correct solution.

What the product really needs is to embrace scripting, and I'll be mega-surprised if they've done that.

Third-party developers (like me) are lucky, in a way, that licensing restrictions virtually force you to implement scripting anyway, for any really decent product.
[Please, don't throw any counter examples at me publicly. Lack of scripting in anything decent implies very serious questions of being genuinely license-compliant. Just because Wizards don't spot it doesn't mean its genuinely, technically, compliant].


----------



## ColonelHardisson (Nov 6, 2002)

I was wondering about this, because I use Templates a lot. Without them, E-Tools isn't as useful to me as it could or should be. I don't want to complain about it too much, but after playing with E-Tools for a while after buying it, it's been sitting on a shelf. So, I just wondered if there was some deeper, technical reason why the utility of the product was limited the way it is.


----------



## Luke (Nov 6, 2002)

ColonelHardisson said:
			
		

> *So, I just wondered if there was some deeper, technical reason why the utility of the product was limited the way it is. *



To re-state what I said in a less convoluted way (hopefully):
Standard (non-templated) characters/creatures are relatively simple, since you "simply" contruct a creature froma single race definition.
When you add a template(s), you typically, effectively combine multiple "race" definitions into  a single entity from which to build a character/creature. Not only that, but there are often complex interactions between the different "race" definitions, such as when the Race HD is modified.
Without the pleasure and the pain of scripting, the complex interactions are hard to reconcile in a way that makes them work. Essentially, building a creature out of a single race definition is child's play, compared to correctly combining several race definitions in the correct way, and building a creature from that - especially within the confines of a rigid database structure.

ReTake on qualifying for LoreMaster :
If scripting is available, its not *that* hard to come up with some code that will examine the appropriate variables and see if your character qualifies for LoreMaster.
On the other hand, trying to come up with a general purpose database that can achieve the same thing without code, is likely to be *hugely* cumbersome.


----------



## smetzger (Nov 6, 2002)

Luke - I know that you are a big proponent of scripting + database.  This strategy seems to work good for RPM and it is the most flexible.

However, it is possible to do alot without using scripting.  Of all the 3e programs released yours is one of the few (and maybe only) that uses scripting.  

Fluid could have done everything in the database to cover the 3 core books; it may not have allowed for entry of all splatbooks and 3rd party material.  But, they could have done this without hardcoding.

First off I believe that e-tools has failed.  I believe it is for a variety of reasons:
1) Fluid is a game and graphics company.  They had no prior experience with database programming.
2) WOTC prioritized the wrong things, like sounds and  3d scans and mapping.  IMO the character generator should have been the priority with everything else being secondary.
3) The WOTC person in charge of the project changed frequently.
4) Hasbro, sold the video game rights out from under Fluid.

I think most of the blame falls on WOTC.  They are the ones who selected Fluid for the job and they are the ones who mismanaged the project.  WOTC doesn't have much excuse for this.  They have managed other projects like this (CD Core Rules I & II).  Although Core Rules I was pretty bad, Core Rules II was usable.

IMO the only thing that was done correctly was using a standard database instead of a custom one.

How can WOTC fix this?  I think the best thing for WOTC to do is to:
1) Deliver the long awaited patch
2) Release clearer software wording for d20 software.

Also, if WOTC wanted to be agressive in addressing this issue they could:
1) Release the source code for e-tools.
2) Keep an up to date list of OGL and d20 software links on their web site.

I don't think that WOTC needs to produce any more D&D software.  The 3rd party D&D software industry is really rich with decent software.  If they just encourage this industry a little bit everything will be fine.


----------



## Arnix (Nov 6, 2002)

As a gamer who is a programmer (not a programmer who picked up gaming), I think that the approach to e-tools was wrong.

They hired a group of non-gamers to write the code.  If you look at the successful 3rd party software out there, you will see that the majority of them are written by gamers who can code, not programmers who read some gaming books to figure out how the rules worked.  Only a true gamer can pick up on the subtle intricacies that are in 3rd Ed.  The group needs to be at the very least, lead by a true gamer, who can fully explain whats going on and make sure that its done right.  If thats not done, you end up with a piece of software written for fanatics, by people who don't know truly understand their target audience.

(Pardon spelling, I forgot how to spell when I got a compiler)


----------



## Luke (Nov 6, 2002)

smetzger said:
			
		

> *However, it is possible to do alot without using scripting.  Of all the 3e programs released yours is one of the few (and maybe only) that uses scripting.  *
> True. But without scripting you skate on very thin ice with license compliance - as the license is interpreted by Wizards (not a popular interpretation with developers - and especially difficult without scripting). I could say more, but that would likely head this thread down a path I don't want to go.
> 
> *Fluid could have done everything in the database to cover the 3 core books; it may not have allowed for entry of all splatbooks and 3rd party material.  But, they could have done this without hardcoding.*
> ...


----------



## ColonelHardisson (Nov 6, 2002)

Luke said:
			
		

> *
> To re-state what I said in a less convoluted way (hopefully):
> Standard (non-templated) characters/creatures are relatively simple, since you "simply" contruct a creature froma single race definition.
> When you add a template(s), you typically, effectively combine multiple "race" definitions into  a single entity from which to build a character/creature. Not only that, but there are often complex interactions between the different "race" definitions, such as when the Race HD is modified.
> ...




I appreciate the effort you're making to explain this to me, and I apologize for my lack of knowledge in the area to really understand. Let me ask this: I don't think E-Tools should have been released without Templates, since they're a fairly major part of the rules; am I unreasonable in thinking this?


----------



## Luke (Nov 6, 2002)

ColonelHardisson said:
			
		

> *I appreciate the effort you're making to explain this to me, and I apologize for my lack of knowledge in the area to really understand. Let me ask this: I don't think E-Tools should have been released without Templates, since they're a fairly major part of the rules; am I unreasonable in thinking this? *




No problem.

For what its worth, I agree that it shouldn't have been released without templates.
The templates and the prestige classes are huge gaps, that are hard to explain.
I recall well over a year ago, one of the very first (and last) public posts by a Fluid programmer was about how cool it was that they had weapon size adjustments coded in - as an example of how complete their rules adherence was, and I thought "pretty cool". I also recall that at about that time they admitted that they saw and copied somebody's fan spreadsheet, or something, where there were different columns for the same treasure table (minor, major,...). An alarm bell went off in my head then, since this should have been obvious from the core books themselves...
To risk being unfair, I did wonder if the team as a whole were as proficient with 3rd edition material as we were led to believe.

Really, you shouldn't need to depend on programmers being domain experts (3rd edition rules masters in this case). WotC should have defined what they wanted clearly enough in their requirements, so that QA prevented things like this happening.
On the other hand, it was a *lot* cheaper to throw the core books Fluid's way, and say "Here. See what you can do with this...".
I suspect that the initial vision (full intenet game with maps, graphics and sound) made it just too difficult (expensive) to properly define *requirements*. Well defined requirements are absolutely fundamental to successful software developement.

I further suspect that it was hoped that the overall sexiness of the maps/sound etc would create a very forgiving attitude to full rules adherence.
Once the sexy bits got chopped out...


----------



## Hollywood (Nov 6, 2002)

> True. But without scripting you skate on very thin ice with license compliance - as the license is interpreted by Wizards (not a popular interpretation with developers - and especially difficult without scripting). I could say more, but that would likely head this thread down a path I don't want to go.
> 
> True, Fluid can hard-code, rather than script, since they don't need to obey the same license requirements, but without providing the scripting service, they make it extremely difficult for people to put in D20 expansion stuff.




"Hard-coding" and "scripting" without context are bad terms.  "Scripting" is not any different than "hard-coding" EXCEPT that the "code" is available to the end-user, sometimes but not always, to be changed outside of closed system and is either interpreted at run-time or pre-compiled.  "Hard-coding" is "code" that the user can not change, modify and recompile.

With an open-source effort there becomes ZERO difference between "hard-coding" and "scripting" because everything is open.



> If you look at the successful 3rd party software out there, you will see that the majority of them are written by gamers who can code, not programmers who read some gaming books to figure out how the rules worked. Only a true gamer can pick up on the subtle intricacies that are in 3rd Ed.




Just because someone, gamer or not, can "code", does NOT mean they can engineer a quality piece of software.  It takes a lot more than knowing a little bit of Java, or reading a few tutorials, to build a quality software product.   

The, as you noted, the subject must be understood and "experts" on the subject matter should be available to the technical people.  Design goals must be laid out, both short term and long term, and absolutely NO scope-creep should be allowed until the first revision is finished... you may scale back features, but not add them.  Technical architects must take said design goals and put together a solid architecture that will meet said design goals, both short and long term.  Only then should the design and development of the software commence.  

3rd party developers can get around some of that, especially in the case where there is a lone or very small [2 or 3] set of core persons working on the software, as they are more able to come to understandings quickly than a bulkier organization such as WotC.  Even then, software can easily be turned into nothing more than spaghetti code.  Taking short-cuts for a consultant, such as Fluid, when dealing with a large client such as WotC will only lead to failure of the product.

Want to know if your favorite tool's developer is engineering the software rather than just "coding" it?  Ask the developer about the BSAs [not so important to 3rd party developers], design and architectural documents, interface mockups and user feasibility tests, UML and database diagrams, etc.  They don't have 'em?  Then they are doing nothing more than shootin' from the hip.  Period.



> 1) Fluid is a game and graphics company. They had no prior experience with database programming.




Technically any data storage system can be called a database.  As a software, game or otherwise, is meant to manipulate data, yes they did have prior experience.  As for relational database experience, unless you've seen their resumes, you really don't know for sure.   Database "programming" really is not all that hard at its base level.  It rises in complexity based on the complexity of the data needing to be stored.  3rd edition data is fairly complex, but its not exceedingly complex nor is there a very large volume of it.   Good engineers can come up with very good database designs even if their actual database experience isn't all that much.


----------



## Hollywood (Nov 6, 2002)

> _Originally posted by Luke _I suspect that the initial vision (full intenet game with maps, graphics and sound) made it just too difficult (expensive) to properly define *requirements*. Well defined requirements are absolutely fundamental to successful software developement.




Bioware managed it.   However, they went through an engineering process that covered several years and determined exactly what they could and couldn't do, i.e. only the basic portions of the Core Rules are available.


----------



## Fast Learner (Nov 6, 2002)

On database vs. scripting: I started design work on a character creation program about 18 months ago and saw the issues with templates and prestige classes you were talking about and concluded that a "pure" database app wasn't feasible without a ton of hard-coding. I came up with a reasonable hybrid system that was database-based where some fields contained, effectively, scripty-bits. While feasible (and I'm confident that it would have worked out nicely), it was clearly a _ton_ of work so I passed. In retrospect, especially with the issues surrounding compliance, I'm really glad I did. 



			
				Hollywood said:
			
		

> *With an open-source effort there becomes ZERO difference between "hard-coding" and "scripting" because everything is open.*



This is incorrect. In a pre-compiled scripting system you don't have to complile the freaking application you're about to use, something that's a _huge_ difference for _everyone_ except technical geeks like ourselves. Re-compiling because you want to add, say, some prestige class from some new book is an absurd requirement, imo. In addition if the open source code is written in, say, C or C++ then it would be _extremely_ easy for WOTC to argue that your code wasn't human readable, as opposed to a fairly simple scripting language. There's a BIG difference between "hard-coding" and "scripting" in an open-source effort.



> *Want to know if your favorite tool's developer is engineering the software rather than just "coding" it?  Ask the developer about the BSAs [not so important to 3rd party developers], design and architectural documents, interface mockups and user feasibility tests, UML and database diagrams, etc.  They don't have 'em?  Then they are doing nothing more than shootin' from the hip.  Period.*



I agree with all of that, with the possible exception of UML (there are other use-case type systems you can use quite effectively). But that's just a nitpick.


----------



## Hollywood (Nov 6, 2002)

> _Originally posted by Fast Learner _This is incorrect. In a pre-compiled scripting system you don't have to complile the freaking application you're about to use, something that's a _huge_ difference for _everyone_ except technical geeks like ourselves. Re-compiling because you want to add, say, some prestige class from some new book is an absurd requirement, imo. In addition if the open source code is written in, say, C or C++ then it would be _extremely_ easy for WOTC to argue that your code wasn't human readable, as opposed to a fairly simple scripting language. There's a BIG difference between "hard-coding" and "scripting" in an open-source effort.




Well, scripting systems don't necessarily need to be pre-compiled.  Usually they are faster that way, but may not be as flexible.  The client-side java/vbscript in browsers or ASP/PHP are  examples of interpreted scripting [for benefit of non-technical people ] whereas JSP [its similiar to ASP/PHP but with Java as the scripting language which is superior to Java/VBScript of course] is pre-compiled.

And yes, you are quite right... usually scripting means you only have to make changes and run or compile the new script.  But if a system is designed well, it may be very easy to add or change code to it.  At the distilled essense there isn't really a difference.  About the only difference is technical ability.

And WoTC can argue itself blue as long as it wants.  But name me a language, scripting or not, that is human readable by someone without any technical ability at all [i.e. lawyers?].  COBOL and PASCAL come to mind as the top contenders for having a syntax thats closest to English grammar.  C, C++, Java, JavaScript all share a very similiar syntax which isn't close to English.   PHP is in a world of its own as is VB/VBScript.  Etc, etc.  And if you start using custom scripting languages [why? there are plenty of good ones to choose from] or say something odd like rules based scripting, it still incomprehensible to those without technical ability.

Bottom-line is basically that the "rules" have to be in human readable form.  That could mean having the scripting source or that could mean the actual program souce available.  The latter is the way one open-source character generator could have passed compliance.

But the other falacy of all of this is that no-one can copyright rules, only the specific explanation of those rules.  So anyone can express the D&D 3rd rules in whatever format they choose, as long as they do not use any WotC content whatsoever.  Same thing applies to algorithms... they can't be copyrighted, only specific implementations of them.  

However, the catch IRT the SRD is that if you use any of the information in it, you are bound by the legal agreement that came with it that basically says you can't use explain, in any implementation, the character creation or leveling up process. 



> I agree with all of that, with the possible exception of UML (there are other use-case type systems you can use quite effectively). But that's just a nitpick.




Yeah, first one that came to mind.   Heck even flow charts are better than nothing!


----------



## Vpenman (Nov 6, 2002)

smetzger said:
			
		

> *
> ...
> I think most of the blame falls on WOTC.  They are the ones who selected Fluid for the job and they are the ones who mismanaged the project.  WOTC doesn't have much excuse for this.  They have managed other projects like this (CD Core Rules I & II).  Although Core Rules I was pretty bad, Core Rules II was usable.
> 
> ...




"Usable."  Talk about damming with faint praise.

Speaking very broadly -- that is not making any specific reference to or inference about E-Tools, Fluid, or WotC -- I believe smetzger is generally correct about where responsibility for published software lies.

When a publisher releases software, that publisher has generally: selected the programmers who developed it, evaluated that program's progress on an on-going basis and decided that project should continue to be funded and developed with those programmers, and finally decided that project is done and ready for publication.  These are the publisher's decisions.  They are not the software developers' decisions.

Getting a little more on topic regarding the subject of this thread -- it will be the publisher who decides when that patch is ready for release.  Both the patch and the product are the publisher's responsibility.  It can say "no" at any time.

I completely disagree with smetgzer's database view. Only people who have access to Access and understand how to use it (a distinct minority) can really take advantage of the E-Tools database. I believe the decision made in the Core Rules programs to create a custom database that everyone could use to create, import, and export custom data was far more useful to the vast majority of customers.

While I am at it, I also believe it was a mistake to us XML for printing. It was also a mistake to not include the necessary I.E.  and ODBC upgrades on the CD.

I'll stop there.

Victor


----------



## Hollywood (Nov 6, 2002)

> _Originally posted by Vpenman _Getting a little more on topic regarding the subject of this thread -- it will be the publisher who decides when that patch is ready for release.  Both the patch and the product are the publisher's responsibility.  It can say "no" at any time.




True.  They can also say "release whatever you have now, we don't want to wait, we don't care if its done, or how many bugs it has".



> I completely disagree with smetgzer's database view. Only people who have access to Access and understand how to use it (a distinct minority) can really take advantage of the E-Tools database. I believe the decision made in the Core Rules programs to create a custom database that everyone could use to create, import, and export custom data was far more useful to the vast majority of customers.




Not really.  Use of an Access database means that there are quite a few, more than you probably think, that can get into the guts of it.  What was lacking, perhaps, was easy front-end tools to allow end-users to easily insert new custom data into the program regardless of what was used on the back-end to store the data.  Most end-users simply don't care and shouldn't.  Besides, there are plenty of good books on the Access database and how to use it out there and it doesn't take too much time or effort to learn... and learning is always a good thing.

Good idea, bad execution.



> While I am at it, I also believe it was a mistake to us XML for printing.




Again, good idea, bad execution.  Dumping the character out to an XML data format allow end-users to construct any type of output they want via XSL using non-proprietary technology/solutions.  However, the reliance on a piece of technology from Microsoft, their XML/XSL object, that was tied to the whole issue of IE embedded in the OS should have raised red-flags.  Plenty of other XML transformation objects that could have been used instead.



> It was also a mistake to not include the necessary I.E.  and ODBC upgrades on the CD.




Poor execution again.  Poor QA too.


----------



## Vpenman (Nov 6, 2002)

Hollywood said:
			
		

> *
> 
> ...
> Not really.  Use of an Access database means that there are quite a few, more than you probably think, that can get into the guts of it.  What was lacking, perhaps, was easy front-end tools to allow end-users to easily insert new custom data into the program regardless of what was used on the back-end to store the data.  Most end-users simply don't care and shouldn't.  Besides, there are plenty of good books on the Access database and how to use it out there and it doesn't take too much time or effort to learn... and learning is always a good thing.
> ...




Boy, do I disagree some more.  I hope I am not being too argumentative here. I recognize some very goods points are being raised.  I just happen to disagree with some of them.

Speaking very broadly, from a product point of view, what should have been delivered was a product that generated a profit for the company. That profit should have been generated both through sales of the actual product and through an increase in the popularity of 3rd Edition D&D. This popularity would have been generated by allowing people who simply enjoy role-playing without the need to get into the guts of the system to quickly and easily generate, operate, and maintain characters.

Instead, what was delivered was a very expensive, late, product with limited use to people who are not very computer savvy.

I appreciate there will be some disagreement on that last point, but I invite you to read through the posts on this thread, note how many people identify themselves as programmers, and the very technical nature of much of this discussion.

I don't agree that learning is always a good thing.  If learning is required to use a commercial product, then that lack of learning is, or should be, a barrier to sales of that product. I can see a benefit from more people acquiring facility with foreign languages.  However, if acquiring a facility with a foreign language is necessary to use a product, than that product will not sell as well as if that facility was not required (unless the product is supposed to teach foreign language).

I believe that most people who play D&D would not agree that acquiring a facility with Access "doesn't take too much time or effort to learn". 

Instead of being a product that virtually any D&D player with a Windows system can use to make play easier and fun, we have instead a toy for the technophiles among us.  By technophiles I mean people who have much greater understanding of software applications than is generally the case and "toy" and "phile" pretty much go together. People, to be more specific, like many who post on this thread.

Based on a number of years in software development where I have communicated with literally tens-of-thousands of users, including thousands who used the Core Rules CD products, I will state unequivocally that the number of users who should attempt to directly modify an Access database is very small.  I put that number at well under 10 percent.

To be clear, I am not saying the percentage of E-Tool purchasers who can use Access is under 10 percent.  I am saying that for people who would have purchased a D&D utility designed for use by normal users that number would be less than 10 percent. I believe it would be less than one percent.

I mean, look at it.  It doesn't even have an autoinstall.  When was the last time you went into a retail store and purchased Windows software that didn't have an autoinstall?  Look at the downloads people are expected to do just to get a printout.  Do you have any idea how uncommon it is for most computer users to download software upgrades? Within the past couple of weeks, there was a study out that reported less than ten percent of U.S. homes have high speed internet access.

Do you know how long it takes to download upgrades over a modem? Do you know how few software users ever even visit a message board like this?

I'll say one thing for using Access instead of creating a custom database, it's a lot easier on the programmer. However, why anyone would use XML instead of the normal Windows print drivers is a mystery to me.  As far as I can tell, it has the disadvantage of Access (harder on the users) without the advantage of making the programming easier.

If you have software that requires knowledge of Access, downloading browser upgrades, or visiting message boards to get product support, then you have software that is not right for the majority of computer users.

D&D is not a game designed just for programmers and power users.  There was an opportunity with this software to not only make a direct profit, but to also expand the popularity of the gaming system.

Victor


----------



## Hollywood (Nov 6, 2002)

> _Originally posted by Vpenman _Instead, what was delivered was a very expensive, late, product with limited use to people who are not very computer savvy.




I don't disagree with you here.  I'm in the opinion that they did not deliver said product.



> ..but I invite you to read through the posts on this thread, note how many people identify themselves as programmers...




With the proliferation of computers and the access to webpage scripting, Java and its free compilers, and other such free or very cheap compilers for different languages, its fairly easy for anyone to become a "coder" or "programmer".  But there is a huge difference, not to diminish anyone, between knowing how to use an IF or FOR statement or create a CLASS in Java or even how to write a SQL statement to access data in any relational database and how to properly, through disciplined engineering, create a viable piece of software. 



> I don't agree that learning is always a good thing.  If learning is required to use a commercial product, then that lack of learning is, or should be, a barrier to sales of that product.




Um, I can think of a lot of products on the market that require learning to use very well.  Word, Access, Excel, Lotus Notes, HR programs such as PeopleSoft, etc.  

However, I believe what your point is, that unlike eTools [or some similiar 3rd party software] is that for the most part you can pick up the above mentioned software packages and at the very least write a letter or put enter some data in a spreadsheet without reading through a massive manual.  To become proficient with the tool [and thankfully I've never had any reason to become proficient with Word or Excel outside of whitepapers. ] you will need to learn more a bout the tool.



> I believe that most people who play D&D would not agree that acquiring a facility with Access "doesn't take too much time or effort to learn".




Learning how to use Access takes far less time than learning a foreign language, as Access like other similiar products, provides an interface that helps protect the "newbie" from the actual language.  Databases like say MySQL don't.

The point I was trying to make, was not necessarily is disagreement with yours.  You were stating that you wished eTools was more like CoreRules which allowed you, through a somewhat well designed [my interpretation. ] interface, to easily add new custom data to the program.  eTools does not really come close, unless you know how to utilize Access [or other databases].   What I am saying is that, no matter how poorly designed/developed eTools is, that utilizing a database that has a high usage in the computer industry as the back-end datastore does allow some enterprising folks, as it has, to create tools or ways to put custom data where eTools fails to allow you to do so.  The failure, for what I preceive you were saying, is with eTools interface/program, and not the back-end, i.e. Access. 



> Instead of being a product that virtually any D&D player with a Windows system can use to make play easier and fun, we have instead a toy for the technophiles among us.  By technophiles I mean people who have much greater understanding of software applications than is generally the case and "toy" and "phile" pretty much go together. People, to be more specific, like many who post on this thread.




Yes, again thats the failure of eTools, not of the choice [for good or ill mind you] of Access as a data repository.



> I mean, look at it.  It doesn't even have an autoinstall.  When was the last time you went into a retail store and purchased Windows software that didn't have an autoinstall?




Personally I detest "auto-install".  But eh, in reality thats simply a small .ini file on the cd they didn't put together.  Nonetheless, yes I agree.   I'm not defending eTools at all.  



> Do you have any idea how uncommon it is for most computer users to download software upgrades?




Yup, and thats why there are so many people with computers, since most PCs run Windows of some sort, are hacked because they don't keep up with the virus updates and Windows updates.  Nonetheless, most people who play computer games, even on a somewhat regular basis, are going to be likely to realize the need to check for updates.

But again, this is totally the failing of the eTools software and its implementation, not necessarily the technology [of which both Access and XML are] used to build it.



> Do you know how long it takes to download upgrades over a modem? Do you know how few software users ever even visit a message board like this?




Yup... I remember surfing the internet, Gopher, Talk, et al. way back on a 2400 baud modem running on my MicroChannel IBM 286.  Or in dorm room's with 8086s and green and amber screens. 



> I'll say one thing for using Access instead of creating a custom database, it's a lot easier on the programmer.




Of course.  Not writing your own file system or relational database but rather using proven components will allow you to concentrate on more important aspects of developing said software.  No reason to invent the wheel again.



> However, why anyone would use XML instead of the normal Windows print drivers is a mystery to me.  As far as I can tell, it has the disadvantage of Access (harder on the users) without the advantage of making the programming easier.




Well with XML, a "technophile user" can create new output formats.  He can always post those where other people can get to them.  There are other uses such as exporting and importing into other programs, etc.  As long as the solution allows the average user to use the software without problems and like with eTools save and print out a character, then utilizing a technology that allows other more advanced users to expand upon the basics is a good thing.  Have to say though eTools seems to have been a bust at this.



> If you have software that requires knowledge of Access, downloading browser upgrades, or visiting message boards to get product support, then you have software that is not right for the majority of computer users.




Depends on the software of course.  But in this day and age, you should keep your software up-to-date [even on a 56k modem].  It'll save you a lot of trouble going foward.



> D&D is not a game designed just for programmers and power users.




I don't disagree.   Actually, it wasn't really designed with software development in mind, no matter what WotC may claim.


----------



## Fast Learner (Nov 6, 2002)

I'll politely disagree with your thoughts on Access, vpenman. Using Access is far better than a custom database. Where eTools fell down is in providing easy tools to manipulate that Access database. If you have two tools, one that uses Access and one that uses a proprietary database, and neither tool has an interface for modifying the database, I'd much, _much_ rather have the Access one so that at least _someone_ outside of the original development team and some hardcore hackers can modify it. Because Fluid uses Access, the day eTools was released we had a publically-available tool for modifying the database, a very simple utility for doing so was released within another day or so, and within a week an uneducated (no knowledge of Access) user could add splatbook material to eTools.

Certainly eTools should have been _designed_ to allow easy modifcation by users, but lacking that, Access is much better than nothing.

On the subject of making users download browser upgrades: amen, that was a terrible, inexcusable QA mistake.


----------



## Vpenman (Nov 7, 2002)

You know, the people on this board are so nice and polite and offer such well-reasoned disagreements.

I really appreciate it.

thanks,

victor


----------



## Arnix (Nov 7, 2002)

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)


----------



## smetzger (Nov 7, 2002)

Luke said:
			
		

> *
> You mean no hard-coding, *and* no scripting. As a single example, I'd be interested in you taking a look at the mathematical expression on qualifying for the LoreMaster class, and tell me how you come up with a purely data-driven solution.*




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:
			
		

> *After that, cast your net wider, to generic D20. Look at the popularity of PCGen when it had all that other D20 material. People are *not* happy at currently being mostly restricted to the core material.
> *




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.


----------



## Hollywood (Nov 7, 2002)

Arnix said:
			
		

> However, there are more than enough companies out there that have a large proportion of their engineering staff that are gamers.




Maybe... 



> The next step should be the Red Hat approach, IMHO.




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.



> I expect that community would quickly convert the access portion to MySql if they had to pay for licenses...




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.


----------



## smetzger (Nov 7, 2002)

Vpenman said:
			
		

> *You know, the people on this board are so nice and polite and offer such well-reasoned disagreements.
> 
> I really appreciate it.
> *




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


----------



## Arnix (Nov 7, 2002)

Hollywood said:
			
		

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




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)


----------



## Vpenman (Nov 7, 2002)

smetzger said:
			
		

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




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


----------



## Luke (Nov 7, 2002)

smetzger 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:
> ...




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.



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




_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,


----------



## Leopold (Nov 7, 2002)

smetzger said:
			
		

> *
> 
> .  As it is now I think that PCGen, RPM, and TwinRose are going to fill this void. *





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!!


----------



## Hollywood (Nov 7, 2002)

> _Originally posted by Arnix _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...




Yeah, no particularly sure myself.  However, I was just going by their Licensing agreement on the MySql homepage.


----------



## Hollywood (Nov 7, 2002)

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


----------



## Arnix (Nov 7, 2002)

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.


----------



## smetzger (Nov 7, 2002)

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




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.


----------



## Leopold (Nov 7, 2002)

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


----------



## Davin (Nov 7, 2002)

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>


----------



## Hollywood (Nov 7, 2002)

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.


----------



## Vpenman (Nov 7, 2002)

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


----------



## Hollywood (Nov 7, 2002)

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.


----------



## Hollywood (Nov 7, 2002)

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.



> Yes.




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


----------



## smetzger (Nov 7, 2002)

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


----------



## Luke (Nov 7, 2002)

smetzger said:
			
		

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



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.




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



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.


----------



## Arnix (Nov 7, 2002)

Hollywood said:
			
		

> *
> 
> Here we go:
> 
> ...





I think you missed sections 3 and 5 (you quote parts of 1 and 2 above).  Section 4 deals with exceptions for NPO's and Free Commercial Licensing so is irrelevent for open source.

3) Commercial Use:  If app is not open source or under special permission
"If your application is NOT licensed under GPL or compatible OSI license approved by MySQL AB and you intend to distribute MySQL software (be that internally or externally), you must first obtain a commercial license to the MySQL software in question. "
- Section 3 paragraph 1


5)  Who can use:  If your app is GPL, use it for free.

"To all GPL/Open Source enthusiasts we do recommend our products under the GPL licence. We believe that MySQL AB is the world's largest company that offers all its software under the GPL licence. So help yourself to the MySQL server and the drivers and feel the freedom of free software! "
- Section 5, paragraph 2


Arnix (tm)


----------



## Hollywood (Nov 7, 2002)

smetzger said:
			
		

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




Well, I don't pay much attention to the d20 license, as I'd never distribute anything under it.  Its too restrictive, and 'sides, I have yet to see any reason to need the "d20 logo".  In the people I've run across in Chicago, outside of my regular gamers, that have some insterest in roleplaying... there isn't a concept of d20 at all, people don't seem to understand what it means.  However, they all know what D&D means.

But yes, I would say that it'd be hard to clearly mark compiled machine code.    Although you could put in variable values that would show up if you opened the executables with a hex editor but still. 

Anyways, I would say that while, and I stand corrected, human readable format is not a formally requirement of d20, its an implied requirement due to the constraints of labeling what is open source content.... unless of course you declare the entire program as open source content.



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




Ok, thats a good point that I missed.  However, I think that this is a problem with the OGL license, and not PCGen in particular.  The GPL license was devised to pretty much keep the current source, and any derivative source, open.  So I can see where it could conflict with the OGL in language, but I don't see that it conflicts in spirit.

Mmms... interesting anyways... and off to lunch, wonk.


----------



## Vpenman (Nov 7, 2002)

Hollywood said:
			
		

> *
> 
> 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." *




Based on my personal interaction with our customers, I am pretty sure many of them would not recognize importing a data item as using a 3rd party addition. Especially as an import utility is built into the program. 

Maybe the people who hacked the database in the first place would recognize that.  But after the hack and the general sharing of the data, it would end up in the hands of people who would have no way to recognize that it was different from the legitimate data they had been importing.

As part of the program design, it was intended that people would be sharing data. The DM sends the player a file containing the custom item that character just received in the campaign.  The player sends the DM the character file so the DM can be familiar with what that character can and cannot do.

With the Core Rules programs, data sharing is a supported feature.  It is not a "use at your own risk" type of thing.  Nor should it be. There are utilities in the program that support the importing and exporting of data.  They prevent the overwriting of valid, existing data.  They do not prevent the sharing of hacked data that might cause the program to malfunction.

Unless a utility provides the ability to share data among the program's users, in my opinion, it is a substandard utility.  If importing something causes the program to break, folding your arms and saying "not my fault" is not an acceptible answer.

Providing an easy out for the service rep is not the same as providing good customer service. How customer service will be handled is something that should be considered when the product is being designed.



			
				Hollywood said:
			
		

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




I was the project manager.  I am also the president of Evermore.

Victor


----------



## Arnix (Nov 7, 2002)

Hollywood said:
			
		

> *
> 
> Ok, thats a good point that I missed.  However, I think that this is a problem with the OGL license, and not PCGen in particular.  The GPL license was devised to pretty much keep the current source, and any derivative source, open.  So I can see where it could conflict with the OGL in language, but I don't see that it conflicts in spirit.
> 
> *




Actually, I think they got around this by seperating the GPL and OGL items.  The GPL is the code, which simply reads data, a glorified parser with a dislay window if you will, and interprets it.  The OGL section is the lst files, which are completely human readable and modifiable.  Either can be distributed independently of the other, if you want to write your own lst files or an app to use existing ones.

If you mix the 2, i.e. intertwine OGL data in the GPL source then you could have trouble (older versions of pcgen fall here I believe). 


Arnix (tm)

p.s. IANAL


----------



## Luke (Nov 7, 2002)

Hollywood said:
			
		

> *
> I'd be much more interested in what Luke is doing under the covers [Sorry Luke, I still don't like your UI ]. *




There's virtually nothing "under the covers", as far as 3rd edition mechanics is concerned. That's the whole point of keeping it open 

As for the user interface: Well, I've done what I can according to what people have told me.
The UI for a kitchen sink of integrated 3rd edition utilities is necessarily a tight balance of competing requirements. "Balance" necessarily means compromise. An obvious example is the spacious layout of lots of info vs the need of many to use a lower resolution laptap. Another example is the simplistic use of a "Wizards-style" guided approach to ease-of-use vs the need to quickly jump between different functions, as suits your gaming style.
If you tell me *why* you don't like it, I could possibly do something with that. If you propose a solution (especially where you've considered that balance of different needs), then we're really cooking.


----------



## Luke (Nov 7, 2002)

Leopold said:
			
		

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




They only said that the source was given to Wizards.

This has led to all sorts of conjecture, including assumptions that Fluid themselves no longer have a copy of the code, and Wizards won't use them anymore.

It could be as simple as: Wizards actually own the source code, and it was always a key deliverable of the "completed" project.


----------



## smetzger (Nov 7, 2002)

Luke said:
			
		

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




Your definition of a script is much broader than my definition.  If I were to use your definition than I would agree that scripting is necessary.


----------



## Bacrof (Nov 7, 2002)

Hollywood said:
			
		

> *
> 
> 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."
> *




It's not always this easy.

My pastor asked me once why the font he was using looked all screwed up on his monitor. The first question I asked was "have you installed anything on this machine since it last worked?" He said that he had not.

Half an hour later, he asked if it could be related to the new fonts he had copied onto the machine the day before...

I think this sort of behavior/level of knowledge is more typical of the average user than what you describe.


----------



## Bacrof (Nov 7, 2002)

Luke said:
			
		

> *It could be as simple as: Wizards actually own the source code, and it was always a key deliverable of the "completed" project. *




Nope. Fluid stated quite clearly a while ago that the object code belonged to Wizards, but the sourc code belonged to Fluid. This was mentioned at the same time that they promised to release the source to the online community if Fluid was no longer able to support the product.


----------



## Hollywood (Nov 7, 2002)

Arnix said:
			
		

> Actually, I think they got around this by seperating the GPL and OGL items.  The GPL is the code, which simply reads data, a glorified parser with a dislay window if you will, and interprets it.  The OGL section is the lst files, which are completely human readable and modifiable.  Either can be distributed independently of the other, if you want to write your own lst files or an app to use existing ones.
> 
> If you mix the 2, i.e. intertwine OGL data in the GPL source then you could have trouble (older versions of pcgen fall here I believe).




Yes, I believe thats the crux of the matter, although I do believe its still a problem with the OGL rather than PCGen itself.   However, there are ways around the problem PCGen or others like it may face.  Simply release the data and any code, properly bundled in scripting or plug-in form, that pertains to the SRD under the OGL.  The application that runs it could be closed or open source and under whatever license you want.



> It could be as simple as: Wizards actually own the source code, and it was always a key deliverable of the "completed" project.




This is a standard industry practice for consulting, such as was done by Fluid for WotC.  Surprised me that WotC even made mention of it at all publically.



> There's virtually nothing "under the covers", as far as 3rd edition mechanics is concerned. That's the whole point of keeping it open




I didn't mean the data or your expression, through script, of the SRD mechanics.  But rather what the scripting language used (sorry, have downloaded last version but haven't had time to look through it and can't remember if I had recognized the scripting language or not), the backend data store, etc.  While I'll argue for a broader interpretations of how to implement thing, I have to agree that having the SRD mechanics in script [or as plug-ins that can be changed and run] and such, it might be nice to reach some accord between those interested in building RPG software [for D&D/D20/whatever] on similiar ways of doing thing so that program can be interoperable.



> If you tell me *why* you don't like it, I could possibly do something with that. If you propose a solution (especially where you've considered that balance of different needs), then we're really cooking.




Never been a fan of one program trying to do it all.  Personally, what I'd look for is a highly usable character maintance program, but one that could plug into a large set of suites, or not, as I may desire.  So to me, having not to wade through all the other wizards or even having to deal with them is key.   Not to mention, because I run either high resolution laptops or CRT displays, I want as much information packed in as possible and the ability to highlight information I consider important to myself.   Also, trying to keep to the standards that most applications adhere too is important [and which RPM does better than a lot of apps].

I'm not in a rush to use anyone's simple because I have my own, and no it'll never be released as its an experiment to play with different technologies to see how they work together, that works for now.  And actually may rewrite my current one using completely different notions or technology, which is one reason I'd be curious to know more about what you are doing so as to make sure one can use the other's data, and what not.



> Unless a utility provides the ability to share data among the program's users, in my opinion, it is a substandard utility. If importing something causes the program to break, folding your arms and saying "not my fault" is not an acceptible answer.




I won't disagree with you here.  I fully agree, that a tool such as eTools or CoreRules needs to be able to share data among its userbase.   Word Processing would be useless if you couldn't share the Word docs with others. 

And I do agree, that if your software comes equipped with an import until, it should not allow data imported to cause the software to malfunction.

However, that is not the same as using a technology, such as Access but could be MySQL or just simply XML [or lst in the case of PCGen] as the datastore and saying to your users, "Hey, we have opted to store data in with this technology or through this manner that is able to be modified by you, the end-user.  However, we take no responsibility for any changes you make in such a manner." 

Its like anything else you buy, if you use it in a manner that is inconsistant with the instructions, then any breakage is your problem [pending all sorts of frivoulous lawsuits of course].



> Providing an easy out for the service rep is not the same as providing good customer service.




Is there such a thing as "good customer service"?  I've never seen or heard of it practiced on a scale that WotC would need. 



> How customer service will be handled is something that should be considered when the product is being designed.




Sure, thats a factor.  But there are lots of other factors too, that drive how a product is designed and what technology to take advantage of.  And you must weight those factors as you feel appropriate.



> I was the project manager. I am also the president of Evermore.




Ok, that jives with your comments and I can see where you are coming from more easily. I think you realize I come from the architectural/development side of things.  

P.S. Nice mix of technical skills... for a moment, when I saw Allaire JRun [which of course ya know is now Macromedia JRun and is a decent mid-tier J2EE server] I was expecting ColdFusion to be listed; thankfully its not....


----------



## Hollywood (Nov 7, 2002)

Bacrof said:
			
		

> My pastor asked me once why the font he was using looked all screwed up on his monitor. The first question I asked was "have you installed anything on this machine since it last worked?" He said that he had not.
> 
> Half an hour later, he asked if it could be related to the new fonts he had copied onto the machine the day before...
> 
> I think this sort of behavior/level of knowledge is more typical of the average user than what you describe.




Oh, I'm well aware of the that situation... I think anyone who is proficient with computers and has friends who are not that ask questions has heard responses like that. 

But that brings up the point, just by copying fonts over, something happened.  But who is at fault and who takes responsibility? The maker of the OS? the creator of the fonts?  the end-user?  Unfortunately, because customer support by its nature is very limited [you can't have your architectures, project managers, and developers working as customer support people... you'd lose a lot  of money], you have to draw the line somewhere.  At some point you just have to say, "if you did X, we can't support it any more."

Look at the electronic gaming scene; plenty of game software for the PCs that allows both developer made modifications and 3rd party hacks.  In just about all cases, currently that is as it was different a few years ago, customer service just won't deal with these types of issues.

But anyways, I think we have really digressed off topic... sorry 'bout that!


----------



## Bacrof (Nov 7, 2002)

Hollywood said:
			
		

> *
> 
> But that brings up the point, just by copying fonts over, something happened.  But who is at fault and who takes responsibility? The maker of the OS? the creator of the fonts?  the end-user?  Unfortunately, because customer support by its nature is very limited [you can't have your architectures, project managers, and developers working as customer support people... you'd lose a lot  of money], you have to draw the line somewhere.  At some point you just have to say, "if you did X, we can't support it any more."
> *




I think the point was that getting the user to say that they did X is very difficult. They may not be aware that they did X at all.

Until you know that the user did X, you have to assume that it is a problem with your software.


----------



## Hollywood (Nov 7, 2002)

Bacrof said:
			
		

> Until you know that the user did X, you have to assume that it is a problem with your software.




If you do that, you could be hunting for an insolvable bug for quite some time.  As contradictory as it may sound, and even to the point of seeming to ignore the end-user's actually complaint, its better to make sure of what external causes may be present before turning to issue within the software.

Customer support is a two-way street.  Good customer support, if there is any out there, wants to remain supportive of the customer, but must in turn be able to provide as much information to the code maintenance staff as possible to be able to find and squash said bug [if it exists].  The maintenace staff won't be happy at all if the customer support staff continually logs issues that are caused by external software, files, etc. that are completely outside of either their control or outside of the limited support box they are working under.


<shrugs> but anyways...


----------



## Arnix (Nov 7, 2002)

Wow, sounds like you have dealt with the company I work for's help desk.  At least until we created forms for them to fill out with a list of questions to ask.


----------



## Bacrof (Nov 7, 2002)

Hollywood said:
			
		

> *
> 
> If you do that, you could be hunting for an insolvable bug for quite some time.  As contradictory as it may sound, and even to the point of seeming to ignore the end-user's actually complaint, its better to make sure of what external causes may be present before turning to issue within the software.
> 
> ...




Assuming it is an issue with your software does not mean you immediately send it to the coders. Far from it. Part of investigating an issue is trying to reproduce it under controlled circumstances. Just taking the step of saying "okay, what steps are you following to cause the crash" is approaching the issue as if it were a problem with your product.

I think you're skipping over the role of the support guys in your argument.


----------



## Hollywood (Nov 7, 2002)

Bacrof said:
			
		

> I think you're skipping over the role of the support guys in your argument.




No, Bacrof I didn't.  Maintenance is another word for support.  Nonetheless, I refuse to argue this point anymore because its going outside of the topic of this forum quite drastically.


----------



## ddavison (Nov 8, 2002)

Arnix said:
			
		

> I expect that community would quickly convert the access portion




...or MSDE instead since it ports easily from Access (being a Microsoft product), is freely distributable by MSDN Universal Subscribers, and allows almost all the features of full-blown SQL.  Also, the front-end utility (SQL Enterprise manager) is free for end-users to install and use since Microsoft's licenses aren't tied directly to SQL Enterprise Manager, but to the SQL Server in the form of processor licenses or CALs.

Anyway, while I despise Access for most business use databases -- mostly because of poor multi-user capabilities, speed, etc. -- I think it was an acceptable choice for a single-user application.

Really though, advanced users could hit the data so long as they stick to an ADO compliant data source.


----------



## Fast Learner (Nov 8, 2002)

Umm... what license for Access? You don't have to purchase a license to distribute an .mdb file. The file is simply being utilized as an ADO datasource that isn't using any specially-licensed DLLs or anything. 

I don't see any reason to take it _out_ of Access if the code actually opened up (which I don't believe will ever happen).


----------



## Fast Learner (Nov 8, 2002)

Erm... ODBC. But you get the point.


----------



## Skullfyre (Nov 8, 2002)

Hollywood said:
			
		

> *
> 
> 
> Yup... I remember surfing the internet, Gopher, Talk, et al. way back on a 2400 baud modem running on my MicroChannel IBM 286.  Or in dorm room's with 8086s and green and amber screens.
> ...





gopher....
2400 baud........
8086's....
*fades to memories*

Franklin computers....
Bard's Tales..


----------



## Arnix (Nov 8, 2002)

No, there may be little reason, other than compliance to sql standards.  But MS complaince to standards is another issue.  I mention the change simply on the basis that most of the people I have met who do free development for software despise MS and would remove MS portions as their first order of business.


----------



## Fast Learner (Nov 8, 2002)

Understood, but since the code is entirely written using MS DLLs, it would make more sense to scrap the whole thing and start from scratch if using MS stuff isn't going to work.

PS: I stared with a 160 baud modem. When I got my 300 baud modem (they were new), I was thrilled. When I finally got a 2400 baud modem (years later, when they first came out), I was incredibly thrilled.

Today I use a 512k high-speed connection in my home. My how things have changed.


----------



## EricLeaf (Nov 10, 2002)

Vpenman said:
			
		

> The press release makes it clear this included the rights to Wizards of the Coast intellectual property.  It is not credible to believe the people working on Master Tools were unaware of this sale. However, at least until June, 2001, updates continued to be released that reported work being done on the mapping utility, monster scans, etc. It was not until sometime in July that somebody said "Wait a minute".
> 
> Victor [/B]




I believe the missing point was that for whatever reason this sale had been used by WotC as an excuse for cutting certain things and changing the goal of the project. But like much that the consumer hears, its all been filtered thru marketting, PR and spinsters. I was there at the beginning and there was never any question of doing anything related to an interactive game or online play (that which infogrames purchased the rights to), there was wishlist stuff for the future but for that sort of thing infogrames could be contacted and licenses settled.

The heart of the problems with this project and many others at wotc was that Pokemon money dried up, thats why Hasbro sold those rights to begin with, and this obviously trickled down to a ton of other areas. Money has to be cut and I'm sure it was cut in many things regardless wether they were deemed potentially successful. This is buisness, albeit kneejerk buisness, but buisness none the less. Master Tools as it was then was completely cancelled shortly after Gencon of last year. Ryan Dancy resurrected it from the grave in January of this year with a vastly reduced budget and a reduced goals (mapper cut, etc...).



In reply to your comment on disagreeing with using XML, since that was my choice and mostly my coding to get that to run, why do you think that wasn't a good choice? The XSLT transform offers tremendous power to the users to customize their output, as evidenced by the fact that the D&D character sheet and the statblock can both be made by the same XML output.


And finally


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




The other programmer on the etools project would bring those sort of topics up all the time. To me it seems to be a control issue only, that is a personal preference on controlling data or others with that data.
These projects are "tools" after all and like any other tool improper use could be damaging. Do all screwdrivers have a warning not to stab yourself in the eye, or perhaps an eye-guard to prevent that? If they did, you would annoy more responsible people with it than lives saved, and this goes for software too. Any "open" product can reap a lot of benefit by opening its data at any level. From users that want something the developers hadn't accounted for, and want it enough to do it themselves. You see this in a wide range for eTools, new stylesheets, creatures and even UI art for inside eTools.

The opposing view which you are supporting is only one of control, if the database is hidden then you and only you can update it, and potentially charge for it. I personally consider that weakness, I prefer code to stand on its merits not a hidden value that I am the only one who knows the formats.


----------



## Chaz (Nov 10, 2002)

EricLeaf said:
			
		

> *
> Stuff.....
> . *




I like ET. The  *ONLY*  problem ive had is the lack of communication from you guys. It seemed everything was great when you first opened the fluid boards. But then it all went to hell. What happend Eric? Thats the only thing I want to know. You guys gave me great hope for the support of ET. I didnt care about what was/wasnt in it. Didnt care about bugs. Becuase you guys at fluid talked the talk of support for the program. And it seemed you would back it up. But then the silence. Can you tell me what went wrong? Thats all I want to know. What went wrong?


----------



## Vpenman (Nov 11, 2002)

EricLeaf said:
			
		

> *
> The heart of the problems with this project and many others at wotc was that Pokemon money dried up, thats why Hasbro sold those rights to begin with, and this obviously trickled down to a ton of other areas. Money has to be cut and I'm sure it was cut in many things regardless wether they were deemed potentially successful. This is buisness, albeit kneejerk buisness, but buisness none the less. Master Tools as it was then was completely cancelled shortly after Gencon of last year. Ryan Dancy resurrected it from the grave in January of this year with a vastly reduced budget and a reduced goals (mapper cut, etc...).
> *




The Pokemon money drying up was obviously a problem for Hasbro/WotC.  However, the fact Hasbro Interactive was losing money was an additional point. Unfortunately for Hasbro, its software business was not profitable.  It appears Master Tools/E-Tools is not an exception to this.  If Hasbro/Wotc had cancelled that project at the time of the Infogrames sale, it would be money ahead now.

Perhaps enough money ahead so that some of the creative people at WotC who got the axe would not had their jobs eliminated. 

As I recall, MasterTools was originally slated for a Q4, 2000, ship (I still have the Jim Bishop post on that).  Had that been done, the Infogrames sale would be a moot point -- plus all the additional money not spent/sales generated since that time would have made WotC and D&D look much more profitable.  Which means that much less likely to fall under the axe.

Mind you I do not know why the product did not ship on schedule. But I do know that you cannot have a product that continually misses ship dates/goes over budget and not expect something bad to happen. 

I do find the statement that Ryan Dancy resurrected the product in January of this year to be interesting.  As I recall (apparently incorrectly), Ryan Dancy's association with WotC and this product ended in December of last year.  Please, any clarification on this will be most welcome. 


[/B][/QUOTE]
In reply to your comment on disagreeing with using XML, since that was my choice and mostly my coding to get that to run, why do you think that wasn't a good choice? The XSLT transform offers tremendous power to the users to customize their output, as evidenced by the fact that the D&D character sheet and the statblock can both be made by the same XML output. [/B][/QUOTE]

One obvious problem is that many people who purchased the product could not get a printout with the operating systems indicated on the packaging.  This has been confusing to many people.  All it takes is a look at the postings on this and other message boards to make that clear. 

Including the browser upgrade on the CD would have been a partial solution. As Microsoft would not have charged for that use of its software, I can see no good reason why this was not done.  The problem was well known to both Fluid and WotC.  Fluid because it noted it in the Help File and WotC because it appeared in the GenCon 2001 Sunday product demo I attended.  That demo was run by Ryan Dancy and Anthony Valterra.

However, requiring a user to do a download to get a product to work is not a good solution.  While people on this board may commonly do downloads, they are at best inconveniences to many. 

The other problem is that there is no way -- that I know of --  to get different systems to get XML printouts that look the same. If I am wrong in this, please let me know.

The choice to use XML as the print option, and to not support the standard Windows printers, illustrates one of the fundamental design flaws in the product.  That is, this product is aimed at power users -- people who have more computer expertise than is common among most people who own computers and play D&D.  These are the people who should have been its target market.

A product that was better designed to fit it potential customers (D&D players with Windows computer systems and average computer expertise) could reasonably be expected to sell more units than one that expected Access competence, high speed internet access, etc. 

[/B][/QUOTE]
And finally


The other programmer on the etools project would bring those sort of topics up all the time. To me it seems to be a control issue only, that is a personal preference on controlling data or others with that data.
These projects are "tools" after all and like any other tool improper use could be damaging. Do all screwdrivers have a warning not to stab yourself in the eye, or perhaps an eye-guard to prevent that? If they did, you would annoy more responsible people with it than lives saved, and this goes for software too. Any "open" product can reap a lot of benefit by opening its data at any level. From users that want something the developers hadn't accounted for, and want it enough to do it themselves. You see this in a wide range for eTools, new stylesheets, creatures and even UI art for inside eTools.

The opposing view which you are supporting is only one of control, if the database is hidden then you and only you can update it, and potentially charge for it. I personally consider that weakness, I prefer code to stand on its merits not a hidden value that I am the only one who knows the formats. [/B][/QUOTE]

This pretty much reinforces the point that the product is aimed at power users and not the typically computer owning D&D player.  Most of whom would be as likely to poke themselves in the eye with a screwdriver as they would be able to create and share custom data using an Access database.

It is not a control issue.  It is simply providing a product that most of your customers can use as is. 

Victor


----------



## Hollywood (Nov 11, 2002)

Victor,



> One obvious problem is that many people who purchased the product could not get a printout with the operating systems indicated on the packaging.




This is not a fault of the choice of technologies.



> expected Access competence




Again, this was not a fault of the choice of technologies.

I'm not disagreeing that the default eTools package should have worked out of the box without downloads, nor that there shouldn't have been a default option to use the standard print Windows features.

However, you keep blaming the technology choices rather than the implementation of the eTools software and/or the implementation of those technologies.   The technology is not at fault at all.


----------



## Vpenman (Nov 11, 2002)

Hollywood said:
			
		

> * ...
> This is not a fault of the choice of technologies.
> ...
> Again, this was not a fault of the choice of technologies.*




Sure it is.  If you choose a technology that many, if not most, of the perspective customers cannot use, or at least cannot use correctly, you have chosen the wrong technology.

[/B][/QUOTE]
However, you keep blaming the technology choices rather than the implementation of the eTools software and/or the implementation of those technologies.   The technology is not at fault at all. [/B][/QUOTE]

Certainly the software could have been implemented to lessen the problems created by these choices.

Including an install program that checked your system for a browser that supported XML and then, if it did not find one, offerig to install the upgrade should have been done.  Similarly, the system should have been checked for the correct ODBC and offered to install that, if needed.

Also, there should have been a front end and back end to the Access database that supported the creation, exporting, and importing of custom items.

However, even the above had been done, you  would still be faced with the fact that most people are not familiar with using XML (compared with their standard Windows print drivers) and that you cannot rely on XML to provide printout that look the same on different systems.

Regarding Access, you still face the problem of people creating data outside of the program that can be put into the program and cause it to malfunction.

The technology itself is not at fault.  But the decision to use a technology that is inappropriate for the target market (or what should have been the target market) is at fault.

Victor


----------



## Hollywood (Nov 11, 2002)

Vpenman said:
			
		

> Sure it is.  If you choose a technology that many, if not most, of the perspective customers cannot use, or at least cannot use correctly, you have chosen the wrong technology.




ONLY, and I repeat ONLY, if that technology has been implemented incorrectly.  If it has been implemented correctly, then the user should never know that technology is at work.  Period.



> Including an install program that checked your system for a browser that supported XML and then, if it did not find one, offerig to install the upgrade should have been done.  Similarly, the system should have been checked for the correct ODBC and offered to install that, if needed.




And these are once again *Implementation Details*.  Its not the fault of the Access product that the ODBC drivers were not present.  Thats the fault of the developers, QA and the publisher for not making sure that their software worked on all listed platforms without a hitch.



> Also, there should have been a front end and back end to the Access database that supported the creation, exporting, and importing of custom items.




Again, these are *Implementation Details*.  This isn't the fault of Access, its the fault of the developers.



> However, even the above had been done, you  would still be faced with the fact that most people are not familiar with using XML (compared with their standard Windows print drivers) and that you cannot rely on XML to provide printout that look the same on different systems.




Again, these are *Implementation Details*.  When printing out an HTML page via Internet Explorer, you use the standard Windows print API [not drivers].  All the XML/XSLT is doing in this case is creating an HTML text file that can be printed.  Its not terribly difficult technology, and since its a standard technology it WILL look the same on every system especially when using the exact same transform.   Now, the implementation of it may have been exceedingly bad that it causes the majority of end-users that have limited computer savy problems; and therefore their implementation of it is a problem of their software.  As I said, it probably would have behooved eTools to have supplied a standard character sheet printout that used directly the Windows print API and then also supplied the XML based output options for more advanced users.



> Regarding Access, you still face the problem of people creating data outside of the program that can be put into the program and cause it to malfunction.




So?  You seem to find this is a problem.  I don't.  Then again, I enjoy such games and software for games such as Army Builder, Quake, Unreal Tournament [I worked for awhile on Tactical Ops which was released retail along with my own Minions of Destruction mod], AoE/AoE2, Warcraft3, NWN, etc.  All software that allows the end-user to add new and exciting things to the software. 



> The technology itself is not at fault.  But the decision to use a technology that is inappropriate for the target market (or what should have been the target market) is at fault.




Thats of course your opinion.


----------



## Vpenman (Nov 11, 2002)

Hollywood said:
			
		

> *
> Thats of course your opinion. *




Yes and I have probably stated it enough by now.

I should have acknowledged your suggestion that providing XML in addition to the standard Windows print methods would have been a completely valid decision (with your implementation qualifiers).

Victor


----------



## Hollywood (Nov 11, 2002)

Vpenman said:
			
		

> I should have acknowledged your suggestion that providing XML in addition to the standard Windows print methods would have been a completely valid decision (with your implementation qualifiers).




No biggie... interesting discussion though that pointed out good things on both sides of the fence, i.e.

- Software must be built to work out of the box.  Yes, there will be bugs, but that happens even with the best engineering and QA practices.

- Software should be designed to used by the target audience without need of external tools and engineered in a standard manner in comparison to other software on the choosen platform.  In other words, a Windows app should work like other Windows app, a Mac app should work like a Mac app, etc.

- Choosing technology that allows power or advanced users to take complete advantage of the software and/or create additional 3rd party tools or data for the software for use by all is a good thing.  But only if the technology is engineered seemlessly so that the majority of the endusers can use it without any knowledge of the technology.

- Implementation is key.  If you are going to sell something to someone, make sure its implemented correctly.


----------



## EricLeaf (Nov 11, 2002)

Vpenman said:
			
		

> *
> If Hasbro/Wotc had cancelled that project at the time of the Infogrames sale, it would be money ahead now.
> 
> Perhaps enough money ahead so that some of the creative people at WotC who got the axe would not had their jobs eliminated.
> *



*

Well Fluid made two Pokemon products that all told sold a million units, sum total WotC had benefitted. Also note that Fluid wasn't getting any percentage for those. So WotC made all the profit.






			I do find the statement that Ryan Dancy resurrected the product in January of this year to be interesting.  As I recall (apparently incorrectly), Ryan Dancy's association with WotC and this product ended in December of last year.  Please, any clarification on this will be most welcome.
		
Click to expand...




I was just using general dates, I started working on the new MT in December. But I don't recall losing Ryan that soon, are you sure about that?







			One obvious problem is that many people who purchased the product could not get a printout with the operating systems indicated on the packaging.  This has been confusing to many people.  All it takes is a look at the postings on this and other message boards to make that clear.
		
Click to expand...



That was a deployment problem. Not enough testing machines, not enough system testing period. I wouldn't second guess the deployment because thats mostly WotC dropping the ball, it was initially going to be an internet download, so concerns about MS drivers would be moot as they would be right beside the product. But none of that came to pass, and hence there was very little time (read none) to deal with planning for a CD.







			This pretty much reinforces the point that the product is aimed at power users and not the typically computer owning D&D player.  Most of whom would be as likely to poke themselves in the eye with a screwdriver as they would be able to create and share custom data using an Access database.

It is not a control issue.  It is simply providing a product that most of your customers can use as is.
		
Click to expand...




It is a control issue. If *I* can't modify the data then I have to wait for the developer to update, if ever. Therefore the developer is in control of the updating. Simple. (Or spend a lot of time figuring out the formats myself which is a pain and also questionable under most EULAs)

The reason I say its one of personal preference is because certain people invent valid reasons to do that and others obviously don't. And in the extreme case there are people like me describing valid reasons why its not true.

The product wasn't aimming at powerusers at all it was aimmed at D&D users. So it had an open region for personal changes and updating while keeping a simple to use for normal use interface.



Note: BTW I am *not* speaking for Fluid, I no longer work for Fluid.*


----------



## Vpenman (Nov 11, 2002)

EricLeaf said:
			
		

> *
> Well Fluid made two Pokemon products that all told sold a million units, sum total WotC had benefitted. Also note that Fluid wasn't getting any percentage for those. So WotC made all the profit. *




I remember buying a special Pokeman product with a "free" instructional CD.  Was that one of the two products?  If so, what was the other one?

BTW: I thought that CD was very good.

[/B][/QUOTE]
I was just using general dates, I started working on the new MT in December. But I don't recall losing Ryan that soon, are you sure about that? [/B][/QUOTE]

No, I am not sure.  That is just the way I remember it. I was hoping someone with better information would speak up.

As I recall, Ryan took over around GenCon 2001 and left around December, 2001.

In your earlier post, you stated that the project was cancelled shortly after GenCon. 

"Master Tools as it was then was completely cancelled shortly after Gencon of last year. Ryan Dancy resurrected it from the grave in January of this year with a vastly reduced budget and a reduced goals (mapper cut, etc...)."

But, as I recall it, GenCon last year through last December  was the time frame when Ryan was posting that he was running the project and things were getting done. Again, if anyone has better information on this, please let us know. 


[/B][/QUOTE]
Note: BTW I am *not* speaking for Fluid, I no longer work for Fluid. [/B][/QUOTE]

Sorry to hear that.  I hope you have gone on to better things.  I had another question from your earlier post.  In it, you stated:

"The other programmer on the etools project would bring those sort of topics up all the time. "

From that, and my attempting to keep up with postings on E-Tools/Master Tools, I never saw that  more than two programmers were on the project (we used five on the Core Rules CD products). 

Were there ever more than the two of you, or was that it?

thanks,
Victor


----------



## Henry (Nov 11, 2002)

Vpenman said:
			
		

> *
> 
> Yes and I have probably stated it enough by now.
> 
> ...




Interesting point: Back on Eric Noah's boards, where the first dialog opened up between the Fluid Programmers, Jim Bishop, and us fans, I don't recall a single voice crying out for XML as the standard for database code. My voice, on the other hand, was crying out very loudly for MS Access, or another fairly open database standard, so that the data would not be hidden away in a closed format such as the one included with the Chargen program. I am a regular user of Access, and am familiar enough with the program to use it for edits. Fluid in fact, in those talks,  was planning to make little to no issue of third party enthusiasts making front ends for the fans to use.

MS Access was a huge step up even from that situation, and XML back in early 2000 was not what you would call a household word. Now, many more seem to tout its advantages as an open database standard, but all I have ever heard of XML is that with larger datasets (50,000+ records) it can become very slow and cumbersome.

Lastly, I am aware of the timeline of Ryan's role in the project, and even though his relationship ended in late 2001, he was still under consulting contract with WotC until near the end of Q1 2002. I still recall the announcement on ENWorld of WotC's termination of his consulting contract, one of the sadder events of this year, shortly behind the last massive layoff. Until that time, he still had a large amount of influence in the company, through his advisory capacity and many former associates still working there, I would surmise.


----------



## Bacrof (Nov 11, 2002)

Vpenman said:
			
		

> *
> No, I am not sure.  That is just the way I remember it. I was hoping someone with better information would speak up.
> 
> As I recall, Ryan took over around GenCon 2001 and left around December, 2001.
> ...




The announcement that Ryan's contract had been terminated was posted here at ENWorld on March 15, 2002.

Requests for Master Tools/E-Tools beta testers went out on December 11 or 12, 2001.


----------



## Ranger One (Nov 11, 2002)

I can see both sides of the Access debate.  Access provides greater opportunity for 3rd party tools and content creation, while a custom database provides more control and reliability.  Perhaps a viable solution would have been to implement something akin to what Relic Entertainment has recently implemented for its modding community.
In short, those who are interested in developing "mods" for their products register and are granted the first of three levels of support from Relic.  This is over-simplifying

Level 1 provides basic information and tips.
Level 2 provides tools and limited support from Relic.
Level 3 provides complete support with the intent of providing "official" mods supported by Relic.

Obviously the higher levels are granted after proving you are not a complete idiot and that what you are trying to accomplish is desirable.
If a custom database was used for Etools, with basic modifications able to be made by all but more in depth (difficult) modifications would also be possible (subject to supervision and approval by Fluid and WotC).... hmmmm....
This is perhaps a bad example, but if I haven't totally confused the issue a solution similar to that outlined above could provide a great deal of opportunity for adding additional capabilities to the program while still ensuring quality control.
In other words, little Johnny Gamer could be trusted to input spells through interface already present, but Johnny would have to register and show he knew what he was doing before attempting to create and distrubute a modified database with various Prestige Classes implemented (or better yet, his brilliant revisions that would allow everybody to safely enter them).  And if Johnny did register and was on the right track with his work, he would get the support and tools he needed released to him to do it correctly.
Hmmmm, I may have failed my eloquence roll.


----------



## Hollywood (Nov 11, 2002)

Interesting idea Ranger One, but that becomes a major support hassle for WotC and/or the developer behind the software.  Really, this issue has been around since about the time of Quake [actually before, but it got popular with Quake] and frankly in most communities, the community does a good job of policing itself without need for formalized, and expensive, developer/publisher interferance.



> MS Access was a huge step up even from that situation, and XML back in early 2000 was not what you would call a household word. Now, many more seem to tout its advantages as an open database standard, but all I have ever heard of XML is that with larger datasets (50,000+ records) it can become very slow and cumbersome.




I never followed the MasterTools/eTools evolution all that much, but I don't recall that XML was ever proposed to be used as a database.  And it probably shouldn't really as markup languages, of which XML and HTML are two of, aren't really built to be such [that being said, there are XML databases out there, but having no experience with them I couldn't say much about them from a technical side].  On the other hand, use of XML as a portable and non-proprietary method of storing characters for export or use in creating print or web output is a good use of that technology [and far better than putting your own propertary lookups in a text file and parsing it for that information].


----------



## FDWojo (Nov 11, 2002)

Actually, I got the impression that VPenman isn't against Access itself as the basis of the database, but rather that to get good use out of the product you need to become proficient in Access in order to manipulate the database beyond any plain vanilla needs.

I do consider myself extremely knowledgable about computers and using programs as well as much trouble-shooting (I'm the computer geek for my friends), but I must admit that I have no knowledge of editing/interpreting an Access database.  

Fortunately, I do have a copy of Access myself, but for me, the following are the problems are a bit advanced for me at this time:

1) knowing how to change something
2) knowing what (valid) changes you can make
3) knowing how a change will impact other parts of the database

I guest I'd liken it to saying, "Here's a great car you can buy, but you'll need to learn how to overhaul and rebuild the engine if you want to use it anywhere other than your drive way or side streets". (Perhaps a bad analogy, but close enough, I think, for these purposes.)

I, too, had all the Core Rules products (great job, VPenman!) and although I don't want to compare them directly, I had hoped eTools would be something I could customize like I did with Core Rules.  I didn't anticipate that programming in Access would be necessary in order to use eTools.

Still, I eagerly await the patch (today perhaps?) and I hope that by using it, along with the updated ET Helper, I'll have more (and easier) control over my characters and creatures.

Thanks for letting me contribute my 2 cents...

Frank


----------



## Vpenman (Nov 12, 2002)

FDWojo said:
			
		

> *Actually, I got the impression that VPenman isn't against Access itself as the basis of the database, but rather that to get good use out of the product you need to become proficient in Access in order to manipulate the database beyond any plain vanilla needs.
> 
> I, too, had all the Core Rules products (great job, VPenman!) and although I don't want to compare them directly, I had hoped eTools would be something I could customize like I did with Core Rules.  I didn't anticipate that programming in Access would be necessary in order to use eTools.
> *




Well, I started out pretty much opposed to both XML and Access, but Hollywood's well-reasoned arguments have almost won be completely over.

Basically, I have to agree with Hollywood's assessment that the problem is not primarily with the technology chosen but rather with how it was implemented.

XML is fine as long as it is in addition to the regular Windows print options and the browser upgrades needed to use it are included on the product CD with an almost, automatic install (don't mean to be putting words in anyone's mouth here).

The main problem with Access, as used in E-Tools, is that you can't really create and share custom data unless you have and know how to use Access.  A secondary problem is that many people need to download the correct ODBC in order to be able to use the database at all.

If a front and back end were in place to allow normal users to create and share custom data and the ODBC had been provided on the E-Tools CD, you are pretty much down to the following trade off -- the benefits of allowing people to directly use Access to create custom data without restriction vs the problems such creation could create either accidentally or on purpose.

As the person at Evermore who answers all of the e-mails we receive on the Core Rules products, I am probably more in touch with people who aren't necessarily top notch computer users than is generally the case.

However, other than that last point, I believe I am now in Hollywood's camp.

Finally, FDWojo, thank you for the kind words on the Core Rules products.

Victor


----------



## Hollywood (Nov 13, 2002)

Vpenman said:
			
		

> Well, I started out pretty much opposed to both XML and Access, but Hollywood's well-reasoned arguments have almost won be completely over.




Woohoo! 



> Basically, I have to agree with Hollywood's assessment that the problem is not primarily with the technology chosen but rather with how it was implemented.




And in neither case should it be taken that the developers nor the people at WotC are idiots or are deserving of non-constructive critism either!



> The main problem with Access, as used in E-Tools, is that you can't really create and share custom data unless you have and know how to use Access.




I'll agree with that.  Not being able to create custom data was a problem with the design/implementation of eTools; and is surprising to me that it was skimped on after reviewing what CoreRules v2.0 could do.

As to the second, eTools could have used XML as a format to export custom data [and only custom data mind you... ] to a non-proprietary format that could be shared with not only other eTool users through an import utility, but also could be supported by other software such as RPM.   This means you could create a cool new sword and place it on the net and any other D&D user could get it and plug it into other pieces of software.  Anyways...



> If a front and back end were in place to allow normal users to create and share custom data and the ODBC had been provided on the E-Tools CD, you are pretty much down to the following trade off -- the benefits of allowing people to directly use Access to create custom data without restriction vs the problems such creation could create either accidentally or on purpose.




Sounds like, from Eric's post, the CD was almost an after thought.  Having had the distinct [and mind-numbing pleasure] of writing a InstallShield for an enterprise application that went to market [don't ask, cuz I won't tell! ] that had to interegate and discover what ODBC drivers, etc. existed and install them, it is completely possible to do.   That is, if the time and resources are properly assigned to that part of the project.



> However, other than that last point, I believe I am now in Hollywood's camp.




Welcome Victor and make yourself at home.   I think there is some carbon covered meat on the spit!


----------



## EricLeaf (Nov 13, 2002)

Vpenman said:
			
		

> *
> I remember buying a special Pokeman product with a "free" instructional CD.  Was that one of the two products?  If so, what was the other one?
> *





More than likely that is it. There were 2 versions of that, and it was translated into a number of other languages, it being pokemon and all. You can see all this info at Fluid's website, I just mentioned it because it was what Fluid did prior to MT, and seeing that and the CharGen demo should illustrate what Fluid does and then compare that to what the fans screamed for and you get eTools. Satisfying no one.
Instead of becoming more graphical than Core Rules, it ended up being less graphical. With only some minor skinning ability and tool icons.




> *
> No, I am not sure.  That is just the way I remember it. I was hoping someone with better information would speak up.
> 
> As I recall, Ryan took over around GenCon 2001 and left around December, 2001.
> ...





I'm not the best with dates, so I'll do this all with relative dates. PHB was released at GenCon (2000?) a few month before that CharGen demo was done. MT work began at or shortly after that GenCon, I began work on the mapper September 2000.
Shortly before GenCon 2001 the mapper is dropped, and then a few months later the entire project is dropped. At about the time Eric Noah was test driving his sneak peak version, it was completely changed by the removal of the mapper. Mid September I was no longer working for Fluid, a few months later the other programmer (co-owner) is no longer working for Fluid (although still an owner). Then December Ryan Dancy gets a reduced project plan okayed and I start a (at that time) 2-3 month contract to clean it up and release it as is. This later evolved into a 6 month clean up, beta test and minor feature addition (namely the table editor and all the generators).

From the cut mapper to when the project came back, I expect it was Ryan working hard to bring something from it. The opposing force was Valterra whom I sure you know.
From what I know he wasn't in the software department at that time, having been drummed out in embarrassment (some legal problems with the Dragon Archive I hear) by Bill Dugan. But after Dugan and Bishop left, there was no software department (almost) so Valterra got back into it. But that is just a guess.


----------



## Vpenman (Nov 13, 2002)

EricLeaf said:
			
		

> *
> I'm not the best with dates, so I'll do this all with relative dates. PHB was released at GenCon (2000?) a few month before that CharGen demo was done. MT work began at or shortly after that GenCon, I began work on the mapper September 2000.
> Shortly before GenCon 2001 the mapper is dropped, and then a few months later the entire project is dropped. At about the time Eric Noah was test driving his sneak peak version, it was completely changed by the removal of the mapper. Mid September I was no longer working for Fluid, a few months later the other programmer (co-owner) is no longer working for Fluid (although still an owner). Then December Ryan Dancy gets a reduced project plan okayed and I start a (at that time) 2-3 month contract to clean it up and release it as is. This later evolved into a 6 month clean up, beta test and minor feature addition (namely the table editor and all the generators).
> 
> *




Eric, thank you for the information.  What happened with that project has been pretty mysterious to those of us on the outside.

One thing I notice that puzzles me is that both the WotC FAQ and the E-Tools help file state the difference between E-Tools and Master Tools is that E-Tools does not have a mapper.

I thought the differences were more substantial.  For example, the Master Tools information WotC had posted on its web site as recently as this time last year stated it would allow people to create custom classes.

E-Tools does not allow people to create custom classes.

How did removing the mapper affect the ability to create custom classes? Or even, how did removing the mapper affect the program in ways people would not expect?

thanks,

Victor


----------



## EricLeaf (Nov 19, 2002)

The removal of the mapper only forced a cut to a lot of the other media, like the models and sounds that were used in the mapping aspects. And many integration things as well as some of the misc generators like doors and traps. As for features cuts unrelated to mapping, those just went the way side under the new and reduced project I mentioned.
I think that class editing specifically was designed for Access editing only, in other words its in there as it was designed, but it was not designed to ever have an in-app UI.


----------



## Vpenman (Nov 19, 2002)

According to official WotC statements regarding the differences between Master Tools and E-Tools, E-Tools is Master Tools, but without the mapper.

According to the official WotC E-Tools FAQ:

"Dungeons & Dragons E-Tools
"Frequently Asked Questions...

"Q: What is the difference between D&D E-Tools and the software originally announced as Master Tools?

"A: Master Tools originally included a mapper, which was developed using the Arcanum Engine technology, authored by Troika Games. E-Tools does not include this mapper...."

www.wizards.com/dnd/article.asp?x=dnd/dx20020607a

According to Help file that is part of E-Tools (an official WotC product):

"What happened to Master Tools?

"E-Tools is the renaming of the originally scheduled Master Tools.  The difference between Master Tools and E-tools is that E-Tools does not include a mapper function..."

This is in the Questions/General section of eTools Help.

I  posted the relevant portions of those messages, but I do not believe the meaning is altered in any way by being removed from the entire messages. Please review them yourselves in their entirety.



			
				EricLeaf said:
			
		

> *The removal of the mapper only forced a cut to a lot of the other media, like the models and sounds that were used in the mapping aspects. And many integration things as well as some of the misc generators like doors and traps. As for features cuts unrelated to mapping, those just went the way side under the new and reduced project I mentioned.
> I think that class editing specifically was designed for Access editing only, in other words its in there as it was designed, but it was not designed to ever have an in-app UI. *




Prior to its disappearance, the Master Tools web page (on the official WotC web site) included the following regarding Master Tools:

"...Change the rules to fit your campaign: make your own races, classes, monsters and treasure..."

(Note: see above claims regarding taking things out of context.) 

Even if Eric's other comments regarding features being cut due project reduction are disregarded, it is clear that E-Tools does not contain everything Master Tools was supposed to contain, except for the mapper -- the make your own classes ability for exaple is not in E-tools.

Does anyone have any idea why WotC is making the claim the E-Tools is Master Tools only minus the mapper?  

thanks,

Victor


----------



## Grimsword (Nov 19, 2002)

Eric,  Iwas woundering why it was secided to make the Race and monster files/tables not visible/editable threw MS Access.  I really don't like the interface that is currently used to edit the Monster/Race files in e-tools.  Now with the Beta patch out part of the Raace Editor is broken the Button that adds Speicial Attacks and speicial qualitiesBut over all I like E-tools very much
and I want you to know that You and the other programers did
a good job on a very hard project.

Mike


----------



## Cougar (Nov 19, 2002)

Victor, I am not sure, but I can suppose that it is perhaps to keep the confusion (for most people) down and make sure that visitors to the site know that eTools IS Master Tools in a fashion. As to the false claims about Master Tools being able to edit classes, perhaps that was something originally included in press releases (or whatever they use internally to describe the product) LONG ago and was never changed. WotC does not have a good history of keeping up with MT or eTools.


----------



## Dustin Clingman (Nov 26, 2002)

I have been following this thread for a while but not posted since the beginning.

There are some obvious errors in ET, but it is basicly functional. The one point I wanted to make was concerning what level of technology a developer wants to expose to the end user. I have been a programmer in the video game industry for some time.  Mods and level editors have certainly extended the lifespan of many games, but it take a certain technical inclination to handle them. That being said, people shouldn't have to change thier levels to get them in game. They should be able to just take another file or map drop and have it plug right into a menu for selection.

Most technically oriented people don't want a dumbed down product, but you have to consider the total number of technically inclined people who might consider a purchase of ET versus average Joe.  

For that matter, consider how many people are/would be using a typical copy of ET.  Now I am sure that everyone on this board has legitimately purchased thier copy of the product, but typically I would say that 5-6 people would use a single copy instead of everyone buying thier own. This is based on the typical group of gamers. How much can you make when you can only get 1 in 6 people to buy your product? Also, it's really not even 1 in 6 because you can get it on Kazaa... This is something that anyone making software for this market has to realize (and probably does, I hope)

All the software extensions that I am making for Blackmoor will be freely distributable as bonus for buying the book. I have no illusions of making money in that sector at this time. 

If you were a bean counter at Hasbro and you came to that conclusion, what would you do? Cut the budget? Cut the project all together?

Remember the old adage about software(or anything really)

There's 3 ways to have something developed:
Quality, Cheap, Fast. 

Pick 2 and set the third to false.

Dustin


----------

