Yes, please send me the iframe doohickey. It sounds like a good idea.
I like the idea of a shared code repository like you mention, but I'm worried about things getting out of sync. The only version that really matters is the one that's loaded into the live system. Any code you find anywhere else is most likely outdated, and could end up being misleading. I already have trouble keeping the devkit in sync with the changes I make on the live site. That's one of the reasons I started having the devkit pull the characters.js directly from op.com
I just don't want to get into a situation where someone is editing an old, outdated version of something and then wondering why it's not working like they expect. I've been in that boat too many times to wish it on anyone else.
On the totally non-critical end of the spectrum, it just occurred to me that it mite be cool to have a skin option for sheets, that uses either an alternate style sheet, or an alternate slug (so the one style sheet can contain styles for various skins). For example, in exalted, there are different types of Exalts - Solar, Lunar, Sidereal, Abyssal, Alchemical, Infernal, Dragon Blooded, and so on - which all use basically the same sheet from a mechanical standpoint. The visual style of the sheet I made has a Solar themed color scheme and decorations though, and it would be cool if people could just select other visual themes on the fly. Ideally without having to re-enter their data. The same thing would let me style for different settings on the 4th Ed sheet I'm working on now.
Micah, I sent the iframe example to you, and I'm eager to hear your feedback. One thing I mentioned in the email but didn't bring up here is that using an iframe on the live site would eliminate the need for namespaces, since the iframe has its own scope.
Yeah, I can see how synchronizing the site with the repository could be a pain. The only way I can think of to deal with this is to reintroduce the version number (revision number, tag, etc.) as part of the slug or as a separate version number. Using the revision number would make it immediately apparent that the copy in OP doesn't match the copy in the repository -- if the DST is under active development, for example.
Chainsaw, I love your skinning idea. One DM I know likes to have a different logo/watermark based on what campaign he's running, but skinning based on character type is cool too. Technically, you could build that into the DST yourself by adding a DSF for the skin (so it's saved) and using Javascript to swap out the CSS. Perhaps "skin" or "styling" could be another required field, and most could safely use "default."
While I could certainly build it in on my own, I think it would be a cool feature to offer as officially supported for less technically inclined sheet creators.
For now, I'd say to use the technique that malfunction mentions for the different skins. The javascript should be fairly easy, and I'd guess that it's a fairly advanced feature that few DST authors would use.
Still, I have to admit that it's a pretty cool idea.
Malfunction - I'll try to take a look at the iframe setup sometime today or tomorrow. I doubt I would use it on the live site, as I'm a little hesitant to put in iframes, but I'd like to see what you're thinking.
#1 I have no idea how to quote someone else's quotes, so I'll just copy/paste this...
pelwer said: It's too wide in "input mode" - I missed the 750 pixel width limit - oops
#2 Where is this pixel width limit? I was looking for a limit because when floating things left and right you really need to set a limit or block-elements will force the container div to be as wide as the page. A lot of stuff from these 3 pages doesn't seem to be listed at http://help.obsidianportal.com/faqs/advanced/creating-a-dynamic-character-sheet-template-dst -- where are you all getting the extra information (like width limits) ?
Is the current plan to always have a "click to edit" where a number should be if that number isn't there? Is there a way to make some section optional? For instance, in Shadowrun, you can have either a Magic attribute or a Resonance attribute, but not both. Usually, the spot there that is will say something like Magic/Resonance or M/R or it'll just say whichever word is appropriate. I tried:
Magic/Resonance:
and got:
Magic/Resonance: Click to editClick to edit
For pixel width, I think we just got it by tryle and error. 730px width seems about right, in my experiance.
For the magic/resonance field, I'd suggest doing something like, "_Magic/Resonance: _" to cover both in one field. If you wanted, you could also build a drop-down menu so the player could select from Magic and Resonance, but that's a more advanced topic all together.
Okay, I think it's time to toss my hat into the ring. I'd like to take what's been done to this point and see about building a DST for ICONS. Let me know if someone else is tackling that one already.
The thing about Shadowrun is that there isn't a set skill list like D&D. Well, ok, there is, but it's so incredibly long that nobody ever writes it all down. You just write down what skills you actually know. To complicate the matter, you can also choose to learn skill groups, which are just like they sound -- instead of learning individual skills, you learn a group at once. Improving a single skill is (new ranking * 2) in Karma points while improving a skill group is (new ranking * 5) in Karma points, so skill groups are only "worth it" if you're going to be improving 3+ skills in a particular group. Anyway, usually there are just a set of blank lines on a character sheet where you write down your skills. If I put spans of dsf_skill01, dsf_skill02... dsf_skill18, there are going to be a lot of "click here" spots. It would be really helpful to make some things optional (especially since that "click here" message is so much bigger than a simple number/name and it's really mucking up the finished sheet).
Instead of "Click to edit" perhaps it could just be ??? or something? All the extra text (13 characters, including two spaces) is throwing my tables out of whack (compared to one, perhaps two, digits).
For the skills list, I'd suggest using something like the list control I added for my Exalted sheet, which allows you to add, remove, and order things on the fly. I can show you how to use that if you'd like.
For the edit message, you can set the value of _aisleten.characters.jeditablePlaceholder_ in your sheet's _dataPreLoad_ function if you like, which will override the default edit text for the whole page.
The reason you see nothing in the _bio_ field is that it's automatically linked to the big Biography field for each character, and cannot be edited through the DST system, and that field is currently blank.
I don't like the "click to edit" text either. In my DST, I'm styling all editable fields with a tinted background, dashed outline, fixed width, and "cursor:pointer." This way, they stand out from regular text labels, and their clickability is conveyed with the changed mouse cursor.
Say, how does jeditable work if you don't have a mouse (some phones)? You can't very well tab through fields that don't exist in the DOM.
Not a convenient one, unfortunately. At least as currently written. If the core script were rewritten to use that as a method instead of a property, you could install a function there (that detected classes or some such), but that would be on Micah's end of things. Could be a useful addition.
Edit: I haven't tested it, but jeditable will probably work ok on mouse-less platforms. While the jeditable fields are added on the fly, they are still part of the DOM tree for the page while they're there. There might be some wierdness with tab-order though.
I did a similar thing with my editable fields - giving them a :hover style color change, and a mouse pointer change in edit mode - which seemed to work well, but I left the edit text in place. I like the idea of the background and border changes you described though, and I think I'll try that out in the future.
Well, I'm going to be leaving at the end of the week for an extended period of time, so anyone who wants to do something with the Shadowrun DST is welcome to do so. I freely revoke all claims to it that I might have had -- go to town with it, it's absolutely not mine.
I'm thinking of working on the adnd2.0 dst which looks unclaimed so far. I'm not completely ignorant, but this will be a stretch for me. If somebody else wants it, I'll step aside. I'd like to check if I understand how this works. Setting aside the css for now, I'd like to confirm I can make a bare bones operational dst with just html by creating an html character sheet and typing in where I would otherwise enter values. 'variable' is whatever parameter is used in the gaming system for which I'd like to be able to dynamically assign a value.
Just in case anyone here can help, none of the DST stuff is working (even if I copy someone else's in that has been approved). Mine is the risus DST. Is there something that I need to do or some switch that needs to be thrown?
kenurion, you can create a fully functional DST with only HTML by putting data into tables. Bear in mind, under a Strict HTML 4.0 doctype, you aren't allowed to have width settings on columns. I don't know what doctype this website enforces. You don't just type: You have to put a after that and then the value is pulled and placed between the tags. For instance...
magically becomes...
5 feet 10 inches
or whatever you put in for the height.
Thanks banaticus. I'll remember the closing tag. I was thinking I'd focus on the dynamic part of this and less on the style part for now, so I'll stay away from width settings on the html sheet. If I'm understanding this, width settings and such should really be on the css sheet anyway.
Just begin putting together a DST for Eclipse Phase. Many of the issues banaticus described apply, with one other doozy:
In Eclipse Phase, you have an ego and a morph. Your ego is 'you', and has stats; your morph is your body, which your ego may sleeve out of in favour of a different morph. I'd like to track available morphs, noting which is active and boosting stats accordingly.
Ie., user has their ego and three morphs. Only 1 morph is active, and the stat boosts are applied to accordingly. The other morphs are simply there for simplicity when being farcast between planets or having to jump back and forth between morphs without a ton of effort. Any thoughts on how this would be accomplished?
On a different note, I want to point out the new Google Font API: http://code.google.com/apis/webfonts/. This allows full support for weird/cool fonts in your stylesheets.
You could certainly do what you're describing Hewhocutsdown, if you're sufficiently familiar with javascript. I'd rate it as a fairly advanced undertaking however. There are a number of ways you mite choose to present this, but they basically come down to:
* Create a dynamic list of Morphs the player can add to and remove from, with key values in each entry
* Use a drop down menu, radio buttons, or some other means to let the user select the active morph
* Recalculate the relevant values whenever the user chooses to change his active morph
I'm thinking it would function as a separate tab (like your Biography tab on the Exalted DST). On that tab, there would be a drop-down to select which morph to view (the active one being the default), with a button to 'add new' and, in the case of viewing an inactive morph, a button to 'make active'.
The rest of the page would display stats accordingly, and would carry across to populate the totals on the main.
One of my fellow Exalted players brought a bug to my attention, which seems to be with the system itself. Here are the reproduction steps:
1. Edit an existing, saved character which has _never_ had a DST before
2. Select a DST from the dropdown, and edit one or more fields
3. Save the character, and note that your changes were not saved
I cannot reproduce this bug when editing and existing DST enabled character. Everything saves fine. This bug also appears not to happen when choosing a new DST for a character than _once_ had one, and then had the menu selection set back to none. This leads me to believe its an issue with the initialization of the _dynamic_sheet_attrs_ variable, or some other edge case in the save system.
Also submitted an update to the Exalted sheet, fixing the following reported bugs:
* Links in fields were not styled differently than the surrounding text
* The up and down buttons on the 9th and 10th item in a list didn't work correctly
* Intimacies did not line wrap correctly in view mode (worked fine in Edit)
* Uncommitted _textarea_ edit boxes were not properly closed out on save
Comments
Sounds good to me!
Pat
Yes, please send me the iframe doohickey. It sounds like a good idea.
I like the idea of a shared code repository like you mention, but I'm worried about things getting out of sync. The only version that really matters is the one that's loaded into the live system. Any code you find anywhere else is most likely outdated, and could end up being misleading. I already have trouble keeping the devkit in sync with the changes I make on the live site. That's one of the reasons I started having the devkit pull the characters.js directly from op.com
I just don't want to get into a situation where someone is editing an old, outdated version of something and then wondering why it's not working like they expect. I've been in that boat too many times to wish it on anyone else.
Yeah, I can see how synchronizing the site with the repository could be a pain. The only way I can think of to deal with this is to reintroduce the version number (revision number, tag, etc.) as part of the slug or as a separate version number. Using the revision number would make it immediately apparent that the copy in OP doesn't match the copy in the repository -- if the DST is under active development, for example.
Chainsaw, I love your skinning idea. One DM I know likes to have a different logo/watermark based on what campaign he's running, but skinning based on character type is cool too. Technically, you could build that into the DST yourself by adding a DSF for the skin (so it's saved) and using Javascript to swap out the CSS. Perhaps "skin" or "styling" could be another required field, and most could safely use "default."
Still, I have to admit that it's a pretty cool idea.
Malfunction - I'll try to take a look at the iframe setup sometime today or tomorrow. I doubt I would use it on the live site, as I'm a little hesitant to put in iframes, but I'd like to see what you're thinking.
pelwer said: It's too wide in "input mode" - I missed the 750 pixel width limit - oops
#2 Where is this pixel width limit? I was looking for a limit because when floating things left and right you really need to set a limit or block-elements will force the container div to be as wide as the page. A lot of stuff from these 3 pages doesn't seem to be listed at http://help.obsidianportal.com/faqs/advanced/creating-a-dynamic-character-sheet-template-dst -- where are you all getting the extra information (like width limits) ?
Magic/Resonance:
and got:
Magic/Resonance: Click to editClick to edit
For the magic/resonance field, I'd suggest doing something like, "_Magic/Resonance: _" to cover both in one field. If you wanted, you could also build a drop-down menu so the player could select from Magic and Resonance, but that's a more advanced topic all together.
I just played around with the widths until the sheet didn't spill over into the left menus.
pat.
For the edit message, you can set the value of _aisleten.characters.jeditablePlaceholder_ in your sheet's _dataPreLoad_ function if you like, which will override the default edit text for the whole page.
The reason you see nothing in the _bio_ field is that it's automatically linked to the big Biography field for each character, and cannot be edited through the DST system, and that field is currently blank.
I don't like the "click to edit" text either. In my DST, I'm styling all editable fields with a tinted background, dashed outline, fixed width, and "cursor:pointer." This way, they stand out from regular text labels, and their clickability is conveyed with the changed mouse cursor.
Say, how does jeditable work if you don't have a mouse (some phones)? You can't very well tab through fields that don't exist in the DOM.
Edit: I haven't tested it, but jeditable will probably work ok on mouse-less platforms. While the jeditable fields are added on the fly, they are still part of the DOM tree for the page while they're there. There might be some wierdness with tab-order though.
I did a similar thing with my editable fields - giving them a :hover style color change, and a mouse pointer change in edit mode - which seemed to work well, but I left the edit text in place. I like the idea of the background and border changes you described though, and I think I'll try that out in the future.
Thanks!
-chris
Thanks!
Larry
magically becomes...
5 feet 10 inches
or whatever you put in for the height.
In Eclipse Phase, you have an ego and a morph. Your ego is 'you', and has stats; your morph is your body, which your ego may sleeve out of in favour of a different morph. I'd like to track available morphs, noting which is active and boosting stats accordingly.
Ie., user has their ego and three morphs. Only 1 morph is active, and the stat boosts are applied to accordingly. The other morphs are simply there for simplicity when being farcast between planets or having to jump back and forth between morphs without a ton of effort. Any thoughts on how this would be accomplished?
On a different note, I want to point out the new Google Font API: http://code.google.com/apis/webfonts/. This allows full support for weird/cool fonts in your stylesheets.
* Create a dynamic list of Morphs the player can add to and remove from, with key values in each entry
* Use a drop down menu, radio buttons, or some other means to let the user select the active morph
* Recalculate the relevant values whenever the user chooses to change his active morph
The rest of the page would display stats accordingly, and would carry across to populate the totals on the main.
1. Edit an existing, saved character which has _never_ had a DST before
2. Select a DST from the dropdown, and edit one or more fields
3. Save the character, and note that your changes were not saved
I cannot reproduce this bug when editing and existing DST enabled character. Everything saves fine. This bug also appears not to happen when choosing a new DST for a character than _once_ had one, and then had the menu selection set back to none. This leads me to believe its an issue with the initialization of the _dynamic_sheet_attrs_ variable, or some other edge case in the save system.
Also submitted an update to the Exalted sheet, fixing the following reported bugs:
* Links in fields were not styled differently than the surrounding text
* The up and down buttons on the 9th and 10th item in a list didn't work correctly
* Intimacies did not line wrap correctly in view mode (worked fine in Edit)
* Uncommitted _textarea_ edit boxes were not properly closed out on save