TokenMaker

[Rumble]

Very cool... would love this to be easily integratable (is that a word?) with Rumble's framework someday. Great work.

So would Rumble!

[AidyBaby]

Very cool... would love this to be easily integratable (is that a word?) with Rumble's framework someday. Great work.

Thinking just the same thing...

[Blakey]

Have you considered publishing your code as you go along? You could use google code as a repository, then folks can see what you have and possibly contribute.

I hadn't but I'll look at that now, certainly. It could be a bit embarrassing having my code on display like that though!! Will let you know when it is up.

[wolph42]

Are you concentrating on this being specifically for D&D, or a more general tool?

I'd love to see a more general tool, along the lines of what I suggested in this thread awhile back:

http://forums.rptools.net/viewtopic.php?f=2&t=13036

now I happen to know that with 'general' you mainly have wfrp 2 in mind
And I thus was wondering whether you have realized that I have already created a character-sheet-in-text-format-to-token-parser, albeith for Dark Heresy. I think that this tool with not too much trouble can be rebuild to support wfrp 2. Its still not 'general', but it least can help you on the way. The parser is in my DH framework see my sig.

[Blakey]

Are you concentrating on this being specifically for D&D, or a more general tool?

I'd love to see a more general tool, along the lines of what I suggested in this thread awhile back:

http://forums.rptools.net/viewtopic.php?f=2&t=13036

Hey,

I'm pretty much 100% a 4E D&D player/DM so that is what I'm working towards. My purposes here is to write something specifically useful for my group. However, this being java, and because I'm more than happy to share my code, it should be easy for anyone else to pick up what I have written and extend it to read other formats in. I hope I'm designing the program objects in such a way that you could simply plug in a different importer and the process would still work. That's certainly my aim.

But my efforts are all towards a 4E D&D parser which assumes and requires DDi account access.

Blakey

[Blakey]

Very cool... would love this to be easily integratable (is that a word?) with Rumble's framework someday. Great work.

I'm not planning it simply because I don't use Rumble's framework in my games. I currently use Veggie's - or at least my own heavily hacked version thereof. I'll probably be generating a new framework entirely for this program though, but as I've said before, it should be easy enough to write extensions to create tokens which match any framework potentially, so I see no reason why a Rumble-Framework interface isn't possible in future.

I suspect Rumble's java-fu to be much stronger than mine so I'm sure when I have something that actually creates tokens at all, he can easily knock up an extension to it to make tokens for his framework. I certainly plan it to be able to extensible that way.

[Blakey]

Have you considered publishing your code as you go along? You could use google code as a repository, then folks can see what you have and possibly contribute.

Okay, I've done that. It's available here:

https://code.google.com/p/tokenmaker/

Only I (should) have any write permissions on the code at the moment which is fine with me. If I ever choose to give up on the project then of course I'll make it available to all. And I'll open it up if I ever finish it.

Now, does anyone care to take a look at the Token class (https://code.google.com/p/tokenmaker/so ... Token.java) and tell me why the tokens it generates are invalid in MapTool????

[Blakey]

Today I added a Power Frame which pops up when you double click on a Power that a PC has. This pops up the HTML representation of the power downloaded from the Compendium.

I've reached a bit of a sticking point now. I'm not too keen on spending ages working on parsing the monster HTMLL to get stats out as they are about to change the monster layout in a couple of weeks. And I have been unable to figure out why my tokens aren't acceptable to MT when I load them - I think I need help on that. Not really sure what to do next, but I'll probably look at monster HTML parsing this weekend as hopefully most of that will be transferable when the new formats come out.

So, if anyone wants to figure out why my tokens are rubbish - or at least give me a pointer - feel free!

Cheers!

[Rumble]

I suspect Rumble's java-fu to be much stronger than mine

You'd be surprised... My Java-fu is essentially idiot-savant in nature. I am not positive I would have been able to create this application, for instance.

[Hawke]

Have you considered publishing your code as you go along? You could use google code as a repository, then folks can see what you have and possibly contribute.

Okay, I've done that. It's available here:

I don't mean to derail, but I found when I was doing PHP development and opened up my project to others it was pretty scary. I knew I had bad habits and it'd look terrible... but in the end it was good to see other's approaches and get the feedback on some easier ways to do things and was very positive.

Unfortunately I know nothing of Java so I can't contribute... but if you need a beer and are passing through town, I'd be happy to assist

[Blakey]

A bit more progress today. I managed to figure out why I couldn't save tokens from MapTool into the save files I'd created with TokenMaker. So I can now save basic PC tokens from the app. These tokens have no properties and no macros yet but it's a start.

I wrote some code to write macros onto the token for each Power a PC has and it looks like the XML is right to me but MapTool coughs when I try and drag a token onto it. Got to figure out why.

I also started to write an HTML parser for the Monster Pages. Quite a good intellectual challenge so I'm enjoying that part. I'm thinking it might need a total rewrite when the new format comes out but we'll see. I don't know if I'll even get it finished by then anyway, and it might not be a huge issue to switch it over to the new format.

Slowly, slowly catchy monkey and all that.

Blakey

[Blakey]

Stupid XML. A quick peek at my code this morning and I realised I'd made a simply mistake in my XML writing. Fixed that and I'm pleased to say I can now create player tokens which have a single macro created for each power the user has. At-Wills are made green, Encounter powers are made Red and Dailys are made black as per the standard colour schemes.

Now I'm really hitting the Framework problem. I have to put some code into those macros and am wondering what I'm going to put in there. This part is going to take some thinking about so I guess I'll be working on HTML parsing again in the mean time!

[Hawke]

Framework wise... Rumble, Veggie, & co... how could Blakey best output information so that it could easily be imported by your framework? It is probably the better method for Blakey to output some sort of generic format that could be pasted into individual frameworks rather than have him consider how he might create tokens for each one. I'm seeing some kind of XML that maybe could be read easily and accurately - similar to how Rumble lets you paste a power card or monster statblock into his framework. Of course with wrappers around the individual parts I imagine it would be much more accurate.

[Azhrei]

Now I'm really hitting the Framework problem. I have to put some code into those macros and am wondering what I'm going to put in there. This part is going to take some thinking about so I guess I'll be working on HTML parsing again in the mean time!

Well, about the best you can do would be to execute a macro whose name is specified by a token property. That property would be setup with a default value by the GM so that it points to the correct campaign macro. That allows the campaign properties to specify the correct macro and your code doesn't change, and yet it can be overridden for individual tokens if necessary.

The only problem is that it can't be a hidden property because it has to have a default value assigned to it, so players could see it and (potentially) change it by simply creating a property with that name. Of course, that doesn't mean it would be trusted and most frameworks will be executing code that requires trust to function properly.

[Rumble]

Framework wise... Rumble, Veggie, & co... how could Blakey best output information so that it could easily be imported by your framework? It is probably the better method for Blakey to output some sort of generic format that could be pasted into individual frameworks rather than have him consider how he might create tokens for each one. I'm seeing some kind of XML that maybe could be read easily and accurately - similar to how Rumble lets you paste a power card or monster statblock into his framework. Of course with wrappers around the individual parts I imagine it would be much more accurate.

An XML-like format (not necessarily XML in a formal sense, with DTD's and all that) would work; that's what I'm doing when I parse Monster Manual 3 statblocks (or what I will do, come next month when - I hope - MM3 statblocks are available in the compendium & monster builder). Put a wrapper around it and it becomes much easier to isolate any single tagged range to text.

It really depends on how finely things are subdivided, and what each framework needs - for instance, DeviantNull's framework and mine are very different in terms of power handling and so forth, but they use the same info. Ideally, it outputs the data in the smallest workable unit, so that frameworks can work with different levels of..uh..."atomicity?"

That is, a simple framework might need only the expression "1d12+2" for damage; others might be looking for "1d12" and "+2," and still others may break it down to "1", "d12", and "+2" - so ideally the output does #3, and you can build up to the whole expression.

It would be fun to extend it via Java, and create whole tokens like "ZAP!" but that's a seriously big job - I'd have to reproduce the power structure AND the property structure of a token and do a lot of variable construction - and it doesn't seem like it would be terribly portable or reusable. It seems like the payoff would be low for the work, since I already know (mostly) how to import stuff and parse it and half the work's done already.