Dynamic Character Sheets

2456789

Comments

  • giftedmunchkin
    Posts: 11
    Oh, okay, cool. I thought that the title was going to be static, based on the tag of the DST. Good to know, thanks.
  • ChainsawXIV
    ChainsawXIV
    Posts: 530 edited May 2010
    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":http://omnichron.net/external/op/pips_demo.html), 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.
    Post edited by ChainsawXIV on
  • Micah
    Micah
    Posts: 894 edited May 2010
    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:

    bq. 6

    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.
    Post edited by Micah on
  • ChainsawXIV
    ChainsawXIV
    Posts: 530
    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'] = '';_

    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.
  • Micah
    Micah
    Posts: 894
    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.
  • ChainsawXIV
    ChainsawXIV
    Posts: 530 edited May 2010
    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...
    Post edited by ChainsawXIV on
  • Micah
    Micah
    Posts: 894
    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.
  • ChainsawXIV
    ChainsawXIV
    Posts: 530 edited May 2010
    I thought folks might be interested in seeing the "work in progress":http://omnichron.net/external/op/dst_exalted/?edit 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":http://omnichron.net/external/op/dst_exalted/javascripts/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.
    Post edited by ChainsawXIV on
  • JimTriche
    JimTriche
    Posts: 483
    Oh my god Chainsaw, that is phenomenally gorgeous. I will sell you my firstborn to do a 2nd edition Shadowrun one.
  • ChainsawXIV
    ChainsawXIV
    Posts: 530
    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.
  • JimTriche
    JimTriche
    Posts: 483
    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.
  • Idabrius
    Idabrius
    Posts: 52
    That is wonderful. My only hope is that there will one day be a 2e character sheet amongst these amazing contributions.
  • Monstah
    Monstah
    Posts: 7
    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?
  • giftedmunchkin
    Posts: 11
    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.
  • ChainsawXIV
    ChainsawXIV
    Posts: 530
    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.
  • Micah
    Micah
    Posts: 894 edited May 2010
    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:

    h3. 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.

    h3. 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?*

    h3. 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:

    Some Thingy Here

    becomes

    Some Thingy Here

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

    h3. 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?*

    h3. 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.

    h3. 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.
    Post edited by Micah on
  • ChainsawXIV
    ChainsawXIV
    Posts: 530 edited May 2010
    *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.
    Post edited by ChainsawXIV on
  • ChainsawXIV
    ChainsawXIV
    Posts: 530
    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").
  • pelwer
    pelwer
    Posts: 18
    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.
  • Micah
    Micah
    Posts: 894
    Pat - We're still getting things working right now, so that's why there's some sizing/formatting issues. Once we get the foundation laid and solid, we'll settle on some standard widths, which should make things easier.

    Chainsaw

    *Default Values* - I'm toying with the idea of using "HTML5-style data attributes":http://ejohn.org/blog/html-5-data-attributes/ which would allow for us to easily define things like default values. The downside here is that our html would be technically invalid, although the browsers don't really care. They just ignore the extra attributes. Alternately, there's a trick that I've used in the past where you embed all the metadata in a hidden span inside, like so:

    Enter name

    That'd be a pain though, as I currently just replace all the innerHTML with the actual value, which would blow away internal spans.

    *IDs* - How would including the sheet slug in the ID prevent collisions? If there are 2 of the same type of sheet on the same page, you'll have duplicated IDs. When I use ids, I always put a unique identifier in there (like the database id), but obviously the DST authors don't have access to that.

    Am I making too big a deal out of this? Should we just go ahead with it as is and try to figure out what to do later if/when putting multiple sheets on a page becomes a real issue instead of a theoretical possibility?

    Finally, one thing I am thinking of doing is passing the surrounding 's ID in as part of the dataPreLoad hook. The surrounding has an id like _dynamic_sheet_XXXX_ where XXXX is the database ID of the character in question. Having this ID would allow DST authors to isolate that particular sheet on the page.

    This is one area where I like jQuery. Once you have established a context (like the containing ) then you can just search inside of it by class for anything you want.

    Anyways, what else would be useful to pass in to the dataPreLoad hook? I can pass all kinds of contextual data there to make it easier to write the DST.
  • ChainsawXIV
    ChainsawXIV
    Posts: 530
    *Default Values:* That sounds interesting, but it might be easier to just initialize _dynamic_sheet_attrs_ with some basic values on a sheet by sheet basis.

    *ID Collisions:* You're right. I wasn't thinking about two of the same sheet on the same page, which is of course the most likely scenario of all if multiple sheets per page are supported. I definitely think we should sort the issue out now, as it will only be harder to add the more invested people get in the existing setup. Containing each sheet in a properly named div, and using classes, would get the job done, and is easy enough to code in bare script as well as jquery, but searching classes is slower than accessing the DOM via ID's I'm pretty sure. Maybe not an issue, as these things aren't really performance intensive, but seems not ideal.

    *Load Function Parameters:* I'll have to think on this. I didn't _need_ anything to get the job done with my setup, but there are certainly some useful things that could be passed in. Most things could be got as needed from passing in the sheet's wrapper element though.
  • Micah
    Micah
    Posts: 894
    I'm about to deploy chainsaw's DST. *IT DOESN'T FULLY WORK YET* I'm just uploading it so he can see that it's close and can see his work live on the site. So, no complaints about bugs, since we already know about them. But, the load/save of the pips works, and adding list items kind of works (although there are some weird issues with duplication).

    For anyone thinking of jumping in, I'd say this DST is pretty much the most advanced thing I'd want to see, especially at this stage. We have to crawl before we walk, and this is more along the lines of full sprinting. Ultimately, there will be features and ideas that I will have to say no to, just to keep this from spiraling completely out of control.

    h3. Direct DST input

    It's also becoming obvious to me that there will need to be a way for DST authors to modify their work without emailing new files to me. That would be a big burden off of my back as well. Otherwise, people will get it working with the devkit, then email it to me, only for me to find that it doesn't work on the live site. Ultimately, that's the only place that matters. It won't be fun editing code in a browser textarea, but that's the best I've got at this point.

    This should be (fairly) easy for the HTML, CSS, and JS, as that's just flat text. I can jam it into the database and serve it out normally. However, for images, we'll need to figure something else out. I don't want to design a new upload interface just for this, so maybe we'll have to handle the images via email. My usual mode is to do things manually until I can't stand it anymore and then program an interface for it.
  • Micah
    Micah
    Posts: 894
    It's up. Here's "a character with the DST":http://www.obsidianportal.com/campaigns/lorem-ipsum/characters/exlated-dst You can't see it unless you've been added to the beta list. If anyone is interested, say so and I'll add you.

    *Remember* - In order to create a character with a DST, you need to *create and save first, then click on edit*. I haven't gotten around to fixing this yet. You'll also need to be in an Exalted campaign, since it will only show DSTs for the campaign system of the current campaign.
  • ChainsawXIV
    ChainsawXIV
    Posts: 530 edited May 2010
    So, after poking around in that a bit...

    *Saving Values:* It appears I guessed wrong about how you were saving values. I see you've added a function which swaps back the pips to their values for saving, which makes sense for them. The text area edit field will need a slightly different treatment however - probably the best thing is to save the value to a hidden _span_ as you suggested for something else before. In light of this, I'd just as soon rewrite my script myself to work with the saving system you have, and save you the trouble. I want to do some other reworking of the scripts anyway.

    *List Functionality:* At a glance, the reason lists aren't working correctly (mostly, see below) is because the list is re-generated from the _dynamic_sheet_attrs_ data when an item is added or removed, and _dynamic_sheet_attrs_, contrary to my expectations when I was writing the code, isn't actually updated by jeditable when a field is edited. Thus, when the list is recreated, it pulls nothing but blank values from _dynamic_sheet_attrs_. I should be able to rewrite this easily enough while I'm working out the things discussed above.

    *IE List Issues:* List items cannot be edited in IE after an item has been added or removed from the list. This seems to be because jQuery writes a unique parameter value (_jQuery127889311621="172"_ or similar) to every element in the page. What it then does with that I can't say, as the jQuery script file has been flattened way past the point of readability, but suffice to say that when the list adds an item, it doesn't get a number of its own, and this seems to prevent the jeditable functionality from being applied properly. This isn't an issue in FF, where these parameters don't appear to be added.

    I'm not sure how this can be addressed, honestly, but it will be an issue for any sheet that needs to add things dynamically like this, so I think it's important to figure it out.
    Post edited by ChainsawXIV on
  • Micah
    Micah
    Posts: 894
    *Saving Values* - Yeah, I want to have a recognized interface between DST authors and the underlying system. I hadn't considered the kind of swapping (image value) that's going on here, but the presave callback seems like it should do the trick. The DST can store everything it needs in some kind of local storage, then replace all the values in the presave callback.

    This DST is a good exercise in coming up with the places to do callbacks, as well as what to pass to them. If all goes well, the DST author won't need to know anything about the internal workings of my javascript, and just has to work with the callbacks and whatever other interface we need to expose (like the ability to re-bind jeditable, which you're doing after adding a list item).

    So, if there's anything you're doing or want to do that requires calling or modifying any of the javascript in characters.js, let me know and we can figure out a way to expose it as part of the interface.

    *Textareas* - jeditable supports textareas, so i think we could set it so that adding a certain class (like _textarea_) to a field means that it will be converted to a text field .

    However, one issue here is that I'm guessing most people will want access to the full textile/html/wiki-linking/etc that's part of all our current text areas. That's just too advanced at this point. The DST fields are not passed through that same parsing/rendering phase, and I don't want to tackle that right now.

    Instead, I think we should reserve a spot in the DST for the existing _bio_ field, just like I'm inserting the character name, player name, and campaign.

    We're still deciding how to integrate the DST into the overall character page layout, and the more required fields we can add to the DST, the more we can remove from the page. So, while right now I've just got it jammed at the bottom under "Dynamic Page", I'd like to flip things and move it to the top, and remove the display of all the standard fields. The only thing I'd leave as-is is the GM-only info, since I think it'd be a little silly to require that be a part of the DST, as only the GM will ever see that.

    When editing the character, I think for now I'd leave all those fields at the top (as currently) and just explain that the values are inserted into the sheet on display. It's not a perfect system, but I'm shooting for "better than it is now", not perfect.

    *IE List Issues* - I'll take a look at this when I get a chance. I know very little about cross-browser javascript, and just depend on jQuery to handle all that. Is this in IE7/8? If so we should fix it. If it's 6, then I really don't care. I'm pretty sure the site already looks like crap in IE6 and I don't think it's worth the trouble to support IE6.
  • ChainsawXIV
    ChainsawXIV
    Posts: 530
    *IE List Issues:* I'm right there with you regarding IE6 - it's almost nine years old, and there are very few excuses not to upgrade at this point. The IE issue is in IE8 however, and it looks like it's one of the pseudo-hacks that jQuery uses to achieve cross-browser support that's causing the problem by basically breaking when normal DHTML techniques are used to manipulated the DOM. I'll know better if I can find and look through a version of jQuery that has its line breaks, white space, and variable names intact, so I'll have a look around the web for that later today and see what I can learn.

    *Text Areas:* Ideally, I'd love to see textarea support from jeditable, even without the formatting options of textile. It just makes sense for fields that are likely to go multiple lines, even if they're only going to be two or three. You could do this with a class as you suggested, or dfs fields in a DST could automatically become jeditable text areas if their height exceeded twice their line height (generally indicating that they're multiple lines of text). I think that keeping the big common text areas separate for now seems fine, although I might suggest consolidating the interface with some tabs, or collapsible sections.

    *Characters.js:* Another thing that occurred to me that would be a good change to characters.js would be to expose the value used for the submit button (Line 60, currently hard coded to 'Ok'). In the file I sent you, I'd hard coded it to something more useful, and it's possible to override the value by accessing the proper object in custom script, but you could officially expose the value to us through a more obvious global, which would make it more accessible.

    *Shared Scripts:* On another note, one thing I think could be cool, and make sheet building more accessible and easier for less experienced authors, is to expand the core jeditable options with select user submissions. I'd be happy to donate my pips and list controls (after doing some more work on them) to the community, and if they were in the core scripts then anyone could use them just by adding the proper class names to their HTML. That would eliminate the need for every author who needs that type of control to re-write the system, and improve reliability and quality in general.

    *Direct Updates:* Earlier you mentioned wanting to work out a way to let authors update their works in progress directly. I haven't used Github at all really, so I'm not entirely clear on how difficult this would be to set up, but I might suggest allowing authors to submit their updates through that system. That way they could check in whatever files they needed. You could use a scripted page to give an accurate preview of work based on submitted files there, and then just push a build from the latest files on a regular basis.
  • pelwer
    pelwer
    Posts: 18
    I like the idea of being able to pull the 'bio' text box into the sheet!
  • ChainsawXIV
    ChainsawXIV
    Posts: 530
    *IE Lists Issue:* I've isolated and fixed this issue for my code, but it will be something to keep an eye on for anyone else working with the DOM tree in these sheets. As it turns out, jQuery sets a unique attribute on HTML elements as part of its searching and caching process. This is fine and good, except that when you use javaScript to get the HTML of an element, IE includes this information, and FF doesn't. If you then use that HTML to create copies of that source element, you end up with multiple elements having the same unique identifier, which porks the whole deal. To resolve this, just make sure that before writing out any new HTML, you remove any instances of this jQuery specific parameter, so that it can replace them with something that's actually unique. It should look something like this:

    _oDestinationElement.innerHTML = oSourceElement.innerHTML.replace(/jQuery[\d]+="[\d]+"/g,'');_
  • Micah
    Micah
    Posts: 894 edited May 2010
    *shared scripts* - I like the shared scripts idea. I'm not exactly sure how to implement it, but it's a good one. It would definitely make the process a little easier. I'll put that on the "someday" list for now.

    *bio/textareas* - Maybe I wasn't clear. I want the bio integrated for _viewing_ a sheet (when someone clicks to see it), but it will be separate for editing. The editing interface is just too funky and I don't want to deal with that right now.

    Pelwer: I think that if you name a field with _ds_bio_ it should auto-insert the bio HTML there. I'll double-check as maybe I forgot to do that. It's supposed to work like that.

    *direct updates* Direct updates (for now) will have to be done via a textarea input or something. I may remove the github account because it's tough to do a deployment from there to the live site. Our deployment tool (called capistrano) wasn't really designed for deploying from multiple repositories, and I'm not really interested in updating it to do that.

    For now what I'm imagining is that you'll be able to get it working with the devkit, then paste all the html/css/js into textareas on a special input screen on OP. Then you can debug from there. It won't be all that nice since editing in a textarea isn't nearly as nice as using your favorite text editor, but it's the best I can do for now.

    However, to prevent people from using it maliciously, all new DSTs will be locked to only the original author. No one else will be able to see them. Once you're happy with it, there will be an option to publish it. I'll come eyeball it, make sure there's no javascript hanky-panky, and then set it live for everyone. At that point, it's set in stone. If you want to make any changes, it requires creating a new version and going through the approval process again.

    There's a fair bit of work for me in all this, so it may be a while. Still, I think this will make it much easier for someone to get involved and just start playing.
    Post edited by Micah on
  • giftedmunchkin
    Posts: 11
    Hey, Micah, do you think I could be added to the DST beta? I'd like to see it in action, if possible. Thanks!
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