Что такое foe scripts space
Что такое foe scripts space
Ну вот и обещанный гайд по программированию или скриптингу в Space Engineers. Это первая часть гайда и в ней мы рассмотрим объвление переменных и типы переменных.
И так, для начала мы установим Programmable block на нашу станцию/корабль.Открываем панель управления блока и жмякаем на кнопку «Edit». Мы сразу же видим:
Данный код создаёт метод Main в нашей внутриигровой «программе» в которой и будут происходить наши действия.Без него код не запуститься.
Писать код мы будем между строк, для этого кликаем ЛКМ после скобочки < и жмём Enter.
Объявим переменную.Что-бы объявить переменную в C# нужно перед названием переменной указать её тип, существует много типов переменных, но я сейчас перечислю самые популярные, а это:
Создадим переменную one типа int и зададим ей значение 100, для этого пишем в коде int one = 100
У нас должно получиться так:
Создадим ещё две переменных типа int.
Что мы сделали?Мы создали две переменные «one» и «two», значение one = 100, значение two = 50, создали ещё одну переменную zn, значение которой равняется разности двух переменных.То-есть 100-50, значение переменной zn будет равняться 50.
Так же можно делить: /
Умножать: *
Складывать: +
Всем доброго времени суток. У вас не бомбит по поводу отсутствия обещанных гайдов? А у меня припекло.
//Так что, возьму на себя смелость написать гайд. Тему возьмём обещанную “Ветвление и циклы”. Как и положено зазнайке, я буду слегка выпендриваться большим количеством теории, но всё же
постараюсь сократить её до необходимого минимума.//
Ветвление.
//C# представленный нам для создания скриптов в SE, представлен в виде ФЯП (функционального языка программирования), а он является линейным. Это значит, что программа выполняется последовательно и её можно представить в виде БСА (Базовой структуры алгоритма). Для того чтобы программа имела возможность нескольких решений, и используют ветвление. Что же такое ветвление? Это своеобразный выбор между возможностями решений, в зависимости от условий.
———————————————————————————————-—
В качестве примера мы с вами разберём кодовый замок, сделанный на основе сенсора. Сенсор будет выполнять в данном случае функцию ячейки памяти. (Поясняю, у сенсора 6 параметров которые мы можем изменять и проверять) Всё что нам надо также знать это увеличение сенсора и метод кодирвоания (экспериментальным, увеличение сенсора-2,45 за одно нажатие кнопки. Максимально значение 50, минимальное 1, значит диапазон возможных значений- 20. Следовательно, мы сделаем код из 3 ячеек, с 20-ю значениями в каждой). Одна из особенностей данной системы в том, что для правильной комбинации может быть множество вариантов. Это может быть сумма чисел, их разность и т.д. Мы будем использовать метод сравнение чисел.
Forge of Empires из AS3 в Haxe. Постмортем
В комментариях к переводу доклада с HaxeUp Sessions 2020 Hamburg — Зимний отчет о состоянии Haxe — был задан вопрос о том, зачем нужен Haxe. На него, конечно же, ответили там же, в комментариях. Предлагаемый вашему вниманию перевод еще одного доклада с прошедшего HaxeUp должен, по моему мнению, стать дополнительным аргументом в защиту Haxe, т.к. данный доклад посвящен игре, заработавшей более 500 млн. евро.
Автор доклада Ненад — один из программистов InnoGames, работавших над конвертацией Forge of Empires из ActionScript в Haxe. 2 года назад в Амстердаме InnoGames рассказывали о своей работе в данном направлении. Сегодня же можно сказать, что им это удалось в полной мере — теперь обе версии веб-клиента (Flash и html5) собираются из единой кодовой базы на Haxe. И данный доклад является по сути обзором проделанной работы и принятых решений, как удачных, так и не очень.
Начнем с представления — кто такие InnoGames?
InnoGames — один из крупнейших разработчиков игр в Германии (г. Гамбург) со штатом более 400 человек. В настоящее время компания в основном занимается мобильными играми, но также продолжает поддержку и развитие браузерных игр, созданных ранее (у большинства их браузерных игр также есть и мобильные клиенты). В этом году доход компании за все время ее существования (lifetime revenue) достиг отметки в 1 млрд. евро.
Forge of Empires — это:
Как можно понять, Forge of Empires приносит существенную долю прибыли, и InnoGames не могли позволить ей умереть вместе с Flash. Таким образом, возникла необходимость создания html5-версии игры, которая работала бы не хуже Flash-версии.
Давайте рассмотрим удачные, по мнению компании, решения, принятые в ходе работы по созданию html5-клиента:
1. Для оценки возможностей и ограничений существующих технологий, а также для минимизации рисков в InnoGames приступили к прототипированию — созданию небольшой демонстрации, показывающей игровой город с анимированными зданиями, работающими tween-анимациями, работающим пользовательским интерфейсом и взаимодействием с бэкендом игры.
В рамках прототипирования было испробовано множество технологий, при этом не все из них позволили создать работающий прототип (например, CreateJS не подошел по причине слабой поддержки Flash API и проблем конвертации ActionScript-кода в JavaScript). До стадии работающего прототипа дошли только Egret и OpenFL — обе технологии соответствовали предъявляемым требованиям. Но в случае с Egret дополнительным минусом было то, что это проприетарная технология. Имеющийся в Egret конвертер кода не всегда выдает оптимальный код — в тех частях кода, которые конвертер не смог «понять», избыточно использовалась рефлексия. А так как код самого конвертера закрыт, то на его работу невозможно повлиять.
Случай Haxe и OpenFL — это совершенно другая история, т.к. это технологии с открытым кодом. Кроме того, на создание работающего прототипа на OpenFL потребовалось значительно меньше времени.
2. Управление проектом:
С самого начала перед нами стояли ясные цели:
У нас был хороший план:
В феврале 2018 была выпущена бета html5-клиента, в которую по своему желанию могли поиграть наши пользователи. Два месяца мы занимались сбором обратной связи и исправлением выявленных проблем.
В апреле html5-версия стала версией беты по-умолчанию.
Еще два месяца спустя мы добавили возможность выбора версии клиента пользователям, играющим в стабильную версию игры.
Затем в июле было проведено A/B тестирование, в ходе которого половине новых пользователей выдавался html5-клиент, а другой половине — flash-клиент. Тестирование показало хорошие результаты и в ноябре 2018 года html5-версия клиента стала использоваться по-умолчанию. И сейчас в html5-версию играет 85-86% всех пользователей.
3. Решение использовать технологии с открытым исходным кодом было одним из важнейших:
4. Что касается технической части, то крайне удачным решением было использование подхода mocked-компиляции, при которой каждый из классов компилируется изолированно от других.
Рассмотрим подробнее, что такое mocked-компиляция:
Исходный ActionScript-код подготавливается с помощью препарсера — из кода удаляется реализация методов, в нем остаются только публичные свойства и методы, таким образом получается mocked-код на ActionScript. Этот код затем конвертируется в Haxe-код (также без реализации методов). Полученный код компилируется и проверяется таким образом на наличие ошибок компиляции.
Затем то же самое делается с «нормальным» кодом (кодом, из которого не вырезана реализация методов). Для каждого из полученных Haxe-классов с реализацией методов выполняем следующее:
Такой подход дает очень хорошее представление об имеющихся ошибках (их количестве и важности) и помогает расставить приоритеты в составлении планов по исправлению найденных ошибок.
5. Аннотации — инструмент, который использовался в ActionScript-коде для того, чтобы «помочь» конвертеру в принятии решений:
Т.к. аннотации — это просто комментарии в исходном коде, то они никак не влияли на работу ActionScript-кода.
6. После того, как конвертер начал выдавать компилируемый без ошибок код, команда приступила к следующему этапу, цель которого — обеспечить возможность запуска игры. А для этого необходимы ассеты.
Для flash-версии использовались ассет-бандлы в формате swf, а также ATF-текстуры. Ни те, ни другие не подходили для использования в html5-версии. Поэтому возник вопрос: либо использовать отдельный набор ассетов для html5-версии, или же внести изменения во flash-клиент и использовать один набор ассетов для обеих версий клиента.
В итоге было принято решение в пользу второго варианта: все swf-бандлы были заменены на текстурные атласы, а в OpenFL была добавлена поддержка сжатых текстур.
7. Одно из неправильных решений (о котором чуть позже) привело в итоге к принятию правильного решения — использованию непрерывной конвертации, когда каждый коммит в репозиторий клиента автоматически запускал конвертацию проекта. Каждый Pull Request также компилировался под Flash и JavaScript.
В дополнение к этому, оба клиента проверялись с помощью UI-тестов.
Данные меры позволяли оперативно сравнивать качество работы html5-клиента и Flash-клиента.
8. Для внедрения зависимостей (dependency injection) в проекте используется фреймворк Robotlegs, который в свою очередь базируется на библиотеке swiftsuspenders. Для работы инжектора в swiftsuspenders необходима информация об используемых типах. Для получения данной информации в Haxe-версии изначально использовался метатег @:rtti — данный метатег сохраняет информацию о типе в xml-формате, который затем необходимо распарсить. Т.к. в коде проекта очень активно используется механизм внедрения зависимостей, то для html5-клиента данный подход работал недостаточно быстро (приходилось обрабатывать слишком много xml-строк уже во время исполнения программы). Для решения этой проблемы Даниил Коростелев создал инжектор, основанный на макросах: вместо метатега @:rtti используется интерфейс ITypeDescriptionAware — макрос, встретив класс, помеченный таким интерфейсом, сгенерирует для него метод, возвращающий описание типа (которое в свою очередь будет использоваться инжектором зависимостей). Таким образом, часть работы удалось перенести с этапа выполнения программы на этап ее компиляции.
9. Использование Canvas-элементов было сведено к минимуму, т.к. они сильно влияли на скорость работы клиента, особенно в случае Microsoft Edge — по этой причине все дальнейшие тесты скорости работы клиента теперь основывались на этом браузере (все остальные браузеры показывали лучшую производительность).
10. Было ли этого достаточно для обеспечения быстрой работы клиента? Нет, нужно было сделать еще что-то для его ускорения.
InnoGames пришлось добавить в OpenFL поддержку батчинга, когда несколько объектов, использующих одно и то же состояние WebGL, можно отрисовать в один drawcall.
11. Чтобы эффективнее использовать батчинг в форк OpenFL была добавлена поддержка текстурных атласов. Для этого был добавлен класс SubBitmapData — объект, представляющий собой только часть атласа (до этого нововведения атласы использовались совершенно неэффективно с точки зрения потребления памяти и оптимизации отрисовки — для каждого игрового объекта создавалась новая текстура!). Теперь, используя батчинг, стало возможным отрисовать весь игровой интерфейс в один drawcall.
12. Было ли этого достаточно? Конечно, нет!
html5-клиент продолжал работать недостаточно быстро. Для дальнейшего улучшения производительности было необходимо улучшить батчинг — следующей его итерацией стал мультитекстурный батчинг, способный отрисовать в один drawcall объекты с разными текстурами (количество текстур, которые можно использовать в рамках drawcall’а, зависит от видеокарты; получить его можно с помощью вызова метода gl.getParameter(gl.MAX_TEXTURE_IMAGE_UNITS) ). Данная оптимизация значительно снизила количество drawcall’ов. Подробнее о ней вы можете узнать из доклада Даниила Коростелева.
13. Было ли этого достаточно? И ответ — снова нет!
Наконец-то html5-клиент начал выдавать стабильные 60 кадров в секунду, но в Internet Explorer он работал не стабильно — часто происходила потеря webgl-контекста, после которой клиент не мог восстановиться. При этом, что важно, пользователи Internet Explorer приносят около 10% прибыли, поэтому «бросать» их нельзя!
Было принято решение выдавать пользователям Internet Explorer Flash-версию клиента.
Но используя текущий рабочий процесс, InnoGames не могли перейти на Haxe, т.к. Flash-клиент все еще собирался из ActionScript-кода, а html5-клиент — из Haxe-кода, полученного с помощью конвертера. При этом конвертер кода был оптимизирован только для генерации кода html5-клиента, форк OpenFL тоже был оптимизирован только для html5.
Да, в InnoGames могли продолжать использовать построенный ранее рабочий процесс (см. п. 4), но это, по их мнению, был бы тупиковый путь, разработка так и продолжалась бы на ActionScript. А полный переход на Haxe позволил бы значительно упростить процесс. В дополнение к этому следует заметить, что старый конвертер генерировал слишком «неудобоваримый» код.
Поэтому было принято решение о необходимости создания нового конвертера.
Новый конвертер позволил получить Haxe-код, который можно скомпилировать как во Flash, так и в JavaScript. Кроме того, полученный Haxe-код меньше использовал рефлексию и был лучше типизирован.
Еще одним плюсом нового конвертера было то, что он значительно упростил рабочий процесс — теперь для преобразования кода использовался только один инструмент.
Интересный момент: OpenFL используется только для компиляции html5-клиента, Flash-клиент собирается напрямую, без использования данной библиотеки.
Подробнее о новом конвертере можно узнать из еще одного доклада Даниила Коростелева с октябрьского HaxeUp.
14. И последний (но не по значению) пункт — полный переход на Haxe, произошедший примерно 2 месяца назад. Хотя кажется, что это должно быть очень просто (просто возьми и закоммить Haxe-код в репозиторий, да поменяй несколько расширений в IDE), но данный процесс занял некоторое время:
Это были удачные решения, а теперь давайте рассмотрим не самые удачные:
1. Был построен довольно сложный рабочий процесс (workflow) — использовалось 2 инструмента: препарсер и конвертер. При этом одни правила конвертации применялись в препарсере, а другие — в конвертере. Причина этого заключается в том, что изначально команда работала над препарсером и mocked-компиляцией, и только значительно позже приступила к работе над конвертером и его улучшениями.
Если команде пришлось бы заново приступить к конвертации проекта с ActionScript в Haxe, то все правила конвертации кода применялись бы только в одном инструменте (новый конвертер как раз реализует данный подход).
2. Второй момент — был выбран довольно сложный процесс управления изменениями в проекте. Для Haxe-кода был заведен отдельный репозиторий:
При этом часто возникали merge-конфликты, когда одновременно вносились изменения в код какого-либо класса на ActionScript и в develop-ветке Haxe-репозитория. Приходилось постоянно разрешать их вручную, кодовая база начинала «расходиться». Поэтому довольно скоро от такого подхода отказались и перешли к непрерывной автоматической конвертации кода.
3. И третий момент — команда изначально сфокусировалась на html5-версии клиента, поэтому созданный конвертер кода подходил только для нее. Но когда оказалось, что для поддержки Internet Explorer необходима Flash-версия, возникла необходимость разработки нового конвертера, иначе переход на Haxe оказался бы невозможным.
Поэтому если команде пришлось бы заново приступить к разработке конвертера, то он был бы как можно более кросс-платформенным.
Но теперь обе версии браузерного клиента Forge of Empires используют код на Haxe. Спасибо за внимание!
Что такое foe scripts space
Скрипт для посадки на планеты.
Аля «Остановить поршень когда посадочное шасси зацепится за астероид»
================================================================
void Main(string argument)
<
IMyPistonBase LandingPiston = GridTerminalSystem.GetBlockWithName(«LandingPistonName») as IMyPistonBase;
IMyLandingGear LandingGear = GridTerminalSystem.GetBlockWithName(«LandingGearName») as IMyLandingGear;
if(LandingGear.IsLocked)
<
LandingPiston.GetActionWithName(«ResetVelocity»).Apply(LandingPiston);
LandingPiston.GetActionWithName(«IncreaseVelocity»).Apply(LandingPiston);;
>
КАК заставить это работать:
LandingPistonName и LandingGearName это названия в панели управления (в терминале) поршня и шасси соответственно. Желательно использовать англ.язык и названия без пробелов. К примеру: LandPiston_1; Gear2 и т.п. Я не ручаюсь за работу с кирилицей)
Это все, что вам нужно заменить в скрипте.
Далее таймер: выставляем задержку таймера в 1 секунду (на минимум), ставим в Setup Action запуск отчета таймера и Run программируемого блока.
ВАЖНО!:
Это скрипт только для одной системы поршень-шасси. Если хотите больше, советую натыкать программируемых блоков и таймеров для корректной работы.
p.s. в воркшоп выставлю позже, когда будет готов прототип и видеодемонстрация.
Автоматический шлюз.
Звуковая и световая сигнализация, вывод состояния на LCD панель, автоматическое переключение откачки/накачки воздуха, автоматическое открытие/закрытие/блокировка дверей.
http://steamcommunity.com/sharedfiles/filedetails/?id..
Для работы ЛЮБОГО количества шлюзов требуется ОДИН программируемый блок.
Отображение провреждённых/недостоенных блоков.
Само собой автоматическое 🙂
Невероятно полезный скрипт, который позволяет с помощью одного нажатия кнопки выбрать положение ротора или поршня. За подробностями смотрите видео по ссылке.
Переименовываете все орудия одинаково, к примеру «Пушка», без номеров и всего остального.
Запускаете прогблок. Включаете блок с именем «sequencerToggle».
Заряжаете орудия жмете на гашетку. Для автоматизации стрельбы просто соберите заскриптованные орудия в группу, и повесьте на горячую клавишу вкл/выкл стрельбы.
При начале стрельбы бывает стреляет сразу из двух орудий.
Простой скрипт, который на левый дисплей выводит предупреждения о повреждениях, заканчивающемся боезапасе и малом количестве ресурсов. На правый дисплей выводится содержимое всех хранилищ корабля. Центральный дисплей отображает визуальное предупреждение (картинкой).
Имеет возможность небольшой настройки под себя в самом начале скрипта, где необходимо будет прописать свои ЖК панели для работы скрипта. По-умолчанию стоит: ЖК панель слева, ЖК панель справа, ЖК панель центр
Работает на версии 01_171_003 без модов на пиратке.
Побудило написать свой скрипт, так как большинство сложных скриптов у меня не работает. Да и скучно было.
В программируемом блоке появилась возможность сохранять переменные.
Если заметили, по-умолчанию кроме Main() в редакторе появились две функции public Program() и public void Save().
Конструктор Program() автоматически запускается при первом запуске компьютера. Туда можно запихнуть инициализацию всех переменных и первоначальную настройку оборудования, чтобы не тратить на это время при очередном запуске скрипта.
Функция Save() так же автоматически запускается и сохраняет предоставленное строковое значение. Сохранение происходит не каждый запуск скрипта. Заметил, что сохраняется, когда открываю редактор программируемого блока или сохраняю игру, других триггеров для срабатывания этой функции я не обнаружил.
Если снести программируемый блок, построить другой и вставить туда идентичный код, сохранения не восстанавливаются.
Переменная сохраняется после редактирования скрипта, отключения бортового питания и перезапуска игры (пока не нашел случая, в котором переменная бы не загрузилась).
Пример прикреплен ниже.
Описание: Скрипт подсчитывает содержимое инвентарей, перемещает позицию, которая не строится в конец очереди сборщика.
Умеет сортировать содержимое по контейнерам и дозаказывать компоненты в ассемблере на основании установленных лимитов.
Настройка:
в поле CustomData вносятся параметры для инициализации скрипта: (любая из строк может быть пустой и будет пропущена)
При первом запуске скрипта инициализация производится автоматически, далее по команде.
Команды: Скрипт поддерживает команды с параметрами. Команда и параметр разделяются «:»
>:МаскаПоискаКонтейнера:ЧтоВНемЛежит,ЧтоВНемЛежит
устанавливает отбор для сортировки элементов в контейнере. Если перед первым параметром добавить +, будут добавлены доступные элементы иначе заменены
mask:маска поиска блоков
Устанавливает маску которая применяется при поиске обрабатываемых инвентарей, если маска пустая строка обрабатываются все доступные инвентари
reload:bloc,ass
Находит и запоминает все ассемблеры и блоки в которых будет в дальнейшем происходить поиск. Параметрами можно ограничивать что нужно искать. Без параметров ищет все.
Unload:маска
Производит единоразовое перемещение элементов из блоков подходящих под маску в установленные контейнеры. Полезно при разгрузке бурового корабля.
Скрипт находит все блоки ассемблеров и инвентаре, а затем обходит эти списки. Поэтому если необходимо заново найти инвентари или ассемблеры вызовите команду reload. Если необходимо переинициализировать текстовые панели воспользуйтесь командой init. Это поможет при разрушении готовых или достройке новых блоков.
Все настройки скрипт сохраняет и восстанавливает автоматически, при перезагрузке ничего перенастраивать не нужно