TODO Core:
 - Ajouter champ TagNumber dans le protocol d'event, qui stocke l'ID en cours d'un event et empeche de s'inscrire si on est tag avec un autre ID
 - Quick feature request. Is is possible to add a edit function for the run leader to edit the roles different people are playing? If someone adds in from the ingame calender, they are assigned no role which makes the set numbers of different roles inside GEM go wanky. 
 - Faire une fonction GEM3_EVT_CopyEvent, qui recopie integralement un event, avec un nouvel ID, et avec de nouvelles dates (ev_date, deadline, duration maj)
   -> que l'ui utilise ca qd elle fait des events sur X semaines
   -> servira pour la synchro calendar, une copie event est faite sur le serveur, permettra donc qd on passera en event custom (pas guilde) de pouvoir faire rapidement plusieurs events
 - commencer a gerer les events calendar custom
   -> si canal guilde, ajouter a la main tous les membres de la guilde lors de la creation de l'event (sauf les mecs offline pas log depuis genre 30jours)
   -> de temps en temps, verifier si il n'y a pas de nouveau guild et l'inviter)
 - Quand on recup ses subscribeInfo pour un event et que plusieurs de mes persos sont inscrits, recup en priorit celui qui est connect (qd on precise pas le nom a la fonction)
   -> dans l'ui, qd on passe la souris sur un event et que 2 persos sont inscrits (genre kikipik et kirash, logg avec kikipik), ca ressort kirash en 1er
 - Fonction GEM3_CanCreateEventOnChannel(channel) -> retourne true si on a le droit de creer un event dans le canal en question (pour canal guilde, depends de l'option de creation en fonction du rang)
 - Fonction GEM3_AmIAdminOnChannel(channel) -> retourne true si je suis un admin de ce channel.  Permettra a l'UI d'afficher d'autres options dans le menu de control des events, comme par exemple pour pouvoir delete un event pas a moi
 - [Plus besoin de CLINK] Completement changer comment les link d'obj sont envoys. Utiliser un char qcq (genre toujours le pipe), mais n'envoyer que le code de l'obj
 - Ajouter la config du core dans le champ description de la guilde:  for _,line in ipairs({strsplit("\n", GetGuildInfoText())}) do print(line) end
  -> gem3 opt: ranktocreate=value,opt2=value2 (ou compact gem3opt:1,0,2,1)
  -> gem3 admins: kiki,celeamas  -> liste des joueurs (en plus du gm) qui ont des droits sur les events, comme delete un evt

TODO GEM4:
  (11:49:26) Kiki: et c'est ca qui me donne une super ide pour modifier completment le core pour GEM4, on fait un fake event, et on stocke toutes nos infos dans le commentaire :)
  (11:49:50) Kiki: comme ca, tout est centralis sur le serveur wow ^^
  (11:51:35) Kiki: on pourra stocker toutes les infos dans qq chose comme 12 events par jour si il faut
  (11:51:48) Kiki: le 1er fake commence a 00h, le 2e a 2h, puis 4h, etc
  (11:51:57) Kiki: ca nous fait 12*255 characters pour les infos dans le commentaire
 -> A faire pour le channel guilde en premier (voir si faisable pour custom channel, eventuellement avec un "bridge" defini pour chaque guilde)
   -> on garde le principe du channel leader, seul lui modifie l'event (modif infos, tri)
     -> du coup, il faut que le leader du channel soit forcement qqun qui a les droits de modif sur les events guilde calendar
     -> voir pour arriver a conserver role/comment inscription et tout ca, surement via msg canal comme gem3

AMELIORATION DES PLUGINS DE TRI:
(13:28:15) Kiki: on peut configurer un sort plugin, au moment de la creation d'un event
(13:28:35) Kiki: en gros un sort plugin etends les donnees de creation d'un event (level, limites, etc)
(13:28:55) Kiki: ces donnees sont stockees dans l'event, dans une section "plugin custom data"
(13:29:22) Kiki: le sort plugin recup ses donnees de creation sans soucis (dans l event qu'on lui passe) lors du tri
(13:29:42) Kiki: on fait transiter les donnees aussi avec l event en brut dans un champ custom
(13:30:09) Kiki: il suffit juste d etendre l api des plugins, pour la creation, et la lecture d'un event (pour afficher ces donnees par ex)

  TODO:
    - Donner acces a la fonction qui recup le bon role d'une target en tnat qu'API (celle de BestTarget)
    - doc de GEM3_EVT_RecoverLostEvent,GEM3_EVT_RejectLostEvent,GEM3_EVT_DeleteLostEvent,GEM3_EVT_AcceptUpdatedRecoveredEvent,GEM3_EVT_RejectUpdatedRecoveredEvent
    - Gerer le cas d'un mec qui s'est desinscrit (passe en not-coming), et qui veut s inscire avec un reroll (histoire de pas avoir 50000 inscrits dans un event... sinon on laisse comme ca qd mm)
    - Quand le leader recoit une queue force, il verifie qu'elle soit correcte (un assistant peut forcer un titulaire par contre)
    - Gerer le kick/ban, en utilisant le message GEM3_COM_SubscribeError()   -> "GEM3_QA_Events.kicked[ev_id][name] = nil; -- Unkick me if I was" <- struct deja en place on dirait, utilise dans GEM3_SUB_SubscribeMyself
    - Pouvoir s'inscrire avec plusieurs reroll -> mettre une autre couleur dans la liste des events (que le vert qd on est inscrit), disant qu'on est inscrit mais avec un autre reroll
    - Add a sorting plugin : By assigning points to someone (DKP like)
    - Add a sorting plugin : By auto adding ppl on a list for the event (only when already created, by using AddExternal)
    - Option to limit event creation to officers (not possible but see CanViewOfficerNote() IsGuildLeader() )
    - Quand on veut supprimer le canal special Guild, il faut que le check se fasse sur n'importe quel canal guilde present, et non pas la variable speciale auto-generee (sinon marche pas si on a chang de guilde sur un autre PC)
    - Si on detecte que le leader est connect, lui envoyer directement les commandes subscribe/unsubscribe en send (permet d eviter les commandes stock sur les autres joueurs, et permet aussi d'envoyer les commandes avec un reroll qui n'est pas dans le canal GUILD
    - GEM_commands.lua: GEM3_CMD_ReceivedCommand dans la section "but I don't know the event. DO NOT ACK", ajouter la commande dans une liste de post-processing, qu'il faut check qd on recover un event (et si on l'ignore, envoyer des msg d erreurs aux commandes)

  TODO DEBUG:
    - Afficher un warning, si on detecte la creation d'une commande qui existe deja (avec le mm timestamp quoi)

  TODO SYNC:
    - 

  TODO GUI:
    - REVOIR le code de groupage (detection more raid/group), et virer le warning si je suis deja dans un grp
    - Option de config : Combien d'heures on garde un event pass
    - Possibility to remove offline members from the list (right clic on them)
    - Panel transparency
    - Option en plus dans la config du channel: Choisir quel ChatFrame utiliser pour les messages GEM
  TODO GUI MOVIX avant alpha:
    - page des options, General, Heure standard pour "LES NOUVEAUX" events (petites erreur syntax en passant) : si je scroll down les minutes, erreur lua
    - Gestion du CB de warning en cas de conflit timeref (j'ai pas verifi)
    - "Voulez vous vraiment supprimer cette vnement" -> "Voulez vous vraiment supprimer cet vnement" :)
    - page des options, General, "canaux" au lieu de "cannaux"
  TODO GUI MOVIX:
    - Scrolling dans la liste des events: Je propose de differencier 2 cas. 1) aucun event est "ouvert", si on scroll (souris) alors ca scroll l'ascenseur. 2) un event est "ouvert", si on scroll (souris) alors ca affiche l'event suivant/precedent, quelque soit la position de l'ascenseur
    - Afficher la liste des canaux dans les options, et pouvoir ajouter un canal (guilde uniquement, mais c'est le core qui fait le check de tt facons) en mettant par ex une case a cocher lors de l'ajout pour dire que c'est le canal guilde qu'on veut (l'UI passe la constante "GUILD" au core)
    - Pouvoir ajouter une liste de pr-inscrits dans un template d'event
    - GroupAll (accessible lead/assistants)
  
  KNOWN BUGS:
   - 

 TEST:
  - Tester le "OnSortingInconsistency"
  - Attention au CrashEvent, alors qu'on est en train d'en recover un, si un autre arrive pdt qu'on en recover un (tant que RejectLost ou RecoverLost n'a pas ete appele), ignorer ceux avec un update_time <=, sinon reappeler la fonction). La gui doit gerer le cas d un update d'un lost event en cours de recover
    -> Pareil pour le UpdatedCrashedEvent
  - Coder et Tester le changement de leader
  - Tester le nouveau mode de IgnoreEvent (on change l'update_time a "1", afin que nos futurs bcast apres unignore ne soient pas pris en compte, et qu'on update notre event des le prochain bcast)

