Often when they write how scary everything is and how much there is to do, there is actually a simple and quick solution. for example, maybe "offset".
Looking for a skilled Java Dev to improve my server movement
- Автор темы markodemarko
- Дата начала
Geodata and pathfinding should not be split. This is all due to fact that both data and path approximation algorithm rely on fast access to determine which Z values need to be used. So in essence data will dictate algorithm and its performance. You can always use good old tried A* and see how horrible it is for any L2J variant performance (even newer A* flavors). Moving to vector movement or perhaps hybrid movement does not solve anything, since you'll be bound to same data (L2OFF or L2J, since it is very slow and non-optimal for Z lookups due to multi-layer structure scan) and suffer in pathfinding time.
I agree with Salty Mike that anything that touches Geodata/Geoengine ultimately becomes intertwined to great degree. Can these components live and act separately? Absolutely. However without understanding each one it will be hard to improve performance.
Can somebody tell why L2D and other formats were invented?
I agree with Salty Mike that anything that touches Geodata/Geoengine ultimately becomes intertwined to great degree. Can these components live and act separately? Absolutely. However without understanding each one it will be hard to improve performance.
Can somebody tell why L2D and other formats were invented?
L2J - as open source cannot use a original korean format
CONV_DAT / PATH_TXT - original korean formats
L2G / L2S - L2J format but with crypting;
RP - custom format which 100% the same as L2J;
L2M - format for saving info in one program ;D
L2D - trying to improve a "nswe" info, by adding into a geo-cell info about accessable of up-left \ up-right \ down-left \ down-right cells
Now l2d format is killed (no used) by their creators (l2acis)
Comment from head-dev (Tryskell) of acis -
Код:
THIS ONE | upper cell | THIS ONE
left cell | center cell | right cell
THIS ONE | lowest cell | THIS ONE
Java:
GeoMainCell upperCell = getUpperCell(block, cellX, cellY, layer);
GeoMainCell downCell = getLowerCell(block, cellX, cellY, layer);
GeoMainCell leftCell = getLeftCell(block, cellX, cellY, layer);
GeoMainCell rightCell = getRightCell(block, cellX, cellY, layer);
byte nswe = lookingCell.getNswe();
final byte nsweN = leftCell == null ? -1 : leftCell.getNswe();
final byte nsweS = rightCell == null ? -1 : rightCell.getNswe();
final byte nsweW = downCell == null ? -1 : downCell.getNswe();
final byte nsweE = upperCell == null ? -1 : upperCell.getNswe();
// north-west
if ((((nswe & GeodataCellDirectionFlag.FLAG_N.getMask()) != 0) && ((nsweN & GeodataCellDirectionFlag.FLAG_W.getMask()) != 0)) || (((nswe & GeodataCellDirectionFlag.FLAG_W.getMask()) != 0) && ((nsweW & GeodataCellDirectionFlag.FLAG_N.getMask()) != 0)))
{
nswe |= GeodataCellDirectionFlag.FLAG_NW.getMask();
}
// north-east
if ((((nswe & GeodataCellDirectionFlag.FLAG_N.getMask()) != 0) && ((nsweN & GeodataCellDirectionFlag.FLAG_E.getMask()) != 0)) || (((nswe & GeodataCellDirectionFlag.FLAG_E.getMask()) != 0) && ((nsweE & GeodataCellDirectionFlag.FLAG_N.getMask()) != 0)))
{
nswe |= GeodataCellDirectionFlag.FLAG_NE.getMask();
}
// south-west
if ((((nswe & GeodataCellDirectionFlag.FLAG_S.getMask()) != 0) && ((nsweS & GeodataCellDirectionFlag.FLAG_W.getMask()) != 0)) || (((nswe & GeodataCellDirectionFlag.FLAG_W.getMask()) != 0) && ((nsweW & GeodataCellDirectionFlag.FLAG_S.getMask()) != 0)))
{
nswe |= GeodataCellDirectionFlag.FLAG_SW.getMask();
}
// south-east
if ((((nswe & GeodataCellDirectionFlag.FLAG_S.getMask()) != 0) && ((nsweS & GeodataCellDirectionFlag.FLAG_E.getMask()) != 0)) || (((nswe & GeodataCellDirectionFlag.FLAG_E.getMask()) != 0) && ((nsweE & GeodataCellDirectionFlag.FLAG_S.getMask()) != 0)))
{
nswe |= GeodataCellDirectionFlag.FLAG_SE.getMask();
}Thanks, it was interesting to know the difference. Finally someone who makes sense in their comment. Well, back when Tryskell was reworking their movement and geodata, I tried to help and explain them some stuff, but they didn't seem they were listening much. They continued to talk about the L2D format being the solution to all their issues. Apparently, L2D format is just geodata with precalculated NW/NE/SW/SE paths. Other than trading CPU cycles for more memory usage, I do not see anything new. I kinda hoped that they'd at least present some more useful data, like UP/DOWN (in Z, for example, for how high up/down the cell's NSWE is valid) data or something like that.
Again, as I've said back in ACIS chat, the main issue is not the geodata's data, but it is the way the movement rays are casted. They are casted from geodata cell center to geodata cell center, not from actual world XYZ to actual world XYZ. Here is what I mean:
And this is what I can offer to fix right now for the creator of this topic. To make geodata actually calculate the proper path, which should minimize, or completely fix the "going through walls", "moving to different Z" bugs. But the issue of "movement ignoring geodata" while underwater or flying will still be there, if there is such issue in his pack.
Последнее редактирование:
im behind the Giran Castle and when im in water and swimming i see the Grids like the image and i can enter in castle
when im not swimming and i cant enter in castle i see the grids like this
guys i have this critical bugs with shit movement .. and i need a skilled dev to improve it ..
server was live and i lost many players bcs i dint knew this bug ... and one clan use it and took the castle .. :/
when im not swimming and i cant enter in castle i see the grids like this
guys i have this critical bugs with shit movement .. and i need a skilled dev to improve it ..
server was live and i lost many players bcs i dint knew this bug ... and one clan use it and took the castle .. :/
look this shit guys
i set allow water = false and bug remains u can enter
players could climp in castle from this area also , its harder for me to reproduce it of course
Seems like the 2 bugs I am aware of, that make this happen, are present for you. The "water ignores geodata" and the bad geodata path calculation. I do not know how to proceed with this, as I need to dedicate a lot of free time. It is very likely that it might take a lot of work and testing.
i tested giran castle with mobius geodata and devme geodata , i had ask him before many months to create me new geodata for castle ... the problem exist with mobius and devme geodata , so its 100% shit geo engine.
Yes, as I explained before, the problem is not the geodata files, but the engine. The first problem (the Z jump) is caused by incorrect calculation of geodata path, which is present in the geoengine and the second problem is the "water movement ignores geodata", which is present in the movement system itself. Fixing the geodata engine is relatively less time-consuming, after all, it is 1 class file and easier to deal with. I've already delt with it before. The movement system on the other hand, is a whole hell on it's own. In other words, it took me 50 commits and 131 files changed over the span of a month.
any suggection , what i do now xd
It's tough. Almost nobody was able to fix geodata and movement issues for all of l2j's existence. To be fair, in my opinion, this is one of the most complex parts of l2j. It really does require some good programming knowledge, low-level programming and, most importantly, math and geometry! Not many programmers know math and geometry very well. And honestly, I am one of those people too.
I've only seen an improved movement system over vanilla l2jserver in "org.mmocore" servers (I dunno which pack this is, it is old source). And even there, it also had its fair share of small issues, like movement happening only from cell center to cell center. And if I recall correctly, spam-clicking to move there would cause your character to glitch.
For now I can only think of suggesting you to try and fix the geodata engine, then disable the water in the castle to prevent the "water movement ignores geodata" bug there, and hope for the best... But this is a temporary solution and will not fix the glitches and other "small" stuff. It can only "hopefully" fix the castle geodata problems and other related problems as "z jump"/falling though floors.
I've only seen an improved movement system over vanilla l2jserver in "org.mmocore" servers (I dunno which pack this is, it is old source). And even there, it also had its fair share of small issues, like movement happening only from cell center to cell center. And if I recall correctly, spam-clicking to move there would cause your character to glitch.
For now I can only think of suggesting you to try and fix the geodata engine, then disable the water in the castle to prevent the "water movement ignores geodata" bug there, and hope for the best... But this is a temporary solution and will not fix the glitches and other "small" stuff. It can only "hopefully" fix the castle geodata problems and other related problems as "z jump"/falling though floors.
Да нет там ничего сложного, это даже проще, чем найти детерминант матрицы 4x4, просто кто захочет тратить свое время на фикс шарных сборок. Кто хотел давно в своих приватных все сделал
Извините, я не хочу обижать, но это звучит как ответ школьника, если честно. Просто очень плохо и без никакой добавленной стоимости. Вы хотите выразить себя, как будто вы делали это и вам всё понятно? Разве вы это делали? Если это факт, то я приношу вам мои извинения, мне будет очень интересно как вы подошли к этой проблеме. За столько лет я не увидел адекватного фикса, и в публичных и в приватных сборках. Мне тоже интересно кто из приватных сборок адекватно починил вся система передвижения.
Да никаких обид. Я давненько изучаю архитектуру игровых движков и видел много людей, которые отлично разбираются в линейной алгебре и алгоритмах поиска пути. В шарных сборках l2 присутствует малая часть той математики, которая к тому же довольно скудно, криво и скучно реализована. Пока что я в своей сборке не переделал передвижение, но я писал свой 3д рендер с нуля без прилинковки каких либо библиотек, и хорошо знаю линейную алгебру, поэтому мне хватает знаний, чтобы сказать, что передвижение в шарных сборках л2 реализовано плохо. Вы написали, что не много программистов знают математику и геометрию. Это не так, довольно много программистов знают довольно много разделов математики, а про геометрию даже говорить не приходится
Ну, например, я. Мой код не связан с мобусом и не основан на его коде. Мой геодвижок переписан практически полностью, умеет работать как с ПТС pathnode.bin, так и считает путь налету(и делает это лучше, лол) из файлов _conv.dat. Мной переписана модель движения как в воде и воздухе, так и по суше, включая вертикальную навигацию между слоями одного блока и сквозной поиск пути в 3D. В моей сборке есть встроенный редактор геодаты, который позволяет редактировать ее налету прямо из игры. Я писал некоторые статьи об этом тут и тут.
Если чего-то нет в свободном доступе или в продаже, это не означает, что этого не существует в целом. И я знаю еще минимум 3 человек, которые сделали это лучше меня в своих приватных проектах)
PS: В НОРМАЛЬНЫХ приватных сборках качество и уровень реализации все же смогли выйти за границы 2009 года и отказаться от стандартов разработки того времени)))
Последнее редактирование:
Ну, вот что-то действительно интересно. Спасибо за статьи и видео. Внутриигровой геоедитор крутой. Я не трогал геодату, просто движок геодаты и систему передвижения. Поэтому мне интересно что вы писали и узнал больше о ней. Вообще когда я переделывал всё это, я думал, что геодата l2j не так уж и плоха и не кричит "исправьте меня!", как движок геодаты и система передвижения. Я больше работал над критичными багами и глюками. Вот как работает у меня, используя геодаты l2j. И да, есть ещё, что можно починить, но пока что, всё работает достаточно хорошенько.
Вот как поиск пути работает. Да, я повысил конфигурации, чтоб сделать такой большой поиск пути, но цель была показать суть работы.
Вот как всё работает в 3D плане.
А в воде есть ещё кое-что починить... передвижение работает в 3D, но координаты клиента и сервера не всегда совпадают, поиска пути нет, хоть геодата работает.
Летение тоже не идеально. Синхронизация кажется лучше, чем в воде, геодата работает и блокирует передвижение когда необходимо, но к концу видео видно, что есть глюки в клиенте. Со стороны сервера всё хорошо, но клиент перепрыгает через мост, падает в воду и всякие другие визуальные глюки.
И я тоже хотел попробовать то, что вы делали в Глудине.
И да, в общем, я говорил что это сложно, потому-что есть сотни глюков и других неприятных вещей, которые тратят много времени, нервов и т.д. Передвижение - ладно, для этово нужно только линейная алгебра. Но потом, когда глюки позовут тебя, всё становится сложнее.
I have no solution yet.. please someone skilled text me.
look around, try to search a java server with fine geo-engine, which will meet your needs and rename topic or create a new one "looking guy, who can transfer geo-engine from source A to source B".
Why I write that - problem of geoengine - you do not understand whats wrong with him. If it will be a skilled dev - he will not waste a time for fix shit-engine for 20$ as result.
As writes before - you have only 1 solution - transfer from source A to your source a
