Дерево элементов. Переопределение родителя элемента.

[Miami Night Studio]

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

Рассмотрим ситуацию.

Существует ресурс "A" и существует ресурс "B". В ресурсе "А" создается транспорт, элементу транспорта применяется родитель - динамическая карта ресурса "B". 
Теперь, раз уж элемент транспорта является дочерним к динамической карте ресурса "B", то по всей видимости он должен быть автоматически удален при отключении ресурса "B". Но к сожалению это не происходит, удаляется транспорт только при остановке ресурса "А".

Возможно ли как то элемент, созданный в одном ресурсе сделать дочерним другому и таким образом получить удаление этого же элемента за счет остановки ресурса нового родителя?

 

 

[Space_Unicorn]

Не совсем понятно.
Почему бы не использовать on(Client)ResourceStop и удалять все необходимые элементы? Возможно лезть в древо элементов впринципе не очень хорошая идея

Не совсем понятно.
Почему бы не использовать on(Client)ResourceStop и удалять все необходимые элементы? Возможно лезть в древо элементов впринципе не очень хорошая идея

 

upd: в вики написано что элементы удаляются только тогда, когда останавливается ресурс который их создал

https://wiki.multitheftauto.com/wiki/SetElementParent
This function does not change when an element will be destroyed - Elements are always destroyed when the resource that created them is stopped

[Miami Night Studio]

Имеется система респавна авто,  она вынесена в отдельный ресурс.
Собственно, изначально транспорт создается именно в том ресурсе, в котором он и нужен ( взять к примеру какую то работу ). Далее с помощью экспортированной функции юзердата элемента и необходимые данные для респавна транспорта передаются в эту систему.

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

В общем вот и вся трагедия.
 

[Space_Unicorn]

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

[Kenix]

On 15/01/2020 at 16:20, Space_Unicorn said:

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

Я на своем опыте скажу, что это не так.
Почему?
Для маленьких модов да, можно в одном ресурсе, но дальше идут проблемы.
Если проект будет большой и нужно в режиме реального времени обновлять его, например внести изменения в конфиг, то сделать не получится такое если всё в одном ресурсе. Нужно будет перезапускать весь мод.
Также скорость разработки снизится, т.к сделав любое изменение вам придется долго ждать, особенно это касается верстки интерфейсов. Любое изменение в UI вы можете легко проверить в игре, сделав просто рестарт, остальные ресурсы будут работать как и работали.
Лучше когда много ресурсов, каждый ресурс выполняется в своем VM, так безопаснее чем это всё делать в одной.
Также если проект поделен по ресурсам есть другая проблема, это использование так называемых utility функций, их придется кидать в каждый ресурс, при грамотном подходе это решается легко.
Если будете делать командой, то можно легко делать разработку, каждый работает над своим ресурсом и он легко внедряется на сервер.

Организация ресурсов может быть такой:
[assets] // папка с вашыми ресурсами, это могут быть шрифты, картинки, шейдеры, модели, звуки и т.д
[ui] // UI вашего мода, например это может быть какой нибудь банк или автосалон
[engine] // Ваш мод, основные компоненты, база или какие-то функции, utilities
[third_party] // Ресурсы сторонних авторов
[game] // Сами ресурсы реализация, например создание автосалонов на стороне сервера

Также можно организовать папки по элементам
[player]
[vehicle] // например vehicle_tuning, vehicle_wheels.
[property]
и т.д

Это тоже интересный подход.

Edited January 18, 2020 by Kenix

[Space_Unicorn]

15 hours ago, Kenix said:

Я на своем опыте скажу, что это не так.
Почему?
Для маленьких модов да, можно в одном ресурсе, но дальше идут проблемы.
Если проект будет большой и нужно в режиме реального времени обновлять его, например внести изменения в конфиг, то сделать не получится такое если всё в одном ресурсе. Нужно будет перезапускать весь мод.
Также скорость разработки снизится, т.к сделав любое изменение вам придется долго ждать, особенно это касается верстки интерфейсов. Любое изменение в UI вы можете легко проверить в игре, сделав просто рестарт, остальные ресурсы будут работать как и работали.
Лучше когда много ресурсов, каждый ресурс выполняется в своем VM, так безопаснее чем это всё делать в одной.
Также если проект поделен по ресурсам есть другая проблема, это использование так называемых utility функций, их придется кидать в каждый ресурс, при грамотном подходе это решается легко.
Если будете делать командой, то можно легко делать разработку, каждый работает над своим ресурсом и он легко внедряется на сервер.

Организация ресурсов может быть такой:
[assets] // папка с вашыми ресурсами, это могут быть шрифты, картинки, шейдеры, модели, звуки и т.д
[ui] // UI вашего мода, например это может быть какой нибудь банк или автосалон
[engine] // Ваш мод, основные компоненты, база или какие-то функции, utilities
[third_party] // Ресурсы сторонних авторов
[game] // Сами ресурсы реализация, например создание автосалонов на стороне сервера

Также можно организовать папки по элементам
[player]
[vehicle] // например vehicle_tuning, vehicle_wheels.
[property]
и т.д

Это тоже интересный подход.

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

А на счёт конфигов зависит от того насколько лень, можно ведь сделать конфиги которые будут в реалтайме обновляться из xml или json