|  |
11.07.2011, 22:15
В первом приближении movement реализован и слинкован с апдейтсистемой. Спаун-система так же интегрирована, в связи с чем начата большая работа над транспортной системой.
Для начала будет реализован слой заселения - грифонщики, при помощи которых будем перемещаться в Мирах. Грузится он будет отдельно от остального для удобства обслуживания. Анимацию планируем сделать выключаемую из конфига, т.к. на этапе разработки и тестирования не очень удобно ждать по несколько минут самого перелета. Ну и за одно будет оттестирована спаун-система.
После чего начнется работа над транспортными ГО, в первую очередь корабли между материками, метро и пепелацы. Затем все остальное сопутствующее, типа лифтов, кранов, всяких элеваторов и т.п.
#1 atmorozock, 13.07.2011, 17:45
| | Патч 4.2.2 будет поддерживаться на вашем сервере ? |
|
| | #2 RomanRom2, 14.07.2011, 12:32
| | да куда он денется... |
|
| | #3 kd, 20.07.2011, 20:21
| интересно,
вы позиции высчитываете on demand(по вызову) или принудительно всем объектам раз в интервал времени?
не знаю как сделать у себя - хотелось бы on demand, и все прекрасно до тех пор пока положение не начинает зависить от положения других объектов(юнит на транспорте, например) |
|
| | #4 kd, 20.07.2011, 20:24
| | + on demand путь усложнит код, а этого не хотелось бы |
|
| | #5 RomanRom2, 20.07.2011, 23:22
| | Принудительно расчитываем. Как же еще организовать видимость мира в полете на грифоне? |
|
| | #6 kd, 21.07.2011, 00:43
| задумка была такой:
при запросе положения - расчет или использование ранее вычисленного (в зависимости от времени последнего расчета).
принудительный запрос позиции раз в N секунд для обновления положения на карте, видимости и т.п.
|
|
| | #7 RomanRom2, 21.07.2011, 13:50
| У user456 в DelphEmu было onDemand и работало по тестам вполне неплохо. Мы ведь знаем время начала движения и время собсно demand. Можно легко вычислить позицию, т.к. знаем координаты, скорости, направления.
Вполне возможно стоит мобов разделить на несколько типов и, например, у праздношатающихся пользовать онДеманд. При сплайновом типе движения "полет на грифоне" целесообразней runtime расчет и так далее. У патрулей/аниматоров скорее всего потребуется применять микс из этих двух типов - пока он идет по своему сценарию - расчет, когда вступил во взаимодействие какое то - онДеманд. |
|
| | #8 kd, 21.07.2011, 17:11
| когда положение начинает зависеть от положения других объектов - пример юнит на юните-транспорте, а юнит-транспорт на транспорте..
В какой-то момент времени юнит-транспот исчезает. Выходит необходимо закешировать позицию юнита-пассажира. И возможно таких принудительных кеширований разбросать нужно будет немало, усложнит код.
Это к минусам onDemand т.к. пытаемся через мизерное число параметров вычислить что-то сложное |
|
| | #9 kd, 21.07.2011, 17:12
| | Ну это уже "пилосопия".. |
|
| | #10 RomanRom2, 21.07.2011, 17:15
| Неправильный дизайн... аля "карта в карте" на мангосе.
Нет юнита-транспорта. Есть GO-транспорт, там реализация совсем другая (привязка по гуиду и флагами в А9). Есть маунты, типа коней, мотоциклов, грифонов - там еще другая реализация (MOUNT_DISPLAY_ID). Юнитов-траспортов не встречал. Может плохо смотрел конечно... покажите? |
|
| | #11 kd, 21.07.2011, 17:22
| назвать можно как угодно - суть будет одна
юнитов-траспортов нет, есть Vehicle - такая себе структура-примочка к юниту.
Позволяет перетаскивать на себе других юнитов.
Не понимаю, почему реализация перетаскивания на себе должна отличаться от свойства GO-транспорта?
[ofttop] Вы случайно не в курсе насчет текущего местоположения форума кобольда?
http://kobold-team.com/forum/ выглядит странно |
|
| | #12 kd, 21.07.2011, 17:29
| ее можно динамически добавить SMSG_SET_VEHICLE_REC_ID пакетом
> (привязка по гуиду и флагами в А9)
точно такая-же привязка и к юниту-транспорту, с теми-же флагами |
|
| | #13 RomanRom2, 21.07.2011, 17:32
| не не не, Девид Блейн...
Я настаиваю на том, что это две большие разницы. Структура-примочка очень похожа на ГО-транспорт. Но в случае с транспортом привязка ГО к плееру, а с вехиклом - привязка плеера к вехиклу. Деталями не владею, подозреваю что в той структуре-примочке есть список гуидов, который инициализируется флагом. Я не занимался вехиклами еще.
точно такая-же привязка и к юниту-транспорту, с теми-же флагами
Хмм, ну раз точно такая же, то в чем проблема?
Насчет форума кобольда информацией не владею. На форуме мангоса в ветке по JavaEmu отписывались люди оттуда сегодня, можете у них попробовать спросить. |
|
| | #14 kd, 21.07.2011, 22:08
| что означает привязка? привязка по гуиду в пакетах?
если да, то в обоих случаях только пассажир привязан к транспорту, не наоборот.
А если о связях вообще - то и в Vehicle в GO-транспорте есть список с пассажирами. У них (в клиенте) даже объект Passenger введен, скорее всего используется как для vehicle так и для Go. |
|
| | #15 kd, 22.07.2011, 00:45
| > Неправильный дизайн... аля "карта в карте" на мангосе.
лучше 1 раз посмотреть код чем 10 раз услышать.
Насколько мне известно такого в мангосе нет, ну а то что там на форуме говорят..
Лучшим дизайном было бы забыть о взаимодействии объектов на транспорте с внешним миром и не вычислять глобальную позицию? |
|
| | #16 RomanRom2, 22.07.2011, 03:00
| Ладно, Бог с ним с мангосом... пусть как хотят так и делают.
Я имел ввиду привязку по гуиду в пакетах, да. Объект Passenger есть уже в первой же альфе 0.5.3.3368, поэтому я думаю это давняя задумка близзов и мы копаем в правильном направлении.
Я повторюсь, вехиклами заниматься еще не довелось. Но на транспортном ГО такого взаимодействия нет. При перемещении объектов по ГО изменяются их (объектов) относительные координаты, в той самой дополнительной структуре-примочке. Ее клиент присылает в move-пакетах. Мировые координаты в этот момент не меняются. Вот не помню, меняются ли они когда, например, корабль начинает плыть (или метро ехать)... Доберусь скоро до этого момента и посмотрю.
Одно могу сказать, транспортное ГО в мире НЕ ПЕРЕМЕЩАЕТСЯ. Мы видим лишь анимацию. Корабль спаунится всегда на пристани, он там всегда находится. Только спаунится с нужным таймстампом, который характеризует бегунок этой анимации и где этот бегунок в данный момент находится.
Далее, еще интересующий уже меня вопрос: как на оффе, возможно ли взаимодействие между пассажирами транспорта и наземными объектами? Другими словами возможно ли с земли жахнуть фаерболом по кому нибудь на корабле?
Можно ли управлять вехиклами? Или это такие же path-скриптовые транспортные средства? Пока всё выглядит так, что вехиклы реализованы точно так же как транспорное ГО. |
|
| | #17 kd, 22.07.2011, 07:00
| > Далее, еще интересующий уже меня вопрос: как на оффе, возможно ли взаимодействие между пассажирами транспорта и наземными объектами?
Слышал, обстреливать с кораблей могут. А для этого нужно знать расстояния между объектами, координаты.
Вообщем-то, если юнит находящийся на корабле стал виден - взаимодействие уже произошло. Вы описываете корабли не перемещающиеся на большие расстояния - раньше возможно они и не перемещались, но как тогда с пассажирами в Northrend которые исчезают и появляются в поле зрения.
Конечно удобнее было бы не перемещать его..
> Можно ли управлять вехиклами? Или это такие же path-скриптовые транспортные средства?
Вехиклами могут быть и плееры. Это абсолютно свободные в своем поведении юниты. Хотите - разрешите пассажиру управлять им - так и будет. Или же это может быть босс с приставными руками(пассажиры). Использование ограничено только воображением дизайнера :) |
|
| | #18 RomanRom2, 22.07.2011, 11:23
| Это расстояние есть расстояние между кораблем, который стоит на пристани и никуда не уплывает и юнитами, которые ходят по берегу. Собсно это расстояние почти никогда не меняется. Когда мы садимся на корабль, наши координаты становятся равными координатам корабля.
Когда мы стоим на берегу и наблюдаем как появился подплывающий корабль, креатится корабль на самом деле на пристани, соответственно для наблюдающих на берегу это маленькое расстояние и им креатятся юниты, которые на корабле тоже. И креатятся они тоже в точке корабля на пристани.
Но так как эти юниты "прикреплены" к кораблю, то мы видим этих юнитов "там", на корабле. Хотя по серверным расчетам они вот, рядом, на пристани. Клиент умный, он сам отрисовывает такие штуки.
Вот это и есть то взаимодействие. Отсюда не вижу проблем обстреливать с кораблей и обратно.
С пассажирами в Northrend надо поразбираться. Если есть возможность, дайте пожалуйста координаты этого места и ИД транспортного ГО. Я попробую поискать в сниффах, где и посмотрим что происходит. Вполне возможно, там клиент присылает мировые координаты тоже. Или эти мировые координаты в процессе движения транспортного ГО тоже меняются - вот этого я не помню совершенно...
Ну а с вехиклами всё понял :) Когда подойду к их реализации, буду держать в курсе. Я думаю что механизмы реализации вехиклов должны быть такие же, как у траспортного ГО. |
|
| | #19 RomanRom2, 22.07.2011, 11:37
| Вообще, сейчас подумалось, что для анимации транспортных ГО в клиенте вшиты path-поинты. Сервер тоже может содержать такие поинты и расчитывать клиенту его координаты в процессе движения. Отсюда мы сможем апдейтить мир со всеми вытекающими. Ну и время, когда именно начнет двигаться ГО мы тоже легко расчитываем: мы всегда знаем таймстамп ГО и момент захода на корабль тоже легко отслеживается. Тогда вырисовывается расчет координат юнитов на сервере. Причем им всем можно вписывать расчитанные координаты корабля - одинаковые соответственно. Причем скорее всего - именно path-поинты, а не какие то промежуточные расчитываемые координаты. Это позволит апдейтсистеме "видеть" подплывающих юнитов и наблюдающие увидят их на корабле. А относительные координаты нужны лишь для отображения перемещения по кораблю. Клиент уууумный, отрисует.
Я почему вспомнил - когда изучал метро в Стормвинде, то думал что в мапе "метро" (не помню номер) собственно и нет никаких OutOfRange расстояний и апдейты шлются всем и вся. Отснифав перемещение увидел что это не так, объекты креатятся по мере попадания в InRange зону. Значит расчет однозначно, т.к. что бы клиент присылал мировые координаты я тоже сейчас не вспомнил. Возможно его и не было тогда, я занимался этим примерно во времена 1.10.0 классика. |
|
| | #20 kd, 22.07.2011, 19:49
| > Если есть возможность, дайте пожалуйста координаты этого места и ИД транспортного ГО
ид транпорта - 188511, ид пути - 1079(координаты в дбц). Какого-то определенного положения у него нет - курсирует по всему побережью. |
|
| | #21 kd, 22.07.2011, 20:48
| Насчет onDemand, мне подумалось, что лучше его вообще не использовать или использовать только в критических по произв. местах.
Мы же эмулируем мир с непрерывными событиями. С onDemand миром юнит, пробегающий мимо другого, может не заагрить его и т.п. |
|
| | #22 RomanRom2, 23.07.2011, 01:40
| Совершенно верно. Я поэтому и говорил выше, что юнитов разделил на несколько типов. ОнДеманд метод примерняется для праздношатаюшихся мобов - это волки всякие, рандомно бродящие вокруг спауна.
На каждый МОНСТЕР_МУВ запускается таймер, который по сути эмулирует изменение координат от клиента - раз в секунду "приходят" новые. Далее апдейтсистема уже рулит - Unit.UpdatePosition -> World[id].Update - > ScanCellsAround() -> FoundUnit[i].OnUpdateFrom(Unit); который в свою очередь изменит threat лист у других мобов. Ну а те в свою очередь примут решение, агрится или нет (faction, level, дистанция, etc).
Нет смысла волкам так делать, им как раз самое место в ОнДеманд типе. И таких мобов большинство, кстати. А вот патрулей/аниматоров нужно по расчету делать, да. |
|
| | #23 user456, 01.10.2011, 19:44
| >С onDemand миром юнит, пробегающий мимо другого, может не заагрить его и т.п.
На оффе собсно так и происходит: можно сесть на быстрого маунта и проскакать по мобу - если не попадет в промежутки времени то ли рассылки мувмент пакета от клиента то ли вычисления позиции - проскакиваеш без реакции.
У меня было не то чтобы onDemand а встроенное в обработчик движения. По краней мере я не городил огород со списком у каждого, содержащим всех окружающих. |
|
| |
|
| |
