Если твой класс наследован от Script - создается 1 экземпляр, всё остальное работает так - как ты заставишь это работать.
ООП тут как мне кажется не причем. В рамках ооп оно могло бы работать как угодно. Я просто хотел узнать, если я буду что-то долгое делать в обработчике, то скажется ли это на обработку других пользователей. Но ты в целом ответил на мой вопрос.
В таком случае вопрос не в "обработчике"(по идее это объект, экземпляр класса, но пусть будет обработчик) а в потоках. Если ты заблочишь главный поток на N кол-во операций - то офк будет небольшая задержка. Если это запрос в бд/сторонний сервис выноси это в асинхронные таски
То есть я правильно понимаю, что выполнение RemoveEvent'а например будет происходить в главном потоке?
Аааа. Я не так прочитал с первого раза. Сейчас возникли вопросы. То есть создается один, вообще? Как синглтон? Или один на каждого клиента как выразился Inoi?
Один, если ты хочешь получить доступ с другого объекта - сделай автосвойство Instance и в пустом конструкторе присвой Instance = this. Те самые цветные надписи при старте сервера - это и есть инициализация классов, наследуемых от script + парсинг всех евентов и команд
Вызов метода с атрибутом RemoteEvent - да, 99.999% из главного потока. А вот то, как он будет работать внутри - это уже другой вопрос. Рейдж имеет удивительное свойство. Даже если ты не создаешь явно новые потоки - при использовании асинхронной таски, прямо во время таски он может "перейти в другой поток". Собственно если включить api-thread-debugging, то ты увидишь варнинг посреди таски. Это достаточно странно, ведь асинхронные таски под капотом это можно сказать корутина, и без дополнительных потоков в тредпуле они не должны туда перескакивать, но у рейджа другие планы, либо я не до конца понимаю этот момент(как он работает под капотом). В любом случае, проблема асинхронных скачков по потокам решается так же, как и в любом .net приложении, либо же можно вызывать NAPI.Task.WaitForMainThread() после какого либо await (например запрос в стороннюю api)
