eTools Patch and Source Code

[Hollywood]

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]

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.

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.

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.

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]

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]

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

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]

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.

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]

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]

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]

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]

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]

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!