Electr0

Пингвин брал в долг и не возвращал

у нас уже и за попрошайничество банят?

https://hlstats.ally.pro/hlstats.php?mode=playerinfo&player=255312 на 14 ом.

Значение Статус изменено на: Отклонено

рисуйте добавим, я не моделлер

Значение Статус изменено на: Отклонено

рисуйте, добавим, я не моделлер

Значение Статус изменено на: Отклонено

думал над этим, ну скажем так это невыполнимо, к примеру не у всех моделек одинаковые оси Z которые смотрят именно вверх или вниз, например в качестве пола ты выбрал деревянную стену у которой ось Z в наклоненном к земле состоянии смотрит в одну из сторон света в итоге хотя копирнуть все наверх, врятли все скопируется так как хотелось, ведь это дело персональное для каждой модели.

Значение Статус изменено на: Отклонено

это дело каждого что покупать, нафармить не проблема для того кому надо

данные перенесены.

да

стим иды пишутся в другом формате, в формате STEAM_1:0:xxxxxxxxx, я тебе писал STEAM_1:762640514 ты мне зачем шлешь обрезок

нет таких стимидов

фикс вложен в Прототип BUTTONS REFRESH 3.8, когда он выйдет никому не известно.

Значение Статус изменено на: Тестируется

второй стим ид несуществует, проверяй правильность скопированных данных.

Прототип BUTTONS REFRESH 3.8 Теория: Реализовать централизованный пошаговый обработчик, который за 0.01 сек передвигает каждый предмет действия который надо двигать по заданному отрезку, предварительно проверив каждое на валидность. Это и будет самопроверка на целостнось, такой подход полностью исключит рассинхронизацию предметов в пространстве Рабочие заметки: Думаю надо использовать массивы под кол-во оставшихся отрезков и рассчитанные координаты чтобы хранить расчеты, и потом в самом конце шаговика делать конкретно исполнение. Вопросы возникают относительно правильной очередности исполнения, раз у нас есть возможность делать отрезки в той же очередности как это прописано в кеше кнопки, нужно попытаться реализовать именно так. Если использовать массивы под координаты и под оставшееся кол-во отрезков то в принципе не возникает вопросов. Просто цикл for и все, ну а в массивах ячейки нумеровать исходя из очередности. Так же есть вопросы относительно того как сохранить коррекцию позиций игроков до а процедуры выполния действий по расчетам. Ведь на каждое медленное действие свои коррекции и их нужно соблюсти. Дать игроку право выбирать нужно ли ему чтобы предметы двигались как один жестко связанный предмет например это выгодно для лифтов состоящих из множества предметов объединенных в одно целое ну например пол и кнопка, но в то же время это не нужно для раздвигающихся дверей, особенно если их много и кто-то решит постоять в одной, в таком случае действие таких дверей будет приостановленно до тех пор пока игрок не перестанет мешать и будет крайне глупо смотрется, поэтому точно нужно добавлять выбор в настройках кнопки. Там же можно кстати позволить игроку выбрать профиль предмета, лифт, раздвижная дверь и прочее что так же может лучше организовать процедуру перемещения в пространстве. Ведь мы будем понимать что делает кнопка и правильней выстраивать проверки. Сделано: В настройки кнопок добавлена опция, Тип медленного передвижения:: Асинхронный (по умолчанию) Синхронный Исправлен баг с очисткой защиты слота после конца раунда Полностью реализовано асинхронное и синхронное движение (100% контроль над синхронностью) Запользовать шаговик как форсировщик, это позволит реализовать повороты т.к. форсировщик больше не будет иметь риск сломать последовательность действий. Восстановить работу сломанной проверки доступа которая ориентировалась на запущенный таймер. Кеширование UUID предметов с которыми будем работать до запуска шаговика, поскольку это очень тяжелая операция и выполняется она при каждом шаге шаговика что прям таки зверзки грузит.из предиктивной проверки вырезана поддержка медленных действий т.к. пока не придумал как внедрить без траты лишних ресурсов. в предиктивной проверке внедрены оптимизации из шаговика, к примеру по новой уже не берет координату под каждое из действий для одного предмета кеширование UUID вне функций PredictCheckButtonActions и ProcessButtonActions, кое где это дает хорошую экономию т.к. избавляет от необходимости кешить два раза подряд, если идет предиктивная а потом исполнительная сразу же. Исправлены утечки памяти появившиеся после прототипа 3.6 Все ранее неуправляемые таймеры анимации кнопок теперь заменены датаймерами и их работа контролируется во время форсировки медленных действий до снятия снимков. Как оказалось предиктивная проверка всех отрезков работает неправильно при наличие более одного медленного действия над одним предметом, данный баг выявился когда тот же принцип я хотел использовать в шаговом обработчике, тоже придется исправлять. Добавить медленные повороты Выделить все нужные данные под медленные действия в отдельный кеш, туда войдет: статус кнопки во время запуска медленных действий кол-во оставшихся шагов структура будет повторять структуру основного кеша кнопок но важно понимать тут только нужные данные, так мы избавивмся от ненужного мусора в основном кеше, а так же от проблем сброса статуса кнопки, когда мы по итогу не понимаем что делала кнопка до запуска форсировщика. Исправлен баг при выполнении пуш кнопкой медленных действий сразу же по концу можно тут же прожать и скипнуть анимацию кнопки. Полностью переписан форсировщик, теперь он не делает что-то за кнопки, а заставляет их таймеры выполнятся сразу после запуска форсировщика, это избавляет от тонн кода и багов.

Прототип BUTTONS REFRESH 3.7 В предыдущем прототипе наладил антизастревание, исправлено много багов, и в целом релиз уже готов, но все же нужно наладить синхронность, например если блокируется движение одного из медленных предметов кнопки, все остальные медленные предметы которые не блокируются продолжают движение, не очень красиво когда кнопка в лифте устремляется вверх пока платформа стоит) EDIT: Первая версия борьбы с рассинхронным движением множества медленно двигающихся пропов под эгидой одного действия, для того чтобы они не теряли свой конечный вид, данная версия имеет точность в один отрезок, это значит что она допускает рассинхрон в один отрезок между пропами, в некоторых тяжелых случаях у нее это не получается вообще, но в целом она спасает 90% ситуаций, что уже намного лучше чем было до нее. есть у этой версии вероятная причина заклинивания кнопки после удаления предметов во время заклинивания и попытки запуска действия снова, сам я этого не смог получить, почему не знаю, должно ломатся, но нет. получить полностью точную версию можно, но это потребует полного рефакторинга текущей системы передвижения предметов по отрезкам. Суть такова, можно сделать вместо кучи таймеров, один общий, который работает раз в 0.01 сек и смотрит каким пропам надо подвинутся, каждый раз он смотрит все предметы на возможность сделать действие и если можно то разом их двигает, а вот если нет то не делает ничего, соотв вероятность сдвига сведена к нулю вообще, но вот получится ли сделать такой подход я не знаю.

это конечно забавно написать о переносе данных в чужую уже выполненную заявку, спасибо я поржал, отказано, оформляй нормально.

Прототип 3.6 залит на сервера, функции медленных передвижений скрыты от всех кроме меня, пока проходит тестирование и выявление новых теоритических уязвимостей. Дополнения: Выявлена уязвимость по телепортации за карту при сверхдлинных отрезках, которую уже удалось закрыть путем уменьшения максимальной длинны отрезка до 20 юнитов. Закрыта проблема сваливания с движущегося по осям x y предмета если прыгать на нем. Закрыта проблема зависания статуса кнопки после включения медленных действий (связано с редкими случаями некорректного расчета оставшихся отрезков) Исправлен кривой рендеринг предмета после работы снимков во время конца раунда во время медленных действий, как оказалось при телепорте предметов на финальные позиции им присваивался эффект EF_NOINTERP самим движком. фикс недостатков округления которые могут ввести в заблуждение форсировщик медленных действий, (продолжение фикса проблемы с зависанием статуса, но уже окончательное решение) фикс дубля создания снимков который исходил из ACS и портил снимки тем что в этому времени кеш кнопок уже очищался и в итоге кнопки ломались в снимке.