Помощь - Поиск - Пользователи - Календарь
Полная версия: Компиляция или не надо
UoKit.com Форумы > Ultima Online : Dev > RunUO Server > Вопросы по RunUO
Chicos
В руководстве по сборке компиляции сказано что надо добавить папку Server в проект и скомпилить ядро. От предшественика мне уже досталось готовое ядро. Почему то подумалось что просто изменив в папке Scripts нужный мне скрипт я получу нужное. Для пробы изменил в кастоме явно свой объект. Но изменения на сервере не отобразились. То есть после каждого изменения в Scripts необходимо пересобирать exe ? Или как то по другому? Начал только разбираться с UO, и что то в сотнях тем прочитанных этот момент не нашел.
Soteric
Ты понял верно. При запуске папка Scripts должна перекомпилироваться автоматически и твои изменения подхватятся. Нужно смотреть вывод в консоле. Там он пишет, что либо не нашел новых скриптов (и это странно в твоем случае) и перекомпиляция не нужна. Либо, что нашел изменения, компилирует их и тогда нужно смотреть твой скрипт, действительно ли ты сделал там именно то что ожидаешь увидеть в игре.
Juzzver
Цитата
От предшественика мне уже досталось готовое ядро.

Если ядро в проекте объединяет обе папки Server и Scripts, при этом ScriptCompiler.cs отключен, то тогда придется делать компиляцию ядра для каждой правки.
Aimed
Ну вы и ответы даёте... я бы не зная сабжа нафиг запутался.
Начнем сначала:
Ядро - это и есть твой RunUO.exe либо ServUO.exe. Исходники ядра находятся в папке Server.
Скрипты - это то что у папке скриптов(Scripts) находится. Они компилируются в рантайме уже ядром каждый раз когда ты запускаешь RunUO/ServUO.exe и создается кеш в виде дллки.

Цитата(Chicos @ 24.11.2017, 3:53) *
То есть после каждого изменения в Scripts необходимо пересобирать exe ?

Нет, нужно просто перезапустить RunUO/ServUO.exe.

Если же изменение было в файлах из папки Server, нужно сперва пересобрать уже сам сервер RunUO/ServUO.exe и после этого эти изменения вступят в силу для твоих скриптов. Допустим ты в классе Mobile добавил новое protected поле, которое должно быть видно в PlayerMobile. Сперва нужно собрать ядро и тогда ты сможешь обращаться к этому полю в PlayerMobile.

Цитата(Juzzver @ 24.11.2017, 13:19) *
Если ядро в проекте объединяет обе папки Server и Scripts, при этом ScriptCompiler.cs отключен, то тогда придется делать компиляцию ядра для каждой правки.


Да, если так уже сделали, то прийдется, но так делать вобще не надо. Лучше собрать все обратно в нормальную структуру ядро-скрипты и включить компиляцию скриптов.
Там есть проверки для сериализации и десериализации. Возможно так-же добавить свои кастомные проверки в ядро, ибо сериализация не очень надеждная система для записи/восстановления данных когда отключена компиляция скриптов и все это в руках не очень грамотных людей находится. Можно делов наделать с сейвами.

Собственно одна из главных причин почему на УОРПГ в свое время Вап сделал вывод что это провальная система сейвов и начал требовать новую систему сейвов, в итоге из-за этого ядро разработчиков команды УОРПГ окончательно разосралось )))
StaticZ
Цитата(Aimed @ 24.11.2017, 18:51) *
Да, если так уже сделали, то прийдется, но так делать вобще не надо. Лучше собрать все обратно в нормальную структуру ядро-скрипты и включить компиляцию скриптов.
Там есть проверки для сериализации и десериализации. Возможно так-же добавить свои кастомные проверки в ядро, ибо сериализация не очень надеждная система для хранения данных когда отключена компиляция скриптов и все это в руках не очень грамотных людей находится. Можно делов наделать с сейвами.

Как по мне при статичной компиляции куда проще и удобнее работать да и ошибки искать. Отладчик лучше всяких проверок, которые в лучшем случае способны выявить лишь общие проблемы, да и от криворукости с полноценным ЯП ничто не спасет, да даже LUA скрипты на практике сплошь и рядом способны привести к крашам =)
Aimed
Цитата(StaticZ @ 24.11.2017, 17:05) *

Как по мне при статичной компиляции куда проще и удобнее работать да и ошибки искать. Отладчик лучше всяких проверок, которые в лучшем случае способны выявить лишь общие проблемы, да и от криворукости с полноценным ЯП ничто не спасет, да даже LUA скрипты на практике сплошь и рядом способны привести к крашам =)


А кто мешает отладчиком пользоваться то?
Нужно просто запускать дебаг скриптов через .exe и будет вам отладка.
А вобще я специально заметил что это в руках не очень грамотных людей может доставить большие проблемы. Да или просто банально забыть разок и уже гора веселья гарантирована.
StaticZ
Цитата(Aimed @ 24.11.2017, 19:10) *
А кто мешает отладчиком пользоваться то?
Нужно просто запускать дебаг скриптов через .exe и будет вам отладка.
Ну так эта и есть статическая компиляция о которой я говорю. В ядре отключается компиляция скриптов а те компилируется уже в студии. Вообще этот ScriptCompiler большая кака.


Цитата(Aimed @ 24.11.2017, 19:10) *
А вобще я специально заметил что это в руках не очень грамотных людей может доставить большие проблемы. Да или просто банально забыть разок и уже гора веселья гарантирована.
Ну вы еще скажите что ассемблер в руках не очень грамотных людей может доставить большие проблемы. Это и так очевидно если лезишь в это надо или знать ЯП и иметь навык или покрайней мере быть готовым к бессонным ночам мучений, ковыряний кода, обучению и поиску проблем.
Aimed
Цитата(StaticZ @ 24.11.2017, 17:43) *

Ну так эта и есть статическая компиляция о которой я говорю. В ядре отключается компиляция скриптов а те компилируется уже в студии. Вообще этот ScriptCompiler большая кака.


Линк был на FAQ о дебаге ядра + скриптов при нормальной структуре с динамической компиляцией скриптов во время рантайма.
Я не согласен что компилятор скриптов это кака. Для главной аудитории это безопаснее чем убрать его полностью. Даже для себя лично я предпочту такой подход, нежели полную компиляцию проекта сразу.

К тому-же если б кому-то действительно было дело до сервера, можно было-бы ещё больше обезопасить все это дело. Создав нормальный фреймворк для создания Save полей и метаданных о версиях и все это динамически проверять при запуске сервера, что-бы уменьшить шанс на всяческие проблемы связанные с сейвами.

Сейвы это наше все. Нужно лишь разок затупить или забыть что-то и можно сразу хорошенько приехать.
Я считаю что нужен очень щепетильный подход к этому делу. А вырубать все *лишнее*, потому что сервер на 20 сек дольше загружается, это по-моему не серьёзно.

Вобщем мое мнение вкратце: нужно не только компиляцию использовать, но и ещё более жесткие проверки добавлять в эту систему. Потому что я её считаю какой-то недоделанной.
Chicos
Цитата(Aimed @ 24.11.2017, 22:55) *

Линк был на FAQ о дебаге ядра + скриптов при нормальной структуре с динамической компиляцией скриптов во время рантайма.
Я не согласен что компилятор скриптов это кака. Для главной аудитории это безопаснее чем убрать его полностью. Даже для себя лично я предпочту такой подход, нежели полную компиляцию проекта сразу.

К тому-же если б кому-то действительно было дело до сервера, можно было-бы ещё больше обезопасить все это дело. Создав нормальный фреймворк для создания Save полей и метаданных о версиях и все это динамически проверять при запуске сервера, что-бы уменьшить шанс на всяческие проблемы связанные с сейвами.

Сейвы это наше все. Нужно лишь разок затупить или забыть что-то и можно сразу хорошенько приехать.
Я считаю что нужен очень щепетильный подход к этому делу. А вырубать все *лишнее*, потому что сервер на 20 сек дольше загружается, это по-моему не серьёзно.

Вобщем мое мнение вкратце: нужно не только компиляцию использовать, но и ещё более жесткие проверки добавлять в эту систему. Потому что я её считаю какой-то недоделанной.


Ну Аймед, так то то ты это и есть предшественик, я сейчас за тобой Нову подобрал, в принципе я уже разобрался, скомпилил ядро новое на тестовом, вижу что скриптс тоже в ядре сидят. Помоги чуть на первом этапе, я же 3 дня как с ней работаю. Пока сервак жив, народ бегает, не хочу что либо поломать по незнанию. Хочу просто список багов поправить и далее развить немного сервак, там народ все устаривает, чисто по нобходимости. Оплачу твое время, в пределах разумного. Мне не надо разжевывать, читать я умею форум, чисто что, где, и как в общих чертах, особенности сервака. Просто Спил скинул на меня, я не отказался, но и контактов не было твоих. Почта kns собак mail.ru
Aimed
Цитата(Chicos @ 24.11.2017, 20:50) *

Ну Аймед, так то то ты это и есть предшественик, я сейчас за тобой Нову подобрал, в принципе я уже разобрался, скомпилил ядро новое на тестовом, вижу что скриптс тоже в ядре сидят. Помоги чуть на первом этапе, я же 3 дня как с ней работаю. Пока сервак жив, народ бегает, не хочу что либо поломать по незнанию. Хочу просто список багов поправить и далее развить немного сервак, там народ все устаривает, чисто по нобходимости. Оплачу твое время, в пределах разумного. Мне не надо разжевывать, читать я умею форум, чисто что, где, и как в общих чертах, особенности сервака. Просто Спил скинул на меня, я не отказался, но и контактов не было твоих. Почта kns собак mail.ru


Послал в ЛС контакты. Вобще меня найти не должно быть сложно.
Juzzver
Я лично не ощутил проблем с сериализациями при работе в обоих вариантах. Так или иначе, если есть проблемы, через консоль показывает характер ошибок связанных с загрузками.

А что касается общей компиляции и экономии времени - это реально удобнее, и когда работаешь над проектом годами, экономия на каждой компиляции тех же 20 секунд - дает огромное кпд smile.gif. Ну и плюс общий вывод в одном месте, не приходится расслаиваться.

Единственное на мой взгляд, чего стоит опасаться, из серии "неподготовленных рук", это когда начинают подключать пространство имён скриптов в сервере, и получается каша c поломанной ахритектурой и рядом зависимостей.

Если это шард Nova, то там так и сделано, объединение ядра со скриптами в одном проекте.
Aimed
Цитата(Juzzver @ 25.11.2017, 13:18) *

Я лично не ощутил проблем с сериализациями при работе в обоих вариантах. Так или иначе, если есть проблемы, через консоль показывает характер ошибок связанных с загрузками.

А что касается общей компиляции и экономии времени - это реально удобнее, и когда работаешь над проектом годами, экономия на каждой компиляции тех же 20 секунд - дает огромное кпд smile.gif. Ну и плюс общий вывод в одном месте, не приходится расслаиваться.

Единственное на мой взгляд, чего стоит опасаться, из серии "неподготовленных рук", это когда начинают подключать пространство имён скриптов в сервере, и получается каша c поломанной ахритектурой и рядом зависимостей.

Если это шард Nova, то там так и сделано, объединение ядра со скриптами в одном проекте.


А что там случилось вобще? Потому что когда мне дали проект - там просто ужас что творилось, я так до сих пор все и не исправил. Особенно у меня подгорает от того как там реализован код с экспансиями и главное - никакой репозитории с кодом от прошлого владельца или какой-либо документации.
И когда я собрал все обратно в структуру сервера и скриптов, у меня он вобще перестал запускаться. Некоторые дома нехотели десереализироваться. А на старой версии никаких ошибок. В итоге там был баг в десерилазиции домов и на старой версии кода, что сейчас там работает, пропадали гильд стоуны, но сервер зато запускался. И там ошибок по сериализации/десерилазции вылезло у меня чтук 8 и ещё где-то с 50 варнингов.

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

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

Если говорить об экономии времени во время сборки для разработки, то гораздо выгоднее разбить огромную папку Scripts тоже на проекты и если были внесены правки только в одном из них, то у тебя с динамической компиляцией скриптов сервер вобще будет взлетать, да и со статической компиляцией будет тот-же результат.
Juzzver
Цитата(Aimed @ 25.11.2017, 19:35) *

А что там случилось вобще? Потому что когда мне дали проект - там просто ужас что творилось, я так до сих пор все и не исправил. Особенно у меня подгорает от того как там реализован код с экспансиями и главное - никакой репозитории с кодом от прошлого владельца или какой-либо документации.
И когда я собрал все обратно в структуру сервера и скриптов, у меня он вобще перестал запускаться. Некоторые дома нехотели десереализироваться. А на старой версии никаких ошибок. В итоге там был баг в десерилазиции домов и на старой версии кода, что сейчас там работает, пропадали гильд стоуны, но сервер зато запускался. И там ошибок по сериализации/десерилазции вылезло у меня чтук 8 и ещё где-то с 50 варнингов.

Самое печальное что я поставил репо на битбакете, все свои правки коммитил туда, написал инструкции как пользоваться, как дебажить и соберать релиз, дал админу доступ, а он ТСу даже не сообщил об этом. Просто дал ему доступ на серверную машину через TeamViewer и все.


Сам сервер был собран из оригинальных исходников Новы, где из всего что осталось - была только папка Scripts. Версия ядра и прочие вещи подбирались методами глубоких анализов по максимальному соответствию, если не ошибаюсь, примерно 147 свн версия была выбрана.
После чего уже шло восстановление сейвов Новы, на основе той же папки со скриптами, скриншотов и памяти игроков).
Качество кода, конечно оставляло желать лучшего... Но моя задача была запустить и донастроить сервер таким образом, каким он существовал в каком-то там году.

Сложности с экспансией, то возможно моя работа, т.к. стояла задача запустить некоторые аос фитчи на ренесансе, уже не вспомню конкретно чего это касалось, но с задачей справился. К примеру одна из таких фитч, им надо было, чтобы Luck работал и отображался в статус гампе, а это пакет из аоса.

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

Дальнейшим сервера я не интересовался, т.к. сменился владелец, и все мои учетки прибрал к себе новый владалец, включая игровых персов laugh.gif

P.S> сервер я поддерживал примерно в районе полугода, вышеперечисленных проблем со стоунами, домами и сериализациями не встречались. Крашей и критических багов было много еще со старых исходников, но это всё исправлялось сразу по мере возникновения.

Цитата
Кстати, насчет 20 сек это тоже не совсем правда....

У меня на то время стоял Атлон, и для него это была сложная задача по времени. Куда быстрее было компилить всё целиком. И если не ошибаюсь студия использует свои наборы для компиляции, а не стандартный csc в соло, в результате чего разница ощущалось. Само ядро даже на Атлоне за пару сек компилилась.

А когда работал с серверами, где компиляция занимала порядка 5 мин, при этом еще и сейвы прогружались столько же, а тестить приходилось к примеру автотурнир, и ты открываешь по 5-6 окон, котоыре сжирают всё цп. В таких случаях у меня бы нервы сдали ждать еще пока ScriptCompiler сделает свою работу))

В общем на цвет и вкус наверное. Но на своем опыте мне было так удобно, и очень много проектов встречал в том же стиле.
Когда держал свои сервера на удаленке, мне достаточно было скинуть лишь один .exe файл, чтобы перенести все апдейты на мэйн сервер, это тоже был плюс. Ctrl+C -> Ctrl+V и готово smile.gif

На линуксе компиляцию в один выход тоже проще было составить.
StaticZ
Цитата(Aimed @ 25.11.2017, 19:06) *

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

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

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

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


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

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

Если б я начинал свой проект с нуля, я б так и сделал наверное, если никаких подводных камней не нашлось бы.
Клонируешь весь проект из репозитория, там в нем уже готовая релиз сборка ядра, запускаешь сервер.exe и все.
Из своего девайса потом вносишь поправки в скрипты, делаешь пулл на сервере и пересобераешь проект скриптов используя команду на сервере.
StaticZ
Цитата(Aimed @ 29.11.2017, 19:17) *
Я что-то не в теме. О каких окнах речь?
Я про окошко самого сервера с его логом. В общем-то дело не хитрое но в оригинальном коде никакого перенаправления вывода в студию нет.

Цитата(Aimed @ 29.11.2017, 19:17) *
При отладке тоже все в той-же студии в одном окне. Ничего не надо присоеденять, это не отдельные процессы.
Вообще-то отдельные и не только процессы а сами приложения. В винде нет отладчика на уровне ядра, поэтому любой отладчик является отдельным приложением, что присоединяется к другому, даже если запускать из под студии. Последнее просто упрощает задачу уменьшая количество действия требуемое от человека.
В оригинальной версии ранки и скорее всего серв уо есть еще не очень приятная штука для защиты от крашей и авто перезапуска сервера в этом случае приложение уже запускается вне отладчика, даже если было собрано и запущено из под студии. Я решил эту проблему просто переписав систему и теперь сервер запускаемый при отладке в случае краша сам перезапускается, после чего ищет запущенную студию с нужным проектом и сам себя аттачит к ее отладчику. Но я ленивый человек у меня нажал ф5 и студия сама запускает сервер, а тот сам запускает клиент, если он еще не запущен и выполняет вход на сервер, в случае краша клиента - перезапускает его, в случае дисконекта - перезаходит...

Цитата(Aimed @ 29.11.2017, 19:17) *
К тому-же можно ведь сделать что-бы во время выполнения пересоберался проект скриптов и правки вступали в силу не вырубая сам сервер не тратя кучу времени на загрузку мира.
А зачем полный мир для разработки? я для этого пустышку использую, кроме случаев когда надо ловить баги что непонятно как воспроизвести. Скажем не корректное поведение конкретного персонажа конкретного игрока. ну или финальной отладки\проверки особо извращенных случаев, скажем при измении принципа тойже серилизации.

Цитата(Aimed @ 29.11.2017, 19:17) *
Я думаю что изначально такая структура использовалась что-бы можно было как на Сфере resync делать.
Такая структура использовалась, так как по замыслу ядро должно было быть закрытым и монетезированым.

Цитата(Aimed @ 29.11.2017, 19:17) *
Если б я начинал свой проект с нуля, я б так и сделал наверное, если никаких подводных камней не нашлось бы.
А смысл? разработкой всеравно заниматься удобнее на локалхосте а там и перезапускать сервер по 100 раз не проблема. а подобная система сложна и таит в себе множество камней, разве что намерено ограничивая возможности какимито патернами или используя что-то вроде lua скриптов для описания подобной логики... Хотя как по мне работать с темиже lua сложнее и дольше, да и с отладкой хуже. Так что сам концепт и техническая сторона вопроса безусловно привлекательны, но практический смысл подобного под вопросом.
Juzzver
Столкнулся с неприятным моментом при использовании ScriptsCompiler, когда кодишь на C# 6 и билдишь корректно, а консоль тебе потом выдает ошибки, т.к. csc поддерживает почему-то только до 5й версии языка. Принудительно выставляя langversion:6, выдается исключение, мол доступные версии только от ISO-1 до 5й версии (при том что фрамворки последние стоят). Вполне вероятно, что это всё настраиваемо, но это лишние телодвижения, опять же проще собрать в одном проекте скрипты с ядром, отключив scriptcompiler, чем решать этот вопрос smile.gif
Aimed
Цитата(Juzzver @ 8.12.2017, 18:02) *

Столкнулся с неприятным моментом при использовании ScriptsCompiler, когда кодишь на C# 6 и билдишь корректно, а консоль тебе потом выдает ошибки, т.к. csc поддерживает почему-то только до 5й версии языка. Принудительно выставляя langversion:6, выдается исключение, мол доступные версии только от ISO-1 до 5й версии (при том что фрамворки последние стоят). Вполне вероятно, что это всё настраиваемо, но это лишние телодвижения, опять же проще собрать в одном проекте скрипты с ядром, отключив scriptcompiler, чем решать этот вопрос smile.gif


Там код ещё со времен динозавров, давно пора его обновлять. Добавить msbuild для винды, посмотреть что там по нему у юниксов. Исходники в открытом доступе.
Да и вобще смотреть в сторону порта на .NET Core.
Juzzver
Цитата
Там код ещё со времен динозавров, давно пора его обновлять. Добавить msbuild для винды, посмотреть что там по нему у юниксов. Исходники в открытом доступе.
Да и вобще смотреть в сторону порта на .NET Core.

Решил покопаться, в итоге получилось сделать через Roslyn компилятор поддержку 6й версии языка:

https://www.nuget.org/packages/Microsoft.Co...mpilerPlatform/
В ScriptCompiler.cs поменять:
Код
using ( CSharpCodeProvider provider = new CSharpCodeProvider() )

на:
Код
using ( CSharpCodeProvider provider = new Microsoft.CodeDom.Providers.DotNetCompilerPlatform.CSharpCodeProvider() )
Aimed
Надо будет ещё попробовать там msbuild/xbuild (if Unix) и скармливать csproj файл в отдельный процесс, вместо массива со всеми .cs файлами.
volkinson
Ребята, а как сделать так, чтобы скрипты подгружались на лету без перезагрузки сервера? Я видел у одного спеца ItWouldBeWise, он в своих видео уроках делает все без перегазруки. Он сказал, что написал какой-то фреймворк Uber Script и серверу не нужна перезагрузка. Буду очень благодарен за совет.
Juzzver
Глянул о чем речь - это нечто иное как конфиги, с которых парсятся данные и соответственно в любой момент могут подхватываться изменения. В данном случае система завязана на событиях, по происшествию которого мы начинаем выполнять те или иные действия, сделано это скорее всего посредством рефлексии.

Так что для самых простых операций со значениями, к примеру вывести рейты на дроп артефактов с босса - просто выводишь в файл параметры со значениями и парсишь их.
Для более сложных - изучай методы рефлексии (System.Reflection).

Полностью сделать сервер без перезагрузки - это опять же в сторону рефлексии, но скорее всего нереально, топорно, долго, больно и т.д.

Можно еще динамически подгружать модули, наклепав заранее dll-ки нужные, но это будет из той же серии рефлексии, что в конечном итоге тоже ни к чему хорошему не приведёт.

Иных ходов не знаю, но мб есть какие-то фрейм ворки, опять же завязанные на рефлексии, которые упрощают жизнь данной идеи.

Aimed
С рефлексией большой гемор будет. Куча подводных камней и очень сложно. Тут надо делать как у Сферы. Закрывать ядро полностью и предоставлять скриптовое АПИ которое будет подстраиваться под определенный набор типов данных из ядра. Никаких наследований от мобайла и так далее. Как и в Сфере через темплейты работать ( тайпдефы ), которые тебе мобайла со всеми нужными параметрами будут создавать. Таким образом никаких проблем с памятью при перезагрузке не будет.

Второй шаг - писать парсер всех скриптов что б их в новый формат, под скриптовое АПИ конвертировать. В принципе это реально сделать, но проект колоссальный. Думаю что пару месяцев - пол года, в свободное от работы время и там уже что-то точно будет работать.
Juzzver
Еще как вариант, можно взять тот же форк UOForever, под который и были написаны эти убер скрипты, и попытаться их перетянуть на свой шард. Но как уже было сказано выше - это не покрывает все возможности, а только лишь предопределенные.
Wap
Цитата(Aimed @ 28.3.2019, 11:38) *

С рефлексией большой гемор будет. Куча подводных камней и очень сложно. Тут надо делать как у Сферы. Закрывать ядро полностью и предоставлять скриптовое АПИ которое будет подстраиваться под определенный набор типов данных из ядра. Никаких наследований от мобайла и так далее. Как и в Сфере через темплейты работать ( тайпдефы ), которые тебе мобайла со всеми нужными параметрами будут создавать. Таким образом никаких проблем с памятью при перезагрузке не будет.

Второй шаг - писать парсер всех скриптов что б их в новый формат, под скриптовое АПИ конвертировать. В принципе это реально сделать, но проект колоссальный. Думаю что пару месяцев - пол года, в свободное от работы время и там уже что-то точно будет работать.
В одно рыло в свободное от работы время - это года три делать. smile.gif Это если активно работать и человек шарящий. Это ж надо весь хай-левел код переписать, тонны контента, если мы говорим о сервере типа стандартной современной Ранки.

А вообще, по сути это типа как переписать эмулятор Сфера на C#. biggrin.gif
Alastar
Как вариант впилить javascript библиотеку в ядро и писать все на жс. Будет то же самое, что писали выше, только все уже сделали за вас.
Ozzy Osbourne
Цитата(Alastar @ 29.3.2019, 8:57) *
Как вариант впилить javascript библиотеку в ядро и писать все на жс. Будет то же самое, что писали выше, только все уже сделали за вас.

laugh.gif laugh.gif laugh.gif
Aimed
Цитата(Wap @ 28.3.2019, 23:45) *

В одно рыло в свободное от работы время - это года три делать. smile.gif Это если активно работать и человек шарящий. Это ж надо весь хай-левел код переписать, тонны контента, если мы говорим о сервере типа стандартной современной Ранки.

А вообще, по сути это типа как переписать эмулятор Сфера на C#. biggrin.gif


Зачем там хай-левел код переписывать? Именно переписывать там нужно очень мало кода.
1) Нужно написать обертку, которая будет скриптовым АПИ, как у Сферы.
2) В этой обертке сделать маппинг с вызовами серверного ядра. Много там не нужно, опять смотрим на Сферу.
3) Перенести некоторые классы, такие как Player, BaseCreatue и им подобные в ядро. Чем больше таких классов будет в ядре, тем меньше скриптов прийдется загружать == профит при старте сервера. По сути драг&дропом позаниматься 1 вечер в солюшене студии.
4) Самое сложное это написать парсер и конвертер текущих РанУО скриптов под новое АПИ. Ну а дальше конвертер сконвертирует все что останется в Scriptsс в новый формат.
5) Переписать нужно только компиляцию скриптов, что б она работала под новое скриптовое АПИ.

Вполне себе проект на несколько месяцев - пол года программисту уровня мидла и выше. Самое интересное то что быстродействие не должно пострадать, в теории. А вот почему у Сферы тогда с этим проблемы...не понятно

Цитата(Alastar @ 29.3.2019, 7:57) *

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


Если только она магическая ))

П.С. На самом деле оч крутой проект. Будь я в другой ситуации, наверное, занялся бы таким. Если грамотно сделать скриптовое АПИ, то Сферу вобще полностью можно будет хоронить. Вытащить ещё нужные механики из ядра Сферы и все, Cфера станет полностью obsolete.
RL_ka
Зачем изобретать велосипеды, если для этих целей уже есть ПОЛ? smile.gif
каждый из эмулей занял свою нишу, и тем они и прекрасны, по-моему
Aimed
Цитата(RL_ka @ 29.3.2019, 12:21) *

Зачем изобретать велосипеды, если для этих целей уже есть ПОЛ? smile.gif
каждый из эмулей занял свою нишу, и тем они и прекрасны, по-моему


Нууу.. это ошибка в архитектуре сервера. Кто ж так делает, что б ядро сервера падало от ошибок в скриптах. А подавляющее большинство, включая самых активных разрабов РанУО/СервУО вобще компиляцию скриптов выпиливают и все одним проектом держат. Тоесть скрипты просто папочка в программе сервера. Это плохая архитектура несущая плохую эффективность разработки. Каждый раз весь сервак компилировать что бы глянуть как 1 изменившийся скрипт работает... это ж позор )
Alastar
Цитата(Aimed @ 29.3.2019, 14:04) *

Если только она магическая ))

Ultima Offline Experiment гугли, там скрипты на жс, ядро компилируется
Ozzy Osbourne
Ты действительно не понимаешь чем UOX3 отличается от "впилить жс библиотеку в ядро ранки что бы писать на жс" ? ))
Это текстовая версия — только основной контент. Для просмотра полной версии этой страницы, пожалуйста, нажмите сюда.
Русская версия Invision Power Board © 2001-2019 Invision Power Services, Inc.