Перейти к содержанию

PointerRage

Постоялец
  • Публикаций

    126
  • Зарегистрирован

  • Посещение

  • Победитель дней

    6
  • Отзывы

    0%

Сообщения, опубликованные PointerRage


  1. Я просто скажу, что волноваться стоит далеко не о логике в ядре сервера. И да, лично я заниматься экстом клиента буду не менее, чем за 600 баксов, поэтому меня можете вычеркивать из списка потенциальных исполнителей:)


  2. Если делать через аугментацию, то это даст невозможность наложения оригинальной аугментации на предмет, если на нем лежит печать. Атрибутов в ИТ клиенте нет:)  Касательно клиента: экстендер пакетки айтемов + расширение пакета аугментации. Тут же понадобится правка u-скриптов. Мало того, экстендер будет несовместим с любыми "защитами" (для СГ - решаемо, там есть система модулей).

    В общем, это никак не 50 баксов и даже не 200. А если вводить систему а-ля атрибуты на клиент, то ценник уезжает за штуку баксов и очень близок к 2к. 

    Рекомендую переосмыслить свою идею:)

    • Like 1

  3. В 05.07.2019 в 20:07, KaRmiN сказал:

    ну, я выбираю между ксеонами, у них, как бы видео ядра нету

    Возьмите самый дешевый IP-KVM (на али по цене блока сигарет). Это намного удобнее в плане администрирования, чем подключать всякие мониторы, мышки, клавиатуры и все такое. К тому же можно будет даже не поднимать удаленный доступ, можно будет выбросить KVM морду в мир и вперед. Полный доступ, вплоть до настройки биоса.

    • Upvote 1

  4. Спойлер

    Хз про какие мифические 70% серверов идет речь, лидер до сих пор SW. Впрочем, я и мои знакомые всегда заказывали/делали самопис, но нас таких мало.

    А довольны, потому-что за 300-400 баксов Вы не получали COL-ы из воздуха, которые разработчик не мог исправить для лайва в течении недели при этом добавляя еще багов. Нахрен оно надо связываться с "этим" опять, если за те же 300 баксов мне напишут нормальное двигло без этих всех багов и засаппортят при критических проблемах?

     


  5. В 16.06.2019 в 21:49, l2Andrey сказал:

    demort Брал у него Лк и несколько доп. услуг Очень порядочный человек!

    Я бы поспорил. Когда-то давно брали у него ЛК, в котором обнаружился критический баг с процессингом платежей. В результате баг закрывал вообще программист нанятый со стороны, потому-что деморт не мог закрыть баг около недели. Данный отзыв сохранился на другом форуме, если надо, то могу скинуть ссылку в личку.


  6. Готов вписаться на указанное время при оплате от 1к usd в месяц при правильно поставленном рабочем процессе.

    На классике не играл. Обо мне тут. Последняя работа была по контракту в геймдеве, длительностью чуть больше года.


  7. В 16.05.2019 в 13:59, Deazer сказал:

    Хорошо восстановленный декомпил, тебе самому не смешно ? :D Не смеши, там нихрена толком не работает. Вообще сферический дурачек и по этой же причине и слился в мусор - туда где ему и место, мне бы столько рвения, я бы сел в конце концов новую сетку написал, что и буду делать. Но теперь уже точно все накрыл. Задолбали меня всякие "тимы" тащат все, ни кто сам писать не хочет, в том числе и пейны у меня много чего потянули. Уроды одним словом.

    Джонни, где пруфы? Ато вдруг, наговариваешь на хороших людей, а-та-та! :D


  8. Bombanuulo.

     

    2 часа назад, sniper сказал:

    да и ты врач такие заявления делать??

    Вы спросили совета и хотели узнать причины, я написал. С такими словами могли бы поднять свою жопу от кресла и сходить ко врачу, а не писать треды с просьбой советов на форуме. Ибо любые советы людей с форума, у Вас, судя по всему, будут восприняты в штыки со словами: "ЙОБА ТЫ ВРАЧ ШОЛЕ А?! А?!!!". Я конечно утрирую, но все же.


  9. Это значит, что у вас монитор регулирует подсветку с помощью ШИМа, причем не качественно. В большинстве случаев это проявляется на настройке низкой яркости плохих мониторов.

    Вот вам просто пример, как проверить действительно ли проблема в мониторе: берете карандаш между двумя пальцев в руки и начинаете трусить напротив картинки монитора. Если карандаш не только оставляет размытый след, но и есть моменты, когда в процессе движения он виден более четко, то ваш монитор - говно. В таких случаях рекомендуется поменять его на более вменяемый, конечно, за большую сумму. Либо выставить яркость, как минимум выше половины, а лучше 2/3.


  10. В 15.05.2019 в 17:38, lvlkoo сказал:

    Есть ли сейчас в свободном доступе\продаже чистые папки system под classic клиенты различных версий? Я вроде находил тут для версии 2.0. Выше нету?

    Системы от инновы (тобишь ру) одинаковы, как для текущей ветки игры, так и для классика. Единственное различие - ini, в котором стоит флаг классика.

     

    В 15.05.2019 в 17:38, lvlkoo сказал:

     Есть ли сейчас в свободном доступе\продаже fileedit'оры для клиента classic?

    Нет, нету. Также, как и для последних версий клиента. И не будет из-за говно-коммунити.

    • Upvote 1

  11. @Silentium вангую, что ничего. Скорее всего ребята просто сперли откуда-то исходник, который немного отличается)

    Спойлер

    Ты там еще живой? Как ты там поживаешь и куда слился в прошлый раз? Пошли какие-нибудь прикольные штуки делать;)

     


  12. Все очень сильно зависит от типа монетизации сервера.

    Допустим, возьмем наиболее эффективную монетизацию: различные сундуки с плюшками внутри. Ключевая плюшка, ради которой люди будут покупать данные боксы - должна иметь наименьший шанс выпадения, шанс должен расчитываться исходя из того сколько требуется выжать из одного игрока, обычно это чуть менее 100 долларов. Расчитываете цену и устанавливаете требуемый шанс, чтобы при приближении к порогу требуемой цены статистический шанс вытащить плюшку возрастал. Также и с расчетом остальных плюшек внутри бокса.

    Касательно что туда пихать. Нормальной практикой считается: визуал и различные расходники, иногда бывает премиум/season pass, и другие похожие вещи. Наиболее "редкие" расходники должны отвечать одному простому требованию: они должны использоваться для создания топ-эквипа, который был создан в крайнем обновлении игры.

    Вывод денег: самое элементарное и что используется чаще всего - вывод внутрянки с помощью различных fun-эвентов; например летний эвент: собирай мешочки из которых могут выпасть кристаллы с определенным шансом, за которые можно собрать некий визуал. Мешочки имеют флаги обмена и продажи, поэтому игроки продают их друг другу. Достаточно просто, можно довольно незаметно выставлять на аукцион созданные из ничего такие мешки и продавать их игрокам, главное делать это аккуратно и управлять ценой. В результате внутрянка собирается с игроков и изымается из оборота. В случае крайних мер, можно подвязать эвент на покупку каких-нибудь сколлов у NPC, которые дают шанс на выпадение таких мешков с мобов, что даст огромный вывод внутрянки с рынка и дефляцию. В паре с этим работает и монетизация, совместно с эвентом запускаются и боксы из которых можно вытащить похожий визуал, но не точно такой же.

    Также, монетизацию следует обновлять сразу после введения нового контентного обновления, но конкретные вещи, которые позволяют добыть "новый контент", стоит добавлять с некоторым временным промежутком после самого обновления, иначе можно получить нехилый такой баттхерт и снижение лояльности игроков.

     

    ---

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

     

    • Like 4

  13. 53 минуты назад, Rozhek сказал:

    Если честно нигде ни на каком сервере не видел, чтобы путь строился в обход коллизии. Проверка проходимости через коллизии - да, но построение пути в зависимости от них - нет. Тем более в динамике с их пересечением)

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

     

    25 минут назад, Rozhek сказал:

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

    В более ранних версиях игроки не были проходимы;)

     

    28 минут назад, Rozhek сказал:

    Не понял, как движение в точку отличную от конечной(и ближе и дальше) может компенсировать анимацию начала движения. Что значит сделать это правильно? По моему это не то что правильно - это бездумно, решать проблему повышением тикрейта и синхронизацией с клиентом игры, разве нет?) На l2j серверах есть тики которые которые выставляют позицию по ходу движения(опять же не точно, а в центры геокоординат) - и эти тики и вызывают рассинхронизацию и попытки клиента интерполировать позицию внутри вектора движения, когда он получает пакет о новом передвижении и текущие координаты отличаются от серверных.

    Дело не в анимации, она далеко не root motion, чтобы она играла какую-то роль, а именно в изменении скорости движения. Сделать "это правильно" - применить линейную интерполяцию на каждый тик движения, в зависимости от времени. Впрочем, подойдет и любой метод получения координат, который будет экстраполировать/интерполировать координаты, в зависимости от времени. В ином случае, с текущей трединговой моделью, расчет попросту будет неверным.

    А кто говорил про решение проблемы увеличением тикрейта? У меня вообще на одном сервере (не lineage 2, к счастью) тикрейт самого сервера (а это, на секундочку, вообще все серверные геймплейные операции, куда входит и движение) выставлен в 15 раз в секунду, что очень и очень низко, особенно, смотря на некоторые сервера, которые имеют тикрейт в 60 фреймов.

     

    40 минут назад, Rozhek сказал:

     Еще раз говорю, если уметь считать координаты точно в любой нужный момент времени, то проблема рассинхронизации исчезает. Это мой best practice. Сетевой лаг или тикрейт в совокупности составляют около 20-30% проблемы и те решаются просто хорошей сетью.

    С этого и следовало начинать! Вы считаете координаты по запросу. Вопросов в этом плане больше не имею:)

     

    51 минуту назад, Rozhek сказал:

    Но этот показатель все равно будет статичным, клиент будет статично отставать от сервера и при получении новых пакетов с той же примерно задержкой будет успевать догонять координаты сервера. Кстати 200мс - с точки зрения любых игр уже выходит за рамки комфортной игры, а в л2 это отставание клиента от сервера при средней скорости бега всего на 30-40 координат, которые при стабильном пинге превращаются всего в 1-2 координаты рассинхрона. Реальное плохая ситуация это когда пинг прыгает, например, разброс пинга в +-100мс при той же средней скорости(брал 170 коорд в сек) может вызывать рассинхронизацию до 20 координат в точке смены направления движения и это уже будет заметно.

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

    • Like 1

  14. В 21.04.2019 в 23:56, Rozhek сказал:

    Понял, что имелось ввиду, но такая задача в принципе не стоит. Такого функционала нет на офф сервере, и я об этом даже и не думал. Наверное в современных играх этот вопрос стоит достаточно остро.

    Одно время данный функционал был на официальном сервере, однако, позже его убрали по неизвестным причинам. Впрочем, его отголоски до сих пор можно заметить, допустим: использовать большую трансформацию и перегородить вход куда-либо. Это до сих пор актуально на текущей версии NA-сервера. В HF-версиях, клиент может послать пакет CannotMoveAnymore (или как-то так), но сервер в силах и без этого пакета все правильно обработать и забраковать путь.

    Раньше в ретейле использовалось не BVH-дерево, а дискретный метод (специальная хеш-таблица) для определения столкновений. Но в таком подходе минусов целая коробка и маленький контейнер.

     

    В 21.04.2019 в 23:56, Rozhek сказал:

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

    Я раньше эксперементировал с различными алгоритмами поиска пути, в контексте lineage 2: руки, двусторонний поиск, различные вариации жадных алгоритмов и различные направленные версии. В общем, лично я, остановился на направленном A*. А потом вообще плюнул на все это и выкинул геодату, и просто вгрузил все коллайдеры с карт. Прогнал их через оптимизатор вершин и получился вполне нормальный граф, по которому можно искать путь (причем в большинстве случаев он легковеснее той же геодаты), как плюс, можно делать нормальные "физические" рейкасты (на самом деле, они реально нормальные, а не то говно, которое трассируется через геодату) для проверки видимости. В теории, можно вообще психануть и написать BSP для тех же рейкастов, но производительность BVH меня вполне устраивает.

     

    В 21.04.2019 в 23:56, Rozhek сказал:

    Почему так не работает у всех, ведь вроде же все так же. Из-за того, что во время бега координата на сервере стоит то справа-сзади от линии движения, то слева-впереди по пол секунды(в центрах гео координат). При получении запроса на изменение пути, расчет начинается от середины той геоклетки(кроме того на всех l2jях банальный баг и первый тик бега считается путь от 0 точки до нее же) -> клиент замедляет скорость, потому что начальная координата ждет, потом ускоряет скорость потому что координата быстро уходит по центрам геоклеток -> потом поступает запрос на смену пути -> серверная координата уже на 30 координат впереди-справа от текущей точки, а клиент бежит не к ней а к конечной локации-> цикл начинается заного, но уже с расхождениями координат.

    Там считается время движения до нулевой точки, чтобы компенсировать линейное увеличение скорости движения персонажа при беге, которое отлично видно в начале движения. Это не правильно, я согласен. Но чтобы сделать правильно - необходимы тики, в ином случае, на маленьких дистанция рассинхронизация будет вполне заметна, а если таким методом двигаться почти беспрерывно, то разница координат может достигать в несколько сотен точек.

     

    В 21.04.2019 в 23:56, Rozhek сказал:

    Опять же все так. Но) В клиенте есть удобный механизм, который сводит микрорассинхронизации на лету(ускоряя или замедляя). Остальной разницей возникающей в период 20-200мс можно принебречь - ведь эта разница не аккумулируется при движении: сервер считает позицию раньше клиента -> сервер получает новый запрос от клиента на смену координат -> пока сервер считает новую координату и отправляет пакет -> персонаж догоняет позицию и рассинхрона не происходит /если есть минимальные расхождения позиция подхватывается на лету  (тут даже до ValidateLocation не доходит, он начинает его слать от разницы в 50-100 координат что ли). 

    Ага, знаю такой механизм, это синхронизация клиентской экстраполяции. Но, если честно, мне было лень ее разбирать на клиенте, поэтому я на это успешно забил:)

    На счет "забить на 20-200мс" - мне не кажется это хорошей идеей, так как при увеличении нагрузки на сервер, время самого серверного процессинга будет увеличиваться без роста сетевой задержки, из-за чего итоговая задержка запроса может быть намного выше 200мс и это следует учитывать. Нечто вроде: delay = trip time + processing time.

     

    Извиняюсь за столь долгий ответ, впредь постараюсь отвечать быстрее:)


  15. 6 часов назад, Rozhek сказал:

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

    Это понятно, ибо эвристика. Я говорю про саму реализацию avoidance динамических актеров, чтобы движущиеся актеры не сталкивались и рекалькулировали свой путь, для избежания столкновений. Очевидно, что это реализуется в рантайме:) 

    Обычно такие задачи решаются отложенным пересчетом пути актера и динамическим изменением веса клетки, по которым, другие актеры двигаются (в случаях дискретной сетки). В более хороших и правильных реализациях используются BVH деревья (причем обычно достаточно балансного AABB дерева), чтобы реализовать приемлемый avoidance. Кстати говоря, второй подход также используется в физических движках, но это уже тема для иного разговора.

     

    6 часов назад, Rozhek сказал:

    Поиск пути работает в соответствии со своим алгоритмом, с параметрами задающими вес клеткам). Если разница в высоте между лесенками позволяет присваивать вес клетке, предполагающий перемещение, то почему он должен выдасть гавно. Другое дело каким образом строится и воспроизводится мувинг по узлам построенного пути и учитывает ли он эти особенности)

    Потому-что на моей памяти, во всех l2j-ях эврестическая стоимость клетки имеет вид: D(sqrt(x*x + y*y + (z*z) / modifier)) - или нечто похожее. Впрочем, даже выставляя "честную" эвристику по Z-оси, результат задастую выходит не таким, какой ожидается, из-за того, что вес клеток по "правильному" пути намного выше, чем вес до, условно, неверного пути. Сюда же можно добавить и то, что во всех l2j-ях реализация поиска пути работает по алгоритму "первый лучший".

     

    6 часов назад, Rozhek сказал:

    Тут стоить начать с того что в клиенте векторное движение, на сервере декартовое. Точность сопадения координат в общем случае характеризуется точностью результата функции аппроксимации, т.е. в идеальном случае рассинхронизация не должна возникать из-за неверных математичеких расчетах. Поэтому необходимости синхронизации по тикам нет, а для всех остальных случаев в клиенте уже предусмотрен механизм оповещения сервера при рассинхроне(ValidateLocation). Проблемы в отсутствии аппроксимации, а синхронизация по тикам это про другие игры.

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

     

    6 часов назад, Rozhek сказал:

    Вы точно правильно употребляете термины?) Поясните подробнее, что имелось ввиду. Как связан пинг и координаты клиента я не совсем понял.

    Минутка шуток: администратор локалхоста недоумевает, как связаны координаты присылаемые клиентом серверу с пингом, потому-что у него нулевой пинг.

    А если серьезно, то они непосредственно связаны тем, что:

    1. Сервер по расчетам движения всегда впереди клиента, потому-что пакет MoveToLocation не доставляется моментально на клиент.

    2. Клиент при отправке запроса ValidateLocation, отправляет координаты, которые актуальны на текущий момент. Пока пакет обработается в очереди, пока отправится, дойдет до сервера, сервер его обработает... Пройдет значительное время, чтобы процессинг на сервере сказал: "нифига, эти координаты неверны". А отсутствие снапшотов не дает заглянуть в прошлое и сверить правильность координат на момент времени отправки клиентом пакета. Именно поэтому я предположил, что может использоваться экстраполяция координат для их проверки, чтобы довести эти клиентские координаты до "текущей точки времени" и проверить, очевидно, их правильность.

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

     

    6 часов назад, Rozhek сказал:

    Вторая часть - не совсем так. Точнее, это происходит не из-за отличия способа изменения координат, а из-за неправильных расчетов координат и самих слоев. На l2j эмуляторах неправильно определяются слои геодаты, когда актор находится между ними. При правильном алгоритме определения слоя, проблем собственно и нет.

    Определение слоев, да, есть такая проблема, но я не о ней говорю на данный момент, потому-что это исправляется легко и быстро, да и обсуждать это как-то не очень интересно:)

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

    Возможно Вы просто не замечали таких кейсов, но когда я еще занимался этими всеми l2j-ями, причем на довольно нагруженных проектах (от 1 200 онлайна до 2 000), такие проблемы всплывали, однако, не сразу. 

     

    6 часов назад, Rozhek сказал:

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

    Спасибо за ответ. Я, если честно, даже не надеялся на ответ. Всегда приятно обсудить интересные технические задачи и способы их решения:)

    На счет терминов:

    BVH дерево - дерево хранящее внутри себя набор геометрических фигур.

    AABB дерево - дерево хранящее внутри себя "коробки" актеров. Если простыми словами, то "коробка" - прямоугольник (либо же куб, в случае хранения трехмерных коробок), который включает в себя полный размер актера.

    AABB - "коробка", см. AABB  дерево.

    Avoidance - механизм уклонения (обхода) от динамических актеров.

    Балансное дерево - дерево, которое имеет сбалансированное количество количество веток и листов на них, на каждом уровне глубины/высоты.

    • Like 1

  16. В 31.03.2019 в 10:55, Rozhek сказал:

    Если вы еще думаете какую сборку выбрать для своего сервера, попробуйте удивить игроков не уникальной концепцией или клиентом классика, а хорошей геодатой)

    Рантайм изменения веса клеток для патчфинда есть? Это для процессинга avoidance, тобишь, обход других актеров во время поиска пути. Или сделано, как обычно, костылем?:)

    Если есть, то как разрешили задачу многопоточного доступа на модификацию веса клетки? Потому-что в этих ваших l2j-ях по другому невозможно, из-за того что общего тика сервера вообще нету.

    Что с перестроением уже найденных путей при изменении веса клеток? Или может быть запилен avoidance по столкновениям? В таком случае какой вид деревьев использовали и опять же, как решили задачу с многопоточным доступом модификации BVH дерева?

    Поиск пути по прежнему выдает говно в случаях с трехмерными плоскостями? (Как пример лестница у кристала в замках)

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

    Как экстраполируете координаты клиента, в условиях того, что получение пинга, это вообще отдельный пакет?

     

    Касательно этого момента:

    Цитата

    [x]Реорганизация гео-движка. Перемещение осуществляется по всем точкам мира, а не только центрам гео-клеток. off-like

    Я понял, что имелось ввиду и что это за фикс. Но скажу к слову: в ретейле, непосредственно, векторное изменение координат идет по дискретным точкам, тобишь по гео-точкам. Результаты игнорирования этого можно посмотреть в любом l2j эмуляторе, со всякими ошибками координат около преград, из-за чего трассировщик высоты ломается и выдает неверный слой геодаты в многоуровневых локациях.

     

    Хотели нормальных вопросов и дискаса - получите;)

    • Like 1

  17. В 27.10.2018 в 10:26, Pepel сказал:

    "PartyWnd.PartyStatusWnd" $ idx $ ".StatusIconDebuff" - это мне вообще не понятно, может кто объяснить что тут происходит?

    Конкатенация строки.

     

    В 27.10.2018 в 10:26, Pepel сказал:

    Можно дать наводку и описать где искать функции StatusIconHandle, GetHandle?

    Смотреть в экспортах/импортах скомпилированного скрипта. 

     

    В 27.10.2018 в 10:26, Pepel сказал:

     Меня же интересует функция которая формирует строки бафов и дебафов, где происходит отсев что куда.

    Если какой-нибудь интерлюд, то в nwindow.dll.

    • Upvote 1

  18. В 18.10.2018 в 10:35, hesh1111 сказал:

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

    Берете IDA, смотрите где вызывается функция connect, проходите выше по стеку и ищите где собирается sockaddr структура и патчите номер порта для нее. Возможно придется пройти выше по стеку, если в функцию передается порт аргументом. Все это делается легко и просто даже без отладчика.

    Можете еще попробовать это говно, которое я писал миллион лет назад, только нужно будет вручную добавить выходную DLL в импорт engine.dll/core.dll/любойдругойDLLл2.


  19. 21 час назад, High сказал:

    В этом и заключен основной вопрос и смысл, и об этом я два месседжа подряд говорю. Что Яву можно сделать как угодно, пожалуйста. Но до сих пор этого нет, и никогда не будет. Нельзя, вот и всё. Было бы можно, уже бы и кол-во AI подогнали, при том действительно правильные AI по коду и по игре, а не написанные через жопу, как весь Java язык на большинстве сборок, речь о конкретных костылях, в любой Java, именно поэтому страдает её стабильность в основном, хотя там еще много нюансов по работе конкретно в боевых условиях. Плюс куча нюансов с дп, выше упомянули. Да. Всё это мать вашу делается. Но только в теории, а на практике действительных 12 лет вне куда и до сих пор уже морально древние хроники не реализованы даже близко к тому же PTS. Поэтому когда начинаются вопли, мол, на Java можно всё, особенно когда идёт речь об x5, то пожалуйста. Делайте. Только любой приличный проект на PTS опережает Яву на шаг, мы же говорим об лоу рейте, верно ? И я уже сказал, что на таких рейтах, ни одна помойка из Java не будет состоятельно смотреться, кто бы там что не говорил.

    Все можно. Да хоть миллион лет могут пилить. Законы рынка еще никто не отменял и нужно быть совсем отбитым, чтобы в это не врубаться.  Обьясняю на пальцах. 

    Просто тут суть, как у неуловимого Джо. Он же неуловим потому-что нахрен никому не нужен, так и тут. Ретейл механики на джаве неуловимы потому-что нахрен никому не нужны. За исключением, может, 1.5 человек, которые и сами не знают, как это должно работать, и не будут знать, потому-что реверсить ретейл слишком "сложна". А знаете почему крупнякам не нужны эмуляторы, которые жмут ретейловские механики? Потому-что есть ретеил. Нахрена тратить кучу денег на их реализацию в джаве? Просто деньги, не более того, достаточно уметь считать.

    • Like 1
    • Upvote 1

  20. 3 часа назад, Gaikotsu сказал:

    Мусье знают толк в извращениях...

    Что мешает по необходимости брать список всех боссов из менеджера спавнов, отфильтровывать из него живых в данный момент, далее рандомно брать одного босса из полученного списка, брать из его свойств текущие координаты и делать телепорт  рядом с ним?

    Не мешай, тут люди грин рубят на уникально-легендарных возвращениях легенд.

    production.jpg

    • Like 5
×
×
  • Создать...