IM Integration. It's iffy on the AOL, Yahoo and MSN. A lot of spam spiders crawl pages looking for e-mail addresses, and much of the code that would need to show up in the HTML to support those systems has has the actual e-mail address of the person. So the spiders get ahold of that stuff and all of a sudden you're getting dozens of e-mails with titles like “enlargement” and “approved mortgage application!” As it stands now, GP doesn't expose e-mail addresses of members anywhere, and though it would be up to the user and could come with a warning, typically that's not enough to truly express the consequences. I'll take a look at ways of obfuscating the e-mail addresses, but the creepy crawly spam bot writers often have a lot more time to dedicate to extracting than anyone else has to dedicate to hiding.Roster appearance -- what did you have in mind?Activity features -- same deal, what would you like to see?Multi-game guilds. It's been brought up many times in the past, and there's certainly a need. On the one hand, a site for each game is the way it's done now. Each site typically has its own unique look, and they communicate with each other using the Alliances feature to share forums. While this works, it does create additional overhead if the administrative load for all of the sites falls on one person's shoulders. This is mitigated by administrators managing their own sub-guild sites, but isn't always the way it's run.I don't like to bring up the business side either, but... If a player association of, say, 7 guilds were to have a single site with 3,000 members, then that's a single site paying the same as a 40-member guild while eating up a lot more bandwidth and database storage space. An alternative would be a new package with a new price, in addition to all the coding that would be necessary to support guild-in-guild functionality. In summary, on the multi-game guild request, it's something we know is a requirement, but haven't nailed down either 1) non-obscene pricing or 2) exactly how it would be accomplished, technically. Guild member newsletter. This is something we've had in the past, but hundreds of spam complaints from people who actually requested that they be included in the newsletter mailings forced us to turn it off. They'd complain to their ISP and then the ISP would paint a scarlet letter on any mail coming from GP, causing support e-mails to be blocked by major providers such as Yahoo. That's just bad mojo.An alternative is a “What's New” content type, but it doesn't exactly fill the same needs a newsletter does (getting people to come back to your site being one of the major reasons newsletters exist). I will look at the possibility of creating a sign-up in user settings that gives ample warning that signing up for a newsletter means you'll get it through your internet e-mail, and then reactivating it. Of course, the back-and-forth between our e-mail server and other servers when users provide bogus e-mail addresses is enough to make rush hour traffic on the Oakland Bay Bridge look like 3 AM traffic in a Colorado suburb.Internal guild IM system. v1.0 of GuildPortal actually had this, in fact it's what the mail system is based off of (one of the reasons the mail system needs a revamp). Used to be, you could click someone's name in the Who's Online box and have a pop-up message window like you do now. You'd click “Send” and the other user would get an IM pop-up within 10 seconds later. It was implemented as an IFrame that existed on all pages, and had a meta-refresh tag that would poll for new IMs every 10 seconds. If one was found, the recipient would get a pop-up with the message, and an option to reply.The problem with that system is that so many people have pop-up blockers installed. Plus, the Who's Online status is actually a facade -- it's based on the last time a user navigated to a page. We could make it so it's updated more frequently (using the IFrame/META approach), but that's a lot more traffic.The final (and more probable) option is an actual GP Messenger, written for Windows in .NET. The web services for this are already written, and I have a prototype here that I've been playing with on occasion. The web services approach bypasses the need for ports to be opened on firewalls, though it's not as fast a refresh as it would be on the other, more popular IM clients (for example, MSNIM has connections that are so direct that you can get a status message when someone's typing on the other end). Finally, the biggest problem with this approach is that it's limited to Windows users, though with projects like MONO there is a possibility of it being ported to other platforms... Thoughts?Configurable point system. Do you mean for the activity ratings? Yeah, this one's been on the burner for a while. Problem with it is, normalization or batch points? For example, if you change how many points a user gets for posting something, say from 5 to 10, should the system retro-actively award 5 more points to everyone who previously got 5, bringing them up to 10? As it stands, the current point system is a running total, not relative to the different items that award the actual points. So now if a post is worth 5, when the user posts, their running activity points are set to (current + 5). If we don't need to do the retro-awarding, it's simpler, but it might not be something that everyone would want... Opinions on this, anyone?