Впервые здесь? Я Роха — провести быструю экскурсию?
Ошибка соединенияНеверный запросСтраница устарелаСессия истеклаТребуется входЗапрещеноНе найденоСлишком много запросовВнутренняя ошибка сервераПлохой шлюзСервис недоступенТайм-аут шлюзаВерсия HTTP не поддерживается
Сессия истекла
Ваша сессия истекла. Пожалуйста, войдите снова.
Требуется вход
Для этого нужна учётная запись. Войдите или создайте её — это займёт минуту.
Страница устарела
Токен безопасности отклонён — обычно потому, что страница была открыта слишком долго или вы вошли в систему в другом месте. Ничего не сохранено. Обновите страницу и повторите.
Запрос не выполнен
При обработке вашего запроса возникла проблема.
Проверьте подключение к интернету и попробуйте снова.
Как вывести текстовое сообщение? Рекомендую ознакомиться с ЧаВо Jack_of_Shadows - есть у него в подписи и в файлах группы у меня в подписи. Делается скриптом.
Как вывести текстовое сообщение? Рекомендую ознакомиться с ЧаВо Jack_of_Shadows - есть у него в подписи и в файлах группы у меня в подписи. Делается скриптом.
Огромное спасибо! нашел у вас множество гайдов и файлов!
Всем привет В процессе создания и тестирования карты столкнулся с одной проблемой. Суть - есть ии игрок, в замке у него сидит мощный герой, он задизейблен, ему назначена роль HERMIT (чтобы с ним никто не взаимодействовал). У ии игроков есть два героя в резерве, которые скриптом оттуда достаются. Они должны вести себе как обычные герои - отбивать шахты, ресурсы, повышалки и т.д. Но они встали как вкопанные и ничего не желают делать. Как можно исправить это поведение и заставить героев из резерва вести себя как обычный ии? Думал поставить ИИ атрактор, но он тоже работает не стабильно, и не можеть быть настроен на двух героев одновременно.
Тогда логично предположить, что поведение HERMIT, указанное в настройках игрока, распростаняется и на них?
Если опираться на документацию, то SetHeroRoleMode должна работать на конкретного героя, но не игрока в в целом. Но вспомнил, что можно попробовать в настройках игрока в map properties глянуть, там вроде для всего игрока было что-то похожее
Добавлено через 2 минуты AstralLein
Кроме того, для блокировки взаимодействия с конкретным героем ИИ есть отдельная скриптовая функция
А про какую функцию идёт речь? Я в доке не нашёл такого
Добавлено через 9 часов 30 минут После череды экспериментов я пришёл к выводу, что сочетание активных героев из резерва (не бегущих в одну точку) и афк героя в замке под контролем одного игрока практически нежизнеспособно. Я ставил разное поведение под игрока в целом, а не конкретного героя через скрипт. Перечитал ещё раз доку - функция на блокировку взаимодействия с конкретным героем ИИ там по сути только одна - та, о которой я писал выше - SetHeroRoleMode (HERMIT). В итоге остались доступны только два варианта: - резервных героев заменить на обычных таверных героев, они ведут себя как надо даже с афк героем в замке. - убрать афк героя из замка, и резервные герои начинают больше активничать.
Всем привет! И снова у меня возник вопрос, на который я пока не нашёл ответа - как сделать так, чтобы после победу над вражеским героем арты не передавались игроку? Как это сделать в пределах одного игрока понятно - свойство untransferable - но увы, оно работает только если я хочу обменять арты между своими же героями. Единственный вариант который пока мне пришёл в голову - отнимать конкретные арты после сражения, но это выглядит как костыль...
SetHeroLootable(<имя вражаского героя>, nil ) должна как раз это делать, но я не проверял.
SetHeroLootable(<имя вражаского героя>, nil ) должна как раз это делать, но я не проверял.
Да, я как раз протестил, работает) И что самое приятное, работает даже на резервных героев, если их нет на карте. А резервные герои это вообще забавная штука, конечно...
Приветствую! Есть вопрос к картостроителям и скриптоделам касательно функции startThread - существует ли какое-то желательное число открытых потоков, при превышении которого игра может зависнуть?
Дело в том, что некоторые проверки я запускаю не через триггеры, а в отдельных потоках, и есть опасения, что игру от этого может переклинуть. У меня была ситуация, когда после запуска функции в отдельном потоке игра фризилась. Я поставил потом слипы в начале и конце функции, но опасения, что игра все так же может зависнуть, остались.
Те, кто практиковали использование startThread - были ли у вас случаи заклинивания функций в отдельном потоке и если да, как вы их решали? А также сколько в среднем на ваших картах было запущено дополнительных потоков в один момент времени?
Если что, на текущий момент все мои функции, запускаемые в отдельных потоках, имеют следующий вид:
function doSomeChecks() while (1) do sleep(10) --some code if (condition) then --some code break end sleep(10) end end
Приветствую! Есть вопрос к картостроителям и скриптоделам касательно функции startThread - существует ли какое-то желательное число открытых потоков, при превышении которого игра может зависнуть?
О конкретном ограничении не слышал. Не знаю, какие проверки требуются в Вашем случае, но я бы попробовал несколько потоков с отдельными проверками заменить на последовательные проверки в одном потоке, если это возможно, так более надёжно будет. IchGViji
Те, кто практиковали использование startThread - были ли у вас случаи заклинивания функций в отдельном потоке и если да, как вы их решали? А также сколько в среднем на ваших картах было запущено дополнительных потоков в один момент времени?
Использовал startThread только один раз (нужен был вызов функции каждый раз, когда герой получает опыт), всё хорошо работало, ставил sleep(5). Зависание возможно из-за бесконечного цикла (где-то там, где у Вас --some code)?
О конкретном ограничении не слышал. Не знаю, какие проверки требуются в Вашем случае, но я бы попробовал несколько потоков с отдельными проверками заменить на последовательные проверки в одном потоке, если это возможно, так более надёжно будет. Использовал startThread только один раз (нужен был вызов функции каждый раз, когда герой получает опыт), всё хорошо работало, ставил sleep(5). Зависание возможно из-за бесконечного цикла (где-то там, где у Вас --some code)?
Цикла бесконечного нет, там условие очень специфичное, я дебажил. Один из примеров, где я использовал startThread - это проверка, что у вражеского игрока нет городов и героев (кроме резервных). С таким подходом код, как мне видится, будет чище и проще.
Если же делать эту проверку триггерами, то получится, что одну функцию придётся прописать в нескольких местах - в функции, триггерируемой потерей героя, в функциях, триггерируемых захватом городов (а каждая группа городов имеет свою отдельную функцию-обработчик). Это делает поддержку кода более сложной.
Плюс проверка разовых событий - для new day триггер-функции я планировал прописывать именно что регулярные события, чтобы не перегружать её.
Можно иметь сотни потоков одновременно и игра будет нормально это воспринимать. Не стоит только некоторые отдельные вещи в бесконечном потоке чекать, например, проверять стоимость пути в мувах соотв. функцией - вот это убивает игру даже одним потоком.