D&D 4E Power Macro API

[Kizan]

I've really enjoyed using your Lib:TKText in many of my games. It's worked out very well. Saves me and my players tons of time!

I have had one suggestion. Several people have commented that their chat window background isn't white. The Lib:TKText doesn't define the text color (foreground/background). Would it be possible in the next version of the tokens to add the code that will define the text background and foreground?

On the other hand should it just be assumed that if you want to use Lib:TKText that you are using a white background and black text?

Thanx,

Kizan

[TK]

I don't like assuming, I think forcing the background color to white makes sense. Unfortunately shortly after work letting up for a little work got all crazy again, so I've been put on hold for a bit, but will definitely make this change when I start up again.

[jfrazierjr]

Honestly, I would love if the end result was common property set that each framework could utilize. While I have my favorite framework, each is missing something that the others have and I would like to be able to do some modifications to make my own in the way I need things to work (talking about targeting) and having the properties consistent would make things 1000% times easier. It would also be a huge boon for Character Tool once Jay finally finishes it since it could export a single token that has everything needed for any framework to just work.

[TK]

I agree with that as well, it would certainly help make things more modular, and modular is always good. However, it would also make it much harder for the current contributors since the people who have already made their frameworks would have to re-write a significant portion of their code to conform to a different standard. I'd be totally willing to help get a standard made, but it'd really be up to the others if they want to revamp their systems.

[mezryn]

Our group is about to begin a new campaign, and I've been using the old framework. Going forward with 1.3.52 and above, is it possible to use both the old framework and new 4E API? The one big issue I ran into last was with using {1d4} type weapon variable rolls within [] brackets that I think I'll just need to manually adjust in each macro (maybe I was doing something wrong?)

[Veggiesama]

I agree with that as well, it would certainly help make things more modular, and modular is always good. However, it would also make it much harder for the current contributors since the people who have already made their frameworks would have to re-write a significant portion of their code to conform to a different standard. I'd be totally willing to help get a standard made, but it'd really be up to the others if they want to revamp their systems.

Rather than having those of us framework writers reconfunk our code to make way for a standardized format, what if a standardized data format was written, and we wrote conversion macros to make it work in our frameworks?

If each power was provided as a JSON object, I know I could twist it into a macro button that would be recognized by my framework.

Yes... there would be compatibility problems... some information might be lost, maybe a warning popup or two, etc. but on the whole I think it'd work. For instance, my attack object is a little different from your attack object a few pages ago, but as long as I understand how yours works, I could easily work it into one of my attack objects, because it looks about 80% the same.

[Craig]

I agree with that as well, it would certainly help make things more modular, and modular is always good. However, it would also make it much harder for the current contributors since the people who have already made their frameworks would have to re-write a significant portion of their code to conform to a different standard. I'd be totally willing to help get a standard made, but it'd really be up to the others if they want to revamp their systems.

Rather than having those of us framework writers reconfunk our code to make way for a standardized format, what if a standardized data format was written, and we wrote conversion macros to make it work in our frameworks?

If each power was provided as a JSON object, I know I could twist it into a macro button that would be recognized by my framework.

Problem with this is when the powers are executed they need to know where things like Strength, Dexterity, etc are located. While it is possible to pass these values as JSON objects to the power API its not the best idea, simple properties like these should always be stored as token properties, there is no reason not to do so, and if you start storing things like this as JSON arrays/objects or string lists/property lists you start slowing down your macros significantly.

At the moment there seems to be a trend for complexity for complexities sake, this would be a good opportunity to go back towards using token properties where ever possible. As a bonus using token properties makes it easier for people who just want the powers and not a frame work.

For those that want to keep using complex objects for everything in their frame works they can still do so, all they would need to do is provide properties with defaults that calculate that field although you would gain none of the speed benefits this way

[PyroMancer2k]

You know me I just can't stay away, even when I should be doing work . Anyhow the whole conversation about making the powers compatible with different token frameworks and not wanting to constantly be passing them the stats which most likely has security issues anyway since players might edit the values being sent .

It got me thinking what about making it so that the Lib:Token can be set to look at different locations on the calling token to thus allow it to work with different frameworks as well as keep the data being pasted around secure from less then honest players . This way you can program all your Power Macros on the Lib:token and the person setting it up for their framework only need to change a few options which then affect the whole token. Now before you go oh that's gonna be too hard just wait cause I already went and made an example which I think will do the trick nicely.

Granted I am still limited on time so I through it together quite quick and just used Basic Token Props to test it but it works.

Here is example campaign
http://www.savefile.com/files/2077761
or
http://rapidshare.com/files/221545105/C ... work.cmpgn

How it works is quite simple the Lib:Token looks at a variable on itself which has name or some form of get command to where the value is located on the calling token. It then looks at that spot on the calling token and gets the value from it. This way a DM can simply change which variable name is in that slot thus changing all macros on the token which use it as a reference point.

EDIT: The test shows off StrProp and I did test it with just variable name which also worked. But I figured I should do json objects as well so I went back now and did a get.json() test and it also works fine. So it should work with any persons Framework as long as they enter the correct command in each spot when you finish with the API, assuming you use this type of setup.

[Craig]

It got me thinking what about making it so that the Lib:Token can be set to look at different locations on the calling token to thus allow it to work with different frameworks as well as keep the data being pasted around secure from less then honest players . This way you can program all your Power Macros on the Lib:token and the person setting it up for their framework only need to change a few options which then affect the whole token. Now before you go oh that's gonna be too hard just wait cause I already went and made an example which I think will do the trick nicely.

I still think the standard property solution is by far the best, I still can't see a good reason for not going with simplicity. The solution for too much complexity is rarely adding more complexity

[PyroMancer2k]

I still think the standard property solution is by far the best, I still can't see a good reason for not going with simplicity. The solution for too much complexity is rarely adding more complexity

Yes but like so many things we are not able to simply choose which way is "best". We are stuck with choosing which way is most flexible at interfacing with people's needs. A lot of different frameworks have popped up all using their own setups and while going back to a simpler property setup maybe more preferable for some odds are it's not gonna happen.

Speaking for myself I don't have time to redo my whole tokens to change how they handle things. And I'm not sure how the others would feel about overhauling their tokens to meet some kind of standard. The issue of inventory alone which would be required to access for use with weapons and implements is handled very differently from framework to framework. This alone I think would cause a bit of a major disagreement.

Once the strProp and List first came out they allowed for tons of options not previously available which quickly caused everyone to break from the "standard" as they tried their own methods for doing things using these new data structures. The topic has come up several times about merging things into a "standard" token type again but no such luck has come from it. And I have doubts that it will change. I think it would be nice to see but given the amount of work involved for all the people to rework their tokens it seems a bit unlikely.

My understanding of TK's goal is to make power macro API that will work with the multiple frameworks out there, if I'm wrong feel free to correct me. And if the different frameworks aren't going to all change to a single matching variable setup the options from there on out are limited. Even if he arbitrarily declares "This is the variable setup you will be using with my API." there are gonna be some left out because curtain frameworks don't have that setup.

So while it's not "optimal" to use my approach or the passing of variables to a macro approach there doesn't seem many other viable alternatives if you want the API to be able to work with different Frameworks.

[mezryn]

Has anybody found an easy way to modify the PC Skill Checks macro in TK's 4E system to incorporate the new execLink/macroLinkText functions in order to make the skill checks hidden to GM only?

[neofax]

I know TK doesn't stop by here much, but I was wondering if anyone knew how TK extracted the info from the UCS database? If he wrote a program that pulls the info, I would like a copy so I could add the rest of the data for Arcane Power and such.

[TK]

I made a database with some VBA code over it to do the heavy lifting. If you copy the set data (open the set "zip" file and just copy all the text) into the table named Set, then the database should automagically take care of the rest (Form "crunch" has the magic button). One note, I currently have a few key lines commented out since they take a long time to run and only need to run when the set table changes, uncomment out lines 47-53 if you do a reload of the set table. Some of the keywords now are more than one word long, which will mess up the results a little. Anyway, feel free to play around with it. My main problem is that I ran out of ideas on how to turn what I have into something more useful. That and whenever I think work is going well it gets really terrible again. Anyway, I posted a (zipped) version of the database, it unzips to over 100 megs, so buyer beware. People are welcome to make any changes and distribute, but may not sell or otherwise make money off it.

My apologies to those who I let down by sounding really exciting and then not delivering.

http://dl-client.getdropbox.com/u/36446 ... ers/PC.zip

PS, I've subscribed to this topic now so if you post something here you'll get my attention

[neofax]

TK,
I am having problems adding any new data past the original set. I am getting errors with null values.

[emperor799]

I dunno exactly what that error is off the top of my head, but:

Remember that in the token's properties you have to have value 0 rather than a blank to represent zero.

Make sure you filled out any and all properties the power macro is calling on.

And make sure you spelled the property correctly.