Предлагаю постить здесь вопросы, про любые связи (links) между объектами. Хочется верить, что помощь будет. :)
Мой вопрос: каким образом можно сконфигурировать данные связи ParticleAttachement так, чтобы частицы шли не с середины объекта, а с его конца? По умолчанию, надо понимать, частицы и идут из центра объекта, а при выборе остальных параметров ничего не изменятеся. Joint, по-видимому, отпадает - неживой объект не живое существо, у него головы нет. :) А вот Vhot и Submodel... Просветите, пожалуйста, кто-нибудь, что это за звери? :confused:
За положение частичек отвечает Vhot, это невидимый куб выставленный на объекте 3D программой, в которой делался объект.
[Исправлено: Winter Cat, 21 июня 2008 23:49]
Ага. Круг сужается! :) Осталось лишь понять, какое число нужно вписать в поле "vhot#", чтобы частицы расположились как надо.
Добавлено позже
И вдогонку: а за что Submodel отвечает? Мне и более неопытным авторам на будущее?
Про Submodel не знаю, а число за расположение не отвечает, это номер vhot-a, на котором будут частички.
Winter Cat Спасибо, буду разбираться.
И другой вопрос - по связи CreatureAttachment. Проблема в том, что предмет (в моём случае - меч) присоединяется, опять-таки, своим центром к нужной точке (в моём случае - руки) AI, а не краем. Причём в данных свзяи всегда поле "Is Weapon?" неактивно, хотя галочка в нём - по-моему, и есть нужный выход. Учитывая, что в данных больше полей нет, где и что нужно изменить в свойствах (видимо, в свойствах предмета)? Или тут проще сделать модель товарища с мечом? :)
То поле вроде всегда неактивно, галочку туда только сама игра выставляет. Меч можно присоединить свойством Renderer>Mesh Attach, подробней на ттлг про это сказано.
[Исправлено: Winter Cat, 22 июня 2008 18:02]
Winter Cat Спасибо огромное! На ттлг всё разжёвано и в рот положено :)
Всё, у меня пока больше вопросов нет.
ЦитироватьJoint, по-видимому, отпадает - неживой объект не живое существо, у него головы нет
По-моему, не совсем так. Joint - что-то наподобие шарнира. Если у предмета есть подвижные части (как крышка у сундука, например) - Joint можно использовать для настройки.
Очередной вопрос.
Общее положение вещей: есть вода с течением. В ней плавает ящик, который можно перемещать как лифт от одного TerrPt'а до другого при помощи ControlDevice'ов (в этом плане всё в порядке, всё работает). Но вот в чём загвоздка: связь TPathInit шалит, на сей раз так, что портит картину.
Вообще, насколько я понял, надо связывать лифт с первым TerrPt'ом для его пути связью TPathInit. Когда я так делал с обычным лифтом, он автоматически перемещался к противоположному TerrPt'у (т.е. допустим, есть два TerrPt'а под номером 400 и 401, мне надо, чтобы лифт стоял на TerrPt'е под номером 400, а он идёт на 401-й. Поэтому приходилось связывать лифт с 401-м TerrPt'ом, чтоб он стоял на 400-м в итоге.) Здесь, в принципе, всё так же, но с непонятным багом: в первоначальном положении ящик стоит НАД водой, причём на заметном расстоянии. Оба TerrPt'а же расположены под водой, так, чтобы при перемещении к ним ящик частично погружался в воду - и если применить ControlDevice к ближайшему, то ящик послушно упадёт в воду.
Так вот вопрос: во-первых (чисто из любопытства) - можно ли как-то убрать этот каприз с перемещением к противоположному TerrPt'у, и во-вторых (собственно, по делу), что сделать с ящиком, чтобы он сразу же был в воде?
Цитироватьмне надо, чтобы лифт стоял на TerrPt'е под номером 400, а он идёт на 401-й. Поэтому приходилось связывать лифт с 401-м TerrPt'ом, чтоб он стоял на 400-м в итоге
Это исправляется очень просто путем убирания галочки Active в свойстве Physics > Misc > MovingTerrain у платформы лифта. Тогда при старте миссии лифт остается неподвижным.
Что касается ящика в воде - у меня по этой части опыта нет, могу только высказать свои соображения. Если одна из TerrPt находится в твердом теле, это может блокировать просчет базы данных пути. Ты рискуешь поместить ее под воду. Возможно, это не вызывает сбоев при обработке, но есть сильные сомнения, что подобная система будет работать корректно, поскольку база данных пути для воды не просчитывается - AI не могут ходить по воде.
Если это так критически необходимо, я бы попробовал убрать воду, оптимизировать, просчитать базу данных пути, вернуть воду, оптимизировать снова и больше ничего не пересчитывать. Но это явно последний шанс и скорее всего тоже не поможет.
Остается только искать какой-нибудь обходной путь - смещать центр тяжести у ящика, использовать какую-нибудь разновидность фальшивой воды и т.д.
[Исправлено: Zontik, 2 июля 2008 14:48]
ЦитироватьЭто исправляется очень просто путем убирания галочки Active в свойстве Physics > Misc > MovingTerrain у платформы лифта.
Так вот для чего эта галочка нужна! Понятно...
Похоже, действительно придётся применять обходной путь - это как раз критически необходимо. (Кстати, Pathfinding Database в моём случае просчитывается нормально - проверял.)
Подскажите пожалуйста! Есть ли упрощеный способ связывать точки патруля? А то стандартным долго и нудно.
Мультибрашем отметь объект, от которого должна идти связь, отметь таким же способом другой объект, к которому должна идти связь, затем в меню жми Tools>Link Group и впиши название связи.
Есть. Уменьши число точек до двух - начальной и конечной. AI сам найдет дорогу.
[Исправлено: Zontik, 25 нояб. 2008 22:26]
Только в случае двух точек, если их между ними стена, AI будет идти максимально коротким путём, напролом упираясь в стену, тоесть не очень реалистично. Да и на большое расстояние между точками движок, зная его капризы по любой мелочи, может быть недоволен.
Zontik ;) Кстати! правильно! реальный способ сэкономить на точках патрулей, достаточно всего лиш 2 точки. С одной части города Ai сам находит путь в другую часть города! Главное после раставления 2-х точек нужно пропатчить начиная с портализации и заканчивая Build AI Room Database затем входить в игру и смотреть как Ai спокойно движется к точке! Сам толькочто испытал способ!
[Исправлено: zmey, 26 нояб. 2008 22:09]
Сделал в gamesys 2 объекта. 2-ой соединен с 1-м связью ParticleAttachment, а 1-ый со 2-ым ControlDevice. Когда создаю новый объект параметры связи ParticleAttachment теряются, а связь ControlDevice не наследуется совсем.
Есть подозрение, что это нормально - параметры связи ParticleAttachement каждый раз нужно настраивать заново (как у того же факела, например).
Вообще, насколько я успел заметить, иерархия и связи - вещи, плохо стыкующиеся друг с другом. Лично мне уже проще каждый раз вручную связь набивать.
[Исправлено: Dront, 13 нояб. 2010 21:21]
А разве у каждого факела нужно настраивать параметры связи? Не замечал.
Что касается ControlDevice - то это же нормально, что она не наследуется. Страшно вообразить, какая была бы каша, если наложить эту связь на какой-нибудь архетип. От всех выключателей к всем лампам, например.
На всякий случай проверь, в нужном ли направлении проложена связь ParticleAttachment. Она такая... немного неочевидная.
Вроде параметры связи ParticleAttachement по умолчанию - привязка к объекту (Object). А если нужно настроить на joint или submodel, то уже придётся менять параметры.
Своим высказыванием
Цитироватьпараметры связи ParticleAttachement каждый раз нужно настраивать заново
я имел в виду это. :embarassed:
Тьфу. Сейчас посмотрел ещё раз, внимательнее, что написал... У факела ж по умолчанию частички от Vhot'а номер 1 идут, и их перенастраивать действительно не надо. Так что написанному не верить, это я запутался. :)
[Исправлено: Dront, 15 нояб. 2010 17:06]
Получить список всех ссылок с номерами объектов:
edit_links
Найти на уровне все объекты, в которых задействована нужная ссылка:
edit_links ,,Имя_ссылки
Какую надо связь, чтобы прикрепить маркер к объекту, при этом маркер создавался, передвигался вместе с объектом?
CreatureAttachment
ParticleAttachment
PhysAttachment
И какой порядок аргументов (что From, что To?)
Прикрепляется 2 объекта из gamesys (т. е. с отрицательными номерами). Будет ли прикрепление сохраняться для объектов глубже по иерархии Н-р, если прикрепить маркер к Human (-14), будет ли он работать с любыми людьми?
И как добавить PhysAttachment? После добавления в списке связей не появляется и редактор все время падает :mad:.
В описанных условиях разве что ParticleAttachment сможет работать (не говорю, что корректно... вообще работать). Но для этого у прикрепляемого объекта должно быть одно из свойств из раздела Particles. Неважно, какие в этом свойстве будут заданы параметры - все равно они не задействуются, но иначе движок не распознает его как частицу.
А можно ли при получении сигнала TurnOn (по связи ControlDevice) отправить его обратно?
TurnOn
1 --------> 2
||
||
\/
TurnOn
2 --------> 1
Разве что ответный ControlDevice обратно, больше ничего в голову не приходит.