[quote=@Captain Jordan]
Want to like...defies principles. Gahhh!

Anyway, I mentioned being able to create an etherpad as a supplement to a PM conversation. What about a cloned PM feature that would create Etherpads instead of PMs? It would be a much simpler creation interface (simply a textbox with space to add comma-delimited usernames and a button), but the options would have to be expanded to allow new users to be invited later. 

I see it working like invite-only Google Docs:
I send an Etherpad (new, fancier name should be invented) invitation to [@Mahz] and [@TheMaster99]. 
Now Mahz, TheMaster99 and I can write and edit my Etherpad. 
Mahz suggests that [@LegendBegins] be invited. 
Only I can invite LegendBegins, and I decide to do that.
Now Mahz, TheMaster99, LegendBegins and I can edit my Etherpad.
LegendBegins thinks [@Hank] should join us.
I don't invite Hank to the Etherpad. No one else can, either. 
Only Mahz, TheMaster99, LegendBegins and I can edit my Etherpad.
When we are done with the Etherpad, I click the Close/Lock* button.
Now no one can edit the Etherpad, including me.
The contents of the Etherpad are still available to myself, Mahz, TheMaster99 and LegendBegins.

*Now, I haven't dived too much into Etherpad. Is there a way to disable it from further edits? If so, I'd suggest a Close/Lock button that the creator can use when the Etherpad is finished. The other way to do this might be to extract the Etherpad text and chatlog, create a PM with the contents of both and the users on the Etherpad, and destroy the Etherpad instance. 

Just my $0.02 on the matter.
[/quote]

Thanks, the breakdown was helpful.

That's what I have in mind as the most generalized implementation of the Etherpad system. Here's my attempt to distill it:

[list]
[*] A user can create and manage many pads.
[*] The pad GM can add/remove others to/from a whitelist of people that are authorized to edit the pad.
[*] The pad GM can toggle a pad between "Public" (anyone can see) and "Private" (only those on the whitelist can see)
[*] A pad has a URL like [code]/etherpads/42[/code]. That's a shareable URL.
[list]
[*] If the pad is "Public", then non-whitelisted users will see the latest revision of the pad
[*] If the pad is "Private", then non-whitelisted users will just see a "Sorry, this pad is private" message
[/list]
[*] The pad GM can "Lock"/"Unlock" a pad. A locked pad cannot be edited until the GM unlocks it.
[*] The pad GM cannot delete a pad unless they are the only user on the pad's whitelist (because users should not be able to delete the labor of other users). If a GM wants out of a pad, they must promote another user to pad GM before they can leave the pad. The delete button becomes a "Leave" button when there are 2+ users on a pad's whitelist, and it becomes a "Delete" button when there's a single user.
[*] Perhaps [code][pad=42][/pad][/code] BBCode can be introduced to allow users to embed the *contents* of an Etherpad in a post or PM (not the actual Etherpad editor itself). If the embedded pad is private instead of public, it'll just render as "The contents of this pad are private".
[*] Etherpad has a built-in system of "revisions". As people make changes to a pad, revisions are saved to the database. This allows users to go back to see previous revisions or iterate through a pad's revision history to watch it change over time. However, it makes sense for me to add some sort of "published_revisions" system on top of it. A published_revision is created when the GM clicks a "Publish" button. The latest published revision of public pads is what people see. It allows the pad GM to only update the public view of a pad when a milestone is reached.
[/list]

Thoughts? This is just me trying to translate some ideas into less-abstract implementation details.

Further notes:

[list]
[*] The hardest part about the Etherpad integration is that I have to host Etherpad on its own server. This adds operational complexity to the Guild for what's a rather niche feature, so I'm reluctant to rush into this.
[*] As soon as I implement Etherpad integration, I'll have to spend time maintaining it which means I have less time to build things.
[*] Etherpad is complex enough to where it's hard for me to experiment with it like I normally like to do with new features. This is why I think it'll pay off the most to implement it in the most general way possible (people can create and share tabs as they wish) rather than trying to be clever with it that has less appeal (like limiting Etherpads to an optional tab on a Roleplay). Once I get the general system working and get a feel for Etherpad's limits, and once the community has played with the general system for a while, we'll be in a better position to think of sensible improvements to the system.
[/list]

[quote=@Aeonumbra]
As far as etherpads go, I don't see any reason to get overly complicated with it. Having an on-site tool to be able to collaborate together would be an awesome improvement all in itself, and I hardly think anybody would be against the idea. A PM system clone, converted to an etherpad does sound like a good way to do it, though I have negative experience in coding so I wouldn't quite know.

However I think you should just take the 'New Reply' box, clone it into a module, and add the ability for others to join like a convo system. The 'new reply' box has everything you need, and can be controlled by whomever started the 'conversation'. Add a little window for present users, an add/remove user button, and maybe a small chat box.



As for the dice, the biggest issue is the ability to people to discretely re-roll until they get the number they want. I would recommend maybe another, optional?, tab 'Dice Logs' will a roll button, that records the user's name, roll number, and an optional box for them to write in the action they are rolling for.
[/quote]

The collaborative "New Reply" box sounds like what [@ZayZe] pitched to me in IRC.

It's a pretty cool idea, although I would need more assurance that people would actually want to use it that way since it's not as general of a system. Though if I did implement that, it would come after the general system is implemented. At which point we would all have better opinions about what we want and don't want.

Agreed about dice. I think the most general system for dice is for GMs to optionally enable dice on their roleplay.

This reveals a "Rolls" tab. When a player is writing their post, a dice widget will appear above the post that let's them conveniently roll (and test-roll) dice and see their outcomes right there so they can immediately incorporate it into their post with some [code][roll=143]Gooseblight kills the goblin[/roll][/code] BBCode that links to the dice roll and shows more detailed results on click/hover.

Players have to write a short description of a roll before they can roll it. This is what prevents cheating. Someone is clearly cheating when you see "Gooseblight attacks goblin" three times in the dice log and the player selects the winning roll.

[quote=@ZayZe]
I'm so excited for the 'etherpad' of awesomeness to happen.

Just imagine writing in your roleplays, *LIVE* with your partner. No pauses between posts. Live roleplaying.

er mer gerd.
[/quote]

Actually, can you break down exactly what you envision like Captain Jordan did in [url=http://www.roleplayerguild.com/posts/2419289]this post[/url]?

Since you're looking forward to the system so much, I'd like to hear exactly what you have in mind since you have much more of a vision than I do.

For example, if a roleplay works by all of its participants taking turns writing their posts, then how do you and your partner "roleplay live" from a single Etherpad? I need help connecting the dots. :newlol