Suggestion for the toolkit (re: powers)

[chip]

1) allow power import/export in tab/comma delimited format.

i love the tool as it's a real timesaver with the charclass i'm creating. . However, a very simple tabled format is simple enuf to allow you to 'toss down' power ideas without getting caught up in formatting or the general details . . . i created a power-maker utility using php+mysql specifically so i could put in a title, flavor text and a basic note of what it did. It also has all the necessary fields etc so that later on i flesh out the power. But when you're brainstorming, you just kinda want to get the basics down and then move on to the next idea.

by doing import/export, ppl can use whatever they want to build the quick n dirty, then import the skeleton data to flesh it out in your tool.


2) a "Use" checkbox per power. Only if a power is Checked should it be includes in the export/compilation.

Great tool, where do i send a donation?


[edit]
3) add a custom "power types" and "Attack Subtype" data file. I would go so far as to suggest that any dropdown list should read from a data file.

3a) did you consider combining all the data files into 1 file? just for reduced footprint sake.

[LoganB]

Hey chip,

Thanks for the feedback!

If you'd like to donate, head over to http://www.playwrite-blog.net/ and hit the Donate button in the top right corner. Of course, all donations are greatly appreciated and do help keep me motivated. :)

Now, I'll see if I can address your ideas:

1) A CSV import feature sounds like an interesting idea. I'll spend some time investigating it and see what I come up with.

2) Are you referring to the Class Creator and its Feature/Power boxes? If that's the case I can see the usefulness and I'll investigate this also.

3) The text files currently available don't have an effect on any of the other data for a power, so it's easy to add custom ones. Attack types and subtypes are a little different though, and would probably require a different file format to work correctly. Some functions related to Attack types are also hard-coded.

That doesn't mean I don't like the idea! If demand is low I can probably add these in myself to the main program.

3a) Definitely possible. Originally, you could only have custom power sources so there was only a single file. With the five or so now it does look a little "messy". I'll have a think about combining them without complicating the process of adding custom data.

[chip]

yeah i saw the donate button a min ago . . . sent from headbags studio. GET SOME BEER. (=


only other suggestion i have until i play with it some is to make the link to these forums from the blog a little more prominent.

thanks for what looks like it's gonna be a really good tool.

[LoganB]

Donation received. Thank you. :)

Yes, the forum does deserve more attention from the blog. I might have to do some reorganising of the side bar...

I've also put some more thought on the CSV feature. I'm thinking the first implementation will focus on the basics (name, flavour text and the basic note that would likely be imported to the "Hit" text box). It's even possible to throw multiple ones into the same CSV and have 4ePT import the file and convert each entry into 4ePT-compatible XML.

Example format:

Code:

Kick,You kick your opponent in the head,1d6 + Dexterity modifier damage and fall prone
Punch,You punch your opponent in the head,1d4 + Strength modifier damage and +1 to next attack
Stab,You stab your opponent in the head,[1W] damage plus 1 damage next round

How does that look? Alternative, line-by-line read might be faster for someone to put together:

Code:

Kick
You kick your opponent in the head
1d6 + Dexterity modifier damage and fall prone

Punch
You punch your opponent in the head
1d4 + Strength modifier damage and +1 to next attack

Stab
You stab your opponent in the head
[1W] damage plus 1 damage next round

Carriage returns would separate the entries.

[chip]

i think you should keep it as simple as possible for best cross compat. i don't think you should limit the number of fields...that kind of defeats the purpose of import (reduce work) try to pull in all fields and if one is empty, leave it empty. a sample document will be necessary so ppl can make sure their data lines up with your input filter.

[LoganB]

My only concern is that each power has about 30 fields... and that doesn't include secondary or tertiary attacks!

You'd have to use the sample doc for every power you made just to make sure you have the whitespace right. In the time it takes you to wipe out all the entries you're not using and check the line-up, you probably could have copied/pasted the text into the GUI.

Alternatively, I might have just completely misunderstood what you're asking. If that's the case, I would help if you could post a short example of what the file would look like. :P

[chip]

no you have it exactly right. it might be a pita to get it lined up with any current document you have. . . but if you have even as few as 10-15 powers already written, it would be less of a pita to clean up your doc to match the example than to paste fields 1 at a time.

i have to admit my suggestion isn't without some intent. over the fall, i'd written an app using php/mysql to track powers for a class i've built but your app is far more refined than mine (my output sucks... it's very dry) cuz it was built more for input and editing rather than final playability. i've got a list of probably 100 powers that i'm not really looking forward to retyping.

[Arlen]

Hey, I could retype a portion of it for you.  I like making powers on this thing.  :)

[LoganB]

@chip: Well, if that's the case I can probably just whip up a custom tool to import it all for you instead of integrating it into the program.

It'd be fairly barebones so it shouldn't take long to put together. If you can post or email me an example of the input, I can start work on it. :)

[chip]

i see that i didn't mention keeping it separate, but i'd considered that earlier. it would probably be the best thing overall. its the kind of thing that gets written, has 1 round of debugging and never changes again. i will pm you on it.