Not signed in (Sign In or Register)

Discussion Tag Cloud

Vanilla 1.2.1 is a product of Lussumo. More Information: Documentation, Community Support.

    •  
      CommentAuthorMicah
    • CommentTimeApr 29th 2010 edited
     

    This is a place to discuss the dynamic character sheets (ie. DSTs) that we’re working on.

    READ THIS FIRST

    If that makes no sense to you and you have no idea what HTML/CSS is, then this thread probably isn’t for you. This is a very technical discussion, but it will hopefully result in something that is easy to use and requires no technical background at all. Once everything is in place, we’ll make an announcement about how to use the dynamic character sheets.

    But, if you’ve read the DST FAQ and have any questions or suggestions, then by all means please post. My hope is that all of us together are smarter than me by myself.

    Update: I’ve added the developer kit This should allow you to see what I’m working on and how it all works. Suggestions welcome.

    Update 2: As per suggestions, I have moved the dev kit to public code hosting on github This will be where all sheets are stored as well. Hopefully this will make it easier to collaborate.

  1.  
    If there's support for checkboxes, then getting a boolean out of the trained/untrained skills area should be easy. jQuery and plain old Javascript both have something for checking this. For example, here's the jQuery documentation for the :checkbox selector.

    http://api.jquery.com/checkbox-selector/

    If it's a text box, I don't positively know of a way off the top of my head to do it, but it'd probably be something about extracting the output and testing it against True or False. Anyone more skilled than I have better ideas?
    •  
      CommentAuthorMicah
    • CommentTimeApr 29th 2010
     

    The editing is very dynamic. We’re using jeditable to allow in-place editing. This saves us from having to define some kind of form for every sheet. Instead, just edit in-place.

    I think there is a way to set an item to use a checkbox, or even a select, using jeditable. I’ll have to dig in. This will probably end up being another class that you tack on to the span in order to force it to a checkbox.

    •  
      CommentAuthordylanryan
    • CommentTimeApr 29th 2010
     
    I've been working on a very similar system and am nearly complete. A few things to consider:

    1) it is often nice to have TEMPORARY modifications: a Druid with wild shape, some casting cats grace, etc. Nice to be able to change this in-game and see updated values for things like attacks, saves, ac, etc, but not commit the change to the page permanantly.

    2) it saves time to hve a common page that lists things like party Xp, hp, consumable items, that everyone in the party "imports". That way after an encounter, you (ie the gm) can go and edit 1 page and every character in the party updates. Saves a ton of time.

    3) it is very nice to have things that are dice rolls linked and clickable. For example, ether than say your attack is +4, make the +4 a link that uses JavaScript to roll a d20 and add 4.

    4) it needs to support house rules! What if someone uses pathfinder's rules as a base, but add a seventh ability score to the mix to measure, I don't know, sanity say. So, users/gms need to be able to add fields to pre-existing templates

    I have a framework that sounds very similar to what you have, that accomplishes all these things, already written and working (though I wrote it assuming only I'd ever deal with the code so it is very much not friendly to anyone but me to work on). It runs in firefox, safari (including iPhone), chrome, and opera at the least (other browsers not tested but anything based on WebKit should work, and there is no theoretical reason it would fail in IE, but I have had no reason to test it there yet). I'd be happy to donate code and ideas and experience on this front. I'm using this in 3 campaigns (pathfinder and 3.5 so far but my framework can theoretically support anything that uses math) and constantly refining it in what amounts to live playtest. I could easily make template pages for every core class in pathfinder/3.5 (and any other game if I went out and bought the rules, and I could refine my language so anyone can make pages for rules I don't have quickly) so people just plug stats in. I sent a link to an example in the email saying I'd be willing to beta test (my server can't quite handle many many hits so I do not want to post an example link publically yet)

    Ps sorry for any horrendous spelling. Editing this on an iPhone is not easy. I'll fix any errors when I get home. Please make things more iPhone friendly! I'd also be glad to help on that front!
    •  
      CommentAuthorMicah
    • CommentTimeApr 29th 2010 edited
     

    Dylan,

    We’re looking to be a lot less than what you’re describing. I don’t want to program a whole gaming engine, and it’s not meant to be interactively used. The goal is to simply provide a “pretty” character sheet, something that you could use at the table if you forgot your paper sheet. Or, another group member could use it to run your character if you miss a session.

    Temporary bonuses, dice rolls, and all that kind of stuff is out of scope at this point.

    Why? Well, we don’t want to be too locked down to any one system. Pathfinder and D&D are nice, but the whole galaxy of systems is much more varied. By starting modest, we can work our way up.

    I’d be happy to look at what you’ve got, though. I’ll take a look when I have a chance.

    P.S. I may take you up on your offer to be more iPhone friendly. We’ve got some ideas in that direction.

    •  
      CommentAuthorgnunn
    • CommentTimeApr 29th 2010 edited
     

    My skill with HTML is fairly limited, but I do have some experience in design, specifically for formats that require quick processing of information (esp. e-learning & museum exhibits) and as someone who started a group of newbie players using 3rd party electronic character sheets , I have learned about some features that can be very helpful/unhelpful from a visual presentation standpoint.

    Specifically, I learned that including a visual representation of the formula used to generate certain numbers (e.g. Final AC or to-hit numbers w/ specific weapons) can be very helpful in game, especially if players print out their sheets. WOTC does a very good job of this with the official D&D character sheets.

    For example, the official sheet lists AC as a sort of equation

    __ = 10 + __ + __ + __ + __ + __ + __ + __
    AC armor shield dex mod size mod nat. armor deflection misc. mod

    Seeing the actual formula spelled out this way does wonders for a sheet’s usefulness by helping players calculate any changes to their stats that might occur mid-game. I learned this the hard way, because since my players started with a sheet that did not include such visual breakdowns, it took them a lot longer to learn what numbers actually made up Total AC etc. Those who eventually switched to the official sheets consistently do better with in-game adjustments to their stats.

    Just food for thought, and likely something people will worry about AFTER they actually have their html set up.

    •  
      CommentAuthordylanryan
    • CommentTimeApr 29th 2010 edited
     
    I totally understand that, and that is how i felt too. Until I started programming it (I should state that I play mostly play-by-email games so these are our primary character sheets: We have no paper versions). But the point is, my pages are not specifically pathfinder or 3.5 or anything, just that that is what I have am using. I coded it to be completely ignorant of any specific game system, and then added "utility functions" that are system-specific. It can read an arbitrary dice expression ("d6+2D8+3"), figure out what it means, and handle it. And it is written so that a 1-line "assume D100s" could change +4 from meaning d20+4 to d100+4. With a little work (writing one JavaScript function and making a one-line "use this" change), it could even mean "draw a card from a standard playing card deck and add 4, counting facecards as 10" or "roll a d6, and roll another if it's a 6 and keep going, then add 4 at the end". Or any arbitrary JavaScript function that returns a number, so anything can be covered. I plan on shortly making Inquisitor (d100 based) pages, and there is no reason it can't adapt (and I mean easily adapt) to any system under the sun. Dice, cards, coin flipping(that's just a d2 of course), anything that a compeer can emulate. It works precisely because it doesn't know what system it is for. It just sees equations ("this thing called 'attack roll' is the sum of this thing called 'dex mod' and this other thing 'bab'. If any one of them changes, this should change to reflect that. The page is telling me this is a d20 roll, so let's make it a link too"). Anyone can make a template that has all the standard equations for the system built in that anyone can use (I essentialy have this for 3.5 and pathfinder but that is purely a function of current games I'm in), and if you wanted to use it for a game system you were just writing (ie that no one else could possibly know), you just write a few equations and lay them out where you want and it'll calculate them and spit out a fully playable sheet. And once there is a template for a game, the next character is just a simple "here are the stats, use that template, go" affair.

    From what I can tell, once a template with all apropriate equations was written, it would be just as easy to make characters as your system: plug in a page that says where things go, a list of stats, and go. The only difference is that each template page is game-aware and tells the underlying system that a modifier uses a d20 or a d100 or whatever. And it falls back gracefully to a non-interactive version in the case of a quick template that provides no equations dictating what is used for what.

    Anyway, just saying, I've done a lot of work on a similar, ultimately compatible version that takes it one step further. All the code is free, and I could easily adapt it to work with this framework.
    •  
      CommentAuthordylanryan
    • CommentTimeApr 29th 2010
     
    And I agree 100% with gnunn: Showing how numbers were achieved is vital (where copyright permits, of course). Seeing that your AC is 15 doesn't tell you anywhere near as much as that you have a dex mod of -1, a amulet of nat. armor +2, and some suit of armor that gives you +4, or what have you.
    •  
      CommentAuthorJimTriche
    • CommentTimeApr 29th 2010 edited
     

    That assumes they want a specific character sheet.

    I think something with a spot for stats, with an editable form, would be the ideal solution. Something the GM would have to do, then all the characters in a specific campaign would use the same sheet.

    If you use a system that doesn’t use Armor Class, why have the stat there on the sheets? Same for Hit Points or whatever else. They should be as generic as possible to ensure maximum potential for use.

    A customizable stats block area, skill area, equipment area, experience (or some synonym to express the analog) and background info and notes should be all the sheets have.

    Not to poke my nose in since I know nothing about markup, but for versatility, the more generic the better.

    <edit> I can also shut up since I just read the FAQ and now realize there will be multiple sheets…
    SORRY. </edit>

  2.  
    I think I like the idea of the DSTs better than a generic form the GMs make. It would allow the opportunity for nice looking character sheets for nearly any system, as opposed to the somewhat utilitarian sheet you're suggesting. And from what I've seen of the code (not a whole lot, just what's on the wiki), they're easy to make, so anyone can make one for their favorite system. Particularly with the rewards system in place, I don't think there not being a template for your system of choice won't be a problem for long.

    EDIT: You edited your post before I could post mine, sorry about that.
  3.  
    Sorry for the double post, but another thought - what about print stylesheets? Probably not necessary, since it's unlikely there will be over-elaborate sheets that won't by default print well, but being able to print off a nice, clean copy of your character sheet hosted at Obsidian Portal would be pretty cool.
    •  
      CommentAuthorMicah
    • CommentTimeApr 30th 2010
     

    A print stylesheet would definitely be a nice-to-have. It wouldn’t be too hard to work into the current system.

    •  
      CommentAuthorkwdav
    • CommentTimeApr 30th 2010
     
    This is a great tool! And I have 2 opinion:

    1. There should be 4 styles for the DST for player to choose: Middle Age (D&D), Classic (COC), Modern & Future (Star War)
    2. Additional pop-up page for DM viewing the basic status of the characters during gaming. Before showing the status, the DM should choose which status will be shown. And this will be prefect, if there is a simple initiative counting.
  4.  

    This all looks very promising. I definitely agree that the character sheets should not try to enforce the rules but rather just assist in filling out the fields, much like a PDF form. I’m definitely going to have to learn more about jeditable.

    I do think the CSS classes should have a namespace. The print stylesheet is a brilliant idea.

    From what I can tell, checkboxes wouldn’t necessarily have to go through jeditable. I would recommend using [input type=“checkbox”] with events to sync its state to the underlying JS Object. jQuery could easily find all checkboxes and bind these sync events.

    I’m looking forward to seeing how we’re supposed to implement the more dynamic behaviors, like having a list of arbitrary length (think D&D feats or multiclassing).

    Maybe there could be some standard mechanism to highlight dependent fields either while editing or when an edit is submitted. For instance, if I edit my Strength score, it could quickly show me that my Strength modifier, melee attack bonus, and Strength-based skills are affected.

    •  
      CommentAuthorMicah
    • CommentTimeApr 30th 2010
     

    Malfunction seems to have a pretty good handle on what we’re trying to say here. It’s not the be-all-end-all online game sheet, but instead just a nice looking, pre-formatted sheet.

    Dynamic behaviors like arbitrary lists could be handled with javascript, like adding new fields on the fly like feat_1, feat_2, feat_3, and just adding new feat fields every time the user clicks a “Add new feat” link or something. The downside is that it wouldn’t really be a true array, just a bunch of unrelated fields. I’d like to support arrays and maps and such, but we’ve got to start small. We’re also hoping to get some ideas on this front.

    We also don’t have any standard mechanisms right now for things like highlighting, but we can start to build some javascript/jQuery utilities. Plus, we have all the jQuery magic at our disposal, so things like animations and effects are possible.

    •  
      CommentAuthorgnunn
    • CommentTimeApr 30th 2010
     

    I agree printable sheets would be ideal, I know my players would not use them unless they could be printed. 4 of my 7 use printed versions of their electronic sheets at the table. I recently discovered an online character sheet that utilized the official D&D sheet layout, but decided not to tell my players about it, specifically because it couldn’t be printed.

    •  
      CommentAuthorMicah
    • CommentTimeApr 30th 2010
     

    I’ll add printable CSS to the list, but remember we’re depending on YOU to make the actual DSTs. I hope that’s clear here. We’re making the underlying platform, but we need community members to step forward and create the HTML and CSS. Creating a full-featured character sheet for each and every system isn’t something we can really do, so we’re asking for help.

  5.  

    At the risk of derailing to a discussion of the meta-system, how community-centric will this process be? How will you prevent someone from submitting a sheet that’s functionally identical to another sheet so they can some free Ascendancy? Will all contributions go through an approval process? Will templates be associated with individual user accounts, like campaigns are now with the DM(s)? It sounds like developers will be able to download others’ templates and build off of them. Will OP provide an avenue for cooperative development, like a public SCM repository?

    I like the SCM repository idea. If a community runs the show, it’s less for you to keep track of. Plus, it would do versioning for us and make branching easy.

  6.  
    I have downloaded the dev kit and am hoping to make shiny things with it as soon as I have the time.
    •  
      CommentAuthorMicah
    • CommentTimeApr 30th 2010
     

    I don’t have answers to a lot of these questions, as I’m just running ahead as fast as I can. I’m hoping some of it will shake out and be apparent in time.

    For now, there will be a manual approval process where you email me a DST, I look it over, play with it in dev mode, and then put it live in the system. I’d rather start manual and build an automated system once you guys overwhelm me with submissions.

    I can definitely see a public repository being a good idea. I hadn’t planned for that, but it wouldn’t be hard to do. I think there would be some good co-op opportunities, like if someone is really good with CSS/photoshop, but needs someone else to write the javascript.

    Templates will be associated with user accounts so that the original author gets full credit for it, something like a “Designed by so-and-so” at the bottom of each page using the template. I’m not sure how to handle multiple authors. Maybe everybody flips a coin to see who gets the credit.

    As for free Ascendant time, if you rip-off an existing one and it has no meaningful changes, you dont get squat. That’s why I said that step 1 is to email me and tell why the existing DSTs for a given system don’t cut it. If your reason is “I wish it were a different shade of blue” then I’m probably going to turn you down. However, if you want to make a separate character sheet for wizards vs rogues or something like that, then I’m definitely interested.

    These are all good questions. Keep them coming.

    (Also, I’ll be out of town next week, so my responses may be a little slower. I apologize for ducking out at such an exciting time.)

    •  
      CommentAuthorChainsawXIV
    • CommentTimeMay 2nd 2010 edited
     

    This is looking like a very cool feature, and I look forward to working with it. I’m certain I can cook up some good contributions to the list given time. As I like a challenge, I think I’ll start by trying to convert in a rather graphics intensive sheet I made for Exalted, but it may be a while before I finish it… If only you’d dropped this a couple of months ago, before I had my new job…

    Also, let me just say, hooray for style sheets, even if they are only for these sheets. Inline CSS is great and all, but doing fancy things like character sheets was getting a little bit beyond the sane man’s patience.

    •  
      CommentAuthorMicah
    • CommentTimeMay 2nd 2010
     

    Well maybe someday you’ll be semi-unemployed like me. Can’t pay my bills, but I can work on Obsidian Portal, which is more important than electricity and water, right?

    We’re working on making things more accessible and controllable. To be perfectly honest: You guys are better at this stuff than me. I’m basically blind when it comes to making things look good. I can work magic when it comes to databases and HTTP requests, but the end result always looks…well you all have seen the site.

    I’m really happy that we’re finding ways to let all of you bring your design skills to the forefront. Obsidian Portal looks good thanks to all your hard work adding such great stuff.

    •  
      CommentAuthorChainsawXIV
    • CommentTimeMay 2nd 2010 edited
     

    As a quick note, you should probably include OP’s standard Doctype in the dev kit’s HTML file, as it has a very significant impact on how some CSS is rendered. Doing so will save a lot of us going, “Hey! That’s not what it looked like on my machine!” down the road.

    On another note, any chance you could point me at the function I’ll need to call to store a field value, or save the values from dynamic_sheet_attrs (I’m not sure if you’re storing values individually, or re-saving the whole lot each time)? I’ll find it eventually, assuming it’s actually hooked up in the dev-kit code, but I’m not familiar with jquery, so it’s a bit of a slog.

    Edit More: Just to add, the save function mentioned above will also be very relevant when employing javaScript that dynamically creates fields on the character sheet, as mentioned above.

    Edit: An additional thought. If you could change the value of the submit string in characters.js to something like <button class=“submit_button”><div class=“submit_text”>&#10003;</div></button> (A button with a check-mark in it, with the necessary trappings to position the button and its contents using CSS), that would allow us to apply styles to the submission button, so it can be pretty too.

    •  
      CommentAuthorMicah
    • CommentTimeMay 2nd 2010
     

    These are all good suggestions. I’ll add the doctype and re-upload a newer version.

    There should be no need to call anything to save the values. Everything will be re-saved every time when the user clicks on save. The values from each field will be written to hidden inputs and then the entire form is submitted. There shouldn’t be a need to mess with any of that, but I could be wrong.

    If you’re looking to do things like update field Y when field X is changed, then you’ll need to bind to an event (using jQuery). In the sheet.js file you’ll see at the bottom where I’m binding to the “valchange” event. That’s a pseudo-event that I created just for this, it’s not a real javascript event. Whenever a field is changed, the valchange event is fired for that field and the new value is passed. That’s how the example sheet is recalculating the ability modifier scores and whatnot.

    I’ll see about the submit button. I’m still not sure how to integrate things like bio, which can have wiki links and textile formatting. Using the jeditable in-line editing to show and edit that text will be difficult. Plus, I’m not sure how nicely it will play with the MarkItUp editor toolbar we use. We’re getting into some strange areas here. The point of all this is that I may (at least in the beginning) leave in some textareas and other basic text fields (like name) on the edit form. They can be cleanly integrated into the display view of the sheet, but will have to be handled separately in the edit view.

    •  
      CommentAuthorMicah
    • CommentTimeMay 2nd 2010
     

    I just updated the tutorial with a list of required fields. There will be certain standard fields across all sheets, like character name, the campaign, the player name, etc. These will be handled somewhat separately on the backend, but it should be invisible when making a DST.

    I’m also considering adding some (well, at least 1) special HTML class: gm_only, or something like that. We’ll need a way to display gm_only notes on each sheet, but we don’t want to display it for non-GMs. Don’t worry, I’m not talking about writing it into the DOM and then hiding it with CSS (since that’s not much of a secret…) Instead, I’m saying that let’s assume you create a section for GM-only notes, and it has a header that says “GM Only”. I’m sure you’d rather that header not display at all if it’s not the GM viewing the sheet. We could accomplish this by setting aside a special class (like gm_only). Anything with that class is hidden if it’s not the GM viewing the page. Does that make sense?

  7.  
    Toying around with the dev kit, now, and I have a few questions.

    * This might be asking for a bit too much, but have you given any thought to Character images?
    * How are we supposed to deal with something like feats, where there needs to be a theoretically infinite list of possible values? What HTML should be put in there?
    * The title of the page - is there anyway that you could have the server change it to "[Name of Sheet] - [Name of Character]"? Or should I rig up a Javascript function to do it for me?

    Thanks in advance.

    Also, with regards to the click to save - right now, it feels clunky and unintuitive. I think people are used to, at this point, having the web save their changes with little effort on their end. It'll take time to adjust, and I'm not sure if they'll want to wait that long.
  8.  

    Ok, so making sure I understand fully, there will ultimately be a “Save” button, which writes the contents of dynamic_sheet_attrs up to the server, so a script that needs to record a value can simply add it to dynamic_sheet_attrs, and it should be good to go? Assuming I understand correctly, that will be nice and easy. Cool.

    Talking scripts, it looks like you use jquery almost exclusively in your own scripts. Personally, I don’t like to use it (and haven’t ever really learned it) because I find it cryptic, and I prefer rolling my own versions of most of its features anyway. Do you have any objections to our using scripts which aren’t written using jquery?

    •  
      CommentAuthorMicah
    • CommentTimeMay 2nd 2010
     

    We could do character images, I suppose. We can settle on a given size and then you could leave a space in the DST for the image. The actual image tag (or even just the src, I guess) could be inserted with javascript. Definitely possible, and not really all that hard.

    For feats and other “array-like” values, for now I’m thinking we just go with “ds_feat_1”, “ds_feat_2”, “ds_feat_3”, etc. With javascript, it’s not too hard to create a “add new feat” link that just inserts a new span with the number incremented.

    Hmm, another approach would be to name each value as “ds_feat[]” That would allow for real arrays. We’d need a way to create unique IDs, but allow for duplicate field names so as to have valid HTML. Let me double check on this, but I think it should be possible.

    What’s the goal of changing the title? I assume you’re talking about the title tag. I’m not sure I see the goal here.

    As to saving, we could make it so all changes are saved instantly, but I’d like to skip that for now. I’m personally not a fan of those kind of interfaces, plus it’d be harder to do. We can explore that later. We’re trying to take small steps.

    •  
      CommentAuthorMicah
    • CommentTimeMay 2nd 2010
     

    Chainsaw:

    The editing and saving should be 99% transparent to DST authors. That’s where jeditable comes in. It will allow for us to automatically insert input tags in place of span elements when someone clicks to edit something. That’s how the devkit works. Basically, all the DST author has to worry about is making sure that the spans have the correct IDs, and we do the rest. If I get a chance, I’ll try to update the devkit to make this a little clearer.

    Yes, I’ve become a 100% jQuery convert. I could gush for hours on how awesome I think it is. That being said, I have nothing against people using bare javascript if they so choose. However, I’m not sure how the event binding can be accomplished without jQuery. Basically, I need a way to be able to notify your javascript or call a function when the user changes a value. I know how to do this with jQuery (ie. event binding), but I’m clueless as to how it’s done otherwise.

  9.  
    The point of changing the title in my mind is that instead of showing "DST Dev Kit", for example, instead it will show "DST Dev Kit - Tordek" (or "Tordek - DST Dev Kit"). It's really a personal preference, but I think it would be nice if the title of the page showed the character's name, or even the campaign's name. If it's not something that you think should be implemented system-wide, then it shouldn't be difficult for the individual developer to implement something like this.
    •  
      CommentAuthorMicah
    • CommentTimeMay 2nd 2010 edited
     

    Ah, ok now I see. The devkit title is pretty much meaningless.

    The title for a character will be the same as it is on the site currently. For example, this character has this title “Alron Tarris | D&D 3.5 | Obsidian Portal”

    I suppose I should change that to include the campaign. The current title is a bit of a holdover from when characters weren’t fully integrated with campaigns.

    Anyways, don’t worry about that. The DST sheet will be part of the current character display, and so the title will stay the same.

  10.  
    Oh, okay, cool. I thought that the title was going to be static, based on the <title> tag of the DST. Good to know, thanks.
    •  
      CommentAuthorChainsawXIV
    • CommentTimeMay 2nd 2010 edited
     

    Micah:

    Cool, that should work great then. Thanks. I can handle my own events and such, so no problem there, I just wanted to know about the saving process since I’m building some non-jeditable inputs (like this), and wanted to make sure they’d save properly.

    Edit: Incidently, anyone could adapt that pips input in the example to work with whatever kind of non-jeditable input they needed. You could use it to do a textarea input, for example, with or without tool bar, without too much trouble I expect. With that in mind, it might be cool to have a wiki page of reusable scripts and such so we can share things.

    •  
      CommentAuthorMicah
    • CommentTimeMay 2nd 2010 edited
     

    Yeah, that pips control looks pretty cool. I’m fairly sure it will work for saving the value, as long as the underlying javascript updates the inner HTML value of an element with the id of “ds_essence”. I assume it will be some kind of numerical value? For example, something like this:

    <span id=“ds_essence” style=“display:none;”>6</span>

    The span is hidden, since it’s not the real control for managing the value.

    I’m just worried that there’s currently nothing in place to display it correctly in the sheet when it loads for display. As it stands now, when the sheet loads, it inserts all the correct values via javascript. Using my hidden span example above, it would insert the correct value, but it would only be in the hidden span. For this to work, there would need to be a way to call a javascript function after the values load to allow the DST author to do some display manipulation onload. I suppose that shouldn’t be all that hard. I can see about adding something.

  11.  

    I had the same concern, so my plan was to save the entire image tag to the value of the essence variable in dynamic_sheet_attrs direclty, so it would load naturally in both the edit and view modes. Like so:

    dynamic_sheet_attrs[‘essence’] = ‘<img src=“http://omnichron.net/external/op/src/pips-00-10.png” id=“test” class=“pips test” />’;

    The numeric values could be parsed out of the file path if needed. The only real obstacle to this is getting jeditable to ignore that field, but that would be easy to accomplish in any of a number of ways, like maybe adding a no_jedi class.

    I had assumed we wouldn’t be able to run scripts on the display end of the thing, but if you want to support that, that would make things cleaner, and open some interesting possibilities, like making sheets with tabs. With that I could store simple numeric values, and just run through and convert them to pip images on load.

    •  
      CommentAuthorMicah
    • CommentTimeMay 2nd 2010
     

    I would much, much prefer to store the numerical value and re-work that into the pips on display. I want to store the data as semantically as possible, since one ultimate goal is to allow some fairly complicated searching. Think along the lines of “search for all characters with essence between 5 and 8” or something like that. If essence is numerical we can do it, but if it’s an image URL then that’s out the window. Plus, we’re not going to write custom handlers to parse out values and such, since that would kind of sink the entire “generic backend/customized frontend” that we’re going for here.

    For now, let’s assume that I will fire another javascript event once the sheet is done displaying, and this can then be used to further alter the values and do things like image substitution.

    Wow, there’s going to be a lot of javascript going on here. That makes me a little nervous about performance and cross-browser compatibility…but oh well. As long as the sheet works for the members of the campaign then I’ll be happy. I’m imagining that there will be several different levels of complexity for DSTs. Some will be full of javascript magic, while others will just be a simple CSS with nothing scripty at all.

    •  
      CommentAuthorChainsawXIV
    • CommentTimeMay 2nd 2010 edited
     

    I’d prefer that too, so it sounds like we’re on the same page. I would suggest two things to make the display end simple to implement:

    1. At the end of the body onLoad event handler function, call a function with a simple, standard name, like sheetLoaded();. Include an empty sheetLoaded definition, so it doesn’t generate errors. Since you load the user submitted js file last, if they define their own sheetLoaded function, it will override the empty one, and do whatever it is that needs to be done.

    2. For ease of reference, set a javaScript global on page load that indicates weather the page is a view page, or an edit page. This could then be used in scripts to generate the appropriate behavior for each (for example, to control whether the pips display is editable or not).

    While we are getting into a lot of script here, which introduces the issues you mentioned above, I tend to think that will sort itself out. If a sheet doesn’t work in one of the popular browsers, either people won’t use it, or they’ll tell the author, who can fix the script issues. Same goes for performance. You might even add a “report bug to author” button on there, if you were so inclined.

    Edit: Another quick question. Is it safe to simply add to and modify the dynamic_sheet_attrs variable directly from script, as touched on above? I’m not sure if you’re re-generating that data from the HTML at some point, or if you’re just updating it from the script as you go…

    •  
      CommentAuthorMicah
    • CommentTimeMay 3rd 2010
     

    Thanks for all the ideas, Chainsaw.

    I’m out of town now, and I won’t have a lot of time to work on this over the next couple days. Keep the suggestions coming and hopefully I’ll be able to tackle some of them next weekend.

    I’ll try to respond when I have a chance.

    •  
      CommentAuthorChainsawXIV
    • CommentTimeMay 7th 2010 edited
     

    I thought folks might be interested in seeing the work in progress on the sheet I mentioned above. I’ve got it working and populated now, and could use some feedback if anyone cares to give some. I included some temporary functionality that allows it to be viewed in edit and view modes (or my best guess at each, as the case may be). Just click the links at the top right of the window.

    Edit: Feel free to play with the form. No actual saving is hooked up on the WIP.

    Micah, in the characters.js file from my WIP link above, I’ve made a few simple changes along the lines of what I was suggesting above. I added three hook functions in the document.ready function at the bottom of the script, allowing behavior to be attached before the spans on the page are populated (hook_dataPreLoad), after they’re populated and before the jedi-table functionality is applied (hook_dataPostLoad), and after jedi-table functionality is applied (hook_dataPostBind). I also changed the value of the submit string to allow it to be styled up.

    •  
      CommentAuthorJimTriche
    • CommentTimeMay 7th 2010
     
    Oh my god Chainsaw, that is phenomenally gorgeous. I will sell you my firstborn to do a 2nd edition Shadowrun one.
  12.  

    Thanks Jim, I’m glad you like it. I’m figuring on holding off on doing more sheets until the system solidifies, just to minimized rework as it gets put in place, but I might be convinced to do that for you. Really though, I’d encourage you to try it yourself. The system is really very approachable in its basic form, and I’d rather help folks learn to make the most of it than just do stuff myself.

    •  
      CommentAuthorJimTriche
    • CommentTimeMay 7th 2010
     

    I end up breaking stuff when I try to experiment with HTML. Hell, I can’t even barely use textile. I could try I guess, but I really just doubt I can do anything.

    •  
      CommentAuthorIdabrius
    • CommentTimeMay 7th 2010
     

    That is wonderful. My only hope is that there will one day be a 2e character sheet amongst these amazing contributions.

    •  
      CommentAuthorMonstah
    • CommentTimeMay 8th 2010
     

    Say, the tutorial mentions reading DSTs, but I can’t find any! I’m interested in using (or helping making one, if there isn’t) an oWOD sheet on my campaign, but I’d like to see something done. Where are them?

  13.  
    Chainsaw, that is beautiful. Do you mind if I take a look at the code, just to see how you did it? It would be definitely help me learn a lot.
  14.  

    Thanks Gifted, be my guest. You’re welcome to scavenge whatever you like from it, and I’ll be happy to answer any questions you may have.

    •  
      CommentAuthorMicah
    • CommentTimeMay 13th 2010 edited
     

    Ok, I’m back to work on this after my trip. I actually deployed the first DST live to the server last night. It’s a fairly simple Savage Worlds sheet designed by Pelwer. No javascript, just some basic HTML/CSS. A good first step.

    It’s only visible/available to a select group of beta testers. I’d be happy to add anyone to that list, but being on it means you understand: This is a beta feature and may change/disappear/delete all your data! There will probably be a lot of flux at the beginning, so don’t be surprised if your character sheets look ugly, or all the data disappears. Being on the bleeding edge means bleeding sometimes…

    Right now I’m working on ChainsawXIV’s DST and it brings up several issues that need to be addressed. But first, an apology:

    Debbie Downer

    I’m afraid a lot of the following will mean more work for the DST authors. I apologize for laying more on your shoulders, but a lot of these rules are necessary in order to keep things running smoothly. I’m going to try and be extra-strict about enforcing things like valid HTML/CSS/JS and the rules we come up with for DSTs. This system is a little brittle, so everybody needs to play by the rules or else it will end up just confusing the heck out of users.

    javascript namespacing

    How can we encapsulate the javascript of each DST so as to keep them outside the global js namespace? This is a serious problem with js overall. I’ve mostly solved it on OP by putting (almost) all our javascript in the aisleten namespace, then sub-namespacing that as necessary.

    Chainsaw’s sheet includes a lot of pretty nice javascript, but it’s all in the global namespace. If we go this route, there will be collisions and things will get messy if we ever allow multiple sheets to be displayed at the same time (which is a goal, by the way). For example, I can definitely foresee multiple authors writing their own addList function. If they’re all in the global namespace then we have a collision.

    So, we need a convention/process for namespacing all the javascript for each DST. The way I do it (encapsulating everything in an object) is somewhat advanced, and also uses jQuery (although it doesn’t have to). Another simpler method is to simply preface all functions with the slug for the DST. For example:

    function addList(){
    }

    becomes…

    function chainsawxiv_exalted_addList() {
    }

    It’s not pretty, but it would accomplish the goal of preventing collisions. Thoughts?

    CSS/HTML-class Namespacing

    After seeing 2 DSTs, it’s obvious that we’re going to need to namespace the CSS & HTML classes as well. All classes in a DST used for CSS should be prefaced by the slug. This will make things wordy (sorry about that…), but is necessary to prevent CSS collisions. An example:

    <span class=‘alignLeft’>Some Thingy Here</span>

    becomes

    <span class=‘chainsawxiv_exalted_alignLeft’>Some Thingy Here</span>

    I may have to be iron-handed about this, since redefining CSS styles could cause havok with the rest of the site’s display.

    HTML ids

    I may have to outlaw HTML ids altogether from the DSTs. I realize now that putting ids in there pretty much makes it impossible to display 2 sheets on the same page, since the ids will conflict. I’m not sure how I’ll go about handling the “ds_FIELD” convention. I could use classes instead of ids. I’ll have to think on this a bit.

    What this means for DST authors is that keying on ids for javascript or CSS will be a no-no. Thoughts?

    Events

    Chainsaw’s sheet depends on being notified of certain events that occur during loading the sheet. This is actually much easier to deal with than the namespacing above, we just need a convention. Like, if the DST author defines a certain function, then this function will be called when the event occurs. For now, I’ll take Chainsaw’s suggested events and use those. We’ll just need to come up with the naming convention to follow.

    Overall Thoughts

    Overall, I’m very positive on the whole thing. I think there are a lot of issues to iron out, but if we work together we can come up with a really cool system that is extensible and allows for a whole constellation of DSTs. Maintaining them over the lifetime of the whole site scares me a little, but I guess we’ll cross that bridge when we get to it.

    •  
      CommentAuthorChainsawXIV
    • CommentTimeMay 14th 2010 edited
     

    Java Script Name Spacing: I’d be happy either way personally, but the naming convention is probably better over all. Putting everything into an object would be the cleaner way, but it’s definitely less approachable for inexperienced developers, and it’s not terribly helpful from a functional standpoint (which is why my scripts work in global space, for what it’s worth – building them into an object would only have made for somewhat more obtuse code without meaningful gains in functionality).

    CSS Name Spacing: This sounds fine to me for the most part, with the one caveat that I’d want a pre-defined class on the jedi-tables edit field, like the classes I added in the submit button for jedi-tables, so that its appearance be adjusted. I didn’t dig deep enough into the jedi-tables code to know how involved doing this will be, but I can’t imagine it’d be too bad to set up. If you compare the appearance of editing fields in my demo to the default, the value should be obvious. Currently, I’m just targeting it with the input tag selector though, which will obviously be out of bounds.

    HTML IDs: This one I’d really like to avoid if possible, though I can see the issues, which are largely the same as the class and function name issues discussed above. Rather than banning the use of IDs in general (which would be a major pain from a scripting standpoint), I’d suggest mandating that the sheet’s slug appear somewhere in the ID string (it doesn’t matter where). This will avoid collisions, and doesn’t hurt the functionality at all. The default editor can either parse it out, or just include it in the variable names, either of which would be harmless.

  15.  

    Another suggestion, by the way, that totally slipped my mind before: It would be really handy to let us include a default value set for fields on a newly created character. This would allow us to create fields that are essentially self labeled, where the layout suggests it would be best (for example, the Name field from my example would have a default value of “Character Name” ideally, rather than “Click To Edit”).

    •  
      CommentAuthorpelwer
    • CommentTimeMay 14th 2010
     
    After playing with the SW sheet for a little while, created 2 characters, here's some observations:

    1. Sheet has some weird background coloring for the "Notice" skill when viewed in Firefox 3.6.3

    2. It's too wide in "input mode" - I missed the 750 pixel width limit - oops

    3. It's got some "illegal" HTML in there. I'm mixing Tables and Divs. I need to go with just divs and css following chansaw's method.
    I wanted something quick and dirty to iterate on.

    4. Micah found that you have to save a new character first and re-edit them to see the character sheet drop down

    5. Cells with sub-tables ( weapons, spells ) show border widths of varying thickness - probably as a result of my sloppy html

    6. It does allow me to edit and save the data - very cool

    Bottom line, it's ugly, but functional :) - great work Micah!

    Pat.