Ну вызови SV_CreateAreaNode из SetCollisionBox, но с защёлкой. Типа инициализация при первом обращении
Токо при DeactivateServer не забудь эту защёлку обнулить.
Ну это ясно понятно. Чтобы это дело только один раз вызывалось.
Цитата:
Дядя Миша писал: SetCollisionBox
Как вариант пойдёт, т.к. вызывается из SV_LinkEdict до первого обращения к areanode_t. Тут другая проблема. На момент вызова SV_LinkEdict из pfnSetOrigin, например, ещё недоступна функция IEngineStudio.GetModelByIndex. Ну или я просто не из того места вызывал её. Клиентка вообще грузится сразу при запуске халфы (стимовской). А вот интерфейс студиорендерера наверное грузится уже при загрузке уровня. ХЗ, надо проверить.
Ku2zoff писал: Можно даже не задерживать спаун, а зациклить вызовы тех же pfnSetOrigin, pfnWalkMove и прочих (возвращая NULL грубо говоря), до тех пор, пока не будет возможно их выполнить с нужным результатом.
Я всегда стараюсь исключать такие варианты. Это приемлемо в многопоточных приложениях, когда нужна синхронизация потоков, но если всё выполняется последовательно, то всегда лучше сделать вменяемую проверку
Ku2zoff писал: А вот интерфейс студиорендерера наверное грузится уже при загрузке уровня. ХЗ, надо проверить.
Действительно, модель мира никак недоступна при первых вызовах SV_LinkEdict. Надо либо грузить её прямо в дллке, либо вызывать функции повторно, после её загрузки.
Добавлено 09-02-2017 в 00:15:
Придётся тащить в дллку Mod_LoadBrushModel, а потом выкидывать всё, что не нужно на сервере.
Думаю, что сразу можно выбросить освещение и текстуры. Может быть и видимость. Надо повнимательнее почитать код, какие компоненты модели нам нужны для физики. Ну и грузить придётся опять же из SetCollisionBox.
А можно и не выкидывать. По крайней мере, загрузив освещение, можно заставить правильно работать pfnGetEntityIllum, который вроде бы не работает как надо в халфе.
Добавлено 09-02-2017 в 00:38:
Надеюсь, если запихнуть загрузку карты (и своего собственного массива моделей) в ServerActivate, то всё будет успевать загрузиться раньше спауна и вызовов SET_MODEL и SET_ORIGIN. Хотя наверное нет, и тогда придётся хитрить со спауном, как для игрока в DMC: сначала спауним без SET_MODEL и SET_ORIGIN, а потом уже спауним повторно из ServerActivate с полным набором функций. И да, через SET_MODEL в этом случае можно будет загнать модели не только в движковый, но и в собственный список.
Есть небольшой прогресс. Сделал проверки на загруженность модели мира и ареанодов. Грузить при использовании клиентской IEngineStudio.GetModelByIndex можно смело только из StartFrame, т.к. на момент вызова ServerActivate экспорты клиентки ещё недоступны.
Короче говоря, нужна защёлка, по которой сначала грузим модель мира, сразу за ней ареаноды, а потом заново вызываем SET_MODEL, SET_ORIGIN и SET_SIZE для тех энтить, которым это нужно, чтобы установить правильные размеры. Можно конечно и не вызывать первый раз, а только во второй. Но не знаю, поломается от этого что-то или нет. Вообще, два раза имеет смысл вызывать только SET_MODEL. Первый раз для регистрации модели в движке, а второй раз уже для установки размеров в дллке.
Сейчас уже нет сил на эксперименты. Надеюсь, что за пару недель у меня что-нибудь получится.
Ku2zoff писал: т.к. на момент вызова ServerActivate экспорты клиентки ещё недоступны.
Не экспорты клиентки недоступны, а конкретно эта функция возвращает NULL, потому что на клиент еще не пришло обновление. А так, экспорты клиентки доступны еще до того, как серверная дллка вообще будет загружена.
Итак, я зашёл в тупик. Помимо подмены движковых экспортов, нужно ещё написать собственную функцию SV_Physics_Entity, из которой вызывается обработка физики для энтить (которая естественно никуда не экспортируется). Это всё конечно не проблема, но придётся заводить новые movetype, о которых движок не знает, чтобы он не обрабатывал энтити, а "отдавал" их на обработку дллке.
Ku2zoff писал: но придётся заводить новые movetype, о которых движок не знает, чтобы он не обрабатывал энтити, а "отдавал" их на обработку дллке.
Ты не сможешь завести новые моветипы никоим образом, потому что SV_Physics настроен на вполне конкретное условие: если моветип незнакомый, то вызывается Sys_Error, штоб неповадно было. Ты наверное ксаш смотрел, где нет такого повидения. А надо было заглянуть в ReHLDS или в OSHLDS. Так что новые моветипы ты не заведёшь. И всё же способ перенести физику на сервер есть и он довольно простой. Но я не буду тебе его сообщать, мне хочется чтобы ты сам догадался. Я даже больше скажу - этот метод был вполне успешно опробован в HLFX 0.7, т.е. он стопроцентно рабочий.
Дядя Миша писал: Но я не буду тебе его сообщать, мне хочется чтобы ты сам догадался.
Ох, ну на это может уйти много времени Если способ довольно простой, то я тем более не догадаюсь. Разве что он частично есть в ксашмоде.
Цитата:
Дядя Миша писал: Но я не буду тебе его сообщать
Да это всё для того, чтобы заставить на ксаш перейти. А вот нет. По крайней мере пока. Посмотрим, что будет после релизв 26 апреля. Если моды начнут заводиться искаропки 1в1 как под халфой (то есть cfg, scr и liblist.gam будут правильно парситься) и будет поддержка новой клиентки с SDL, тады да. А если будет винегрет как сейчас, тогда я лучше пожертвую размерами уровней и наличием некоторых фич.
Ku2zoff писал: Если способ довольно простой, то я тем более не догадаюсь
Лёгких путей не ищешь? Ты только подтверждаешь общее правило, что новичок городит сложные и бессмысленные конструкции там, где можно обойтись одной строчкой. Хорошо, дам подсказку. Движок обманывается ровно тремя строчками кода. Никакой огород при этом городить не нужно.
Дядя Миша писал: Движок обманывается ровно тремя строчками кода.
Единственное, что мне пришло в голову, это pev->movetype = MOVETYPE_NONE. Для энтить с этим мувтипом физика не выполняется. Выполняется только тчинк. Но это только одна строчка.
Ku2zoff писал: Да это всё для того, чтобы заставить на ксаш перейти. А вот нет. По крайней мере пока.
Ты всеръез думаешь, что я на ксаш кого-то заманываю? Или ты думаешь, что ты какой-то важный разработчик, которого я задался целью на ксаш заманить? Охренеть у людей фантазии.
Цитата:
Ku2zoff писал: (то есть cfg, scr и liblist.gam будут правильно парситься) и будет поддержка новой клиентки с SDL, тады да.
cfg, scr и liblist.gam - да. Собственно я это давно мог сделать, но не въезжал в этот механизм, да меня он на тот момент не сильно волновал, т.к. я не придавал мультиплееру большого значения - предиктинг всё равно не работал как следовает. А теперь конечно сделаю.
А вот клиентку с SDL я делать пока не планирую. По одной простой причине - через SDL невозможно включить расширенный отладочный GL-контекст, ну по крайней мере с той версией, которую юзает халфа. А он мне нужен. Вероятно есть и какие-то другие ограничения, так что SDL отправляется фтопку. К тому же, как я понял он не даст мне сделать окошко системной консоли выделенного сервера. Если какие-то придурки собирают мод с SDL, то это исключительно их проблемы. Я это говно к себе тянуть не буду. Вон в форке пусть альбатросы тянут на здоровье.