АХРИНЕТЬ.... вот это патфайндинг.... просто чума как по лестнице поднимается! и тулзы крутые
Looking for a skilled Java Dev to improve my server movement
- Автор темы markodemarko
- Дата начала
АХРИНЕТЬ.... вот это патфайндинг.... просто чума как по лестнице поднимается! и тулзы крутые
Unfortunately right now I am full with other stuff to deal with. And still, the only thing I can do for you right now, is to try and fix the geoengine. But that will feel like a duct-tape fix than a full fix, as the visual glitches will still be there. At least no critical exploits will be present.
So what kind of things need to be fixed? And what kind of visual glitches are there usually? Aside from falling through floor.
Falling through the floor is not a visual glitch, but a real bug. The geoengine doesn't correctly calculate the path you move through and sends you to a whole different Z level.
What needs to be fixed at geoengine side is:
1) Correct calculation of movement path and which geodata cells it moves through.
2) Correct checks of availability of movement from one cell to another. Or one Z level to another.
3) Correct checks of Z level and proper readjusting of it for ground movement.
What needs to be fixed at movement system:
1) Do not ignore geodata while swimming or flying. Use 3D geodata checks.
2) Synchronize the client<->server position. Use the correct formula for movement speed. In the first ~500ms when movement starts, the player needs to use walking movement speed.
3) Correct the relative location inside Vehicles (Boats, Airships) and allow fluent transition from world XYZ to relative XYZ when entering the said vehicles.
4) Correctly start/stop movement when you can and cannot move. Correctly reflect switching from walking/running. Same for NPCs. They would otherwise appear as walking or stopped, but when you target them, they will appear at some totally different place.
5) Correct the pawn following, and overall the following system. If it is not correct, you will have problems with attacking moving targets.
And pathfinding needs to be fixed, if you feel extra fancy. But this is something that is not as critical and obvious to fix as the others, imo.
As for the visual glithes, there are so many.
For example, creatures appearing to be running, but not. Or creatures to appear to be on one place, but when you click on them, they appear to be walking, or in a totally different place.
Rubber-banding is also a problem, which occurs due to bad synchronization of client/server positions. Or you appearing at some location, which you are not at.
When entering in water, you instantly fall to the bottom. This happens, if client's movement type is ground movement still, so it ignores the water animations and directly falls. But in the server you are still swimming and somewhere in the middle of the water.
On my video with the wyvern, at the end of it, you can see other visual glitches, how it skips the bridge and appears on top of it, or how it falls in the water instantly.
There are more things, but this is what I can think of right now.
And the main issue is that, if you try to fix one thing, you might break another and cause another bug. So it is endless bore of trying to fix something and testing to see if you haven't broken something else. It is 50/50.
What needs to be fixed at geoengine side is:
1) Correct calculation of movement path and which geodata cells it moves through.
2) Correct checks of availability of movement from one cell to another. Or one Z level to another.
3) Correct checks of Z level and proper readjusting of it for ground movement.
What needs to be fixed at movement system:
1) Do not ignore geodata while swimming or flying. Use 3D geodata checks.
2) Synchronize the client<->server position. Use the correct formula for movement speed. In the first ~500ms when movement starts, the player needs to use walking movement speed.
3) Correct the relative location inside Vehicles (Boats, Airships) and allow fluent transition from world XYZ to relative XYZ when entering the said vehicles.
4) Correctly start/stop movement when you can and cannot move. Correctly reflect switching from walking/running. Same for NPCs. They would otherwise appear as walking or stopped, but when you target them, they will appear at some totally different place.
5) Correct the pawn following, and overall the following system. If it is not correct, you will have problems with attacking moving targets.
And pathfinding needs to be fixed, if you feel extra fancy. But this is something that is not as critical and obvious to fix as the others, imo.
As for the visual glithes, there are so many.
For example, creatures appearing to be running, but not. Or creatures to appear to be on one place, but when you click on them, they appear to be walking, or in a totally different place.
Rubber-banding is also a problem, which occurs due to bad synchronization of client/server positions. Or you appearing at some location, which you are not at.
When entering in water, you instantly fall to the bottom. This happens, if client's movement type is ground movement still, so it ignores the water animations and directly falls. But in the server you are still swimming and somewhere in the middle of the water.
On my video with the wyvern, at the end of it, you can see other visual glitches, how it skips the bridge and appears on top of it, or how it falls in the water instantly.
There are more things, but this is what I can think of right now.
And the main issue is that, if you try to fix one thing, you might break another and cause another bug. So it is endless bore of trying to fix something and testing to see if you haven't broken something else. It is 50/50.
Оверпостинг
Regarding rubber-banding and server-client position de-sync for npcs/objects, I regard that problem as insufficient updates from server to client. Basically L2J style knownlist and keeping track of moving objects outside of its broadcast radius, which is solvable by various means, easiest and non-optimal would be broadcast in world region (depending on size of course). However, it is not a problem of geodata, nor movement.
As for other things you listed, has there been any work to improve geodata beyond simply using same format (8x8 block of cells with NSWE flag, even keeping same block types) ?
As for other things you listed, has there been any work to improve geodata beyond simply using same format (8x8 block of cells with NSWE flag, even keeping same block types) ?
i will text u when i got time , if i fail to solve this, give me some time please.
No, it is not due to insufficient updates from server to the client. The update is what causes the rubber-band effect, as the server corrects the client position to match the server position. The issue usually occurs when there is a mismatch between the server's movement speed and client's movement speed, and both calculate the movement wrongly. In l2j, movement speed is always taking running/walking speed, but in the client, the first 400-500ms when you start moving, you are walking, and then you start running. This is one cause of this desync. It also occurs when the client thinks it can move, and it moves, but the server doesn't allow movement and keeps the position unchanged (usually happens when you spam click to go somewhere and client goes, but the server doesn't, due to geodata blocking it). You can see those glitches in my video with the wyvern. Also, take note of the blue spheres in my videos. They mark my position in the server. The moment they start to differ way too much, a rubber-band will happen.
Also, I did not work on geodata format at all. I didn't need it changed in order to achieve a decently enough working geodata engine, movement system and pathfinding. I do not even know what more is needed in the geodata format...
One thing is for sure though. As far as I've seen, in retail, the water zones are integrated within the geodata. I have no idea how, but the geodata engine knows if one geodata block is a water block or not. Digging into this will help for sure for moving underwater.
We are talking about same thing. You see it as problem of geodata. I see it as problem of server NOT recognizing cases where client needs to be either stopped, or properly synced. Hence, the outcome of client not respecting position on server. There are different ways to solve it, from server movement as you describe it, to server compensation of movement and handling of ValidatePosition packet.
Is there a problem with geodata? Absolutely, just inspecting L2J H5 files I see oddities here and there ( I see these in-game, not through any editor ). However I do not know a better way to deal with that except getting a better set of files (premium or not).
The reason I asked about improving geodata is because in its current state (L2J style) is very hard to work with. As I have previously mentioned the format does not allow constant time to arrive at a cell Z value (see multi-layer block ), nor easy look up which Z value to choose from based on Z range. For my server implementation I improved that. Instead of three L2J blocks I have seven. I also sort all values across multiple layers into new layers (and this is also how I can spot if there are problems with geodata values), preserving original layer count. Improvement for me is constant lookup of layer Z values and reduced geodata size (approximately 35% less than in L2J original), all while containing same NSWE flags (no data loss). Pathfinding is not implemented yet, however new block types are geared toward easy look ups for question "do I engage pathfinding?" or "can I travel through block without pathfinding".
Once you start digging into such problems like desynchronize, you start to notice the hundreds of small issues that appear and you need to address. This is why everything is so complex and time-consuming. Too many unexpected small issues that need addressing.
Also yeah, if you engage in changing the geodata format, for sure you can achieve some great optimizations. But the base and most important data is already there in the original l2j format. And it is what I chose to work with. There is a great deal to fix without even touching the l2j format. Once everything is fixed, optimizations can come. But a solid working base is necessary for that. Actually, the l2j's geodata engine doesn't need that many changes to make it decently good (at least to not have critical bugs).
The most critical thing is the path calculation that finds out which cells it goes through. In L2J (and many other private packs) is just plainly WRONG, because it converts world XY (of start and end point) into geodata XY (start and end cell), and uses geodata XY to calculate which cells it goes through. And in the end of the calculation, it re-converts the geodata XY into world XY, but inaccurate world XY, as they always point to the center of the cell and are not equal to the original world XY. And the movement starts from the XY it requested, but the geodata check was done at the XY of the cell center, and we end-up moving through different geodata cells than we've checked. And this is how we end-up moving through walls, falling underground, etc. Take a look at the poorly painted explanation in my previous post here: Looking for a skilled Java Dev to improve my server movement
Fixing this one issue will solve the major issue of geodata engine. With it solved, you can finally be able to rely on the geoengine to do a proper path check and to tell you for sure if the path you requested is traversible or not.
Also yeah, if you engage in changing the geodata format, for sure you can achieve some great optimizations. But the base and most important data is already there in the original l2j format. And it is what I chose to work with. There is a great deal to fix without even touching the l2j format. Once everything is fixed, optimizations can come. But a solid working base is necessary for that. Actually, the l2j's geodata engine doesn't need that many changes to make it decently good (at least to not have critical bugs).
The most critical thing is the path calculation that finds out which cells it goes through. In L2J (and many other private packs) is just plainly WRONG, because it converts world XY (of start and end point) into geodata XY (start and end cell), and uses geodata XY to calculate which cells it goes through. And in the end of the calculation, it re-converts the geodata XY into world XY, but inaccurate world XY, as they always point to the center of the cell and are not equal to the original world XY. And the movement starts from the XY it requested, but the geodata check was done at the XY of the cell center, and we end-up moving through different geodata cells than we've checked. And this is how we end-up moving through walls, falling underground, etc. Take a look at the poorly painted explanation in my previous post here: Looking for a skilled Java Dev to improve my server movement
Fixing this one issue will solve the major issue of geodata engine. With it solved, you can finally be able to rely on the geoengine to do a proper path check and to tell you for sure if the path you requested is traversible or not.
This action list is actually pretty good, I would add:
- calc move / swim / fly speed multipliers in User Info packet with correct scale, to have exact values between client <-> server
- recalc precisely positions on turn - stop - move actions, basically on any actions that affect moving
- take into account stop-move animations ( on geopath for example) resets character running state and cause 500ms walking
- consider rotation timing on turns, turn on 180 degree costs character significant amount of ms of movement
Yeah, using correct multipliers is something of a must, if you want to avoid coord desynchronization as much as possible. For moving on geopath, you can work around and avoid the moving stop and starting again, and thus avoid the badly looking slowdown when you take turns on it. I do not remember how it was in retail, but to me it seems much more intuitive, if your character didn't stop on every point on the geopath. But yeah, there might be some rotation delay in the movement, which I haven't studied yet. This might also add some desynchronization between client and server calculation in movement. In general, there are tons of such tiny things you need to investigate and take account for.
