Aller au contenu

Nouveau membre ?! Pense à te présenter pour accéder au contenu du forum !

New member ?! Introduce yourself to get access to the forum !

Cassegrain

Membre
  • Compteur de contenus

    10
  • Inscription

  • Dernière visite

  • Points

    0 [ Donner ]

Réputation sur la communauté

3 Neutre

À propos de Cassegrain

  • Rang
    Moussaillon

Visiteurs récents du profil

Le bloc de visiteurs récents est désactivé et il n’est pas visible pour les autres utilisateurs.

  1. Pas de souci. Les coordonnées de ta map ne sont pas bonnes, puisqu'elles ne sont pas divisibles par 256 comme je te l'ai indiqué. 77452 / 256 = 302,8984375 Corrige ça partout (Setting.txt serveur, setting.txt et atlasinfo.txt client) et ça devrait fonctionner.
  2. [Contenu Masqué] Voilà un outil qui te sera utile pour gérer ton atlasinfo et les coordonnées de tes maps. Les map fonctionnent même si leurs coordonnées ne sont pas divisibles par 256, le problème est lié aux attributs de la map. Les maps sont divisées en carrés de 256x256 (qui équivaut à une map 1x1). Comme sur l'outil d'au dessus, imagine les maps sur une grille de ces carrés. Lorsque tu mets une map dans la grille, les attributs de la map vont se positionner dans le coin en haut à gauche du carré dans laquelle elle se trouve, même si la map n'est pas dans le coin. Ce qui fait que toutes les safezone / zone passables / non passables sont décalées. Ca n'affecte que la partie serveur, tu pourras faire le test si tu veux.
  3. Yop, Il faut savoir que les safezone client et serveur ont deux actions différentes. Celle du serveur fait en sorte qu'un personnage à l'intérieur d'une safezone ne puisse pas recevoir de dégâts d'autres joueurs ou d'attaques de monstres. Par contre, celle du client empêche un joueur d'infliger des attaques. Comme on peut le voir sur ta vidéo, lorsque le personnage est en safezone, il continue de recevoir des attaques mais ne reçoit plus de dégâts. C'est donc la partie client qui pose problème. En premier lieu vérifie que la version de la map dans ton client est bien la dernière. Ensuite, tu peux vérifier les coordonnées sur lesquelles tu as mis ta map, il faut qu'elles soient divisibles par 256, si ça ne l'est pas, il peut y avoir un décalage des attributs de la map; et identiques (Setting.txt serveur, setting.txt et atlasinfo.txt client)
  4. Yop, Il te manque la class ExpandedTaskBar qui, sur l'interface de l'offi, est accessible en cliquant sur le bouton au centre de la barre de skill et qui permet d'ouvrir un menu contenant des boutons. Tu es en train d'essayer d'ajouter le bouton permettant d'ouvrir la fenêtre de familier à l'intérieur de cette extension. Sur l'interface Illumina, le bouton au centre est sensé simplement ouvrir / fermer le chat comme c'était le cas sur l'interface de l'offi avant l'alchimie des pierres dragon. Tu as donc plusieurs options. Soit tu ajoutes la class qu'il te manque en la reprenant de l'offi et tu modifies l'action du bouton du chat pour permettre de l'ouvrir; ou alors tu mets ton bouton ailleurs, comme par exemple sur le bord de l'inventaire. N'hésite pas à lire le code pour essayer de comprendre. Si tu as changé ton interface et qu'un tuto s'adapte à celle de l'offi, essayer de comparer les fichiers de l'offi et les tiens pour voir ce qu'il te manque me semble être une bonne démarche lorsque tu rencontres un souci tel que celui-ci. Tu vas y arriver !
  5. Bonne initiative, surtout au niveau des explications. Je pense que pas mal de personnes ne prennent pas la peine d'essayer de comprendre ce qu'ils font en suivant un tuto, au moins ici, chaque chose est expliquée. Niveau compression du client, je crois qu'il faut pas chercher trop loin. Après quelques comparaisons, je suis passé sous LZ4 surtout pour ne plus utiliser l'algo de base et compliquer la tâche à quelqu'un qui voudrait faire un depacker. Le client est légèrement plus lourd qu'en LZO (+8% environ). Le premier chargement est plus rapide (-15%) environ. La fluidité en jeu reste la même, à l'oeil nu on ne voit pas beaucoup la différence sur quelques centièmes de seconde. Il y a beaucoup d'outils pour compresser. Moi je suis parti vers LZ4 qui a été celui qui offrait les meilleurs performances en terme de décompression pour le client. La compression en LZMA est plus optimale, mais la décompression est plus longue. Faut peser le pour et le contre et voir ce qui compte le plus. Je ne me suis pas encore tourné sur l'encryption des fichiers, mais oui, regrouper les packs et index ou compiler les index dans le lanceur est un bon moyen d'empêcher de les avoir. Les clés de cryptages sont jamais très sûres, peu importe les efforts que vous fournirez à les cacher. Le mieux est de refaire un algo unique. C'est beaucoup plus dur à reverse. Il faudra par contre, comme l'a dit Kijaru, penser à désactiver / retirer les fonctions pack du python dans le lanceur au cas où quelqu'un injecterait un script python dans le client. Comme d'habitude, il faut éviter de trop compter sur l'anti cheat pour ce genre de choses. Au lieu des pyc, compiler son root / uiscript en C avec cython ? Y'a des tutos depuis pas mal de temps. Les fichiers python sont convertis en C puis compilés en lib qui finit dans le lanceur. On gagne environ 10% de performance globale sur l'interface du jeu. Même si certains fichiers en C font + de 50.000 lignes, c'est bien plus rapide qu'en python. Là encore, à l'oeil nu, à moins d'avoir une fenêtre d'interface très chargées, on ne remarque pas vraiment la différence, mais y'a pas mieux pour obfusquer ses scripts. (A moins d'oublier de le faire avant de faire une mise à jour, comme l'a fait l'offi il y a peu...) C'est tout ce qui me vient pour l'instant ! Le mieux, c'est de ne pas batifoler dans tous les sens. Gardez un jeu à peu près fluide et réfléchissez avant de vous lancer dans de grosses modifications comme ça. Voyez si ça vaut le coup, comparez différentes méthodes etc... Bon chance !
  6. Hello, C'est se compliquer un peu la tâche pour pas grand chose. L'ajout d'une simple variable dans le constInfo modifiée à l'ouverture et fermeture de l'entrepôt suffirait, comme c'est le cas pour la variable isItemQuestionDialog. Toutes ces modifications ne me semblent pas nécessaires. L'utilisation que tu en fais est bonne cependant !
  7. Attention aux failles de sécurité ! Le string de raison n'est pas escapé et il n'y a visiblement aucune restriction sur les caractères que l'on peut y mettre. Même si cette commande ne peut logiquement être utilisée que par un Game Master, il serait tout de même dommage de laisser une vulnérabilité capable de supprimer ou modifier l'ensemble de vos données sql ! Voici la commande corrigée: ACMD(do_ban) { // Args char arg1[256], arg2[256], arg3[256]; // Local variables const char* szName; const char* szReason; char szReasonEscape[1024]; int iDuration; one_argument(two_arguments(argument, arg1, sizeof(arg1), arg2, sizeof(arg2)), arg3, sizeof(arg3)); // Invalid syntax if (!*arg1 || !*arg2 || !*arg3) { ch->ChatPacket(CHAT_TYPE_INFO, "Invalid Syntax, usage: tip: don't use spaces in the reason, use _"); return; } szName = arg1; iDuration = atoi(arg2); szReason = arg3; // Escape szReason to szReasonEscape DBManager::instance().EscapeString(szReasonEscape, sizeof(szReasonEscape), szReason, strlen(szReason)); if (iDuration <= 0) { ch->ChatPacket(CHAT_TYPE_INFO, "Duration can't be 0 or minus."); return; } LPCHARACTER tch = CHARACTER_MANAGER::instance().FindPC(szName); if (!tch) { ch->ChatPacket(CHAT_TYPE_INFO, "%s is not playing", szName); return; } if (!tch->GetDesc()) { ch->ChatPacket(CHAT_TYPE_INFO, "%s don't have desc", szName); return; } if (tch == ch) { ch->ChatPacket(CHAT_TYPE_INFO, "What's wrong with you? Don't ban yourself"); return; } if (tch->GetGMLevel() > GM_PLAYER) { ch->ChatPacket(CHAT_TYPE_INFO, "Do not ban GMs"); return; } std::auto_ptr msg(DBManager::instance().DirectQuery("INSERT INTO account.ban_ingame (id, name, begins, finish, reason) VALUES ('%d', '%s', NOW(), FROM_UNIXTIME(UNIX_TIMESTAMP(CURRENT_TIMESTAMP()) + %i), '%s')", tch->GetAID(), tch->GetName(), iDuration * 3600, szReasonEscape)); DBManager::instance().DirectQuery("UPDATE account.account SET status = 'BLOCK' WHERE id = %d", tch->GetAID()); tch->GetDesc()->DelayedDisconnect(5); sys_log(0, "%s[%d] banned %s for %i hours with reason: %s", ch->GetName(), ch->GetPlayerID(), szName, iDuration, szReasonEscape); ch->ChatPacket(CHAT_TYPE_INFO, "%s has been banned for %i hours with reason: %s", szName, iDuration, szReasonEscape); } Je n'ai pas testé mais ça devrait fonctionner. De plus, je n'ai pas compris pourquoi le status du compte est mis à BLOCK alors que seul availDt pourrait directement avoir la date de fin du bannissement pour que le débannissement soit automatique. Il faudrait remplacer : DBManager::instance().DirectQuery("UPDATE account.account SET status = 'BLOCK' WHERE id = %d", tch->GetAID()); par : DBManager::instance().DirectQuery("UPDATE account.account SET availDt = FROM_UNIXTIME(UNIX_TIMESTAMP(CURRENT_TIMESTAMP()) + %i) WHERE id = %d", iDuration * 3600, tch->GetAID()); Petite remarque supplémentaire, il me semble qu'il n'est pas nécessaire de sélectionner la table account dans les query. Pour ceux qui ont modifié le nom des tables, je pense, mais sans certitude, que l'on peut simplement retirer "account." des deux query. Merci tout de même !
×

Information importante

By using this site, you agree to our Conditions d’utilisation.