В любой момент (до компиляции движка) просто создайте файл BuildConfiguration.xml по указанному пути. Если этого пути еще нет, то можно создать его самостоятельно. Содержимое файла я привел в статье. Перед компиляцией движка еще раз его можно перепроверить, что ничего не поменялось (хотя и не должно).
Согласно документации этот файл можно положить еще по таким путям :
А с настройками “по умолчанию” 2022-я студия, или не собирает движок совсем, или собирает его с багами. Причем, результат можно увидеть только через несколько часов томительного ожидания.
Речь идет о движке. Т.е. о третьем варианте о котором я написал выше.
Вы сейчас говорите про сборку игры на бинарной версии движка из лаунчера, сборку игры на базе движка из исходного кода, сборку движка в бинарный вид для последующего распространения? Если мы говорим про VS2022, то как минимум без правильно настроенных SDK последние 2 варианта могут "удивить". А без полной инструкции последний пункт вообще невозможен.
Т.е. данная инструкция не о сборке игры, а о сборке движка и редактора. И если у вас на VS2022 сборка движка проходит без проблем... То, тогда у нас какая-то очень странная студия, можно вашу? :)
А проблем и не должно быть... Эта инструкция для тех, кому нужна свежая сборка UE 4.27, со всеми последними апдейтами. Ну или тех, кто собирается вносить свои изменения в движок, и затем бинарные версии уже раздавать внутри команды.
Можно написать плагин, и использовать в блюпринтах уже его. Я думал о таком варианте, пока не начал разбираться с UE5. А после этого решил не связываться, так как красивый и универсальный вариант сделать не получится.
А вообще нет, к сожалению блюпринтами обойтись не получится. Для IPlatformInputDeviceMapper есть своя библиотека, но через нее можно только получать информацию. Я не нашел способа, как изменить мэппинг устройств.
Русский язык естественно будет. Если его сейчас добавлять в список, то стим насыпет дополнительных проблем с оформлением странички (нужно же поддерживать все языки, а это доп. тексты, арт и т.п.). Сейчас нет времени, а ближе к релизу займемся локализацией.
У нас каждый тайл - это обычный актор. Если глянуть второе видео, видно что помимо кнопок генерации карты, есть еще кнопки генерации декора. Это команда акторам как-то себя "украсить": добавить пару камушков сверху, сменить материал и даже основной меш. Важно чтобы грани совпадали. Т.е. можно считать, что происходит дополнительное изменение тайлов, но уже после формирования уровня. WFC по сути задает только форму уровня.
А про блэклисты я не понял... У каждого тайла это просто массив пар: тайл и сторона. Причем если сторону не указать, то считается, что этот тайл нигде рядом ставить нельзя. Разрешены ссылки и на себя (тогда два одинаковых тайла рядом не поставить). Заполняется просто: видим "некрасивую" ситуацию, добавляем в черный список.
У нас все проще: уровни очень маленькие примерно 12х12х3 тайла. Т.е. я бы сказал одна комната и есть. А для огромных карт, алгоритм почти всегда находит подходящий вариант. Я просто что-то больше 20х20 редко генерирую и не помню ситуаций когда вываливалось бы с ошибкой.
Выше в комментарии правильный подход был предложен: для проблемы ошибок надо полноту проверять. Ну и наполнять набор тайлов.
Я сейчас крайне редко получаю ошибки. Например, чтобы сделать скриншот для статьи мне пришлось уровней 25-30 сгенерировать. Поэтому, тайлы добавляем в порядке необходимости для визуала или геймплея. Т.е. стараемся в золотую середину: рисовать тайлов столько, чтобы процент ошибок не раздражал. Как-то расширять систему WFC дополнительными проверками, банально нет времени. Над игрой работает всего 2 человека, и более приоритетных задач больше чем надо.
Это скорее способ красиво оформить презентацию уже готовых работ. Поддержка markdown и формул значительно этому способствует. Другой вопрос, зачем нужна desktop версия, если все отлично работает и в браузере...
Нет, в оригинальной версии прошивки такого функционала не было. А мне лезть внутрь TZX формата очень не хочется. Я и саму прошивку изначально не планировал править.
Ну а если понадобится что-то сохранить с ZX, то для такого дела не грех развернуть и ноутбук.
Загляните в исходники, изучите код. И напишите мне, понял ли я как генерируется сигнал, что это вообще за сигнал и как я переписал код для SD карты, чтобы не происходило задержек. И все это будет.
Магия соединить ардуину, ридер, дисплей и пару кнопок? Хм... Ну а если про софт, то всегда можно сравнить с оригиналом и на сколько изменения пошли ему на пользу или вред.
В любой момент (до компиляции движка) просто создайте файл
BuildConfiguration.xmlпо указанному пути. Если этого пути еще нет, то можно создать его самостоятельно. Содержимое файла я привел в статье. Перед компиляцией движка еще раз его можно перепроверить, что ничего не поменялось (хотя и не должно).Согласно документации этот файл можно положить еще по таким путям :
Engine/Saved/UnrealBuildTool/BuildConfiguration.xml
%USER_FOLDER%/AppData/Roaming/Unreal Engine/UnrealBuildTool/BuildConfiguration.xml
My Documents/Unreal Engine/UnrealBuildTool/BuildConfiguration.xml
Речь идет о движке. Т.е. о третьем варианте о котором я написал выше.
Вы сейчас говорите про сборку игры на бинарной версии движка из лаунчера, сборку игры на базе движка из исходного кода, сборку движка в бинарный вид для последующего распространения? Если мы говорим про VS2022, то как минимум без правильно настроенных SDK последние 2 варианта могут "удивить". А без полной инструкции последний пункт вообще невозможен.
Т.е. данная инструкция не о сборке игры, а о сборке движка и редактора. И если у вас на VS2022 сборка движка проходит без проблем... То, тогда у нас какая-то очень странная студия, можно вашу? :)
А проблем и не должно быть... Эта инструкция для тех, кому нужна свежая сборка UE 4.27, со всеми последними апдейтами. Ну или тех, кто собирается вносить свои изменения в движок, и затем бинарные версии уже раздавать внутри команды.
Одна из наших игр, до сих пор на 4.23. Просто из-за DX10 и +10 FPS на андроиде. Поэтому смена движка, не совсем простое дело.
Можно написать плагин, и использовать в блюпринтах уже его. Я думал о таком варианте, пока не начал разбираться с UE5. А после этого решил не связываться, так как красивый и универсальный вариант сделать не получится.
А вообще нет, к сожалению блюпринтами обойтись не получится. Для IPlatformInputDeviceMapper есть своя библиотека, но через нее можно только получать информацию. Я не нашел способа, как изменить мэппинг устройств.
Спасибо, не знал о такой штуке. Но, я не думаю, что ее будут учитывать при прохождении игрой Steam Deck Compatibility Review.
Русский язык естественно будет. Если его сейчас добавлять в список, то стим насыпет дополнительных проблем с оформлением странички (нужно же поддерживать все языки, а это доп. тексты, арт и т.п.). Сейчас нет времени, а ближе к релизу займемся локализацией.
У нас каждый тайл - это обычный актор. Если глянуть второе видео, видно что помимо кнопок генерации карты, есть еще кнопки генерации декора. Это команда акторам как-то себя "украсить": добавить пару камушков сверху, сменить материал и даже основной меш. Важно чтобы грани совпадали. Т.е. можно считать, что происходит дополнительное изменение тайлов, но уже после формирования уровня. WFC по сути задает только форму уровня.
А про блэклисты я не понял... У каждого тайла это просто массив пар: тайл и сторона. Причем если сторону не указать, то считается, что этот тайл нигде рядом ставить нельзя. Разрешены ссылки и на себя (тогда два одинаковых тайла рядом не поставить). Заполняется просто: видим "некрасивую" ситуацию, добавляем в черный список.
У нас все проще: уровни очень маленькие примерно 12х12х3 тайла. Т.е. я бы сказал одна комната и есть. А для огромных карт, алгоритм почти всегда находит подходящий вариант. Я просто что-то больше 20х20 редко генерирую и не помню ситуаций когда вываливалось бы с ошибкой.
Выше в комментарии правильный подход был предложен: для проблемы ошибок надо полноту проверять. Ну и наполнять набор тайлов.
Я сейчас крайне редко получаю ошибки. Например, чтобы сделать скриншот для статьи мне пришлось уровней 25-30 сгенерировать. Поэтому, тайлы добавляем в порядке необходимости для визуала или геймплея. Т.е. стараемся в золотую середину: рисовать тайлов столько, чтобы процент ошибок не раздражал. Как-то расширять систему WFC дополнительными проверками, банально нет времени. Над игрой работает всего 2 человека, и более приоритетных задач больше чем надо.
Это скорее способ красиво оформить презентацию уже готовых работ. Поддержка markdown и формул значительно этому способствует. Другой вопрос, зачем нужна desktop версия, если все отлично работает и в браузере...
Например, в описании репозитория в разделе Wiring:
https://github.com/sadken/TZXDuino
Можно попросить схему у них на FB:
https://www.facebook.com/Arduitape
Да, вы правы. Закупался я года полтора назад, и с учётом текущей ситуации с полупроводниками цены могли неприятно измениться.
Я впервые увидел такое устройство на этом канале и очень был удивлен:
https://youtu.be/M70AeNOIzMw
А когда Мастер был моим основным компьютером, то даже представить не мог существование такой техники. :)
Да, вполне возможно. Так как для тестирования у меня только одна железка, то и ориентировался я только на нее.
Почему вы к себе в множественном числе обращаетесь? :) Оригинально. Все эти действия я предложил сделать вам и только вам.
Нет, в оригинальной версии прошивки такого функционала не было. А мне лезть внутрь TZX формата очень не хочется. Я и саму прошивку изначально не планировал править.
Ну а если понадобится что-то сохранить с ZX, то для такого дела не грех развернуть и ноутбук.
Загляните в исходники, изучите код. И напишите мне, понял ли я как генерируется сигнал, что это вообще за сигнал и как я переписал код для SD карты, чтобы не происходило задержек. И все это будет.
Магия соединить ардуину, ридер, дисплей и пару кнопок? Хм... Ну а если про софт, то всегда можно сравнить с оригиналом и на сколько изменения пошли ему на пользу или вред.