Компиляция или не надо, Надо ли компилить ядро каждый раз как сделал изменения в Script Опции

[Chicos]

В руководстве по сборке компиляции сказано что надо добавить папку Server в проект и скомпилить ядро. От предшественика мне уже досталось готовое ядро. Почему то подумалось что просто изменив в папке Scripts нужный мне скрипт я получу нужное. Для пробы изменил в кастоме явно свой объект. Но изменения на сервере не отобразились. То есть после каждого изменения в Scripts необходимо пересобирать exe ? Или как то по другому? Начал только разбираться с UO, и что то в сотнях тем прочитанных этот момент не нашел.

[Aimed]

Кстати, насчет 20 сек это тоже не совсем правда.... у тебя статическая компиляция всегда все соберает и выходит что у тебя время билда дольше. Просто ты дольше смотришь на то как студия компилирует твой проект, чем на консоль сервера и то как он компилирует папку Scripts.
С динамической компиляцией ядро уже собранное в 99% случаев и скрипты динамически компилируются и то только тогда когда были внесены правки в Scripts папке.
По сути если просто перезапускать сервер с правками только в скриптах, то он не сильно медленее будет вставать чем при статической компиляции всего проекта и я даже не уверен медленнее ли он на самом деле.

Основная экономия во времени идёт как раз засчет проверок типов и сериализации/десерилазции, но оно очень шустро через PLINQ все проверяет. И в тоже время каждый раз все из папки Server пересоберается, хотя это нужно крайне редко.

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

[StaticZ]

Кстати, насчет 20 сек это тоже не совсем правда.... у тебя статическая компиляция всегда все соберает и выходит что у тебя время билда дольше. Просто ты дольше смотришь на то как студия компилирует твой проект, чем на консоль сервера и то как он компилирует папку Scripts.

Да нет все таки через студию быстрее, там идет частичная перекомпиляция без всяких плясок с бубнами (разницу между собрать и пересобрать можете сами почувствовать. Первого в 99% случаев достаточно и компиляция идет 1 секунду). Но дело даже не столько в 20 секундах, а в общем удобстве. Не надо скакать между окнами, я к примеру во время дебага даже вывод самого сервера делаю в студии а сама она без всяких окон стартует. Что еще более важно в случае ошибок компиляции в студии одним кликом попадаешь на проблемное место, а если у человека мало опыта то подобных ошибок будет много и время на чтение, переключение между окнами и поиска нужного места уходит куда дольше 20 секунд. Тоже и с отладчиком, если скрипты собирает ранка, то конечно можно присоединить отладчик студии к ней, но эти действия тоже требуют времени или изобретения костылей, а порой приходится отладку начинать с начала по нескольку раз.

Есть и куча других плюсов к примеру копирование скриптов на сервер занимает куда больше времени чем уже собранной дллки (опять же да можно настроить костыли и для решения этой проблемы к примеру копировать через репозиторий, но зачем если можно без них?), проект приобретает более целостный вид так как библиотеки и исполняемые файлы принадлежат какой-то конкретной версии, тут не может вылезть какая-то неприятная путаница что кто-то как-то что-то поменял\добавил\убрал из скриптов. Да и вообще понятие скриптов я считаю крайне не удачным, так как это полноценный код что отвечает почти за всю логику приложения, обладающий собственной архитектурой. Впрочем и само деление на ядро\скрипты слегка сумбурно, сервуо еще больше внесло хаоса. Вообщем если работать с кодом то однозначно удобнее когда все через IDE выполняется, а если на уровне скачал что-то откудато запихнул к себе то да удобнее с само компиляцией

[Aimed]

Да нет все таки через студию быстрее, там идет частичная перекомпиляция без всяких плясок с бубнами (разницу между собрать и пересобрать можете сами почувствовать. Первого в 99% случаев достаточно и компиляция идет 1 секунду). Но дело даже не столько в 20 секундах, а в общем удобстве. Не надо скакать между окнами, я к примеру во время дебага даже вывод самого сервера делаю в студии а сама она без всяких окон стартует. Что еще более важно в случае ошибок компиляции в студии одним кликом попадаешь на проблемное место, а если у человека мало опыта то подобных ошибок будет много и время на чтение, переключение между окнами и поиска нужного места уходит куда дольше 20 секунд. Тоже и с отладчиком, если скрипты собирает ранка, то конечно можно присоединить отладчик студии к ней, но эти действия тоже требуют времени или изобретения костылей, а порой приходится отладку начинать с начала по нескольку раз.

Я что-то не в теме. О каких окнах речь?
У меня всегда 1 окно студии и вывод тоже попадает в студию в Output.
При отладке тоже все в той-же студии в одном окне. Ничего не надо присоеденять, это не отдельные процессы. Отладка с первого раза начинается. Я скидывал линк о гайде с отладкой.
Студия и правда быстрее соберает засчет MSBuild. Но у меня там разница меньше 10 секунд получается.

К тому-же можно ведь сделать что-бы во время выполнения пересоберался проект скриптов и правки вступали в силу не вырубая сам сервер не тратя кучу времени на загрузку мира. Это очень актуально когда надо тестировать системы на сервере с настоящими сейвами и большим кол-вом обьектов. Компиляцую скриптов тоже наверняка можно оптимизировать. Если сервер на винде, то использовать тот-же MSBuild к примеру. Я думаю что изначально такая структура использовалась что-бы можно было как на Сфере resync делать.

Если б я начинал свой проект с нуля, я б так и сделал наверное, если никаких подводных камней не нашлось бы.
Клонируешь весь проект из репозитория, там в нем уже готовая релиз сборка ядра, запускаешь сервер.exe и все.
Из своего девайса потом вносишь поправки в скрипты, делаешь пулл на сервере и пересобераешь проект скриптов используя команду на сервере.

[StaticZ]

Я что-то не в теме. О каких окнах речь?

Я про окошко самого сервера с его логом. В общем-то дело не хитрое но в оригинальном коде никакого перенаправления вывода в студию нет.

При отладке тоже все в той-же студии в одном окне. Ничего не надо присоеденять, это не отдельные процессы.

Вообще-то отдельные и не только процессы а сами приложения. В винде нет отладчика на уровне ядра, поэтому любой отладчик является отдельным приложением, что присоединяется к другому, даже если запускать из под студии. Последнее просто упрощает задачу уменьшая количество действия требуемое от человека.
В оригинальной версии ранки и скорее всего серв уо есть еще не очень приятная штука для защиты от крашей и авто перезапуска сервера в этом случае приложение уже запускается вне отладчика, даже если было собрано и запущено из под студии. Я решил эту проблему просто переписав систему и теперь сервер запускаемый при отладке в случае краша сам перезапускается, после чего ищет запущенную студию с нужным проектом и сам себя аттачит к ее отладчику. Но я ленивый человек у меня нажал ф5 и студия сама запускает сервер, а тот сам запускает клиент, если он еще не запущен и выполняет вход на сервер, в случае краша клиента - перезапускает его, в случае дисконекта - перезаходит...

К тому-же можно ведь сделать что-бы во время выполнения пересоберался проект скриптов и правки вступали в силу не вырубая сам сервер не тратя кучу времени на загрузку мира.

А зачем полный мир для разработки? я для этого пустышку использую, кроме случаев когда надо ловить баги что непонятно как воспроизвести. Скажем не корректное поведение конкретного персонажа конкретного игрока. ну или финальной отладки\проверки особо извращенных случаев, скажем при измении принципа тойже серилизации.

Я думаю что изначально такая структура использовалась что-бы можно было как на Сфере resync делать.

Такая структура использовалась, так как по замыслу ядро должно было быть закрытым и монетезированым.

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

А смысл? разработкой всеравно заниматься удобнее на локалхосте а там и перезапускать сервер по 100 раз не проблема. а подобная система сложна и таит в себе множество камней, разве что намерено ограничивая возможности какимито патернами или используя что-то вроде lua скриптов для описания подобной логики... Хотя как по мне работать с темиже lua сложнее и дольше, да и с отладкой хуже. Так что сам концепт и техническая сторона вопроса безусловно привлекательны, но практический смысл подобного под вопросом.