АХРИНЕТЬ.... вот это патфайндинг.... просто чума как по лестнице поднимается! и тулзы крутые
Ну, например, я. Мой код не связан с мобусом и не основан на его коде. Мой геодвижок переписан практически полностью, умеет работать как с ПТС pathnode.bin, так и считает путь налету(и делает это лучше, лол) из файлов _conv.dat. Мной переписана модель движения как в воде и воздухе, так и по суше, включая вертикальную навигацию между слоями одного блока и сквозной поиск пути в 3D. В моей сборке есть встроенный редактор геодаты, который позволяет редактировать ее налету прямо из игры. Я писал некоторые статьи об этом тут и тут.
Если чего-то нет в свободном доступе или в продаже, это не означает, что этого не существует в целом. И я знаю еще минимум 3 человек, которые сделали это лучше меня в своих приватных проектах)
PS: В НОРМАЛЬНЫХ приватных сборках качество и уровень реализации все же смогли выйти за границы 2009 года и отказаться от стандартов разработки того времени)))
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.I have no solution yet.. please someone skilled text me.
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.
i will text u when i got time , if i fail to solve this, give me some time please.So what kind of things need to be fixed? And what kind of visual glitches are there usually? Aside from falling through floor.
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.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) ?
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.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.
This action list is actually pretty good, I would add: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.
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.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
We use cookies and similar technologies for the following purposes:
Do you accept cookies and these technologies?
We use cookies and similar technologies for the following purposes:
Do you accept cookies and these technologies?