Solved MonoBleedingEdge folder purpose?
Mono is what Unity uses, that folder is related to that. It isn’t really something you need to worry about. «Bleeding edge» in software (or anything really) generally means the latest development/experimental version of something.
Inkss
Mono is what Unity uses, that folder is related to that. It isn’t really something you need to worry about. «Bleeding edge» in software (or anything really) generally means the latest development/experimental version of something.
Click to expand.
Thanks Wolf. wasnt too worried just notice something new so i wanted to know what it is. appreciate the response
Facepunch буквально вынудили меня использовать Docker
У меня есть собственные Rust сервера на арендованной удаленной машине. Онлайн пока что крайне мал (в основном — никого, хотя бывает и 1-3 игроков), но мне нравится настройка и администрирование, поэтому в первую очередь мой сервер мне служит в образовательных целях.
Начинал я с малого: пытался писать небольшие плагины для OxideMod с помощью ChatGPT и, организовав git репозиторий прямо в папке oxide/plugins, сделал процесс обновления плагинов максимально удобным. А недавно мне досталась задача посложнее: в свете недавнего обновления RustDedicated Server (которое стало отправной точкой) я решил наконец по максимуму автоматизировать имеющиеся задачи — об этом далее в статье.
Все началось с того, что разработчики Rust Dedicated Server починили сломали функцию restart. Она и ранее не работала, поскольку выключала сервер вместо того, чтобы перезагружать его. А теперь она стала работать согласно названию, но параллельно с ней перезагружать почему-то начала и функция quit. Очевидно, что это два названия одного и того же, но разработчики не определились, чего же именно.
Как бы то ни было — данный фикс создал мне проблему: теперь я мог выключить запущенный сервер только нативными средствами Linux:
pkill RustDedicatedи это работало исправно, пока сервер был всего один. Но серверов стало два. И выключение всех серверов каждый раз, когда я выключаю один из них — меня не устраивало. Вот тут-то и появился он.
Docker
Давно уже посматривал на эту технологию, но как-то не было повода ее применить. А теперь, когда мне потребовалось запускать каждый сервер в изолированной среде — docker оказался вполне подходящим инструментом (плюс появился хороший повод наконец изучить его на практике).
Сама по себе папка с сервером представляет собой развернутое с помощью steamcmd приложение, куда дополнительно устанавливается oxidemod. Когда я начинал использовать docker, я так же добавил в эту папку Dockerfile с настройками.
Типичная структура сервера примерно такая:
Rust_Server ├── Bundles (~ 6.5 ГБ) ├── HarmonyMods ├── RustDedicated_data (~ 700 МБ) │ ├── Managed │ ├── Mono │ ├── MonoBleedingEdge │ ├── Plugins │ ├── Resources │ └── StreamingAssets ├── oxide ├── scripts ├── server │ └── melee.mayhem │ ├── cfg │ ├── scripts │ └── serveremoji ├── steamapps └── DockerfileКогда мне понадобилось больше серверов, я просто копировал всю папку Rust_Server каждый раз, когда хотел добавить еще один. Очевидно, что подход избыточный, особенно в условиях ограниченного места на диске, ведь папка сама по себе весит более 7 ГБ, а вдобавок еще и каждый docker-образ занимает столько же.
Поэтому в конце-концов структура эволюционировала в единственную папку, в которой для каждого нового сервера (./server/$IDENTITY) я просто добавлял локальную подпапку oxide с отдельным набором плагинов и конфиг-файлами, что значительно экономило место на диске. Для запуска/сборки всех серверов было решено использовать docker-compose.
В итоге, преобразования произошли только в подпапке server, остальная структура осталась без изменений:
Rust_Server ├── Bundles ├── HarmonyMods ├── RustDedicated_data │ ├── Managed │ ├── Mono │ ├── MonoBleedingEdge │ ├── Plugins │ ├── Resources │ └── StreamingAssets ├── oxide ├── scripts ├── server │ ├── melee.mayhem │ │ ├── cfg │ │ ├── oxide │ │ │ ├── config │ │ │ ├── data │ │ │ └── plugins │ │ ├── scripts │ │ └── serveremoji │ └── oxid.vanguard │ ├── cfg │ ├── oxide │ │ ├── config │ │ ├── data │ │ └── plugins │ ├── scripts │ └── serveremoji ├── steamapps ├── Dockerfile └── docker-compose.ymlНа этом этапе возникла проблема — корневая папка oxide (строка 11 выше) оказалась общей для всех контейнеров (поскольку она, как и остальные папки, примонтирована в volumes), тогда как мне было нужно, чтобы в каждом контейнере такая папка была изолированной (поскольку наборы плагинов разные).
И хотя в wiki Facepunch я не нашел, как я могу указать кастомный путь к папке oxide, решение, к счастью, было найдено.
TMPFS
В процессе изучения документации докера я наткнулся на этот тип монтирования, при котором создается временная папка, доступная только в рамках текущего контейнера и удаляемая при его остановке.
Итоговый конфиг docker-compose.yml при этом стал таким:
version: "3.8" services: main_server: build: context: . args: - SERVER_ROOT=main_server environment: - IDENTITY=oxid.vanguard - HOSTNAME=ZGR | Zombie Got Rust | PVP - Solo.Duo.Trio.Quad - SERVER_URL=zgr.ddns.net - SERVER_TAGS=monthly,vanilla,EU - SERVER_PORT=28015 - QUERY_PORT=28016 - WORLDSIZE=3000 - MAXPLAYERS=100 container_name: main_server ports: - "28015:28015/udp" - "28016:28016/udp" - "25888:25888" - "80:80" - "443:443" volumes: - .:/main_server tmpfs: - /main_server/oxide command: ./run-server.sh mayhem_server: build: context: . args: - SERVER_ROOT=mayhem_server environment: - IDENTITY=melee.mayhem - HOSTNAME=ZGR | Melee Mayhem - SERVER_URL=zgr.ddns.net - SERVER_TAGS=weekly,vanilla,EU - SERVER_PORT=28017 - QUERY_PORT=28018 - WORLDSIZE=1200 - MAXPLAYERS=150 container_name: mayhem_server ports: - "28017:28017/udp" - "28018:28018/udp" - "25889:25888" volumes: - .:/mayhem_server tmpfs: - /mayhem_server/oxide command: ./run-server.shМысли насчет конфига
В конфиге выше меня смущает только необходимость дублировать SERVER_ROOT (см args, container_name, volumes, tmpfs), поэтому если не найду другого решения — просто создам bash-script для генерации docker-compose.yml, а дублирующееся значение перенесу в переменную.
А в файле для запуске сервера run-server.sh я просто выполняю копирование из текущей подпапки oxide в изолированную корневую tmpfs папку oxide:
cp -R ./server/$IDENTITY/oxide/* ./oxideОднако, данный подход забрал у меня одну важную фичу — live reload папки oxide. Папка копируется всего один раз на старте и больше не обновляется. Т.е. если я залью новый плагин в эту папку (./server/$IDENTITY/oxide), мне придется подключаться к контейнеру:
docker exec -it mayhem_server /bin/bashи выполнять вот это действие вручную:
cp -R ./server/$IDENTITY/oxide/* ./oxideПоэтому было решено использовать watch на каждой папке ./server/$IDENTITY/oxide и выполнять обновление tmpfs oxide при изменениях. В самом docker уже имеется такая фича, но она помечена как experimental, что лично меня отпугивает, поэтому решил пока воспользоваться проверенными средствами линукс — inotify-tools.
Я сделал bash-скрипт watch-oxide-dir.sh, который будет отслеживать изменения в папках oxide каждого сервера и при необходимости обновлять содержимое tmpfs oxide:
#!/bin/bash while inotifywait -r ./server/$IDENTITY/oxide -e modify,create,delete; do cp ./server/$IDENTITY/oxide/discord.config.json ./oxide cp ./server/$IDENTITY/oxide/oxide.config.json ./oxide rsync -a --delete ./server/$IDENTITY/oxide/config ./oxide rsync -a --delete ./server/$IDENTITY/oxide/plugins ./oxide rsync -a --delete ./server/$IDENTITY/oxide/data ./oxide rsync -a --delete ./server/$IDENTITY/oxide/lang ./oxide rsync -a --delete ./server/$IDENTITY/oxide/logs ./oxide doneИтоговый run-server.sh стал таким:
#!/bin/bash SEED=$(cat ./server/$IDENTITY/seed.txt) cp -R ./server/$IDENTITY/oxide/* ./oxide "./set-permissions.sh" & "./watch-oxide-dir.sh" & ./RustDedicated -batchmode \ +server.hostname "$HOSTNAME" \ +server.identity "$IDENTITY" \ +server.maxplayers $MAXPLAYERS \ +server.worldsize $WORLDSIZE \ +server.seed "$SEED" \ +server.tags "$SERVER_TAGS" \ +server.url "$SERVER_URL" \ +server.port $SERVER_PORT \ +server.queryport $QUERY_PORT;Здесь добавление амперсанда (&) на строке 7 и 8 делает скрипт выполняемым в фоне.
Итоговый Dockerfile с необходимыми зависимостями, устанавливаемыми при сборке образа:
# syntax=docker/dockerfile:1 FROM ubuntu:22.04 RUN apt-get update && \ apt-get install -y openssl iproute2 ca-certificates inotify-tools rsync && \ apt-get clean ARG SERVER_ROOT WORKDIR /$ EXPOSE 28015 28016 28017 28018 25888 80 443 COPY . .Далее все отлично запускается командой docker-compose up -d
В качестве бонуса буду рад поделиться ссылкой на свой консольный rcon-client для Rust серверов, который написан на языке Rust. Предельно прост в использовании.
А вы администрировали подобные сервера ?
Monobleedingedge что это
Alonzo 21 сен 2013, 22:55
Добрый вечер, уважаемые коллеги!
При компиляции кода одной популярной .NET-библиотеки, Unity выдаёт ошибку:
Assets/Packages/Rx-Core/src/Reactive/Concurrency/Scheduler.Recursive.cs(24,66): error CS0119: Expression denotes a `variable’, where a `method group’ was expected
В то время как MonoDevelop и VisualStudio успешно компилируют сгенерированный проект.
Ошибка относится к последней строке метода:
Синтаксис:
Синтаксис: [ Показать ]
Используется csharp
namespace System . Reactive . Concurrency
{
public static partial class Scheduler
{
.
public static IDisposable Schedule ( this IScheduler scheduler, Action < Action >action )
{
if ( scheduler == null )
throw new ArgumentNullException ( «scheduler» ) ;
if ( action == null )
throw new ArgumentNullException ( «action» ) ;
return scheduler. Schedule ( action, ( _action, self ) => _action ( ( ) => self ( _action ) ) ) ;
}
.
}
}
Версия Unity (Windows, не Pro): 4.2.1f4 (4d30acc925c2)
Версия MonoDevelop: 2.8.2
Какие компиляторы (каких версий) и какие целевые рантаймы (Mono или .NET CLR) используют Unity и MonoDevelop для сборки под Windows?
Как можно узнать используемую в Unity версию Mono из папки «c:\Program Files (x86)\Unity\Editor\Data\Mono\»?
Можно ли вместо неё использовать «c:\Program Files (x86)\Unity\Editor\Data\MonoBleedingEdge\»?
Зачем Unity генерирует по две версии sln- и csproj-файлов?
Спасибо за внимание!
Alonzo UNец Сообщения: 29 Зарегистрирован: 21 сен 2013, 21:59
Re: Разница в поведении Unity и MonoDevelop
pod4444 21 сен 2013, 23:38
Mono 2.6, что является «аналогом» .Net 3.5
несколько .sln, .csproj, .unityproj нужны для разной последовательности компиляции кода и исключения editor скриптов из билда
компиляция проектов присходит в такой последовательности:
C# firstpass
C# firstpass editor
UnityScript firstpass
Unityscript firstpass editor
C#
C# Editor
UnityScript
UnityScript Editor
отличия проектов с припиской -vs не скажу, есть догадки, что это для работы с Visual Studio, но нет Monodevelop, чтобы проверить, создаются для него такие файлы.
два солюшена имеют различия, что в один включены сборки UnityScript, в другой нет.
почему бы Вам не сбилдить этот плагин в сборку и кинуть dll в проект?
- Сайт
Re: Разница в поведении Unity и MonoDevelop
Alonzo 22 сен 2013, 00:02
pod4444 писал(а): Mono 2.6, что является «аналогом» .Net 3.5
И всё-таки, почему поведение разное? Сообщение выглядит так, будто компилятор споткнулся о какую-то конструкцию — лямбду, extension-метод, или не может найти нужну перегрузку метода Schedule(), или вывести типы-аргументы дженерик-метода — не суть важно. Интересно, почему тогда в MonoDevelop всё ок? Они используют разные реализации компилятора и/или рантайма? Кто-нибудь сталкивался с подобным несоответствием?
Я бы пережил тот факт, что используемый в Unity компилятор не соответствует спецификациям языка, и придумал бы workaround. Но в этом случае хотелось бы, чтобы и MonoDevelop сообщал об ошибке. Мне важно, чтобы собираемость кода в MonoDevelop гарантировала собираемость в Unity.
В PlayerSettings в качестве Api Compatibility Level указан «.NET 2.0», не «.NET 2.0 Subset».
Alonzo UNец Сообщения: 29 Зарегистрирован: 21 сен 2013, 21:59
Re: Разница в поведении Unity и MonoDevelop
Alonzo 22 сен 2013, 00:18
pod4444 писал(а): почему бы Вам не сбилдить этот плагин в сборку и кинуть dll в проект?
В данном частном случае third-party-библиотеки это, возможно, вылечит симптом. Но хотелось бы разобраться с вопросом принципиально, чтобы застраховать себя от появления таких проблем в будущем; например, в скриптах, где выносить код в предкомпилируемые сборки будет неудобно.
Кроме того, возможно, понадобится собирать проект, использующий эту библиотеку, на OS X. В той редакции Unity более свежая версия Mono, которая позволяет компилировать код библиотеки с дополнительными возможностями. (Код библиотеки предусматривает дефайны, которые «выкусывают» из кода современные фишки типа ко- и контравариантных дженерик-интерфейсов, чтобы можно было собирать библиотеку на старых версиях фреймворка вроде .NET 3.5.)
Alonzo UNец Сообщения: 29 Зарегистрирован: 21 сен 2013, 21:59
Re: Разница в поведении Unity и MonoDevelop
seaman 22 сен 2013, 09:54
Особенности разработки Bleeding Edge Статьи редакции
Нельзя отрицать, что Hellblade: Senua’s Sacrifice значительно улучшила репутацию студии Ninja Theory. Эта игра получила широкое признание критиков, продалась тиражом более миллиона копий в первый год и получила пять премий BAFTA. Недавно студия объявила о создании нового проекта под названием Mara, в котором разработчики продолжат исследовать темы страха, тревоги и других негативных эмоций.
Несмотря на это, в Ninja Theory остаётся как минимум одна команда, которая осталась верна корням. Опираясь на опыт создания Heavenly Sword, Enslaved и DmC: Devil May Cry, эта команда работает над Bleeding Edge, сетевым многопользовательским браулером для Xbox.
Креативный директор Bleeding Edge Рани Такер рассказала изданию GamesIndustry.biz о главных сложностях разработки новой игры студии Ninja Theory. Особенное внимание она уделила проработке уникальных персонажей и трудностях создания многопользовательского экшена с акцентом на ближнем бое. Мы выбрали из текста главное.
Когда я впервые подумала об этой идее, у меня в голове пронеслось: «Почему этого всё ещё не существует?». У меня было ощущение, что такую игру обязательно нужно создать. Мы собрали небольшую команду, а затем начали прототипировать и экспериментировать, чтобы увидеть, будет ли эта идея действительно работать. У нас всё получилось, поэтому мы сделали игру.
Рани Такер, креативный директор Bleeding Edge
Команда Bleeding Edge в среднем состояла из 15 человек, но на пике в неё входило 25 сотрудников. По словам Такер, это около четверти студии. Также она рассказала, что контраст между Bleeding Edge и Hellblade возник из-за разного виденья креативных директоров.
Тамим [Антониадес] был креативным директором всех других тайтлов Ninja Theory. Он был геймдиректором Hellblade, и у него действительно большой опыт работы с персонажами, с построением нарратива и подобными вещами — это то, что он любит делать. Лично мне немного больше нравится геймплейная составляющая. Я люблю весёлые игры, поэтому это просто вопрос вкусов и того, над чем каждый из нас любит работать.
Рани Такер, креативный директор Bleeding Edge
По словам Такер, Bleeding Edge отличается от всего остального на рынке. Несмотря на то, что сейчас доминируют многопользовательские игры, только For Honor в той же мере акцентируется на ближнем бое.
До этого Platinum Games постаралась воплотить подобную концепцию в идейном наследнике MadWorld — Anarchy Reigns. Другая попытка — Rise of Incarnates от Bandai Namco Entertainment, которая просуществовала всего несколько месяцев. Разработчики Bleeding Edge осознают, что удачных примеров многопользовательских игр с ближним боем было не так уж много, поэтому у команды нет чётких ориентиров, которыми можно вдохновляться.
Также команда столкнулась и с техническими проблемами. Например, программистам пришлось вкладывать очень много усилий, чтобы минимизировать задержку ввода, потому что это непозволительный аспект в сетевых играх, в которых важна реакция.
Важная задача заключалась в том, чтобы сделать игру интересной для тех, кто проигрывает в бою. В одиночных браулерах игрок без больших проблем справляется с сотнями врагов, но это абсолютно не работает в мультиплеере, потому что пользователи находятся примерно в равном положении. Если оппонент исполняет комбо, то у игрока должна оставаться возможность совершить контрманёвр.
Например, все персонажи могут уклоняться. Но игрок не сможет делать это постоянно, потому что его ограничивает шкала выносливости. У некоторых есть дополнительные способности для передвижения, например, прыжковая платформа или ускоритель — они помогут избежать беды. К тому же товарищи по команде всегда могут прийти на помощь, чтобы игрок смог вырваться из вражеского комбо.
Bleeding Edge также выделяется своим красочным художественным стилем и необычными персонажами, на которых повлияли герои комиксов и аниме, таких как Akira, Ghost In the Shell и Tekkonkinkreet. Такер рассказала, что она хотела бы, чтобы игра была похожа на графическую новеллу.
У нас по-настоящему разнообразная команда, благодаря чему получились очень разнообразные персонажи.
Buttercup — была первым персонажем, которого мы создали. Я не знаю [почему мы начали с неё]. Тогда мы сказали: «Да, это то, что мы хотим сделать с игрой». Мы хотели, чтобы каждый персонаж выглядел так, что он может быть главным героем своей собственной игры. Если бы вы захотели, вы могли бы сделать однопользовательский спин-офф с любым из этих персонажей, потому что они достаточно интересны и имеют достаточно индивидуальности, чтобы заинтересовать людей. Мы не хотели, чтобы в игре был главный герой и куча помощников.
У нас достаточно долгий процесс проработки дизайна. Наша команда довольно мала, но почти все подпрыгивают, когда речь заходит о создании персонажей. Иногда всё начинается с механики, а иногда просто с классной идеи. Создание Nidhogger начиналось примерно так: «Ну, он блэк-метал гитарист из Норвегии, так что давайте отталкиваться от этого и посмотрим, что мы сможем придумать». После этого мы решили сделать его немного сумасшедшим и добавить элементы, которых вы от него не ожидаете.