Изучаю DromEd

[Shaver]

Dront, большое спасибо! Alt+Е это конечно хорошо, но меня очень волнуют последствия сохранения после этого Alt+E.

...приучил себя сохранятся перед каждым Alt+G. Теперь надо ещё привыкнуть загружаться после каждого возврата в Редактор. Или в 1.19 не надо? Чем конкретно это может быть чревато? Если я продолжал работать в редакторе после игрового режима и сохранялся (почти всегда в новый файл, но практически с самого начала работы) обязательно ли это приведёт к ошибке (если не сейчас, то позже)?приучил себя сохранятся перед каждым Alt+G. Теперь нада ещё привыкнуть загружаться после каждого возврата в Редактор. Или в 1.19 не надо? Чем конкретно это может быть чревато? Если я продолжал работать в редакторе после игрового режима и сохранялся (почти всегда в новый файл, но практически с самого начала работы) обязательно ли это приведёт к ошибке (если не сейчас, то позже)?

[Zontik]

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

[Dront]

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

[Soul_Tear]

Уже раз сто сохранился после возвращения в редактор. А в пол проваливался еще до того, как узнал про команду.

[Shaver]

Спасибо всем!

Такая напасть:

ERROR: SplitPortalPolyhedronByPlane: didn't cross plane
ERROR: Portalization ailed, WR was cleared

Слова вроде понятные, сути не пойму.

[Dront]

Shaver, эта ошибка стара, как Дромед.
Очень велика вероятность, что беда в плохо выровненных по сетке брашах.
Если уменьшить размер сетки до 11 и ввести последовательность команд:
hilight_check_snap 1
hilight_do_snap
hilight_clear
- ошибка исчезнет?
Бонус: внимательно следить за брашами после ввода второй команды

[Zontik]

И не забываем про Area Brushes > Me only, чтобы локализовать источник проблемы.

[Soul_Tear]

hilight_check_snap 1
hilight_do_snap
hilight_clear

Дополню, в Toolkit'е это делается Highlight > Snapping > Unsnapped (аналог hilight_check_snap 1) > Snap Highlighed (аналог hilight_do_snap).
Однако, это касается брашей, расположенных под углами кратными 90 градусов. Браши с другими углами через вкладку выровнять нельзя, и придется вводить вышеуказыванные команды, за исключением hilight_clear - так как выделение само снимается при заходе в игру.

[Shaver]

Спасибо за ответы.

И не забываем про Area Brushes > Me only, чтобы локализовать источник проблемы.

Это не помогало, т.к. проблема была глобальной (буквально повсеместной). Ниже я объясню, почему.

Что ДроМеду "приятнее" XXX,8 или XXX,75; XXX,1 или XXX,125 (XXX+1/8)?

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

Так вот: "случайные" дроби он не переваривает вообще!!!
ДромЕд понимает только целые числа, и частные случаи десятичных дробей! А именно кратных 1/2 (0.5), 1/4 (0.25), 1/8 (0.125), 1/16 (0.0625), 1/32 (0,03125) и так далее.

Так, если вы вводите вручную, например, координату 12,8 ДромЕд тотчас же подло корректирует её до значения, которое он понимает. И если в окне ввода вам видно, к примеру, 3 знака после запятой, то отображаться будет 12,800. Но если отображается 8 знаков после запятой (для этого в DromEd.cfg должны фигурировать строки:
gfh_height 170
gfh_max_cmd_width
gfh_coord_decimals 8
ссылка на тему ТТЛЖ была чуть выше), то вы увидите, что 12.8 подкорректировано до 12.79999993. Может цифры другие, но суть та же: это 12 целых и сколько-то-там 128-х (или 256-х, или 512-х).
Похожий принцип рабатает и в угловых величинах, но там за целое (некую единицу) принимается 45град. Дробное же будет кратно 22.5град, 11.25град, 5,625град и т.д.

У меня же в миссии даже понятные ДромЕду целые числа-координаты некоторых брашей оказались с погрешностсями. Возникли они из-за частого пользования кнопками-стрелочками по бокам окон ввода коорд-т. Одно нажатие даёт смещение на одну сотую ед. НО! мы ж помним, что 0.01 это "непонятная" дробь, ДромЕд её заменяет дробью вида 0.00999998. В результате координата 12.25000000 после нажатия на правую стрелочку 25 раз превращается в 12.50000012 (или около того) и при оптимизации все эти хвосты и приводят к ошибке, о которой я писал в предыдущем посте.

Знатокам всё это может и не интересно, но тем кто изучает ДромЕд пригодится.

[Shaver]

Стрелочками теперь не пользуюсь, а если и да, то потом вручную стираю "хвост"

А и ещё: рум-браши созданные через Шифт+Инс обычно не имеют аккуратных размеров (Zontik писал где-то что они на несколько процентов болльше оригинальной браши) - корректируем вручную.

[Dront]

Насколько мне известно, только для operation brush-ей (то бишь обычных брашей, из которых строится уровень) нужно такое строгое выравнивание. Во всяком случае, с area brush'ами, room brush'ами и т.д. такие ухищрения уже не нужны.
Подозреваю, такая избирательность нужна только для одного: совокупность operation brush'ей - это скелет уровня, который нужно обсчитать и превратить уже в портализованный 3D-уровень. А уже после этого можно наращивать всякие мяса и кожи в виде объектов, источников света и т.д.
Как раз в процессе обсчёта и используются все эти "плоскости", "полихедроны" и тому подобные малопонятные термины. Но это если совсем на пальцах и совсем поверхностно, вроде где-то на форуме писали более подробно о том, как это происходит.
Поэтому рум-браши, флоу-браши и уж тем более ареа-браши, которые, по сути, являются вспомогательными, и их размеры/координаты не требуют такой драконовской точности. По логике. Опять-таки, повторюсь, лично моё предположение.

А касательно размеров брашей - лично я ВСЕГДА ввожу координаты вручную, если не уверен в выравнивании и/или лень его перенастраивать. Когда вводишь 0.125, то будешь железно уверен, что это 0.125, а не 0.124935343.

[Zontik]

Room brushes на портализацию никак не влияют, так что менять их или оставлять - дело вкуса. Доказательство очень простое: после их изменения не требуется выполнять портализацию.
А вот по поводу хвостов - интересное наблюдение. Получается, что реальный контроль возможен только при режиме отображения n знаков после запятой?
Правда, сейчас стал вспоминать - и не нашел в обозримом прошлом ни одной ситуации, когда мне пришлось бы двигать архитектуру стрелочками. Одна сотая - все же слишком мелкий шаг для реальной работы, не нажимать же на стрелку 100 раз, чтобы сдвинуть на единицу! Куда как проще вбить эту единицу вручную. И даже пять раз - это все равно неоправданно много.
А-а, стоп! Вспомнил! Как раз недавно поймал ошибку при оптимизации на большом уровне. Долго искал источник. Когда сузил пробленую область до немыслимых пределов, в нее попали несколько объектов в том числе. Решил исключить их в первую очередь. Каково же было мое удивление, когда ошибка пропала после удаления одной из дверей!
Ну, поскольку внутри двери также находится один портал, ее можно условно приравнять к элементу архитектуры. То есть они точно так же просчитываются при портализации. Так что здесь сюрприза нет.
Сюрприз был в другом: все координаты двери были, как обычно, совершенно точными. Я объяснил для себя эту ошибку тем, что расположил слишком много одинаковых дверей друг под другом, в одних и тех же координатах.
Но теперь нашлось другое объяснение, куда более логичное. Дело в том, что именно двери я как раз выравниваю стрелочками!! Поскольку подвинуть их обычно бывает нужно совсем чуть-чуть.
Что ж, пора менять старые привычки. Теперь только ручной ввод координат, и для дверей тоже. Спасибо за исследование!

[Soul_Tear]

У меня же в миссии даже понятные ДромЕду целые числа-координаты некоторых брашей оказались с погрешностсями. Возникли они из-за частого пользования кнопками-стрелочками по бокам окон ввода коорд-т. Одно нажатие даёт смещение на одну сотую ед. НО! мы ж помним, что 0.01 это "непонятная" дробь, ДромЕд её заменяет дробью вида 0.00999998. В результате координата 12.25000000 после нажатия на правую стрелочку 25 раз превращается в 12.50000012 (или около того) и при оптимизации все эти хвосты и приводят к ошибке, о которой я писал в предыдущем посте.

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

Что касается румов, есть какая-то команда, позволяющая наложить ее на брашь 1 к 1.

Room brushes на портализацию никак не влияют, так что менять их или оставлять - дело вкуса. Доказательство очень простое: после их изменения не требуется выполнять портализацию.

Ну здрасти, звездочка точно также появляется.

[Shaver]

Есть лесница. Ширна ступенек - 4, глубина 1.25, высота 0.75. Оснащена столбиками, перилами, балясинами, шишками на столбиках (весьма детализированнная в общем). Ступени образованы клиньями, состыкованы плотно (хайлайт не ругается).
Так вот при подъёме, иногда, наверное, в зависимости от настроения Г., застряёт на одной из них. Если чуть сдать назад, потом вперёд - застревания нет.
Других закономерностей не обнаружил.
Уверен, что проблема популярная. Подскажите, пожалуйста решение.

[Soul_Tear]

Это винтовая лестница? Вполне возможно застрять в самой узкой части клинов. А может мешают перила и пр.