Jump to content

PACI

Developer
  • Posts

    402
  • Joined

  • Days Won

    18
  • Feedback

    0%

Posts posted by PACI

  1. Hello.

     

    I reckon important to always log datetimes of actions. The table you provide there could use an account ID field (so you can basically track the account that was HWID banned) and a datetime row (for verification purposes if ever needed). Maybe then limit the rows of that query to 1, since one single result is plenty enough for this verification to do its job.

    This is considering you have a game management platform (adminpage) where you (or your teammates) can trigger these type of actions.

     

    It's also important, the moment of the ban to update the state of the affected account to 'BLOCK' instead of simply adding its hwid into a table, or you might just end up having this player use other methods to enter the game under this (supposedly) locked account.

     

    For the rest, you should probably only update the player's HWID once it reaches the handshake phase, because there is just no need to do so beforehand, especially when (during server launches or restarts) a lot of people tend to connect all at once.

     

    These are only friendly advises that in my opinion are important to consider for this particular addition. But the content OP proposed is definitely a start!

     

    Good share!

    • Metin2 Dev 1
    • Good 2
    • Love 1
  2. There are plenty of other methods to cancel skill animations. It is not exclusive to switching gear, you can also do it by triggering certain emotions, or playing with certain items that often cause some lag (due to the massive usage of CHARACTER::ComputePoints() perhaps, such as the Auto-potions, or Dragon Soul).

     

    You could start doing that, but my advise is to consider each skill individually, as their animations have different duration. Using the same value as cooldown will not do the trick.

  3. 21 hours ago, Cappuccino said:

    Costume bonuses are taken from item_attr table but this is quite a limit.

    May I ask why is this limited?

    You could as well just create separate fields for costume_body, costume_head, costume_weapon (or even costume_acce, if wanted), in the common item_attr table, and you'd break the limitation, if any.

  4. Couple of things.

    A server_timer is an event that is supposed to run once. Unless you decide to make a loop out of it - which on this case, it'd make sense to use clear_server_timer to ensure you cancel it.

     

    Obviously, you must bind map indexes into them, especially when it comes to dungeons, since they mostly are private instances, their indexes go up to 10.000, so you want these timers to run exclusively on the runs. The first approach is correct.

    Nevertheless, I recommend you to keep using d.get_map_index upon clearing them - since it is exactly the function you should use.

     

    About the flags. Yes, you're doing it correctly. I don't remember, though, if dungeon flags' definitions are set and updated on the fly, though you can use this preferred and common practice used in quest-flags, however it's all about taste:

    local my_flag = d.getf("Flag1") + 1
    d.setf("Flag1", my_flag)
    
    if my_flag == 150 then
    	d.setf("Flag1", 0)
    end

     

    As for the issue you described, and you seem unsure where it comes from. Personally, I'm not quite familiar with it, and don't even have such log in my files, but I can only guess it's related to a malfunction in the usage of the npc.lock and npc.unlock quest-functions. My advice is to review any quest that uses either of them and attempt to trigger this error - then you'll find where it comes from.

    • Love 1
  5. Not only skill_proto entries were changed but also formulas and algorithms from the core. So you will not reach that balance you talk about solely with it.

     

    My advice is to make your own set of changes based on how your server is built. It will take a good while, probably, but there is no shortcut when it comes to jobs well done.

    • Love 2
  6. 1 hour ago, VegaS™ said:

    You just have to use party.is_party before calling the function and everything will be fine

    Actually no because party.is_party() verifies if the current pc belongs to a party - which does not meet the requirement of the quest, apparently. That is: to retrieve the vid of the leader of the monster's group in order to progress further (npc).

    In short, on this case, having such verification prior to the vid-condition, without fixing it on the source, is not going to address the issue. In fact, it will trigger it in case the player running the quest has a group.

    • Love 3
  7. 40 minutes ago, xP3NG3Rx said:

    My opinion about these kind of contents: It kills the cooperative, multiplayer gameplay feeling which drives the private servers to death.
    All of you can think about it, if you would like to open a private server. If you don't need a support character, who could be your friend or a stranger person, you gonna lose after a while players time by time when they get bored.

    Allow me to do a quick off-topic, as I would like to respond to this part of the message above. I definitely agree with you! But from a more realistic point of view, there's a close-to-none playerbase that would actually like to cooperate on Metin2.
    The mindset is quite simple: why would I wait for someone to help me if I can do it alone, without sharing any possible profit I can get from playing the game?

    Let me reference again that I do concur with what you just said, and between playing alone or with somebody else, I would pick the latter option. However not you, nor me, nor any of us here are the ones who make the difference on our possible servers, but the ones who actually play them, and have been playing all of these years.

    As the private scene of Metin2 grown up, several QoL modifications have been seeing the light. Changes the community seems to like, some of them are, indeed, great and a must have. However, these have gone a bit too far, though, apparently, they defined a new standard on the scene.

     

    • Love 5
×
×
  • 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.