Jump to content

Cysgod

Inactive Member
  • Posts

    28
  • Joined

  • Last visited

  • Feedback

    0%

Posts posted by Cysgod

  1. 25 minutes ago, martysama0134 said:

    There are far better solutions than using std::map or std::unordered_map (which still takes a lot of ram for no reason for each mob):

     (I included the most important parts)

    You also forgot the CubeItems, and we could probably fit the quickslot too.

    That's exactly what I did. Running since 24. Oct without any problems.

    Spoiler

  2. Did anyone test the impact on cpu usage or the time needed for the execution of the functions? The usage of a ordered std::map should be (in theory) way slower.

    ATM I moved the fixed sized arrays into a new struct and added a shared_ptr as member variable to the CHARACTER class. When "SetPlayerProto" gets called I'll create a shared_ptr of the new struct. - Which ofc means I wont save any memory for players which don't use all slots.

    In idle (without players) this results in a drop from 1480mb to 540mb ram per channel -> ~64% less ramusage.

  3. Maybe someone can make use of it:
     

    spacer.png

     

    Sourcechanges:

    Spoiler


    discord_rpc.h (in the rpc source & your extern folder)

    // Search the struct and replace it
    
    typedef struct DiscordRichPresence {
        const char* state;   /* max 128 bytes */
        const char* details; /* max 128 bytes */
        int64_t startTimestamp;
        int64_t endTimestamp;
        const char* largeImageKey;  /* max 32 bytes */
        const char* largeImageText; /* max 128 bytes */
        const char* smallImageKey;  /* max 32 bytes */
        const char* smallImageText; /* max 128 bytes */
        const char* partyId;        /* max 128 bytes */
        int partySize;
        int partyMax;
        const char* matchSecret;    /* max 128 bytes */
        const char* joinSecret;     /* max 128 bytes */
        const char* spectateSecret; /* max 128 bytes */
        const char* buttonLabel; /* max 128 bytes */
        const char* buttonURL; /* max 128 bytes */
        int8_t instance;
    } DiscordRichPresence;

     

    serialization.cpp (in the rpc source):

    // Search:
    
                    if ((presence->partyId && presence->partyId[0]) || presence->partySize ||
                        presence->partyMax) {
    
    // Add ABOVE:
    
                    if (presence->buttonLabel && presence->buttonLabel[0] && presence->buttonURL && presence->buttonURL[0]) {
                        WriteArray assets(writer, "buttons");
                        WriteObject btn1(writer);
                        WriteOptionalString(writer, "label", presence->buttonLabel);
                        WriteOptionalString(writer, "url", presence->buttonURL);
                    }

     

    In your client source you have to add it to the RPC update:
     

    	discordPresence.buttonLabel = "Join Servername2's Discord";
    	discordPresence.buttonURL = "https://discord.gg/ASDASDASDIASDASDAOPS";
    
    	Discord_UpdatePresence(&discordPresence);


     

    • Metin2 Dev 1
    • Good 1
    • Love 2
    • Love 5
  4.  

    As far as I know there are two ways to create a wait hack:

     

    1) Exploiting the too high defined range, in which a attack packet is accepted (300 for damage, 5000 for pulling) (Widely known as "wait Hack")

     

    2) Sending Move Packets to "teleport" to the monster (you wont see that in your client) and after that sending a attack packet. (Widely known as "range wait hack")

     

    How ever, If both ways are blocked serverside, they obv. won't work. You could (If you coded the cheat on your own) play arround with the attack range, move range and packet count to find out which could work. 

     

    I doubt that there is any tutorial for that stuff.

×
×
  • Create New...

Important Information

Terms of Use / Privacy Policy / Guidelines / We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.