Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation on 12/19/23 in all areas

  1. This is such a minor tweak that I don't even really think it's worth creating a topic for, but my testers reported that this makes the game feel significantly smoother. This change attempts to address a desync issue when attacking. When clicking on a monster that is hostile and is also moving towards you, sometimes your character will fail to begin attacking because the client thinks it is within range to attack, but the character is actually too far away to attack on the server side. It's especially common with monsters that move fast. With this tweak, this situation should no longer happen. The change is in unit.cpp: Find this comment: // Player tries to attack but target is too far, notify client Add this line immediately afterwards: clif_fixpos(src); // synchronize the player's position with the client Don't change anything else. The finished code block should look like this. if(sd && !check_distance_client_bl(src,target,range)) { // Player tries to attack but target is too far, notify client clif_fixpos(src); // synchronize the player's position with the client clif_movetoattack(sd,target); return 1; Then just recompile the code and test it out. Everyone I had test it said it felt instantly noticeable. This does increase the number of packets being sent so this may cause a very minor increase to network traffic, but based on the number of packets that are typically sent back and forth I don't think the effect is very significant.
    1 point
  2. Because you are using mapannounce you need to use announce
    1 point
  3. Double check your database if you have a table named pvp_arenas If you don't have it, it will not show anything since you don't have that table.
    1 point
  4. So it turns out there's actually another version of this glitch where sometimes your character will fail to attack because they're at an extremely precise range where they are out of range to attack, but too close to move closer and then attack. This seemingly requires some degree of client desync and is rare, but it annoyed me enough that I spent many hours tracking down the exact problem. Find this in unit.cpp: if(src->type == BL_PC && ud->walktimer != INVALID_TIMER && (!battle_check_range(src, target, range-1) || ignore_range)) { (it occurs twice in the file) In both instances, replace it with this: if(src->type == BL_PC && (!battle_check_range(src, target, range) || ignore_range)) { if (ud->walktimer == INVALID_TIMER) { unit_walktoxy(src, target->x, target->y, 8); } Do not touch anything below this code, leave everything about the stepskills untouched. If your rathena is old, the ignore range part is not present so you are instead looking for this: if(src->type == BL_PC && ud->walktimer != INVALID_TIMER && !battle_check_range(src, target, range)) { Which you replace with this: if(src->type == BL_PC && !battle_check_range(src, target, range)) { if (ud->walktimer == INVALID_TIMER) { unit_walktoxy(src, target->x, target->y, 8); } The problem is that if the user is too close for the client to execute a move to attack instruction, but not close enough to attack, the walktimer will not be initialized, but the range check will fail. It should execute a stepskill in this situation, but it does not because it requires a valid walktimer to execute a stepskill. This handles this boundary case by forcing the user to approach the target, as the client would do automatically under all other circumstances. This is maybe not the most graceful solution (maybe they should just move one tile closer to the target?) but it works and the problem can no longer occur.
    1 point
×
×
  • Create New...