TokenMaker

[Blakey]

Glad you noted this. One thing to think about is breaking components down into nouns and each noun becomes it's own class. For example, in your entry above, when you look at the compendium there are Creatures, classes(player classes that is), powers, etc. But each of those are an instance of a CompendiumEntry, so CompendiumEntry(or something like that) would be an interface or more likely in this case class or partially abstract class that the other classes extend.

There are some common things about compendium items that you should not have to reimplement in each of your subclasses...Name comes to mind...

Yeah, I already have a CompendiumEntry class which does 95% of the work and then a CompendiumNPC and CompendiumPower subclass which just add on a little specialist functionality where needed. Same with Token and NPCToken/PCToken (oh, just realised I have inconsistent naming convensions there - the Compendium classes all start Compendium and the Token classes don't - as an aside, what is the better convention?)

I'm much happier with the way all the object interact now after a little refactoring. I'm sure there is stuff that could be better designed - I'm more than happy if people want to critique my design!! I shouldn't get too defensive I don't think.

On the progress front today I have refactored, commented up and documented all the classes as I said. I've also added formatting code to the HTML output of the powers so they look much better now.

I improved my HTML parser as well adding a little RegExp function to get integers from strings that include an int plus potentially a bunch of spurious characters. That means I can now read "AC 14;" and parse out 14 for AC. I can read "Will 16 (but see also Blah power)" and parse out 16 for Will. I threw Gwenneth the Vampire at the parser after those changes and it nailed all her stats first time! Well chuffed.

I'm currently not picking up resistances and vulnerabilities, alignment, attributes, skills, equipment, saving throws, action points and all sorts of other stuff so there is more work to do, although a lot of these I'll be ignoring for now anyway as I don't need them.

I think my next important job is to parse out the last stats that I do need and then start added the stats into the token as properties.

When that is done I want to parse the monster HTML for attack and damage strings and replace them with MACRO link calls - so I can call macros to roll attacks and damage by clicking on the links on the HTML output - I have this facility with James' HTML parser and it's great so I want to replicate it on my HTML frame.

At that stage I think the monsters might be usable in a game!

Blakey

[Hawke]

Sounds like great progress !

Here's a question... if you've got a class what about getting together with some of the others working on MapTool to see if we can't drop your class in and tie it to macros? Let folks making the frameworks use the maptool scripting to grab the info they need? I know it might be a bit much trying to integrate something new right off... but I'm wondering if someone else might have ideas on how to help with that.

I'm jealous of your elite javaness.

[Blakey]

MonsterMaker Update

I made a nice addition to the MonsterMaker today. Added some more search fields to the frame so you can now search for monsters based on level, role and type. I have no interest in searching on source book or by XP value so I didn't add those fields to the search boxes.

This is what it looks like now:

Latest NPCSearcher frame.

monstermaker.jpg (113.43 KiB) Viewed 3613 times

I also added parsing of Saving Throw and Action point values for the monsters. Next up, saving these monster stats as properties out to the token...

Cheers
Blakey

[Azhrei]

OOA&D is a journey, not a destination.

I've been writing code since the late 70's (Z80 machine code and BASIC) and using OO languages since the mid 80's (C++). I've read at least a dozen books on OOD not counting language-specific books. And yet every time I flip through the Design Patterns book (by the Gang of Four) I realize that MapTool should be using this pattern or that pattern and where. I've become very enamored lately of the Strategy pattern as it fits quite well with a couple of things I'm working on...

If you want a good read on OOD and how to draw your designs on paper so that others can read them, pick up Martin Fowler's book called "UML Distilled". It's a relatively thin book -- and pricey for the size -- but it does a great job of describing terms, techniques, and tips for OOD. I've had some students tell me they love that book and others that they hate it. But I pick up something new every time I read it (the next one will by my sixth, IIRC).

[Blakey]

Yeah, I agree Az - it's a long journey at that!

I'm partially a programmer by profession (you'd not guess it looking at my code I know!) but I have flipped from everything from doing UNIX c-shell scripts to C++, fortran, java and everything in between. Trouble is in recent years I've been doing lots more Linux system admin rather than programming so I'm a bit out of touch. my work is expecting me to do some java programming soon (hence the course) and so I figured I'd best get back into the 'swing' of things (pun intended) ASAP. This little project has been a good exercise in that regard.

So, a bit more progress last night - and something pretty significant. I figured out how to get Properties into the tokens I'm saving. So I can now get all the properties that I am interested in for my version of Veggie's framework onto the monster token directly out of the compendium - it's really coming together!

My next move is to add Macro Links to the HTML that gets displayed for each monster over their attack rolls and damage rolls so that I can automate making attacks by clicking links on the HTML frame, rather than by using macro buttons on the "Selected" panel. That is how I like to do things with my framework now and I plan to replicate that as a first pass. Once that is done I think I'll be able to use this tool to build monsters for my framework. Yay!

Then I'm going to think about other framework support (see next post).

[Blakey]

Framework Support

I am using Veggie's framework for my games. Or at least I was. I've hacked it around a lot and it's now quite modified and a user of Veggie's framework would probably recognise it but it's not the same anymore. I've decided I'm going to officially split off from Veggie's FW at this time, rename "Lib:Veg" to "Lib:Blakey" and completely split away from saying mine is the same as Veggie's. Of course it will always be a side branch of Veggies and wouldn't have been possible without his work but I would like to make something my own from here. When I have done that I am going to make TokenMaker work with my new framework and get it all working in the manner I require - from the monster point of view at least.

With that done it should be fairly easy for me to make a version of TokenMaker that supports the default Veggie framework. I know it well and know how to make tokens that work with it. I suspect I'll probably take that task on as well.

After that I will think about writing an extension for Rumble and maybe other FWs. Trouble with this is that I'd need to get up to speed with how the other FWs work in order to write a token class to output valid tokens for those frameworks. I'm not sure I have the time or inclination to do that.

Then of course there is the problem that FWs are naturally always evolving and I won't be looking to keep making changes to TokenMaker to keep up with the latest changes people make to their FWs.

The code to TM wil always be available so there is nothing to stop another person downloading it, writing a Token class for a given FW and building a new version which supports it. That's probably what will realistically happen I guess. We shall see though.

[Hawke]

The code to TM wil always be available so there is nothing to stop another person downloading it, writing a Token class for a given FW and building a new version which supports it. That's probably what will realistically happen I guess. We shall see though.

Rather than learning the individual frameworks, if you get any part of your code well commented, I would say spend your time getting some info about how someone might write this class. Not sure about veggie, but I do know that Rumble has java experience and depending on how easy it is even some really green guys might be able to write something code wise to export.

In addition, I wonder how hard it would be to write a converter that would load a token from Veggie's and then spit it out in a way that could be loaded into FrameworkX.

As an aside, Rumble's latest 5.0 beta is really cutting edge. I'm very surprised with not only how much it does but how simple and refined it is. Even if for inspiration on your own edits, I suggest you give it a quick whirl.

[Blakey]

Rather than learning the individual frameworks, if you get any part of your code well commented, I would say spend your time getting some info about how someone might write this class. Not sure about veggie, but I do know that Rumble has java experience and depending on how easy it is even some really green guys might be able to write something code wise to export.

Yeah, this has always been my plan really. I was thinking about this the other day and I need to work out a simple way for others to expand my code. Shouldn't be difficult at all.

In addition, I wonder how hard it would be to write a converter that would load a token from Veggie's and then spit it out in a way that could be loaded into FrameworkX.

Now I'm getting familiar with the internal MapTool token format I'd say this was quite easy. HOWEVER, the big problem here is that these frameworks are constantly evolving which means as soon as someone changes their framework the converter is broken.

As an aside, Rumble's latest 5.0 beta is really cutting edge. I'm very surprised with not only how much it does but how simple and refined it is. Even if for inspiration on your own edits, I suggest you give it a quick whirl.

I did have a play with Rumble's FW about 6 months ago - it was excellent then I have to say. My group prefers slightly less automation in terms of automatic HP adjustment and so on, because we often realise after the fact that they should have had combat advantage on this guy or that he had concealment or cover, or whatever, so we change the results of hits and misses a lot. That would mean undoing attacks and damage a lot using Rumble's FW. Plus of course the small matter of all the experience and familiarity we have with Veggie's FW over the months we've been using it.

[Blakey]

A bit more progress today:

maptool.jpg (493.98 KiB) Viewed 3573 times

As you can see from the picture my HTML monster frame now has attack, damage and recharge strings as links. Clicking on these will fire off macros to make the relevant attack, roll the relevant damage and make the relevant recharge check. With the macros I'm using underneath these links they check the target's relevant defence and report a hit or miss. They also report critical hits (natural 20's) and misses (natural 1's).

All this is autogenerated on the token by TokenMaker but these tokens are now getting specific to my framework - obviously these links don't work without the underlying macro and Lib: support.

I *think* I'm about at the stage where I can start using this application to generate monsters for my game now. Wow. I'll have to have a real think about how I want to set up my FW now I think.

Cheers
Blakey

[Blakey]

Over the last few days I've been toying with how to make TokenMaker work with actual game frameworks. I'm struggling to come up with an answer.

I've knocked up this PC frame, based on the monster frame I showed in the previous pics:

maptool2.jpg (405.16 KiB) Viewed 3545 times

This gives a sort of character sheet for the PC and allows him to make attacks and roll damage by clicking on links - exactly the same way that I do with my monsters. This is quite neat, is visually effective and gives all the PC's stats and data in one place. Plus with this frame working you don't need any macros on the PC itself at all.

However there is one big flaw. It doesn't have a way to record what powers are used. All the other good frameworks out there change the colour of the macro button when the power they represent is used (for Encounter and Daily powers anyway). Seeing as mine are just links, there is nothing to change. I'm really not sure how to get around this either as all the HTML you see in that frame is generated by TokenMaker and not really designed to be altered on the fly.

I've spent some time thinking about maybe ditching this approach for PCs and trying to generate full on Veggie compatible PC tokens (seeing as my framework is still pretty much the same as Veggie's on the PC side of things) but that could be really difficult to do.

So, I'm still trying to figure out where to go from here...

[Rumble]

Updating power usage should be relatively easy to do. I understand that you generate the HTML up front, but if you can generate macros you can get it to record power usage - and all I'd do is put a checkmark or a big X in front of the power name.

How I'd approach it is this:

1. Create a property on the token (since you're making the token) that is a JSON Object with the keys being the power names, and the value being 1 or 0. E.g.

Code: Select all

Powers: {"Twin Strike":0, "Hunter's Bear Trap":0, ...}

2. When you generate the dice roller macro, put in a call to refresh the frame as well, which passes an argument of the power name you just clicked and a 1 to indicate that the power has been expended - use this to set the value of the corresponding key in the power JSON object. I don't know what the dice roller looks like, but something like this:

Code: Select all

[macro("ReloadFrame@TOKEN"):json.set("{}", "Hunter's Bear Trap", 1)]

3. At the top of the macro that summons the frame, before any frame & html is generated, use that argument to set the Powers JSON to expend the appropriate power.

Code: Select all

[h:powerClicked = json.fields(macro.args)]
[h:isUsed = json.get(macro.args, powerClicked)]
[h:PowerTracker = json.set(PowerTracker, powerClicked, isUsed)]

4. Reload the frame. In the frame, in front of each power, just put something like:

Code: Select all

[r:if(json.get(Powers, thisPower), "<b>X</b>", "")]

I realize that adds in a bit of stuff, but it doesn't seem like that much and it should be addable by your token maker, and it will provide limited, but functional power use tracking. Obviously, I left some details out - you'd need to make sure you establish the proper variables and so forth, and it does assume that the token maker can actually identify the powers and not just format text-that-looks-like-dice-rolls, and so forth.

[Blakey]

Hey Rumble,

I'm sorry but you lost me there. I think my macro-fu is too weak to really get what you're saying.

This is my current macro to throw up the Player stat card frame:

Code: Select all

[frame(\"PlayerStatCard\"): {" + html + "}]

Actually that's a snippet of the java that builds it but you get the jist. The "html" bit is basically built by me to look like a compendium entry for a monster but with all the powers the PC knows put into the html. I then do a little search and replace on all the power html to look for "+16 vs Reflex" and replace it with a call to a macro in MapTool on my Lib:Blakey library token which rolls the dice.

I think you're suggesting adding in some macro code to the HTML for each power which says "maybe display an X here, depending on a property on the token. I get that bit. I get adding the basic properties to the token up front too.

I think the bit I'm confused about is the middle 2 points. Can you expand a bit?

Cheers for the ideas!
Blakey

[Rumble]

Sorry about that. It's kinda hard to do it without seeing the exact HTML, but since you are inserting macroLink()'s into the code as it is (for the dice rolls), it shouldn't be too hard to do the rest.

So, okay - in your variable html, you set up a page to look like the compendium entries - which is awesome. You're also adding in links wherever there's a diceroll, using the macroLink() function, so basically it's a matter of adding in a few more macro commands in addition to the HTML.

So, step one is to create a new property on your tokens, called something like "PowerTracker". The value of this property should be a JSON Object in the format powername:value - where the value can be a simple 1 or 0. This property is what records whether a power was used, and is consulted whenever the token's statcard frame refreshes.

Step to is to embed the updating of that JSON Object, PowerTracker, when you click a button. There are several ways to do this but I think the simplest for your purposes might be to modify the variable html to include a couple extra commands. At the top, before any actual html code, you'll want to add something like:

Code: Select all

[h:args = macro.args] <!--just for convenience-->
[h,if(json.type(args) == "ARRAY"),CODE:
{
   [powerClicked = json.get(args, 0)]
   [PowerTracker = json.set(PowerTracker, powerClicked, isUsed)]
}]

<!--rest of the HTML for the frame follows here...-->

That section is run every time the frame initialized, and it checks for an argument being passed to it. If the argument is a JSON Array, it "knows" a power roll has been clicked. If so, it gets the power name from the first element of the array, and sets the corresponding key in the PowerTracker variable to 1 to represent the power being expended. I use an array here (even though it's only sending a single element) because I can do a type check on it.

Okay, so there's that. Now, in the HTML, I see that you can format a power's name differently, so clearly you know how to identify the power name. Assuming you can identify which dice roll goes with which power name, there are two things to do. First, what you append to whatever macro the dice roll link calls is something like this:

Code: Select all

[macro("ShowStatCard@TOKEN"):json.append("[]", powerName)]

The above code assumes a few things - one, there's a macro on the token that shows the stat card. I don't know what it's called, but "ShowStatCard" is a reasonable guess. Also, it assumes, you can identify the power that the diceroll applies to, and can put that value in a variable.

Second, embedded in the HTML code next to each power name, you have this macro code:

Code: Select all

[r:if(json.get(PowerTracker, powerName), "X", "")]

What this does is every time the frame is loaded for a token, it looks at the PowerTracker JSON object. For every power, it checks the corresponding key in that object, and if the key's value is 1, then it puts an X in front of the power name. If it's 0, it leaves it be.

What will happen then, assuming it all works, is this:

1. You load the frame. Since it's the first load, macro.args is not an Array, so nothing happens except it loads. All of the powers should be un-used.
2. Click on the power's dice roll link. This launches the macro that rolls dice.
3. The macro that rolls the dice also then calls the macro to re-launch the stat card. However, this time it sends a JSON array containing the name of the power that was just clicked. The code at the top of the HTML quickly sets the value for the power in PowerTracker to 1 (meaning used), and then continues.
4. When MapTool renders the HTML, it checks each power against PowerTracker, and if the power is used, puts an X in front of it.

It's not the only way to do it - if you would like, I'll take a look through your code and see if I can implement something like it? I don't want to step on your toes, though!

[Rumble]

After looking through the code, I realize that you could put most of the processing (namely, the updating of the PowerTracker) in the macros on Lib:Blakey, and not have to do too much with the frames themselves. However, I can't tell whether there's connection between the name of a power and a specific dice roll, or if you're just doing "replace all dice rolls with links." I gather it may be the latter.

[Blakey]

After looking through the code, I realize that you could put most of the processing (namely, the updating of the PowerTracker) in the macros on Lib:Blakey, and not have to do too much with the frames themselves. However, I can't tell whether there's connection between the name of a power and a specific dice roll, or if you're just doing "replace all dice rolls with links." I gather it may be the latter.

I'm doing a search and replace yes, but in the case of Player Powers I process them actually one power and in fact one weapon/attack at a time for each power. At the moment the weapon entry doesn't know which power it belongs to, but there is no reason at all why it shouldn't do so.

In other words I could easily replace "+16 vs AC" with a macroLink call which included the name of the power. In fact I was going to do that anyway because when you click that link I wanted to output the name of the power being used to the chat window, so there was better feedback in the chat window.

I've had a look through your more detailed description and it does make sense to me, thanks. I'm a bit short of time to work on this right now but when I next work on TokenMaker I'll see if I can't get something like this to work.

Cheers for the advice and help!
Blakey