Aynekko писал: У скопированного триггера при смене класса не сбрасываются спаунфлаги.
Это вполне ожидаемое поведение.
Вообще, возможность менять класс в списке у уже созданной энтити - это просто катастрофический прокол UI хаммера. Из-за кажущейся лёгкости многие создают произвольную энтитю, и потом меняют класс на нужную. И им кажется, что они понимают, что при этом должно происходить. А на самом деле это сценарий запутаннее некуда.
Вот еще деталь. Да, галочки остаются при копировании. И они остаются, если выбрать новый класс из списка окне свойств. А я вбил trigger_once вручную (для меня это быстрее). И галок нет. Но, судя по всему, по факту они остались.
Aynekko писал: И галок нет. Но, судя по всему, по факту они остались.
Остались конечно, потому что поле spawnflags осталось.
Выглядит как баг, да, в какой-то момент это поле не считывается для обновления галок. Спасибо, гляну!
Aynekko писал: если выбрать новый класс из списка окне свойств. А я вбил trigger_once вручную (для меня это быстрее)
Из сохранения свойств при смене класснейма для скопированной энтити вручную, а не при выборе из выпадающего списка, растёт много проблем. Было бы поведение как в хаммере с занулением всего при смене - не пришлось бы городить огороды с подсвечиванием неописанных в фгд полей красным, не пришлось бы заводить кнопочку purge. Вот, теперь проявилась проблема со спаунфлагами. XaeroX помнится, ты писал, чем обоснована такая логика в Джеке. Кажется особенностями undo/redo, верно?
Aynekko писал: У скопированного триггера при смене класса не сбрасываются спаунфлаги.
Дело не в том что они не сбрасываются (в Кварке тоже не сбрасываются), дело в том, что умный Джек при смене класснейма прячет это поле совсем. А должен показывать снизу, как обычное поле.
Добавлено 22-01-2022 в 09:32:
Цитата:
Ku2zoff писал: Было бы поведение как в хаммере с занулением всего при смене
Это тоже нехорошо. Не надо трогать то, что ты не редактировал.
Надо просто показывать что эти поля теперь не считаются частью настроек и рисовать их после полового разделителя.
Вот такой прикол словил. Помогло переименование энтити на "ex" и обратно на ec_sg. Для другой так же. Как уж так получилось - не представляю.
Даже перезапуск джека не помогал, все равно не находил таргетнейм)
Aynekko писал: Даже перезапуск джека не помогал, все равно не находил таргетнейм
Джек ищет не по именам полей targetname/target. Иму всё равно как они называются. Он смотрит описание в fgd - если там тип поля target_source, он будет сверяться с target_desination-ами. В твоём случае, возможно, произошла чюдовищная ошибка и Джек потерял связь с реальностью описанием класса в fgd. Возможно, ты ошибся в написании класснейма? Всё равно же SmartEdit отключен, мог не заметить.
Отключил я его чтобы сверить, таргетнейм там или что, думал в фгд ошибка может. Вот хз даже, что это было. Потом я включил смарт, ввел другой нейм, кликнул на него (чтобы применить типа), потом ввел старый и еще раз кликнул. И все, нашелся.
Вот даже так. У меня не воспроизводились сентенсы в игре, парочка. Вывел все энтити в консоль и очень удивился. И самое странное, что в ксашевском логе отображается нормально, а в консоли нет. И как раз эти же энтити и не запускаются - пишет нет такой энтити.
Я снова в смарт режиме переписал название и все заработало... Где и что просочилось, ума не приложу.
Баг: выделяю 2 энтити с разным параметром. У одного 200, другой 199. Открываю свойства. Вижу (no change). Кликаю на текстовое поле с надписью (no change). Затем кликаю на имя параметра в левой таблице. Закрываю свойства. Выделяю одну из энтитей, открываю свойства. Вижу (no change), хотя должна быть цифра. Скомпилил карту, и да, параметр похерился. Он превратился в тыкву текст.
Логично. Но зачем? Может лучше сделать, чтобы это значение игнорировалось?
Просто было я случайно нажал и пришлось восстанавливать по памяти, благо ничего особо важного. Сейчас вот отловил уже, буду знать.
| IP: 
21-01-2022 20:22
Кликнул в поле = отредактировал.
