iplay4e to dndvt xsl

[psychopez]

I've been in the DnD Virtual Table beta, and have been looking at how
the character files from the VT are made. Here's a link to a sample
file: http://dl.dropbox.com/u/1177409/cb2vt/masaki%20-%20default.ddchar

If you unzip it, there is an object file inside, which is the xml
format that the VT uses. I've started making an xsl file that
converts iplay4e xml to vt. It's not finished, but a lot of it is
there.

http://dl.dropbox.com/u/1177409/cb2vt/ip4e2vt.xsl

Now that the holidays are over I plan on trying to finish hacking this
together. If any of you are in the beta, I thought I could share this
with you and see if yinz have any input.

[Andrew Reutter]

This is great, psychopez!

Please keep us in the loop as this comes along - and if you have any
questions about the iplay4e XML, don't hesitate to ask. (Your posts
will show up immediately now that I've moderated you up. Stinking
spammers won't let me have the group unmoderated...)

[David Berg]

I looked at this extensively right after they opened the VTT to beta
testing. Modifying the VTT XML is playing with fire so do so with some
care.

It does work and I've done some porting of CB/MB files to automate the
process for both monsters and characters. The process works but is not
without issue. The issue you will have is that they are using java and
assigning unique ids to various items in the file. In the VTT XML you
will see that there are some trusted element ID tags that you can't
just replicate w/o the use of their server (see below). These tags can
result in conflicts with other trusted resources and that will cause
VTT usability issues. Conflicts can and do corrupt entire map/
adventure files.

The fact that the data in these xml files is pretty close to what we
need implies it should be a short order for WOTC to marry the VTT with
the other DDI apps. I think the delay is that they don't want to
release too much detail in the XML and will likely provide a service
to gain the needed data directly from the online versions. That route
will make any developement done on this pretty much useless if or when
the format changes.

These are java tags you will find that ultimately kill 3rd party
developement for the VTT.

<elementID>
<unique>-1210631749</unique>
<time>1290530843816</time>
<count>-31928</count>
</elementID>


I'd say have fun with it as a proof of concept, but don't waste too
much time hoping that you can develop a useful system to port CB/MB
files to VTT useable content.

Dave

> > with you and see if yinz have any input.- Hide quoted text -
>
> - Show quoted text -

[Mike Hasko]

Well frell me.  I thought the errors and issues I was getting on loading a transformed ip4e was from some mistransform somewhere...

...meh, it was a good practice exercise none-the-less.  Thanks for the heads up, David.

[David Berg]

Cudos for getting that far!

You should consider yourself among the elite as I only know of a
couple of other people who have made it as far as you did. It is just
frustrating to spend lots of time on the project only to find that it
can't be done effectively.

The only plausable way to use the file is to create a "dummy" master
file prefilled with blank/known entries into which you can overlay
actual CM/MB data. The master file will have good element id tags
that are known/trusted. It is a messy way to do it, but does work.
Like I said it is a nice proof of concept, but of little real-world
value. The id tags don't seem to be done to purposefully stop 3rd
party developement. They appear to be used to insure consistancy and
validity of the data flowing between the java VTT app and the Vecna
server.

btw what's your DDI user name as I'd like to add you to my friends
list of other 3rd party developers

Dave

> > > - Show quoted text -- Hide quoted text -

[Mike Hasko]

Same as this one, psychopez.