We are thinking about using a Group Calander mod, we were wondering if you think it might be a good idea to have a way to import / export the calander information on the website into and out of it like the RAID DKP tool. Here is a link to the Mod.
We are thinking about using a Group Calander mod, we were wondering if you think it might be a good idea to have a way to import / export the calander information on the website into and out of it like the RAID DKP tool. Here is a link to the Mod.
I asked for this a long time ago. I think it is somewhere on chops list of things.
-- Six Demon Bag Jack Burton: Hey, what more can a guy ask for? Egg Shen: Oh, a six-demon bag! Jack Burton: Terrific, a six-demon bag. Sensational. What's in it, Egg? Egg Shen: Wind, fire, all that kind of thing!
I asked for this a long time ago. I think it is somewhere on chops list of things.
It is indeed. I admit I've been a slacker in this regard. One, because of all the other stuff that I'm working on on the site, and two, because part of me wants to implement my own version, simply because I don't feel comfortable relying on someone else's code who does it "for fun" and therefore may not maintain it. Granted, the code is available to keep updated, but when a system is designed (in this case) around another system (as I'd design the mod around working with THIS site), it ultimately becomes a much smoother interaction. The big example is using the GRSS for DKP and importing rather than CT_RaidTracker. The GRSS was designed from the beginning for recording attendance for DKP purposes for uploading to this site.
So there are my two reasons why I haven't implemented the import yet.
I don't feel comfortable relying on someone else's code who does it "for fun" and therefore may not maintain it. Granted, the code is available to keep updated, but when a system is designed (in this case) around another system (as I'd design the mod around working with THIS site), it ultimately becomes a much smoother interaction
This is where you have to love the world of Open Source. Refernce the original Author. Use his mod as a base and go from there. Rename it as DKP_Calendar or something and you're on your way. /cough HAXXOR
-- Six Demon Bag Jack Burton: Hey, what more can a guy ask for? Egg Shen: Oh, a six-demon bag! Jack Burton: Terrific, a six-demon bag. Sensational. What's in it, Egg? Egg Shen: Wind, fire, all that kind of thing!
This is where you have to love the world of Open Source. Refernce the original Author. Use his mod as a base and go from there. Rename it as DKP_Calendar or something and you're on your way. /cough HAXXOR
I asked for this a long time ago. I think it is somewhere on chops list of things.
It is indeed. I admit I've been a slacker in this regard. One, because of all the other stuff that I'm working on on the site, and two, because part of me wants to implement my own version, simply because I don't feel comfortable relying on someone else's code who does it "for fun" and therefore may not maintain it. Granted, the code is available to keep updated, but when a system is designed (in this case) around another system (as I'd design the mod around working with THIS site), it ultimately becomes a much smoother interaction. The big example is using the GRSS for DKP and importing rather than CT_RaidTracker. The GRSS was designed from the beginning for recording attendance for DKP purposes for uploading to this site.
So there are my two reasons why I haven't implemented the import yet.
I would only caution you that some guilds standardized on using GEM and GC. They get a little testy if you tell them to use something else. We are using GC to coordinate RAIDS among several guilds.
The way we are using GC and the Website is if you are not logged into WoW but want to sign-up for the RAID, you can use the website. In-game use the mod. All I want to do is easily import the calendar data into the Mod without having to manually enter the info.
If you want to develop you own mod, that is great... but you said yourself you are busy... it might not be worth the effort to develop something if it is already done and works pretty well.
They get a little testy if you tell them to use something else.
I certainly wouldn't ever tell them they HAVE to do it, but it can very well be the only one that I support. I think many people were turned off to the GRSS when CT_RaidTracker always worked for them, or when eqDKP was "just fine."
Still not sure what I'll do, but I might do Saud's suggestion about forking the GroupCalendar.
I certainly wouldn't ever tell them they HAVE to do it, but it can very well be the only one that I support. I think many people were turned off to the GRSS when CT_RaidTracker always worked for them, or when eqDKP was "just fine."
It's always hard to support other peoples things. They may not continue it. You can never guarantee what they are going to change and how it might affect your stuff. When we were in the midst of trying to establish our guild has a force I was looking for a new hosting service. When I found DKP System I was instantly drawn "Custom Addon's for World of Warcraft" as a selling point. I have never used anything but GRSS since starting with DKPSystem and have suggested when other officers have had issues with CT_RaidTracker or other "supported" mods to try GRSS instead. They all love it.
You will always have players that don't want to use mods. Don't want you telling them what mods to use. I think the main difference people will understand here is. Hey look there is this new version of an in game calendar that you can use for raid signups and if you don't want to use that you can still go to the guild website. Now instead of only hitting x% that use the web or y% that will use the mod your hitting the full cumulative total of x and y. Now from an officer standpoint they are using the mod and have the option to DL updates from the website before logging into the game. In game the updates will show people that use the website as well as people that use the in game mod to signup. This will simply require someone downloading and uploading data once a day to ensure both are updated. But from an officer perspective I like this idea more. The more I could manage from in game and upload to the site the better. I don't always like tabbing out to fix things. it will be up to Chops to see how much he can do with this and manage the potential for conflicting changes. Like I deny someone on the in game mod and then upload but another officer has approved that person via the website. Like it might be a good idea to only allow approvals of those that signup in game to be approved in game and likewise on the website.
Sorry I cut myself off here because I could get really long winded on this subject.
-- Six Demon Bag Jack Burton: Hey, what more can a guy ask for? Egg Shen: Oh, a six-demon bag! Jack Burton: Terrific, a six-demon bag. Sensational. What's in it, Egg? Egg Shen: Wind, fire, all that kind of thing!
Exactly. One-way communication is easy. Synchronization is a bitch. Ideally, I'd want to structure it exactly the same as I would the GRSS. Where the file that's imported from the website is located in the mod directory, and therefore static, while the "changes" are stored in the Saved variables file.
What makes it all weird is the communication aspect. GRSS can be run effectively by one person, assuming WoW doesn't crash. What makes it tough is the persistant communication. I have never used GroupCalendar, and I've only but glanced at the code for it, but how does it record changes? How does it survive persistently online? I can only assume that at least ONE officer needs to be on for it to work. What happens if one officer approves someone in-game, logs off before another officer can see it, and then that officer (having not received the update from the officer that approved the signup), approves someone else, effectively approving 21 in a raid that can only handle 20?
Having website-based signups takes away all that confusion because there's a central repository that's reliant on one thing: the server being up.
I have never used GroupCalendar, and I've only but glanced at the code for it, but how does it record changes? How does it survive persistently online? I can only assume that at least ONE officer needs to be on for it to work. What happens if one officer approves someone in-game, logs off before another officer can see it, and then that officer (having not received the update from the officer that approved the signup), approves someone else, effectively approving 21 in a raid that can only handle 20?
The question your eluding to is whether you need a client/server version so to speak and I would be inclined to say yes. I have used it and here is the basic way it works.
Player A running group calendar schedules and event in the calendar. When they hit ok the event is sent via the SendAddonMessage() function using the GUILD Channel parameter. Everyone receives the message and their calendar parses it and keeps it updated.
Player B just logs in. His Calendar Sends a message again using the addon channel that says something to request a synchronization. At his point some other players mod in the guild would see the request and sync to it adding data that it doesn't have to its tables.
Yes everything can still get lost if people crash but because the mod is synchronizing between all online users they are able to stay updated as long as the world server doesn't crash.
What should happen in the mode you expect to run in is this. Officer downloads latest Website calendar details. When he logs in the mod will need verify that everything in the download and saved variables is in sync. If it isn't you'll have to either prompt to confirm update to the saved variables data or do it autonomously some how. This should be an option on available in the "server" mode version that officers will run. Auto syncing should be easy if it is just a matter of updating signups or signup status. Prompting probably needs to occur in an event where a raid leader deleted a scheduled raid on the calendar but not in game when you were online last. Prompt in this case and confirm deleting from online version. Sync requests could probably be handled in 2 modes. Sync to other officers. Your mod would request updates first from only online officers. Then sync from all members. Your mod could request a sync for all members. What is really neat about using the SendAddonMessage() fuction is that the arguements you can make to define who you want to talk to.
This difficulty in following the model I am outlining is that you have guilds that are in an alliance. You will need to find a way to allow synchronization with non guild members. Group Calendar does this by creating a private password protected channel to do all the sync messaging in. 2 problems. Sync by this method is laggy as compared to the built in message channel fuction. Also you can actually join the channel and see the garbage lol.
I offered a long time ago and my services are still available to you FREE OF CHARGE if you want help on this project.
-- Six Demon Bag Jack Burton: Hey, what more can a guy ask for? Egg Shen: Oh, a six-demon bag! Jack Burton: Terrific, a six-demon bag. Sensational. What's in it, Egg? Egg Shen: Wind, fire, all that kind of thing!
I for one would be highly encouraged by a version of the in game calendar from you Chops, as all the other tools you have provided thus far they are very effective (Dependable) and convienient. So get hopping slacker!!
--
All it takes for evil to triumph is for good men to do nothing - Edmund Burke
Exactly. One-way communication is easy. Synchronization is a bitch. Ideally, I'd want to structure it exactly the same as I would the GRSS. Where the file that's imported from the website is located in the mod directory, and therefore static, while the "changes" are stored in the Saved variables file.
What makes it all weird is the communication aspect. GRSS can be run effectively by one person, assuming WoW doesn't crash. What makes it tough is the persistant communication. I have never used GroupCalendar, and I've only but glanced at the code for it, but how does it record changes? How does it survive persistently online? I can only assume that at least ONE officer needs to be on for it to work. What happens if one officer approves someone in-game, logs off before another officer can see it, and then that officer (having not received the update from the officer that approved the signup), approves someone else, effectively approving 21 in a raid that can only handle 20?
Having website-based signups takes away all that confusion because there's a central repository that's reliant on one thing: the server being up.
Okay let me make the request simpler.... Can you write a small export function. Export the calendar data in a CSV format.
I can take that to the mod developer and say... I got this calendar data in a CSV format... how do I import in your mod?
This program is a PHP script that is to be placed on website and will receive the GroupCalendar LUA file, parse it, and save the information to the MySQL database on your webserver.
The main file for this program is calendar_upload.php and this what does all the work. All it does is save the data into your webserver's database. I have also included some files that I use to display our guild's calendar information to assist you in setting up your own.
Yes everything can still get lost if people crash but because the mod is synchronizing between all online users they are able to stay updated as long as the world server doesn't crash.
Not even that, everyone's copy of the AddOn caches all the events as well - so even if everyone in the guid is offline, the next time someone logs in, it'll sync up to whatever everyone last saw. (this is the data that the script Toddler mentioned extracts)
Not even that, everyone's copy of the AddOn caches all the events as well - so even if everyone in the guid is offline, the next time someone logs in, it'll sync up to whatever everyone last saw. (this is the data that the script Toddler mentioned extracts)
I'll be sure to play with it when I get the chance.
Yes everything can still get lost if people crash but because the mod is synchronizing between all online users they are able to stay updated as long as the world server doesn't crash.
Not even that, everyone's copy of the AddOn caches all the events as well - so even if everyone in the guid is offline, the next time someone logs in, it'll sync up to whatever everyone last saw. (this is the data that the script Toddler mentioned extracts)
one problem ive found with GC is if a player leaves one guild that is using it and joins another, the new guilds GC can be flooded with the old guils events ( if not set up properly)
one problem ive found with GC is if a player leaves one guild that is using it and joins another, the new guilds GC can be flooded with the old guils events ( if not set up properly)
/cough HAXXOR
