L2Character, L2PcInstance, L2PlayableInstance

[Zubastic]

В l2j она тоже одинаковая, мой юный ПТСник, т.к. большинство не статичных актеров наследуются от карактера.

Вот только параметры взяты статичные, а не рассчитываются динамически. На яве НПС это одна большая головная боль, да. И в ПТС я поболее твоего разбираюсь

[mountaineer]

Pointer*Rage, прошу прощения, я вас не понимаю.(

[n3k0nation]

Вот только параметры взяты статичные, а не рассчитываются динамически. На яве НПС это одна большая головная боль, да. И в ПТС я поболее твоего разбираюсь

Какие параметры и значения взяты - вообще по барабану, их не должно быть в коде, в хорошем случае.

Pointer*Rage, прошу прощения, я вас не понимаю.(

Плоскость

[ANZO]

Вот только параметры взяты статичные, а не рассчитываются динамически. На яве НПС это одна большая головная боль, да. И в ПТС я поболее твоего разбираюсь

Такое дело что в ПТС почти все так-же (вплане наследия) (исключаем наследника Playable и его чайлдов - они ,само собой, не нужны)

Пример:

Код:

case "creature":
                case "created_npc":
                case "deleted_npc":
                case "npc0":
                case "npc1":
                case "npc2":
                    varType = "L2Npc";
.......

                case "c0":
                case "c1":
                case "c_ai0":
                case "attacker":
                case "last_attacker":
                case "target":
                case "private":
                case "victim":
                    varType = "L2Character";
......

                case "talker":
                case "member":
                case "speller":
                    varType = "L2PcInstance";
......

Это еще не берем контейнеры gg, myself и всякие SpawnDefine.

Ничего плохого в наледовании нет, другое дело что ту же лыжу раньше писали школьники, которые учили собственно язык, делая эмулятор.
В итоге куча дублируеещегося когда из родителей и почти нулевое желаение перегружать модель тех же суперклассов. Сейчас это они, славтигоспади, поняли и меняют полностью архитектуру сервера.

[Gaikotsu]

что-то я так нормально и не понял чего хочет тс, кроме того что вроде как ему не нравится иерархия классов объектов в сервере и все это стоит упразднить и свалить все в один класс и в нем как-то определять, к какому типу игрового объекта это относится.

[mountaineer]

Pointer*Rage, а, ну окей. Спасибо. Но это меньшее, что может мне помочь, я не могу сам принцип работы карты понять и как движется герой, где это находится, что за это отвечает, можешь подсказать?

[n3k0nation]

Pointer*Rage, а, ну окей. Спасибо. Но это меньшее, что может мне помочь, я не могу сам принцип работы карты понять и как движется герой, где это находится, что за это отвечает, можешь подсказать?

Движется на плоскости, геометрия, школьный курс. Как именно актер может двигаться, это уже другой совершенно вопрос: от векторного передвижения до выстраивания обычной прямой.
Если лыжа есть на руках, то см. методы moveToLocation & routeNextPoint или типо того, по памяти уже не помню.

[mountaineer]

Pointer*Rage, пожалуйста будьте так добры, а поясните мне принцип этих чисел " 16_20, .._.. ", милости прошу, какую роль играют и что за чем следует, я не могу разобраться никак, можете рассказать алгоритм работы? Я не могу никак понять как они обрабатываются

Можете прям показать "кусок" скрипт-кода (или хоть что нибудь)", что не дает персонажу провалиться под карту?

Каждая кочка, камушек, каждая впадинка и пригорок обрабатываются как разные объекты? При столкновении с персонажем клиент дает сигнал или это рельеф?


---- Прошу прощение за столь глупые вопросы, но я устал разбираться в одиночестве и требуется помощь в понимании. Спасибо за понимание!

[i_am_kisly]

Pointer*Rage, пожалуйста будьте так добры, а поясните мне принцип этих чисел " 16_20, .._.. "

координаты квадрата x_y. Почему начинается не с 0_0 ? В душе не знаю почему корейцы зарезервировали номера первых тайлов.

Можете прям показать "кусок" скрипт-кода (или хоть что нибудь)", что не дает персонажу провалиться под карту?

За это отвечает сразу два механизма : детектор коллизий в физике клиента, и geo- движок на сервере. На L2J geo_engine что называется "из коробки" отсутствует, geo-data как правило или рисуют вручную, или генерят из .unr (особо "одареные" тупо копируют BSP геометрию, что по понятным причинам доставляет)

Каждая кочка, камушек, каждая впадинка и пригорок обрабатываются как разные объекты? При столкновении с персонажем клиент дает сигнал или это рельеф?

Я так подозреваю, что срвер о ней них и не знает вовсе. Если мне не изменяет память, то механизм следующий: клиент сообщает, что чар собирается двигаться из точки А в точку Б, далее уже в процессе движения делается проверка координат (собственно из-за этого возможен баг клиента с циклическим возвращением чара).

Прошу прощение за столь глупые вопросы, но я устал разбираться в одиночестве и требуется помощь в понимании. Спасибо за понимание!

Угу

[mountaineer]

На L2J geo_engine что называется "из коробки" отсутствует, geo-data как правило или рисуют вручную, или генерят из .unr (особо "одареные" тупо копируют BSP геометрию, что по понятным причинам доставляет)

С этого места поподробнее, не понял, тогда как он проверяет, что координаты верные, если карта рисованная?
Есть значит место где перечислены все координаты?
Или это работает как то по-другому? Ничего не понял, хоть убей.
Вот же заморочился ппц, спать спокойно не дает Веселуха!

уже в процессе движения делается проверка координат

Во! Откуда берется и как проверяется координата? Мне вот это не понятно.