Dynamic Character Sheets

1356789

Comments

  • Micah
    Micah
    Posts: 894
    giftedmunchkin - I've added you. feedback welcome.
  • Micah
    Micah
    Posts: 894
    I've added direct input textareas to allow you to edit the html, css, and js for a DST. It's pretty barebones, but functional. We'll figure out some way to handle images in the future. For now, if you need images, just reference them from an external server.

    I'll roll it out to production tonight when we do our maintenance update (around 11 Eastern).

    This should allow for DST authors to move much faster to create stuff.

    For now, creating new DSTs is locked down to people in the beta program, although anyone will be able to browse around and view the DSTs that are available.
  • Micah
    Micah
    Posts: 894
    Just rolled out the direct input for the DSTs. Check it out at "http://www.obsidianportal.com/dynamic_sheet_templates":http://www.obsidianportal.com/dynamic_sheet_templates

    Right now there is only Pelwer's and Chainsaw's sheets. We're still ironing out the issues, but this should make it easier to play with things.

    FYI: I still don't have the approval process fully figured out, so just ignore it for now. We'll get to that in the future.
  • pelwer
    pelwer
    Posts: 18
    Micah,

    This is so sweeet!

    I found one interesting behavior with the tool kit ( not the new direct input pages )
    SW has a skill called "Notice" and when I set up the sheet, that skill always had wierd formatting.
    I'm guessing that ds_notice is a reserved variable, cause when I change this:

    span class="dsf ability_skill_score" id="ds_notice"

    to this

    span class="dsf ability_skill_score" id="ds_notice2"

    everything looks as expected.

    If ds_notice is a reserved word, you will probably want to add that to the DST developer tool kit along with any others.

    Nice job on the direct input.

    Pat.
  • pelwer
    pelwer
    Posts: 18
    Micah,

    I tried to get the Bio/GM Info to show in the sheet and it's not coming up.
    Not sure if I'm calling it right. Here's a code snippet from the bottom of my html:
    Changed tp []

    [div class="bio_gm_info">
    [div class="bio"] Bio: [span class="dsf" id="ds_bio"][/span][/div]
    [div class="gm_only"] GM Only: [span class="dsf" id="ds_gm_only"][/span][/div]
    [/div]

    Let me know if I missed anything.
    Example character is here:
    http://www.obsidianportal.com/campaigns/shadora/characters/prospero

    thanks,
    pat.
  • Micah
    Micah
    Posts: 894
    Patrick,

    You don't want to insert the entire devkit HTML into the HTML template box, only from the "" and down, not including the and . The surrounding html is there just to make the devkit valid and usable. I've updated the HTML template to just include the right html.

    The bio thing was my fault. I wasn't inserting it correctly. That's fixed now.

    Take a look at "this character":http://www.obsidianportal.com/campaigns/lorem-ipsum/characters/savage-dst You'll see the bio is inserted correctly, links and all. I also double-checked with "your prospero character":http://www.obsidianportal.com/campaigns/shadora/characters/prospero and it seems to be working there too. Awesome!

    I'm going to skip the gm_only section for now. I have an idea on how to do it so it only shows when the GM is viewing. You can leave it in the DST but it will be blank for a while.

    I'm also pondering the versioning and wondering if it will be useful. There will have to be some kind of approval process for changes to DSTs, but that might not require any kind of funky versioning. So, don't worry about incrementing/updating versions.

    Overall, this is shaping up to be really cool. Your sheet looks great. I'm sure Savage Worlds players will be ecstatic to start using it.
  • pelwer
    pelwer
    Posts: 18
    Micah,

    Thanks for the how-to on pasting in the HTML.

    For the GM Section, I just moved it to the bottom of the sheet. Will save space since the player would never see it.

    Added Prospero's portrait to the sheet - looking good!

    pat.
  • ChainsawXIV
    ChainsawXIV
    Posts: 530 edited May 2010
    I'll have more to add tomorrow night, but one thing I wanted to bring up this evening, so it can be considered sooner rather than later. I've been working on getting my Exalted sheet up and running, and one minor snag I've run into is that you're loading data into the sheet by id (characters.js, line 36), but saving it out by class (characters.js, line 73). I would suggest doing both by id. It would be more consistent for one thing, but more importantly, it would allow for fields that shouldn't get the jeditable functionality (currently done by class, using the same class that's matched by the save code), but still get saved, such as my pips data.
    Post edited by ChainsawXIV on
  • pelwer
    pelwer
    Posts: 18
    Micah,

    Could you please add my players (spc, farringtonss ) to the beta so I can have them test my sheet?

    thanks
    pat.
  • Micah
    Micah
    Posts: 894 edited May 2010
    Pat - Added them both. Let me know what they think.

    Chainsaw - I've updated characters.js to include an explicit public/private interface. This way you can call something to rebind fields, and I'll do my best to guarantee that it won't change. I've updated your DST, but I'm guessing you have a locally saved copy that you're pasting in. The thing to look for is anywhere you're calling a "aisleten.characters" function. Look in the new characters.js and you'll see the public/private interface laid out. If there is anything you'd like added to the public interface, let me know. For the record, here's the line I added:

    aisleten.characters.bindAllFields('chainsawxiv', oOptions['containerId']);

    The reason we save by class is that it's much easier. When we load from the server, we can infer all the ids from the field names. When we are saving, there could be new fields added. So, we just rely on every field having a specific class. jQuery makes it very easy to iterate through all those elements with the class and save their values. It may seem inconsistent, but it's a pretty standard jQuery way of doing things.

    If it makes sense, I could add another class "dsf_editable" to represent editable fields. When saving, anything with "dsf" or "dsf_editable" will be saved. When binding for jeditable, only fields with "dsf_editable" will be affected. Would that work?

    Also, I hate to be a stickler, but I'd like you to stick to the namespacing scheme with your function and variable names. I see that you're namespacing with "cx_", and to stick to the convention it needs to be "chainsawxiv_exalted" If you'd like a shorter slug, we could go that route too. Plus, variables like oOptions will also need to be namespaced.

    h3. CSS Namespacing

    Finally, I think I'm going to be even more iron handed and enforce some kind of namespacing on the CSS, to prevent issues with the main site's stylesheet. The easiest way to do this is to add "div.ds_chainsawxiv_exalted" to all your CSS rules, as that is one of the classes of the surrounding div. All DSTs will be contained in a div with a class of "ds_SLUG"

    Once the approval system is in place, I'm going to be iron-fisted about enforcing the namespacing rules, both in terms of javascript and CSS.

    h3. Final round of changes

    This has taken much longer to get out than I had hoped. In many ways it's a good thing, as the final product will be more polished. However, I'm much more of a patch-the-ship-as-it-sails kind of guy (hence the reason much of the site feels half-done), and I hate to sit on a feature like this and not release it. So, let's do a final review on this and then flip the switch.

    On my TODO list, I have the following:
    * Update to add the "dsf_editable" class.
    * Add the approval system
    * other?

    If there's anything else you want from me, let me know now. I can't guarantee anything, but I'd like to know if I've left anything important undone.
    Post edited by Micah on
  • Micah
    Micah
    Posts: 894
    Come to think of it, I also need to update the page layout so that the DST is shown at the top, and the other fields are hidden. Plus, I suppose I need to finalize the width, but that's not absolutely necessary.
  • ChainsawXIV
    ChainsawXIV
    Posts: 530 edited May 2010
    Heh. No fair looking under the hood while I'm working on things. :p I was using some short hand in my name spacing while I was working, but the intention was always to find and replace the long version in before final submission. That's done now, and if you look again you'll see it's now fully implemented (along with CSS name spaces).

    For the dsf_editable class thing, I'd suggest doing a no_jeditable class or something like that instead, as fields that people _don't_ want to use the functionality should be the exception rather than the rule.

    For the overall width, I've found that 730px is good for the area, at least in view mode (the edit move seems to have a little more padding in the content area). That's also the standard width that works for wiki pages, so it's consistent.

    Here's a list of other outstanding issues I'd like to see addressed:

    * I strongly recommend you expose the Submit string for jeditable (characters.js, line 174) so we can customize it. You can just expose it as a property of the object to be set, ideally.
    * I would like to see classes added to the automatically generated jeditable _form_ and _input_ elements, so those can be styled as well. This can be done by selecting the whole tag type, but that's not ideal.
    * I would also like to see classes added to the _a_ tags generated for the fields that are automatic links (name, campaign, and so forth). Same thing as the above.
    * I would also suggest adding a second style sheet field, for a sheet which is only used in edit mode. This would allow us to do things like :hover styles and cursors for editable versus static text.
    * I might recommend removing the error catching in the main script (characters.js, lines 325 - 329), since it provides no feedback and stops some normal error reporting that would.
    * I strongly recommend simply returning to the submit page when submitting code changes. The current page you go to after submitting is pretty pointless, and I almost always just click _back_ from there.

    Finally, regarding sharing code, I think he best way to do that would really be by hand, as submissions will probably be pretty rare. I'd suggest just taking submissions of well made code with documentation, and integrating them into the common page script. Then anyone could use them on any sheet. I've got a little more re-factoring to do on my stuff before it's as self contained as it needs to be for this (specifically, I'm using a global options variable for ease of reference, which isn't as self contained as it needs to be, given the name spacing), but it should be a snap to integrate once that's done.

    Edit to add another suggestion:

    Allow and detect an object passed in to the bindAllFields function as an alternative to a string in containerId, and use that object as the context for the operation. This will allow for efficiently rebinding only the area of the sheet that has changed (which you can currently do just fine by passing an Id string for that area, as seen with my lists at the moment), in a way that won't break if you ever choose to go id-less.

    Speaking of which, if you want to go id-less (as it seems like you must if you want to show multiple sheets per page), then that would be a good thing to work out before going live as well. It seems like it would be pretty trivial to re-implement around class names instead at this point, but since it will require changes to all the HTML templates on file, it will only get to be a bigger hassle the more go in before it's changed.
    Post edited by ChainsawXIV on
  • Micah
    Micah
    Posts: 894
    Thanks for updating with the namespacing.

    * I strongly recommend you expose the Submit string for jeditable (characters.js, line 174) so we can customize it. You can just expose it as a property of the object to be set, ideally.
    ** Ok, will do.
    * I would like to see classes added to the automatically generated jeditable form and input elements, so those can be styled as well. This can be done by selecting the whole tag type, but that
  • Micah
    Micah
    Posts: 894
    Just deployed some updates:

    * Allow change of jeditable text and button text
    * Added a class "jeditable_input" to the jeditable input forms. Note, it's on the surrounding *form* not the input tag itself.
    * Added classes to each of the generated links (player, campaign, character name). I also added an internal inside the tag. This should allow for all kinds of funky styling. Note: I may add a dst_author field as well, so that each DST author gets credit for their work...plus bug reports ;)
    * Saving a DST now takes you right back to the edit form
    * DST javascript errors are sent to the Firebug console if it's found. This should allow for debugging, without causing the entire execution to fail.
  • Micah
    Micah
    Posts: 894
    As hoped, switching to classes instead of ids was actually pretty simple. I'll update the tutorial and devkit, but the basic rule is this:

    # Take all the "ds_FIELDNAME" id fields and turn them into "dsf_FIELDNAME" classes.
    # Remove all the "ds_FIELDNAME" ids.

    Keep everything else the same. For example:



    becomes



    Avoiding ids altogether in the DST should allow us to use any number of DSTs on the same page.

    I'll push the updated code to the server in a couple minutes. I'll update Pat's Savage Worlds DST (which will be a quick 2 minute fix), but I'll leave the Exalted one to Chainsaw.
  • ChainsawXIV
    ChainsawXIV
    Posts: 530
    Cool beans. I'll get it fixed up this evening then. :)
  • Micah
    Micah
    Posts: 894
    I've updated the layout of the DST on the page so it shows at the top instead of the bottom. Essentially, only the dynamic sheet and the gm-only info are displayed and everything else is hidden. It really looks good. I'm so excited. I'll deploy that tonight, along with a few other changes.

    I think I'll also add some more required fields to each DST:
    * dst_author - Will be a link to the profile page of the person who made the DST. Best way to give credit. Will have a class.
    * avatar_image - The uploaded image for the character. We resize to 256x256, but we don't square them, so it's 256px on the longest side, possibly (and often) rectangular. DST authors would just need to leave a spot for the image, and we'd insert the tag, along with a class for easy styling.

    The approval system is also coming along. Basically, all DSTs need to be approved, and any changes to approved ones will need to be approved. At least in the beginning, it will be me eyeballing everything. However, if it gets to be too much, I may recruit some of you to help out.

    I think we're in the home stretch. I can't wait to launch this!
  • ChainsawXIV
    ChainsawXIV
    Posts: 530
    I'm working on converting to the class based system now, and I've got it mostly working, but I've got a key question before I continue - will that no-jeditable class we discussed above make it in tonight? That would seriously simplify my life, as the jeditable functionality is now tied to the same class that's required to load the data, so all my pips and things are getting hijacked by jeditable. I could script around it, but it would be a pain, and I'd rather not if that functionality is coming.
  • OPAdmin
    OPAdmin
    Posts: 53
    Just hold off on things for now. I'll try to push the updates (including the not-editable stuff) tomorrow. I missed my window tonight, as I'm trying to get the newsletter finalized for tomorrow.
  • Micah
    Micah
    Posts: 894
    Hold of for now. I'll try to update everything, including the not-editable stuff tomorrow night. I missed my window for tonight as I'm trying to finalize the newsletter for tomorrow.
  • ChainsawXIV
    ChainsawXIV
    Posts: 530
    Just wanted to note a couple of quick issues that aren't noted above. You may have addressed these already, but figured it wouldn't hurt to mention them just in case they'd got lost in the process.

    * You still have to create the character, save, then edit, before the dynamic sheet option appears
    * When you select your dynamic sheet type, style sheets aren't loaded, and startup scripts aren't run
  • Micah
    Micah
    Posts: 894
    I'm going to work on the 2nd one (stylesheets and scripts when choosing a sheet), but I may punt on the first. It's a little more complicated than it sounds, and is not strictly necessary. I can fix it in the future.
  • Micah
    Micah
    Posts: 894
    Fixed the stylesheet/javascript not loading issue.

    If you put the class "readonly" on a dsf span, it will not be bound for editing with jeditable. I thought "readonly" fit a little better and matches with other similar HTML attributes.

    The approval system is in, but a little clunky. We'll just have to play with it. My hope is that once created and approved, there won't need to be a lot of modification to a DST. That's usually not the case, but we'll see.

    I'll deploy all this tonight. I made a lot of changes today, and there's a good chance I've broken something. The next day or so might be a little dicey.
  • Micah
    Micah
    Posts: 894
    Also, I'm still not 100% clear on the necessity for the readonly fields, but I trust you know what you're doing. Just in case others misunderstand the purpose, I added this section to the tutorial:

    =====
    *Readonly fields*
    If, for some reason, you need to prevent certain fields from being edited (like, for example, they're auto-calculated by javascript), you can add a class of "readonly" to the field. This will prevent it from being editable.

    However!! In most cases we recommend letting the user override any auto-calculated value. The DSTs are not intended to enforce any particular rules for a system. Let the users put in whatever value they want. It's their character, after all.
    ======

    I really don't want DST authors going overboard and trying to enforce rules of the system. All I'm looking for are pretty character sheets. I'll leave rules enforcement up to things like Herolab or WotC's builder.
  • ChainsawXIV
    ChainsawXIV
    Posts: 530
    Sounds good. To clarify, the _readonly_ class isn't strictly necessary to make things work for me, but it makes things simpler.

    Take my Pips inputs for example. I've set them up to simply convert any given span with the proper class to a Pips input, and then back again before save. Without read only, that same field was also jeditable, so when you clicked the Pips element, it would show you the text of the Pips image tag in the jeditable editing box. I could have worked around this by loading the values for each Pips element from the variable, and adding the proper classes just before save, but it's easier and cleaner to let the core script handle things.
  • Micah
    Micah
    Posts: 894
    Deployed the latest code.

    You might get some emails about submitted DSTs as I play with the submission/approval system.
  • Micah
    Micah
    Posts: 894
    I've gone ahead and approved the Savage Worlds DST by Patrick. Chainsaw: when you're ready, submit your DST and I'll approve it.

    Everything is still in beta, so we can take a couple days and make sure we're happy with everything.

    We're almost there!!!!
  • Micah
    Micah
    Posts: 894
    By the way, there are a couple layout issues with the Savage Worlds sheet, but I'll leave that to Patrick if he wants to fix it. It looks like a width issue, along with float.
  • ChainsawXIV
    ChainsawXIV
    Posts: 530
    What is the correct key to use for the portrait image? I tried copying the one out of the savage worlds sheet, but that doesn't seem to be it (though you can always paste an image tag in there...).
  • pelwer
    pelwer
    Posts: 18
    Micah,

    I fixed the Width and Float issues - sheet is looking ok now.

    CS,

    I just entered in the image tag html code

    Pat.
Sign In or Register to comment.

March 2024
Wrath of the Highborn

Read the feature post on the blog
Return to Obsidian Portal

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Discussions