Здравствуйте, гость ( Вход | Регистрация )

2 страниц V  1 2 >  
Ответить в эту темуОткрыть новую тему
> Компиляция или не надо, Надо ли компилить ядро каждый раз как сделал изменения в Script
Chicos
сообщение 24.11.2017, 5:53
Сообщение #1


**

Neophyte
Сообщений: 21
Регистрация: 20.6.2006
Группа: Пользователи
Наличность: 0
Пользователь №: 6.565



В руководстве по сборке компиляции сказано что надо добавить папку Server в проект и скомпилить ядро. От предшественика мне уже досталось готовое ядро. Почему то подумалось что просто изменив в папке Scripts нужный мне скрипт я получу нужное. Для пробы изменил в кастоме явно свой объект. Но изменения на сервере не отобразились. То есть после каждого изменения в Scripts необходимо пересобирать exe ? Или как то по другому? Начал только разбираться с UO, и что то в сотнях тем прочитанных этот момент не нашел.
Пользователь в офлайнеDelete PostОтправить личное сообщение
Вернуться в начало страницы
+Ответить с цитированием данного сообщения
Soteric
сообщение 24.11.2017, 6:04
Сообщение #2


********

Master
Сообщений: 1.377
Регистрация: 7.8.2006
Группа: Пользователи
Наличность: 3227
Пользователь №: 7.166



Ты понял верно. При запуске папка Scripts должна перекомпилироваться автоматически и твои изменения подхватятся. Нужно смотреть вывод в консоле. Там он пишет, что либо не нашел новых скриптов (и это странно в твоем случае) и перекомпиляция не нужна. Либо, что нашел изменения, компилирует их и тогда нужно смотреть твой скрипт, действительно ли ты сделал там именно то что ожидаешь увидеть в игре.
Пользователь в офлайнеDelete PostОтправить личное сообщение
Вернуться в начало страницы
+Ответить с цитированием данного сообщения
Juzzver
сообщение 24.11.2017, 15:19
Сообщение #3


**********

Модератор RunUO
Сообщений: 3.425
Регистрация: 1.11.2008
Группа: Супермодераторы
Наличность: 22565
Из: Северная Корея
Пользователь №: 11.273



Цитата
От предшественика мне уже досталось готовое ядро.

Если ядро в проекте объединяет обе папки Server и Scripts, при этом ScriptCompiler.cs отключен, то тогда придется делать компиляцию ядра для каждой правки.


--------------------
Пользователь в офлайнеDelete PostОтправить личное сообщение
Вернуться в начало страницы
+Ответить с цитированием данного сообщения
Aimed
сообщение 24.11.2017, 18:51
Сообщение #4


*********

Grandmaster
Сообщений: 2.250
Регистрация: 29.12.2012
Группа: Пользователи
Наличность: 8846
Пользователь №: 15.607



Ну вы и ответы даёте... я бы не зная сабжа нафиг запутался.
Начнем сначала:
Ядро - это и есть твой 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 отключен, то тогда придется делать компиляцию ядра для каждой правки.


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

Собственно одна из главных причин почему на УОРПГ в свое время Вап сделал вывод что это провальная система сейвов и начал требовать новую систему сейвов, в итоге из-за этого ядро разработчиков команды УОРПГ окончательно разосралось )))
Пользователь в офлайнеDelete PostОтправить личное сообщение
Вернуться в начало страницы
+Ответить с цитированием данного сообщения
StaticZ
сообщение 24.11.2017, 19:05
Сообщение #5


*********

Разработчик проекта "Квинтэссенция"
Сообщений: 2.155
Регистрация: 15.6.2009
Группа: Пользователи
Наличность: 0
Из: РФ, Москва
Пользователь №: 11.948



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

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


--------------------
RP сервер UO: Quintessence, а также ПО: EssenceUCS, EssenceUDK, CentrEd+, Fiddler+ и др.
Game isn't a dream, it is the reality, reality which is coming while we dream...
Пользователь в офлайнеDelete PostОтправить личное сообщение
Вернуться в начало страницы
+Ответить с цитированием данного сообщения
Aimed
сообщение 24.11.2017, 19:10
Сообщение #6


*********

Grandmaster
Сообщений: 2.250
Регистрация: 29.12.2012
Группа: Пользователи
Наличность: 8846
Пользователь №: 15.607



Цитата(StaticZ @ 24.11.2017, 17:05) *

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


А кто мешает отладчиком пользоваться то?
Нужно просто запускать дебаг скриптов через .exe и будет вам отладка.
А вобще я специально заметил что это в руках не очень грамотных людей может доставить большие проблемы. Да или просто банально забыть разок и уже гора веселья гарантирована.
Пользователь в офлайнеDelete PostОтправить личное сообщение
Вернуться в начало страницы
+Ответить с цитированием данного сообщения
StaticZ
сообщение 24.11.2017, 19:43
Сообщение #7


*********

Разработчик проекта "Квинтэссенция"
Сообщений: 2.155
Регистрация: 15.6.2009
Группа: Пользователи
Наличность: 0
Из: РФ, Москва
Пользователь №: 11.948



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


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


--------------------
RP сервер UO: Quintessence, а также ПО: EssenceUCS, EssenceUDK, CentrEd+, Fiddler+ и др.
Game isn't a dream, it is the reality, reality which is coming while we dream...
Пользователь в офлайнеDelete PostОтправить личное сообщение
Вернуться в начало страницы
+Ответить с цитированием данного сообщения
Aimed
сообщение 24.11.2017, 20:55
Сообщение #8


*********

Grandmaster
Сообщений: 2.250
Регистрация: 29.12.2012
Группа: Пользователи
Наличность: 8846
Пользователь №: 15.607



Цитата(StaticZ @ 24.11.2017, 17:43) *

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


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

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

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

Вобщем мое мнение вкратце: нужно не только компиляцию использовать, но и ещё более жесткие проверки добавлять в эту систему. Потому что я её считаю какой-то недоделанной.
Пользователь в офлайнеDelete PostОтправить личное сообщение
Вернуться в начало страницы
+Ответить с цитированием данного сообщения
Chicos
сообщение 24.11.2017, 22:50
Сообщение #9


**

Neophyte
Сообщений: 21
Регистрация: 20.6.2006
Группа: Пользователи
Наличность: 0
Пользователь №: 6.565



Цитата(Aimed @ 24.11.2017, 22:55) *

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

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

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

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


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


*********

Grandmaster
Сообщений: 2.250
Регистрация: 29.12.2012
Группа: Пользователи
Наличность: 8846
Пользователь №: 15.607



Цитата(Chicos @ 24.11.2017, 20:50) *

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


Послал в ЛС контакты. Вобще меня найти не должно быть сложно.
Пользователь в офлайнеDelete PostОтправить личное сообщение
Вернуться в начало страницы
+Ответить с цитированием данного сообщения
Juzzver
сообщение 25.11.2017, 15:18
Сообщение #11


**********

Модератор RunUO
Сообщений: 3.425
Регистрация: 1.11.2008
Группа: Супермодераторы
Наличность: 22565
Из: Северная Корея
Пользователь №: 11.273



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

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

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

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


--------------------
Пользователь в офлайнеDelete PostОтправить личное сообщение
Вернуться в начало страницы
+Ответить с цитированием данного сообщения
Aimed
сообщение 25.11.2017, 18:35
Сообщение #12


*********

Grandmaster
Сообщений: 2.250
Регистрация: 29.12.2012
Группа: Пользователи
Наличность: 8846
Пользователь №: 15.607



Цитата(Juzzver @ 25.11.2017, 13:18) *

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

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

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

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


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

Самое печальное что я поставил репо на битбакете, все свои правки коммитил туда, написал инструкции как пользоваться, как дебажить и соберать релиз, дал админу доступ, а он ТСу даже не сообщил об этом. Просто дал ему доступ на серверную машину через TeamViewer и все.
Пользователь в офлайнеDelete PostОтправить личное сообщение
Вернуться в начало страницы
+Ответить с цитированием данного сообщения
Aimed
сообщение 25.11.2017, 19:06
Сообщение #13


*********

Grandmaster
Сообщений: 2.250
Регистрация: 29.12.2012
Группа: Пользователи
Наличность: 8846
Пользователь №: 15.607



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

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

Если говорить об экономии времени во время сборки для разработки, то гораздо выгоднее разбить огромную папку Scripts тоже на проекты и если были внесены правки только в одном из них, то у тебя с динамической компиляцией скриптов сервер вобще будет взлетать, да и со статической компиляцией будет тот-же результат.
Пользователь в офлайнеDelete PostОтправить личное сообщение
Вернуться в начало страницы
+Ответить с цитированием данного сообщения
Juzzver
сообщение 26.11.2017, 1:02
Сообщение #14


**********

Модератор RunUO
Сообщений: 3.425
Регистрация: 1.11.2008
Группа: Супермодераторы
Наличность: 22565
Из: Северная Корея
Пользователь №: 11.273



Цитата(Aimed @ 25.11.2017, 19:35) *

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

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


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

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

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

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

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

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

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

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

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

На линуксе компиляцию в один выход тоже проще было составить.

Сообщение отредактировал Juzzver - 26.11.2017, 1:06


--------------------
Пользователь в офлайнеDelete PostОтправить личное сообщение
Вернуться в начало страницы
+Ответить с цитированием данного сообщения
StaticZ
сообщение 29.11.2017, 0:57
Сообщение #15


*********

Разработчик проекта "Квинтэссенция"
Сообщений: 2.155
Регистрация: 15.6.2009
Группа: Пользователи
Наличность: 0
Из: РФ, Москва
Пользователь №: 11.948



Цитата(Aimed @ 25.11.2017, 19:06) *

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

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

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


--------------------
RP сервер UO: Quintessence, а также ПО: EssenceUCS, EssenceUDK, CentrEd+, Fiddler+ и др.
Game isn't a dream, it is the reality, reality which is coming while we dream...
Пользователь в офлайнеDelete PostОтправить личное сообщение
Вернуться в начало страницы
+Ответить с цитированием данного сообщения
Aimed
сообщение 29.11.2017, 19:17
Сообщение #16


*********

Grandmaster
Сообщений: 2.250
Регистрация: 29.12.2012
Группа: Пользователи
Наличность: 8846
Пользователь №: 15.607



Цитата(StaticZ @ 28.11.2017, 22:57) *

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


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

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

Если б я начинал свой проект с нуля, я б так и сделал наверное, если никаких подводных камней не нашлось бы.
Клонируешь весь проект из репозитория, там в нем уже готовая релиз сборка ядра, запускаешь сервер.exe и все.
Из своего девайса потом вносишь поправки в скрипты, делаешь пулл на сервере и пересобераешь проект скриптов используя команду на сервере.
Пользователь в офлайнеDelete PostОтправить личное сообщение
Вернуться в начало страницы
+Ответить с цитированием данного сообщения
StaticZ
сообщение 30.11.2017, 19:11
Сообщение #17


*********

Разработчик проекта "Квинтэссенция"
Сообщений: 2.155
Регистрация: 15.6.2009
Группа: Пользователи
Наличность: 0
Из: РФ, Москва
Пользователь №: 11.948



Цитата(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 сложнее и дольше, да и с отладкой хуже. Так что сам концепт и техническая сторона вопроса безусловно привлекательны, но практический смысл подобного под вопросом.


--------------------
RP сервер UO: Quintessence, а также ПО: EssenceUCS, EssenceUDK, CentrEd+, Fiddler+ и др.
Game isn't a dream, it is the reality, reality which is coming while we dream...
Пользователь в офлайнеDelete PostОтправить личное сообщение
Вернуться в начало страницы
+Ответить с цитированием данного сообщения
Juzzver
сообщение 8.12.2017, 20:02
Сообщение #18


**********

Модератор RunUO
Сообщений: 3.425
Регистрация: 1.11.2008
Группа: Супермодераторы
Наличность: 22565
Из: Северная Корея
Пользователь №: 11.273



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


--------------------
Пользователь в офлайнеDelete PostОтправить личное сообщение
Вернуться в начало страницы
+Ответить с цитированием данного сообщения
Aimed
сообщение 9.12.2017, 19:03
Сообщение #19


*********

Grandmaster
Сообщений: 2.250
Регистрация: 29.12.2012
Группа: Пользователи
Наличность: 8846
Пользователь №: 15.607



Цитата(Juzzver @ 8.12.2017, 18:02) *

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


Там код ещё со времен динозавров, давно пора его обновлять. Добавить msbuild для винды, посмотреть что там по нему у юниксов. Исходники в открытом доступе.
Да и вобще смотреть в сторону порта на .NET Core.
Пользователь в офлайнеDelete PostОтправить личное сообщение
Вернуться в начало страницы
+Ответить с цитированием данного сообщения
Juzzver
сообщение 1.2.2018, 21:13
Сообщение #20


**********

Модератор RunUO
Сообщений: 3.425
Регистрация: 1.11.2008
Группа: Супермодераторы
Наличность: 22565
Из: Северная Корея
Пользователь №: 11.273



Цитата
Там код ещё со времен динозавров, давно пора его обновлять. Добавить 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() )


Сообщение отредактировал Juzzver - 1.2.2018, 21:13


--------------------
Пользователь в офлайнеDelete PostОтправить личное сообщение
Вернуться в начало страницы
+Ответить с цитированием данного сообщения

2 страниц V  1 2 >
Ответить в эту темуОткрыть новую тему
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0

 

- Текстовая версия | Версия для КПК Сейчас: 28.3.2024, 19:12
Designed by Nickostyle