KOllapsE

Хорошо бы доработать разрушаемость построек (раз уж у них есть хп и танки-люди могут ломать их), тогда эта и подобные проблемы просто отпадут и можно будет восстановить разнообразие построек. Может, можно разработать и добавить режим с разрушениями, чтобы обычные зомби и спецзаражённые могли ломать? Сделать типа мутаций на коопе - захотели, проголосовали, играют. Если эксперимент удастся, то вообще только на этот режим перейти и развивать его, чтобы не было некоторой несправедливости с заработком средств на разных серверах Альянса да и нудятины фарма.

Почти у каждого на сервере есть убежище с мостами → многие будут недовольны, сломанные убеги + нарушенный фарм . Нужно придумать другое решение проблемы

0_о Это будет уже не выживание с огромным элементом фарма, это будет просто фарм-тир. Скучновато в такое играть

Ну, если бы объекты были бы разрушаемы, в том числе и от выстрелов, то ничего плохого бы в этом не было. А так получится ситуация как с мостами - заставил себя со всех сторон обычным деревянным забором, сделал прозрачным и стоишь как в тире, что довольно быстро надоедает. Так-то курильщики и плевальщицы создают интерес, когда нужно проявлять осторожность и взаимовыручку.

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

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

А мб пусть она в туалетах рядом с убежищем сидит? Ну или пусть спаунится после того, как нажали кнопку лифта.

Если посмотреть на слово "мау" с другой стороны

Знакомьтесь, это - Ящик! Ящик недавно увидел этот свет, поэтому у него все углы по нулям. На следующем фото Ящик немного перебрал спиртного и завалился по оси Х После такого, на следующий день, надо ли ему идти на работу или всё же можно дрыхнуть до обеда (повороты по осям Z или Y), он выберет только одно : D В общем, мы наблюдаем, что повороты по Z и Y свалились в одну ось, причём совпали по направлениям (это мы +90 по Х сделали). Если же сделаем -90 по Х, то они всё равно свалятся в одну ось, но уже будут поворачивать в разные стороны (!). Если сначала повернуть по Y или Z, а потом поворачивать другие, то сваливания двух осей в одну уже не можем поймать. Делаем вывод - используется одна иерархия и она во всём виновата. Теперь смотрим на повороты в видео и видим, что так происходит только при иерархии YXZ. Итог: надо бороться с алкоголизмом предметов : D. А если серьёзно, то повороты сначала по Z, потом Y, потом X не меняют конечного результата. Кругом пичалька. В общем, можно попробовать использовать повороты вокруг осей предметов (rotate YAW), но там может возникнуть та же проблема. Или узнать, где сидит эта иерархия (смотреть код поворотов) и при поворотах по другим осям менять иерархии - раз уж по Y сейчас всё нормально, то по другим тоже так можно.

Тут была надежда на то, что не будет скоса при повороте второго объекта, т.к. по другим осям в момент поворота ноль. Кстати, такие повороты "Если поворачиваем по Х, то делаем в таком - ZXY или YXZ. (0; 0; 89) → (90; 0; 89) → (90; 67; 89) можно смоделировать просто поворачивая объект в стройке по заданным углам. Действительно, если после поворота по Х не можешь правильно повернуть, допустим, по Z, то надо поменять порядок и сначала поворачивать по Z, чтобы в конце получить желаемый результат. Поменять порядок, в общем

Всё действительно происходило точно так же, только в другом порядке? Это же отлично! Это прямо указывает на gimble lock и что надо думать конкретно над ним Можно сделать следующее: обнулили углы, до этого у объекта были углы (45; 67; 89). Потом высчитали, как он должен повернуться - (90; 67; 89) (или YAW тут использовать, если неправильно я посчитал), т.е. сам объект не поворачиваем, только держим в памяти значения углов. Чтобы обойти "шарнирную ловушку", нужно грамотно использовать иерархию. Давай ещё раз глянем в видео (4:18), как там происходят повороты. Повороты по У там проходят идеально только в двух случаях - XYZ и ZYX. Смотрим дальше на другие повороты и выводим следующие рекомендации по поворотам: Если поворачиваем по У, то делаем после поворота три изменения углов в таком порядке - XYZ или ZYX. (это надо сразу проверить, если поворачивать будет нормально, как и раньше, только тогда пробовать другие, чтобы не тратить зря время) Если поворачиваем по Х, то делаем в таком - ZXY или YXZ. (0; 0; 89) → (90; 0; 89) → (90; 67; 89) Если поворачиваем по Z, то в таком - XZY или YZX. P.S. Если я нещадно туплю и не могу понять, что каждый раз используется одна иерархия, то надо узнать, какая она. Допустим, это XYZ. Тогда надо всегда сначала прибавлять Z, потом Y, потом X

@Electr0, ну да, поворот по У - самый нужный. Я вот думаю, что это может быть хорошей идеей - что-то делать с углами при других поворотах: Просто добавлять углы не получится - мы не знаем, как повёрнут объект и можно вызвать gimble lock там, где его не было. Есть такой вариант: запоминать углы всех поворачиваемых объектов, обнулять их, поворачивать объекты, а потом прибавлять им запомненные углы (если больше 360, то отнять 360). Не могу предсказать, ровно ли это будет, но вполне может быть.

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

Не, вру. Есть ещё четвёртая - если бить его рукопашкой, то она может выпасть.

Ну да, у него только три суперспособности: 1) Быть прозрачным 2) Делать спецзаражённых вокруг прозрачными 3) Страшно хрюкать при беге

Расстояния и так и так сохраняются, как надо - я сейчас ещё четыре опыта сделал, по-разному поворачивал объекты и расположение разное делал, сейчас с четырьмя объектами хочу проверить. Если гемморно переделывать всё под нулевые точки, то можно придумать, как их заменить или сымитировать. Но самое главное-то:

Расчёт "нулевых" точек «Нулевая» точка - чтобы узнать её для объекта из восьми крайних точек объекта узнаётся наименьший вектор к нулевым координатам карты. (или просто используются координаты всех восьми точек, если есть, по ним наименьшая длина и вычисляется) Вектор AB у первого объекта (жёлтый) самый маленький, поэтому В – «нулевая» точка для него. Если таких четыре, то берётся точка с наименьшей аппликатой (значение по Z для карты). AB=AC=AD=AE – при этом нулевой точкой выбирается B, так как она ниже всех расположена. Если таких две – выбирается точка с наименьшей ординатой (значение по Y для карты) AB=AC – выбирается В, так как у неё значение ординаты меньше.

Окей, я нашёл способ сохранять целостность постройки. Изложу по порядку. Я смоделировал то, как сейчас поворачиваются постройки. Вот у нас два объекта, плотно примыкающих к друг другу, чтобы потом можно было проверить правильность поворота. Делаю вектор АВ, затем поворотом получаю АС После этого перемещаю второй объект в точку С и доворачиваю оба объекта на градус, на который был повёрнут АС. Получается вот такая шняга с разлётом объектов: Как видим, один объект попал внутрь другого, в то время как они должны были прилегать друг к другу, без более тесных взаимоотношений Тогда я вспомнил об идее "нулевых" точек, от которых отказался в пользу точек пересечения осей объекта (даже на практике потом стало видно, что расстояние между объектами сохраняется как дОлжно, да и рассчитывать эти нулевые точки надо). Вкратце - "нулевая" точка - это ближайшая к началам координат карты точка объекта, выбирается из этих: Но у неё есть некоторое преимущество, пока не вкурил какое, но связано это с размерами объектов и векторами... Psycho (Shower Scene Theme).mp3 (можно заметить, что сейчас при переносе второй объект "вошёл" в первый на половину своего размера по ширине - как раз расстояние от пересечения осей объекта до его ближней точки к первому объекту). В общем, я решил быстренько проверить, что будет, если вектор АВ будет соединять "нулевые" точки объектов, а не пересечения осей объектов. Вот я провёл вектор АВ между нулевыми точками, повернул его, получив АС и уже переместил "нулевую" точку второго объекта в точку С: Теперь беру и поворачиваю объект на тот же угол, что и вектор АС до этого (как раньше, короче). При этом "нулевые" точки объектов и пересечения осей расползаются, но так и должно быть - поворачиваем объекты мы ведь не вокруг "нулевых" точек (я тут градусы в скобках не поменял, должно быть уже 90;-45;0, накосячил): Но зато что получилось - объекты не разлетелись! Стало/Было

"Так в чём же смысл жизни? О, бренность бытия..."

Я предлагаю поменять порядок расчёта. Пока не уверен, но он вполне может зависеть от порядка расчётов Rx, Ry и Rz отсюда https://en.wikipedia.org/wiki/Rotation_matrix#In_three_dimensions Получается - меняем при расчётах местами Rx, Ry и Rz, создавая нужную для поворота по этой оси иерархию и получаем правильный поворот.

Ну, сейчас же повороты по У всегда осуществляются правильно, как ни крути?) Хотим повернуть по У - и получаем нужный результат. Теперь меняем иерархию на zxy - и поворачиваем по Х всегда правильно. Т.е. опять получаем нужный результат. Используя нужную в зависимости от случая иерархию можно будет всегда получать правильные повороты.

Я имею в виду, что поворот по часовой привязан к системе координат объекта, а не карты. И это можно использовать, раз уж есть такое на руках. Я так понимаю, сейчас при поворотах используется xyz или zyx иерархия. Решение для правильных поворотов по Z и X - менять иерархию в зависимости от того, по какой оси мы хотим поворачивать объекты. Хотим по Х - используем zxy, что будет с остальными осями нам всё равно, мы их не используем в тот момент. Если после этого поворачиваем по Z - используем yzx. Только вот осуществимо ли это сейчас и не распухнет ли плагин ещё в пару-тройку раз? : D

Не пойму никак - просто брать и поворачивать? Каждому объекту вроде и добавляется угол, как должно. Наверно, надо обратить внимание на пункт меню стройки "по часовой". Если остальные повороты просто добавляют заданные значения к углам, то повороты по часовой делают с углами непонятно что на первый взгляд, но объект всегда поворачивается вокруг синей оси и именно на заданный угол. Т.е. они правильно используют http://en.wikipedia.org/wiki/Rotation_matrix#In_three_dimensions относительно XYZ объекта Если с проблемой поворотов Х и Z ничего не выгорит, то есть такой вариант: проверить, можно ли будет использовать его не только для поворотов самого объекта, но и другие объекты относительно него поворачивать, а так же сделать поворот типа "по часовой" для красной Х и зелёной У оси. Если да, то можно будет делать так: запомнить и обнулить углы всех, кроме одного, предметов, повернуть относительно какой-либо его оси все предметы, а потом к углам каждого предмета добавить запомненные ранее. Есть минусы - игрокам поворачивать будет менее удобно, потому что оси первого объекта могут быть расположены не параллельно соответствующим осям карты и надо будет сначала поворачивать его; всё ранее сделанное по поворотам будет впустую. Но повороты будут). В общем, на крайний случай вариант.

а что, прототип уже на Меге? 0_0

Ну-у-у, тогда стоит уделить внимание тому, почему по Y магия работает, а по X и Z - нет