Вход в систему
Логин
Пароль
 

Sprint #26: Terrain.Сейчас на сайте 13 посетителей
WoWCore
История 2.0
История 1.0
SandBox

Ресурсы
Форум
Файлы

Документация
Литература
Ссылки


Sprint #14: Transport.
← назад к списку

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 а встроенное в обработчик движения. По краней мере я не городил огород со списком у каждого, содержащим всех окружающих.

Представьтесь
Ваше мнение
Из соображений безопасности необходимо ввести символы, которые вы видите на картинке.
Контрольные символы


Copyright © 2005-2017 WoWCore Team