# D20 Modern supplement available [RolePlayingMaster]



## Luke (Nov 14, 2002)

I'm pleased to announce that you can now download the free *D20 Modern* supplement for RolePlayingMaster.

Even if you're not sure about trying the modern day rules any time soon, D20 Modern has *some interesting variations* on current rules - well worth a look!
The supplement has 6 new basic classes and 12 advanced classes, along with a swag of new skills, feats, and items (modern weaponry!). 

A report of the RPM Campaign Encyclopaedia entry can be viewed 
*here*.

The following shows an entry with an interesting rule variation on stabilizing when dying:






Go here to get the download.

Regards,


----------



## Leopold (Nov 14, 2002)

damnitt beat us to it! Can you generate PC's with this or is this just info based??


----------



## Max (Nov 15, 2002)

I just downloaded the update, and you can create PC's just like any other class.


----------



## Twin Rose (Nov 15, 2002)

Leopold said:
			
		

> *damnitt beat us to it! Can you generate PC's with this or is this just info based?? *




Don't worry, Leopold, we're just a step behind as well.  Of course, we'll have vehicle creation rules, ways of organizing your feats and weapons by category, Action Points, etc.  I could have done it 'juts like a fantasy character' but seeing new damage types (balistic, electricity) and special rules for 'ordinaries' has had me working on new editors.

Be wary of certain traps, such as hard coding the ordinaries, or the damage types.  However, personally, I'm having a fun time ripping out huge sections of code and replacing them to make more editors that can make the software just that much more configurable.  I can't wait to try making a 'jello' damage type  


PS Luke: Are you allowed to use the IP "D20 Modern" like that?  Might want to double check, just in case.


----------



## Hollywood (Nov 15, 2002)

Its like lemmings in here... 

We have two tools that are essential DM/campaign managers and one that is primarily a creature/character generator with DM feature additional program.  And there are one or two others out there too.  But then again, it apparently hasn't dawned on anyone to sit down, hammer out your differences and come up with a common data/script solution so that one supplement can be used by any user no matter the program.

All the end-user has to do then is select the program that best fits his/her needs and he's off to play because everyone is contributing to one base set of data and not reinventing the wheel three, four, five or more times.

Right now, I can't use that cool sword that was produced with the TwinRose software in RPM or PCGen.  Rather, I must take the time and import it into one of those, or other, packages myself.

Ah well, guess it matters little to me since I consider d20 outside of D&D and d20 Modern as nothing but complete trash [my god, who in the world thinks that a Strong hero should be capable of handling animals better than a Smart hero... and then there is the combat; eh, they just don't bother to learn or use common sense at all].  And I'm not much impressed by any of the tools I've yet seen.


----------



## Twin Rose (Nov 15, 2002)

Hollywood said:
			
		

> *
> We have two tools that are essential DM/campaign managers and one that is primarily a creature/character generator with DM feature additional program.  And there are one or two others out there too.  But then again, it apparently hasn't dawned on anyone to sit down, hammer out your differences and come up with a common data/script solution so that one supplement can be used by any user no matter the program.
> 
> *




Well, I've been working with Todd from DM's Familiar to create OLE automation and .COM objects for cross compatibility.  It's not as easy as you might think, but I've been able to drag and drop CH5 (campaign suite characters) around through explorer/CS so it's just another step away.

Also, I've worked with the folks who make both Fractal Mapper AND Campaign Cartographer 2 to make maps that are usable with CS - it really didn't take much, but our sample maps are made with these programs.

Lastly, RPM is 'new' and slightly different.  While I'll be porting my databases over to XML in the near future, I have no idea how compatible his scripting engine will be with that.  Once the XML database is complete, I'll be creating .DLL files that read them, as well as an API and SDK to go with them.  These should allow otehr developers instant access to my XML databases, or they can simply query them themselves.  There will be complete documentation.


----------



## Hollywood (Nov 15, 2002)

Twin Rose said:
			
		

> Well, I've been working with Todd from DM's Familiar to create OLE automation and .COM objects for cross compatibility.  It's not as easy as you might think, but I've been able to drag and drop CH5 (campaign suite characters) around through explorer/CS so it's just another step away.




OLE Automation/COM?  UGH!  UGH!  UGH!  Thats awful, its not cross platform, its... ugh.  Try dropping that object into PCGen and see how far it gets.  

Export the object with an agreed upon format, hopefully using open-standards and not proprietary BS, then each application can utilize the tools available in the language the application is developed in to facilitate the drag/drop functionality.

Take in Java for example, its not terribly difficult to setup a drop-zone and when an .xml file is dragged onto it, you can use, say jdom, to read it.



> Also, I've worked with the folks who make both Fractal Mapper AND Campaign Cartographer 2 to make maps that are usable with CS - it really didn't take much, but our sample maps are made with these programs.




Thats nice, I suppose... if you find that feature at all useful.  Personally as a DM, I don't.  And I even have CC2 Pro.



> Lastly, RPM is 'new' and slightly different.  While I'll be porting my databases over to XML in the near future, I have no idea how compatible his scripting engine will be with that.




Its Javascript.  And XML database?  Why?!  XML is a useful tool in many situations such as import/export, as a report tool, etc.  But not as a database....



> These should allow otehr developers instant access to my XML databases, or they can simply query them themselves.  There will be complete documentation.




And if they were all in one agreed upon format for import/export, no one would need to bother with proprietary API/SDKs from each small-time 3rd party developer.


----------



## Twin Rose (Nov 15, 2002)

Hollywood said:
			
		

> *
> 
> OLE Automation/COM?  UGH!  UGH!  UGH!  Thats awful, its not cross platform, its... ugh.  Try dropping that object into PCGen and see how far it gets.  *




As much as I respect the folks at PCGen, I can't really understand why character files from one character generator NEED to be transferred to another?



> *Export the object with an agreed upon format, hopefully using open-standards and not proprietary BS, then each application can utilize the tools available in the language the application is developed in to facilitate the drag/drop functionality.
> 
> Take in Java for example, its not terribly difficult to setup a drop-zone and when an .xml file is dragged onto it, you can use, say jdom, to read it.
> *




Thats what I said, isn't it? 



> *Thats nice, I suppose... if you find that feature at all useful.  Personally as a DM, I don't.  And I even have CC2 Pro.
> *




CS lets you link a given section of your map to a given city or dungeon or specific room in the database.  You can highlight areas for specific encounter tables.  All one click away from viewing if you should wish at the table, or even during design time for printout.





> *Its Javascript.  And XML database?  Why?!  XML is a useful tool in many situations such as import/export, as a report tool, etc.  But not as a database....
> 
> And if they were all in one agreed upon format for import/export, no one would need to bother with proprietary API/SDKs from each small-time 3rd party developer. *




Because we are all trying to have the most complete tool, to the point that it would make no sense to have them be cross-compatible.  CS goes to retail very soon, and grows every month.


----------



## Hollywood (Nov 15, 2002)

Twin Rose said:
			
		

> As much as I respect the folks at PCGen, I can't really understand why character files from one character generator NEED to be transferred to another?




Gee, I dunno.  If I as a DM am using CS and one my players is using PCGen [for whatever reasons], would certainly be nice to be able to take his character from PCGen and have it available in CS so that I could use use CS to keep track of its stats during the campaign.

I hate to say it, but thats not a terribly hard concept to grasp.



> Thats what I said, isn't it?




Not since you were referring specifically to proprietary technology.



> CS lets you link a given section of your map to a given city or dungeon or specific room in the database.  You can highlight areas for specific encounter tables.  All one click away from viewing if you should wish at the table, or even during design time for printout.




Thats nice, but its not useful to me.



> Because we are all trying to have the most complete tool, to the point that it would make no sense to have them be cross-compatible.  CS goes to retail very soon, and grows every month.




Yeah, I read you loud and clear.  You want to have a tool that does everything you think it should and in completely proprietary formats that if an enduser who purcahses it doesn't think it does everything he needs it to do, but wants to utilize data from parts of it he does use in other programs, he can't.

Its wonderful in this day and age where the big players are putting together ideas like Web Services [and no, I won't debate whether they will take off or not] and looking at how to allow people to distribute data between different platforms with as much ease and security sa possible, that some small botique software vendors are still stuck in the "dark ages" so to speak.


----------



## Max (Nov 15, 2002)

Hollywood said:
			
		

> *All the end-user has to do then is select the program that best fits his/her needs and he's off to play because everyone is contributing to one base set of data and not reinventing the wheel three, four, five or more times. *




(Luke's thread has sort of been hi-jacked.    )

I love the fact that there are several programmers/companies working hard to address the needs of the gaming community.  As is generally true with competition, I'm sure they are pushing each other to produce the best programs possible.  I have no problem with each company putting its efforts towards making their own product the best.

That said, I also don't have a problem if the various programs don't spend a lot of resources trying to work together.

Just because there are other programs out there that are pretty good, it doesn't mean I have to use them - nor will I.  I am currently in the process of figuring out what will work best for me.  Once I've selected the program that best fits my needs, I won't be using the other programs.  So, I won't be reinventing the wheel over and over and won't run into the problem you suggest exists.

Max


----------



## Twin Rose (Nov 15, 2002)

Hollywood said:
			
		

> *
> 
> Gee, I dunno.  If I as a DM am using CS and one my players is using PCGen [for whatever reasons], would certainly be nice to be able to take his character from PCGen and have it available in CS so that I could use use CS to keep track of its stats during the campaign.
> 
> ...




The OGL, which I ams ure you are familiar with, rather makes proprietary file formats difficult.  They need to be human readable AND human understandable.  All the developers provide documentation on the files use.  But many of us are too busy moving forward to take the time to look back, though it is certainly planned to work that way eventually.  We are taking steps to work together, but it's rather difficult when you are talking about developers literally spanning the globe.


----------



## Hollywood (Nov 15, 2002)

.lst is a proprietary format yet because no other software uses their format.  Get the point?  Additionally, saving character information if you reference an open 'datasource' of OGL'd data could be fine as a closed file format.



			
				Twin Rose said:
			
		

> The OGL, which I ams ure you are familiar with, rather makes proprietary file formats difficult.  They need to be human readable AND human understandable.  All the developers provide documentation on the files use.






> But many of us are too busy moving forward to take the time to look back, though it is certainly planned to work that way eventually.




Often too many boutique, and no I'm not saying you fall into this class and it applies to non-boutique vendors, simply code-and-go rather than actually plan things out, in other language go through a design phase and produce a design document, in the first place.  So it would not be surprising to see folks continue on divergent courses, etc.



> We are taking steps to work together, but it's rather difficult when you are talking about developers literally spanning the globe.




Funny that you mention that, but there are many successful projects out there whose developers span the globe... Linux kernel, JBOSS J2EE app server, NetBeans [with a lot of help from Sun], etc.

But whatever.


----------



## Twin Rose (Nov 15, 2002)

Hollywood said:
			
		

> *
> 
> Funny that you mention that, but there are many successful projects out there whose developers span the globe... Linux kernel, JBOSS J2EE app server, NetBeans [with a lot of help from Sun], etc.
> 
> But whatever. *




You're still talking about seperate platforms, by seperate people.  CS was the first, or one of the first, released with others coming later through beta trials and final releases.  I can't possibly predict who will be next, and I really see no need why I should go out of my way to hunt them down - my days are busy enough trying to scrape out a living doing this that adding to it just to help others makes no sense.  They are welcome to come to me, I've shared my data, worked with people like Todd who approached me.  But to do constant searches for others, trying to get their attention, asking them what I can do for them isn't good business sense.


----------



## Hollywood (Nov 15, 2002)

Twin Rose said:
			
		

> I can't possibly predict who will be next, and I really see no need why I should go out of my way to hunt them down - my days are busy enough trying to scrape out a living doing this that adding to it just to help others makes no sense.




Ok, hows this.. take ENWorld, its a well attended place by most people looking to hawk software for d20, no?  So if you post something that you are looking to form a group to talk about putting together common formats for certain data or ways of doing things to benefit the END-USER, I bet you'd have some interested parties talking to you.   You don't need to take lead it, but it takes 5 minutes to start if off.



> They are welcome to come to me, I've shared my data




I'm scrounging the site looking for the data/scripting/et al. formats.. none available.



> But to do constant searches for others, trying to get their attention, asking them what I can do for them isn't good business sense.




No, but providing a good experience for the END-USER who buys your product is.  And if being able to import/export information from PCGen because the END-USER prefers that program to create characters in, but likes CS to use at the table, gets you another several hundred sells, its in your interest to pursue it, no?  Better off, it'd be better to allow PCGen [used as an example only] to have information on your formats so that they could write a CS importer/exporter and thats less work for you and gives more value to your END-USER.   However, if both PCGen and CS had, along with other 3rd party vendors, had agreed to use the same format [we're talking about future versions, not current versions mind you], then there wouldn't need to be import/export tools and neither of you would have to write stuff for the other.

And to get back on topic, Luke put together the d20 modern, or a subset of it, for RPM.  If RPM, CS, PCGen, DM Whatever, etc. had agreed to utilize a common format... boom, your END-USERS could get RPM's d20 Modern download and you wouldn't have to do that work, but maybe you would add the vehicles section to it and Luke wouldn't hav eto do that work, etc.   As is right now, CS customers either need to wait til you release d20 Modern download, or do it themselves while RPM END-USERS are happily creating new stuff for the quesiontable d20 Modern rules.


----------



## Twin Rose (Nov 15, 2002)

Hollywood said:
			
		

> *
> And to get back on topic, Luke put together the d20 modern, or a subset of it, for RPM.  If RPM, CS, PCGen, DM Whatever, etc. had agreed to utilize a common format... boom, your END-USERS could get RPM's d20 Modern download and you wouldn't have to do that work, but maybe you would add the vehicles section to it and Luke wouldn't hav eto do that work, etc.   As is right now, CS customers either need to wait til you release d20 Modern download, or do it themselves while RPM END-USERS are happily creating new stuff for the quesiontable d20 Modern rules. *




He did it differently than I am doing it, basically making d20M an extension of the current SRD - which is something I'm doing differently.  In fact, I'm trying to allow for greater flexibility as I can see where the trends are going.  His scripting language is different from a data-file with scripting code in it - and PCGen uses .lst files that I'm not 100% comfortable with in that I feel they leave a chance for OGC to become a part of code.  That's okay for them - they have an open source project.  Tapping the RPM script would require extensive coding, and even mroe so I believe every time some 'new' D20 rule came down the pike.  As you can see, we have different philosophies as well as different products.

The end result might make for characters to move from one to another, in fact plain ol' text statblocks seem to work for most, but certain aspects are just plain done differently.  Each, of course, we believe is best for the ease of use of the end user.


----------



## Luke (Nov 16, 2002)

*Very much hijacked...*



			
				Max said:
			
		

> *
> 
> (Luke's thread has sort of been hi-jacked.    )
> 
> *




I'll say. I certainly welcome all sorts of community discussion, but I started this as a kind of "press release" on a free RPM download, and I'm very surprised at Chris taking the opportunity early in the thread to advertise his own program and its future directions here. Nothing prevented Chris from starting his own thread.

*
I had thought that there was a protocol of politeness that we all basicly adhered to.
*

I noticed a "Genie rocks" post appear within 2 hours, that looked a lot like an ad. It was by somebody anonymous that had registered for their first post. At least that was amusing.

*Chris, when a developer makes an announcement, and a competitive developer makes a counter-announcement on that thread, along with criticisms of technology choices - don't you think it starts to suggest a nasty turn on these friendly boards?
*
Some info for you on RPM:

- RPM has an extremely flexible development environment within in it, that doesn't require me to rip out code and replace it. Anybody wanting to take the time can add their own stuff to what is a very flexible framework for this. In fact, there is no special built-in coding for a Monk's BAB, or even Cleric domains. RPM's flexible framework allows for it, so anyone can do it.

- RPM already has a COM component in it that contains a chat capability and can make network connections that can even access the full scripting environment within RPM. So far there hasn't been much call for me to extend and really use it.

- There's no problem using maps from other sources, and the RPM sample dungeon uses maps from CC2 and DungeonCrafter. This should be a no-brainer.

- RPM is not new. It has been available for download for almost 2 years now, with open invitations to the community to download, try and make any suggestions to the development of the program. The development is "market driven", in that I work on what the community tells me is important.

- RPMs scripting engine inherits a built-in capabiity to deal with XML. I look forward to the arrival of good XML content. I've actually downgraded my personal, internal use of XML, since I've found it to be generally great for communication ( basically import/export), but terrible for database storage. In my experiments with multi-tier on-line database editors with XML, I found images to be a particular problem (not that much of an issue though).

- In short, I believe that my choice of technology balances the best for major requirements:- power to people wanting to create their own content, lots of editors for them to do it with, powerful scripting capabilities to get fancy if required, fast database/memory caching for instantaneous character/creature recalculation on the fly.

As far as I can see it offers unparalled, properly integrated  power for character/creature development that fits right into adventure building and in-game play. I don't see any other in-game play solution that easily does templates, levelling etc to near the same degree.


----------



## Hollywood (Nov 16, 2002)

Twin Rose said:
			
		

> The end result might make for characters to move from one to another, in fact plain ol' text statblocks seem to work for most.




Not when they don't take into account custom feats, classes, abilities, equipment, etc. and send that data along with it.  Without that extra information, if needed, the statblock is pretty useless.



> Tapping the RPM script would require extensive coding, and even mroe so I believe every time some 'new' D20 rule came down the pike.




No, I believe thats Luke's point is that by encapsulating the actual game mechanics code in script, anyone can add something new even to a closed program.  Correct me if I'm wrong Chris, but last I looked, I couldn't manipulate the game mechanics with your program to allow for my house rules - a simple example would be; we allow cross-class skill limit to be the same as the class skill limit, no double jeopardy.  That would be one of the most simple house rules.



> Each, of course, we believe is best for the ease of use of the end user.




Have you actually done feasibility and usage studies on this?  Or are you just relying on feedback from those who take the time to download a trial version or actually purcahse it?  Best for yourself is not always best for anyone else and often you will find that what, with all the best intentions, what you think is best for the end-user actually ends up being the worst.



> (Luke's thread has sort of been hi-jacked.  )




Sorry, that was completely my fault. 



> Chris, when a developer makes an announcement, and a competitive developer makes a counter-announcement on that thread, along with criticisms of technology choices - don't you think it starts to suggest a nasty turn on these friendly boards?




I don't necessarily get the feeling that was the case, at least I hope it wasn't.


- RPM has an extremely flexible development environment within in it, that doesn't require me to rip out code and replace it. Anybody wanting to take the time can add their own stuff to what is a very flexible framework for this. In fact, there is no special built-in coding for a Monk's BAB, or even Cleric domains. RPM's flexible framework allows for it, so anyone can do it.



> - RPMs scripting engine inherits a built-in capabiity to deal with XML.




What scripting language are you using?



> I look forward to the arrival of good XML content. I've actually downgraded my personal, internal use of XML, since I've found it to be generally great for communication ( basically import/export), but terrible for database storage.




Yes, thats exactly what I've been saying. 


As far as I can see it offers unparalled, properly integrated power for character/creature development that fits right into adventure building and in-game play. I don't see any other in-game play solution that easily does templates, levelling etc to near the same degree.


----------



## Twin Rose (Nov 16, 2002)

>> Chris, when a developer makes an announcement, and a competitive developer makes a counter-announcement on that thread, along with criticisms of technology choices - don't you think it starts to suggest a nasty turn on these friendly boards?

Actually, if you look again, you'll see that I was making a jab at Leopold meant in fun between myself and someone I know rather well.  It sense escalated witht he questions and etc that Hollywood posted, which I tried to address.  I didn't mean it as a criticism, you will also see that I clearly posted that they were different philosophies and ones that I couldn't go back and change now - whether I wanted to or not.

Additionally, you will notice my expressed desire to work with other developers on things, and ways that I am working to try and fascilitate that.


----------



## Luke (Nov 16, 2002)

Hollywood said:
			
		

> *Not when they don't take into account custom feats, classes, abilities, equipment, etc. and send that data along with it.  Without that extra information, if needed, the statblock is pretty useless.
> *




Exactly right Hollywood.
I get a lot of requests to do a PCGen import, but I'm not at the point of doing it properly - and I'm not prepared to pretend that a statblock import will do the trick. If you have special sources (3rd party races, classes etc) that aren't in the target system, the target system can't do a proper job of maintaining it.

The game mechanics behind the races, templates and classes is extremely important - especially to a system like RPM. RPM will let you fiddle extensively with characters/creatures - adding and subtracting templates, classes, or even the base. I make a special point of recording the raw roll ability dice rolls for that reason, since extensive playing revolves around that. This is great for a DM tinkering an adventure.
The in-game mechanics of RPM also mean that the mechanics behind that statblock is important. For example, if you add the magical "Disruption" ability to your mace, and crit a creature, RPM can determine if they're undead, and prompt for the save.



			
				Hollywood said:
			
		

> *No, I believe thats Luke's point is that by encapsulating the actual game mechanics code in script, anyone can add something new even to a closed program.  Correct me if I'm wrong Chris, but last I looked, I couldn't manipulate the game mechanics with your program to allow for my house rules - a simple example would be; we allow cross-class skill limit to be the same as the class skill limit, no double jeopardy.  That would be one of the most simple house rules.
> *



Right again. I've actually planned for this kind of eventuality from the start. The game mechanics in RPM are effectively "open-source".
To begin with, the mechanics are typically attached to the things they effect (eg the skills, feats, classes, races themselves). This means that the sources you activate for your current campaign will activate the code you require for those sources.

That said, there are still plenty of *core* rules that may also be affected.
I've also planned for that. The "Game Rules" configuration section of RPM will very soon have the "Source" field, meaning that it acts like all the other tables (feats, skills, races, items etc), and only shows and uses what you've chosen.
In addition to that, you can add you're own house specials into "Game Rules", and you can selectively turn certain sections on and off.
I find these days that I do comparatively little work on RPM itself. For example, anybody could have done the "D20 Modern" I just released. RPM itself didn't change one bit, since I just used the existing framework.
That's how I got it out within a few days of the SRD being released :
1 - Create a new "Source" and set it as the default entry.
2 - Just copy-and-paste for the encyclopaedia.
3 - Use of the open editors for classes, feats, skills, abilities etc.
4 - Export the source, and stick it up on the web page.

I plan to soon split the RPM "Core" source into "Core" and "Core fantasy". That way, you could play a Modern or Sci-fi game without having spells, skills, and races appear as inappropriate options. If you really want meta-magic feats, then turn them on "Core fantasy". The Psionics already has its own source, so you could mix it easily with D20 Modern, using 2 mouse clicks...

To be honest, I'm sure Wizards planned for separate StarWars, SciFi, Modern etc genre from the start. I'm surprised that a distinction between core and core fantasy wasn't built into the core books - as with GURPS.



			
				Hollywood said:
			
		

> Sorry, that was completely my fault.



Not a problem, and I didn't mind your comment, as I didn't mind Leopold's. Leo didn't even mention PCGen (which I would have been cool with anyway) - pretty different from Chris, who carried on about CS and included some comments about RPM that were inappropriate and wrong.



			
				Hollywood said:
			
		

> What scripting language are you using?




Essentially its a super JavaScript, enhanced for RPG. I picked it because:
- Its very fast.
- Its object-oriented (allowing for rule replacement).
- Its available on every Windows machine.
- Many, many thousands of people already know it (through web programming).
Those are are interested have shown independant ability to modify the scripts for their house rules. There are plenty of examples of the super enhancements to see how it entends the basic JScript language.

Regards,


----------



## Hollywood (Nov 16, 2002)

Ok, I'll have to respond when my head's clear of beer.... too much to digest right now!


----------



## Mynex (Nov 16, 2002)

*Jumping in here for a minute*

Hey guys...  Interesting read, won't hijack the thread either... just wanted to point something out that may be of interest...

We've (the PCGen team) have been slowly working toward the charater file (.pcg - plain text) being completely self contained.

Every detail of teh character saved, skills, feats, equip, etc...

In theory, once we hit total encapsulation, it should be a fairly simple deal to import/export most of that data into RPM (if I am understanding how Luke it doing it).. not to sure about CS, might require some serious tweaking...

But Javascript is an easier way to handle the data/character files of PCGen.

Anyways, Luke, good job on getting the D20 Modern done so quick!  We should be there in the next release or 2... some tweakings going on to make it happen. 

Good job with RPM.


----------



## Luke (Nov 16, 2002)

*Re: Jumping in here for a minute*



			
				Mynex said:
			
		

> *We've (the PCGen team) have been slowly working toward the charater file (.pcg - plain text) being completely self contained.
> 
> Every detail of teh character saved, skills, feats, equip, etc...
> 
> ...




Thanks Mynex 

A lot of people will be happy if I can properly import their PCGen characters/creatures into RPM adventures, and for in-game play.

I kind of assumed that the skills, feats, equip etc are already encapsulated in the .pcg file.
To do a complete job also means knowing the mechanics behind all the feats, class abilities etc.
To make things a little more challenging, RPM does have a slightly different outlook on programs that generate statblocks as an endpoint. For example, a statblock program wouldn't really have anything behind feats like cleave. For in game use, RPM has code behind "Cleave" that will notice if you just downed an opponent, and then prompt for another attack. In general, to do in-game stuff, you need to put more behind all the different parts of the game.

I've tried to keep an eye on the D20-XML project, but it progresses very slowly, and not sufficiently for in-game stuff. 

Still, it sounds like PCGen is determined to continue its great community efforts, which can only help. I think that there's also a PCGen/XML effort in the works, which would be very, very good 

Regards,


----------



## Leopold (Nov 18, 2002)

pcgen has an XML project in the works. I keep hearing about it on the yahoo boards every so often..


----------

