RPTools.net

Awesome! I spent an hour or so trying to break things on the new release this morning

One small bug. Import in a caster and select them, but don't impersonate anything. On the Selection tab Feats, Abilities and the initial Spell tabs work, but when you try to drill down into a specific spell it throws an Unknown macro "spell 3" error.

Other things tested. I imported goblins, a drow, wolf, dwarf, elf, human, harpy, gnome and setup a campsite. All the visions seemed to work great.

Imported a goblin sorcerer, human witch and gnome illusionist. All the DC's seemed to work as expected for the spells. Only really minor thing is on the gnome I took the Precocious Spellcaster trait to bump his Color Spray up to CL 2 and that doesn't show. Not your fault though, Herolab puts CL1 in the known spells and CL2 for it as a memorized spell, which you're not messing with.

Though I don't think Traits are importing into the token as general text. Maybe put that into the Feats tab?



I'm really looking forward to seeing how you handle the ability/spell tracking and trying to break that

This framework is great and so easy to work with. It takes me more time to create a NPC in Hero Lab than it does to convert them into Maptool with Tokenlab and once they're in, there's zero tweaking to do.

Okay, playing with it some more I found a spot where the importing isn't working quite right: familiars.

This is a level 1 witch with a fox familiar. You can download the bundle to test with at http://tarsis.org/me/witch_test.zip

The Alia XML contains both the witch and familiar. Only the witch will show up in Tokenlab. The Durnis XML is just the familiar. That will import, but it looks like the skills aren't working right.

Hero Lab skills:



Stealth skill roll:



I think this is in how the original framework is handling skills. For example, my gnome has Craft jewelcrafting but that's tossing an error:



Other skills are also probably going to be off. Rerolling the gnome as an alchemist with a trait for spellcraft:







I shouldn't be able to roll that low. It looks like the framework is still using the rank + bonus + attribute type stuff which misses out on a lot of bonuses(Traits, Gnomish obsessiveness). I'd just completely scrap all that and use the HL skill value from the XML. HL does all the math, no need to have Maptool attempt it.


One other thing, and this is nit picking(but hey, it reduces a UI click), when you drag a token onto the map it asks if it's a PC/NPC and always seems to default to NPC. If there's a way to change the pre-selected default in the token you could set this via the below HL XML:

I've uploaded version 13, which I'll discuss below:



Yeah. The only way for me to fix this (that I know of) is to create a Lib:token that has the spell macros in it. Thus far I've been trying to avoid creating any library tokens as that detracts from my design goal (which is to be as simple as possible, to make it easy for MT n00bs). I suspect as I continue to add functionality I'm going to have to re-address this, but for now the bug is going to have to stay alive.


Done. I actually added a 'Traits' button next to feats to keep at cleaner. As a result of this, I had to change the campaign properties; I added a "TraitsJSON" property. (So reload the props or adjust by hand, as you prefer).


Done, works as described above.


Added to todo list.


Yeah, I've been thinking this too. Going to have to bite the bullet and rework how skills are handled. I'm going to create a simple SkillsJSON token property and shove everything into that. The reason I've been avoiding this is because I haven't wanted to really learn how Maptools forms work ...

Hmm, no idea about the JSON stuff either. I'm a maptool newbie myself. What I was thinking was, just scrap how MT does the skills at all. Gut all references to it. Parse the HL XML skill block and do a for each on each skill in that block. Take the text of the skill name and create a token macro in the skills group: [rd20 + value] where value is taken from the HL value attribute.

Format it up a bit, and crud, if you REALLY wanted to be nice use an external template for the text so users can edit how their skill macros print that Tokenlab creates.

As a player/GM that's all I really need anyway. Pre-made macro's that roll my skill. It's simple and also future proof in that so long as the HL XML stays static when new skills are added nothing needs to be changed. I can have "Underwater basket weaving, value 18" in the XML and Tokenlab could parse and create a skill macro for it without missing a beat.

Of course that may be what you're were talking about anyway. I really wish my Java skills weren't completely atrophied or I'd help.

Yep. It's going to be a straightforward implementation, and will work as a you describe.

Ok, the skills stuff is complete and uploaded. This is breaking update -- you'll need to refresh your campaign properties.

It's nice to get rid of all those hardcoded skills from the campaign properties file, I deleted 100+ rows from the file

Please note that I deleted the skills page from the character sheet for now, as I'm going to have to rejigger it and didn't want to leave it in in a broken state).

Oh, and it sounds like its time to brush off those rusty Java skills! (that's what I had to do for this project )

Awesome, thanks for the updates. The skills are all working now, even on the familiar. Only minor bug on the familiar is his unarmed attack errors, but that's a framework issue since his damage is 1-1 and it doesn't know how to cope with it.



Yeah, at the moment I'm playing more with the maptool's level macro'ing since I need to know that anyway. Also, I'm a bit of a lazy programmer and while I've worked with Java off and on since the 1.02 JDK days, it's been 6 years since I've touched it and I've never used it for parsing. Perl has always been my text parser of choice and I since I work with Perl on a pretty much daily basis today(I sysadmin these days) I could whip up experiments pretty easily for token creation to test some ideas.

For example, I'm wondering if a converter like this couldn't be system agnostic. All systems typically have the same concepts, weapons you attack with, powers/spells/feats/traits you need lists of, resource track lists, and skill rolls. And Hero Lab seems to output all the fluff in the XML.

Certainly possible, especially with 3.5. With something like Call of Cthulhu (for example), it'll probably be a bit different. I leave this as an exercise for the community, as I exclusively focus on Pathfinder nowadays.

The way I'm parsing herolabs xml is fairly cheekly; I code generate the java classes from the herolabs dtd file using JAXB, and then simply serialize the xml into those code generated classes. End result: zero parsing of xml. From the code:



I'm an old-skool Perl guy myself, one of my favorite languages, but I must confess that over the last few years I've forced myself to migrate to Python in order to expand my repertoire.

Ok, wanted to provide an update on the resources per day/week work.

I've hit a bit of a wall on how to do this properly and would definately be interested in what folks who've done tricky forms using MT think about how to do it.



On the left ("Solution A") is how I'd prefer to handle usages per day. There are two buttons (red and green) that adjust the usages up and down, a description of the power, and a little help/info button. (Hero Lab users will recognize this as being very similar to the HL tab.) On the right ("Solution B") is a more ghetto solution that implements the same concept with simple checkboxes.

So, 1) is it even possible to implement Solution A? The problems I'm running up against seem to hit the wall of MT forms capabilities; that is: callbacks within forms (so when the user hits the green button the counter bumps up by one), and persistance (so that when the user presses the 'Save' button it sets, foreach power, the integer counter).

And 2) is it even possible to implement solution B? I can get around the callback problem with Solution A by using simple checkboxes, but I'm not sure how to handle persistence. Obviously I'd keep a json data structure on the token that indicates the current number of usages per power, but when I hit the 'Save' button how can I count how many of the checkboxes have been selected?

Thoughts appreciated!

Cheers

well... there is zero "automatic" stuff in the HTML forms. If you want to click a button to update a number of uses, you have to actually submit something to the server. For that, each up/down button would need to be a submit button(ie, the save button would be redundant since each click "saves"....well it submits and your back end code would have to do the saving of course!)

Look here and pay attention to the "buttons" for "weapons" and "main" on the last picture.... you can make "sort" of a pretty version to "tabify" the top where the two "sections" show up, but are limited by java's html implementation in how much styling you can use(CSS).

Thank you, that helps. What about refreshing the form (but not closing it!) each time the user clicks the increment or decrement buttons? Is there a way to do, in order: submit-but-don't-close; change text label (from 0 to 1, for example); refresh form to show newly updated text label?

Click link... read tutorial... until you get the basics down(I would suggest following along with the tutorial(s) with each example.) Otherwise, your just asking questions that are already covered. In any event, to get a refresh, you have to have the form to submit and then your back end code it is submitted to has to handle what ever the change was and then reshow the form with the updates.

Heh, RTFM. (I did go through that exact link in detail prior to making my OP, but apparently not in enough detail.) Thanks again.

Well... it's more of a case of give a man a fish vs teach a man to fish. DOING the examples, preferably by typing instead of just copy/paste will help you learn FAR faster than someone just giving you an answer and will allow you to much more easily adapt the code to your specific situation which is good in the long run. Another good cliche is: How do you eat an elephant... one bite at a time... so goes any type of coding.