RayTwitty, сделай через lua_register, без луабинда. Правда придётся вручную данные из луа доставать.

Обновил ссылки на репозитории.

В luabind 0.9 частично изменился экспорт и вызовы в скриптах. Вот к примеру:


При вызове в скриптах как стала падать:



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

Zagolski, по-моему ещё в OpenXRay говорили, что новый байнд более требователен к типизации. Я использую Дексовский и вам советую.

Да, пришлось повозиться в скриптах, да и вообще. Очень все строго стало, а где-то и кардинально вызовы изменены. Но хотелось бы разобраться с проблемой, с той, что выше я описал.


Там у него вроде старый 0.7.

А что делает эта функция? По id возвращает гейм-обжект?
Почему тогда не:
CSriptGameObject* dynamic_engine_object(u16 id);
Можно сделать:
void dynamic_engine_object(const luabind::object& o);

Да. Его вполне за глаза. Хорошо вычищен и реструктурирован.

https://github.com/xrOxygen/xray-oxygen/tre...include/luabind

// alpet: получение произвольного объекта движка по ID или game_object


Спасибо большое, помогло!

Недавно закончил с клиент-сервером, эгейн. Со всеми своими предыдущими вопросами разобрался. В итоге вырезал целиком весь код из xrNetServer, вырезал как класс xrServer со всеми вытекающими, существенно упростил клиент-серверную систему выбросив оттуда всё не требующее синхронизации, перефигачил ивенты (как движковые (это отдельная история), так и серверные (тут частично)) требующие синхронизации. Также выхолостил IGame_Level оставив только один указатель (его требует один объект в CLevel). Полностью снес все, что относилось к типам игры, в том числе из серверных объектов (поставил заглушки, чтобы не нарушать архитектуру спавна). Отсюда очевидно, что повысилось быстродействие. Протестировал все на ТЧ и на ЗП, привел код к идентичному виду, о чем я и говорил здесь ранее неоднократно.

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

Насколько?

Карлан, поделись немного опытом, а ьо я устал понемногу его вычищать.

Лучше там ничего не трогать в сервер-клиенте, если не спец. Я у себя "вычистил", на первый взгляд вроде все хорошо, но теперь спонтанные ошибки время от времени выскакивают, которые никак отловить не могу. Что примечательно, субъективно скорости совсем не прибавилось. И даже время компиляции всего на 5% снизилось, несмотря на удаление всего мультиплеерного кода.

Zagolski, у меня тоже нет мультиплеера, работать вполне стабильно.

SkyLoader, не настолько, чтобы заниматься этим ради быстродействия . Цифры не помню, ивенты смотрел стандартным профилированием, если хочешь скажи сколько сервер жрет у тебя, у меня он уже ничего не жрет, так как его нету, и это не самая большая часть всей эпопеи.
ForserX, конкретнее спрашивай, у меня информации очень много по всем трем (я так выделил по своей версии) направлениям, хоть цикл статей пиши, но этим я точно заниматься никогда не буду.
Zagolski, что ты вычищал и какого плана ошибки?

Карлан, самая медленная часть и её альтернатива. Если можно, с примером на xray.

ForserX, я довольно мало занимался замерами, мерил сервер (ну потому-что там тупо дефолтный таймер), и выборочно некоторые ивенты, поэтому не могу в полной мере ответить на вопрос. У меня цель была разобраться поглубже в одной из фундаментальных систем движка, а не повысить быстродействие. О нем я упомянул просто потому-что видно общую картину оздоровления, я принял кучу всяких мер, даже все не вспомню, это и рефакторинг менеджмента пакетов, и вырезание ивентов (=> увеличение стабильности), и вырезание кучи ненужных крутящихся событий, уменьшение порций передаваемой информации, больше чем на 50% вычистил загрузку, просто писал различный оптимизирующий код. Что из этого в большей мере помогло, что в меньшей сказать не могу, не замерял, просто не интересно, извини. Сейчас у меня в голове более менее все структурировано выстроено именно на основе опыта, если бы была х64 платформа можно было бы задействовать ресурсы, кардинально переделать пару моментов и просто оторваться от земли по некоторым вопросам давно набившим оскомину (например там всякая муть с памятью за которой я пристально слежу на х32 движке чтобы не было переполнений через каждые два часа игры). Есть еще много идей по реформированию серверной части объектов, там тоже чудовищное количество всякой ерунды (в идеале вообще довести это все до состояния полной замены этой системы, тут тоже у меня есть концепция). По симулятору тоже есть мысли. По скриптам тоже в чем проблемы я писал выше. В сетевухе нашел тоже косяки, но ей вроде никто не занимается, я думаю всем пофиг на это. В конце концов все равно я уже упираюсь в форматы (подпираю всякими заглушками), и нужны люди, которые будут писать сдк и компиляторы подо все, что я делаю, иначе от этого всего толку мало в итоге выйдет. Поэтому я и написал, мало-ли кто копается также как я, можно было бы обменяться опытом, может есть более крутые решения/идеи, чем я там напридумывал. Без этого всего эти взоры на горизонты так ими и останутся. Слов можно много понаписать, была-бы от них польза .

Возьми порт от окси. У нас х64. Всё рабочее.

С объектами в ClientSend. Бьются пакеты судя по всему, обычно при сейве/загрузке, хотя может и само по себе упасть на "холостом ходу". Как уже говорил, ошибки редкие и спонтанные, непонятно из-за чего. Но стабильность явно пострадала. Вычищено много чего, xrServer, скажем так, "похудел" на 75%.

ForserX, зачем?
Zagolski, можешь свой xrMessages показать, мне было бы интересно посмотреть что ты там убрал, я где-то в районе 5 событий так и не доковырял окончательно нужны они там или нет (и в каком виде нужны). По твоей проблеме, как ты догадываешься, не смогу подсказать, но я переделывал сохранения и у меня все без проблем работает, в остальном это использует только апдейтер который выбирает экшн на серверной части, скажи хотя-бы ивент на котором у тебя игра сыпется, возможно ты где-то вычистил часть инфы из пакета на клиенте и не вычистил на сервере, или наоборот (не всегда явно), или не соблюдаешь очереди обработки (это весьма важно!), перепроверь. Специально у себя посмотрел в этих местах, стоят какие-то выводы в лог, но вообще уже не помню что там и зачем, давно очень делал видимо. Я когда загрузку переделывал там довольно много всего неявного было, но было довольно интересно установить все взаимосвязи .

ForserX, хорошо, а с ТЧ мне как быть? К тому же х64 это не вещь первой необходимости для меня на данном этапе, меня гораздо больше интересует поддержка сдк и компиляторов, чтобы вплотную заняться серверной частью объектов, прям руки чешутся . В итоге конечно все упрется в память (при моей концепции частичного изменения системы), и вот тут уже будет очень желательна х64.

Карлан, тебе портировать?

ForserX, спасибо, но зачем мне х64, когда, при текущем раскладе, я не буду переделывать серверную часть объектов? Мне х64 нужен вынужденно, а не чтобы было, и нужен он только после определенного этапа работы, который я без подгонки сдк и компиляторов делать точно не буду (или буду, но это будет мерзотненько на заглушках и прочих костылях ). У меня и так уже все по швам трещит от вынужденной надобности сохранения совместимости, с сдк и компиляторами я бы уже давно встряхнул этот гадюшник (и не только в объектах), а не сидел бы тут разглагольствовал.

Карлан, если захочешь мои руки для порта в х64 - пиши. Помогу.

ForserX, я не против, если есть желание, бери и вперед. Отдельной веткой.

Дошли руки проверить, у меня прирост в районе 40%, стандартный движок компилиться не менее 25 минут, мой не более 15 (я понимаю, что дело еще в конфигах проектов и еще много в чем, но все же).

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

Карлан, на самом деле, это достаточно интересно. Больше всего мне интересен пункт производительности. Расстраивает то, что она достигнута вырезанием сетевой части игры

Xottab_DUTY, сетевая часть на сингл в плане производительности вообще не влияет. Практически никак. Вырезать мультиплеер для повышения производительности это пустая трата времени. Влияет другое, если заботит только производительность, то можно смело оставлять сетевую игру и работать только над тем, о чем я выше говорил. Рецепт тот же, только сетевуху загнать в отдельное место, а сингл переделать, и все.

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

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

Маландринус когда-то хотел менять систему серверный-клиентский объект. Перевести это в состояния объектов и расширить их. Например сделать 3 состояния:
- оффлайн(не грузится модель и тд и тп),
- онлайн(модель, физика, все такое),
- инвентарь(снова нет модели, физики, может даже ид отнимать).
Делали что-нибудь в этом плане?

Идею с инвентарным состоянием часто проворачивают в скриптах, например удаляют из ящиков предметы при выходе в оффлайн и хранят просто строчку вида kolbasa:2;vodka:1;

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

Проблему с ClientSend у себя решил повесив его обратно на M_CL_UPDATE.

Не знаю, у меня весь двиг 10 минут компилится на i7-2600K.

У меня 5 минут. Минимум. Что ваниль, что окси.

Кошмар. Как же можно так жить?
У меня ваниль с холодного старта секунд 10, при быстрой загрузке секунды три. Смею предположить, что у тебя совсем древнее железо...
А вот по поводу накопителей, то с ССД грузится заметно быстрее, чем с харда. Раза в два точно. Просто у меня они оба стоят, и копии сталка там и там, поэтому разницу вижу.

Замучила ошибка, никак не могу понять, в чем проблема. Периодически появляется, если в лагере между сталкеров стоять. Какой-то конфликт между игроком и одним из неписей, проблемы с костями или анимацией. Что это может быть?

Код

stack trace:

0023:5C7002AF xrGame.dll, CIKLimb::get_start(), x:\trunk\xray\xr_3da\xrgame\ik\iklimb.cpp, 1253
0023:5C6FE1AE xrGame.dll, CIKLimb::BonesCallback0(), x:\trunk\xray\xr_3da\xrgame\ik\iklimb.cpp, 1266
0023:5CBE17A3 xrRender_R4.dll, CKinematics::CLBone(), x:\trunk\xray\xr_3da\xrrender\skeletonrigid.cpp, 133
0023:5CBE16DE xrRender_R4.dll, CKinematics::BoneChain_Calculate(), x:\trunk\xray\xr_3da\xrrender\skeletonrigid.cpp, 201
0023:5CBE1EC3 xrRender_R4.dll, CKinematics::Bone_GetAnimPos(), x:\trunk\xray\xr_3da\xrrender\skeletonrigid.cpp, 157
0023:5C4FE146 xrGame.dll, CEntityAlive::get_last_local_point_on_mesh(), x:\trunk\xray\xr_3da\xrgame\entity_alive.cpp, 969
0023:00C6327C XR_3DA.exe, Feel::Vision::o_trace(), x:\trunk\xray\xr_3da\feel_vision.cpp, 166
0023:00C63A8A XR_3DA.exe, Feel::Vision::feel_vision_update(), x:\trunk\xray\xr_3da\feel_vision.cpp, 152
0023:5C2C111B xrGame.dll, CCustomMonster::eye_pp_s2(), x:\trunk\xray\xr_3da\xrgame\custommonster.cpp, 588
0023:5C2C0819 xrGame.dll, CCustomMonster::Exec_Visibility(), x:\trunk\xray\xr_3da\xrgame\custommonster.cpp, 602
0023:00C6B819 XR_3DA.exe, mt_Thread(), x:\trunk\xray\xr_3da\device.cpp, 190
0023:5CD28B6C xrCore.dll, thread_entry(), x:\trunk\xray\xrcore\_math.cpp, 349
0023:766FAB35 ucrtbase.dll, crt_at_quick_exit()
0023:757962C4 KERNEL32.DLL, BaseThreadInitThunk()
0023:77090FA9 ntdll.dll, RtlSubscribeWnfStateChangeNotification()
0023:77090F74 ntdll.dll, RtlSubscribeWnfStateChangeNotification()

Отлаживал процесс загрузки уровня, обнаружил стопор на стадии "Загрузка формы объектов". Начал копать и увидел, что всё это уходит в OPCODE. Мы передаём ему данные уровня, а они довольно большие, поэтому эта стадия проходит долго. Надо ускорить. Кто-нибудь пробовал колдовать с OPCODE? Или вообще на другую библиотеку уйти?

У формы объектов есть же другопоточная загрузка из коробки. if(!strstr(Core.Params, "-mt_cdb"))
Только надо чуток переписать, чтобы не ждать другой поток, а делать что-нибдуь полезное

Никакой прибавки скорости от -mt_cdb не увидел. Может там что-то и есть, но на глаз не заметно.

Сейчас основной поток ждет, пока цформ загрузится. Я ж написал, надо чуток переделать

abramcumner, кстати да, рассинхронизирую их на днях.

Видел, видел. Поэтому и спросил про сам OPCODE. Почему-то не подумал спросить про то, как сделать так, чтобы основной поток занимался чем-то полезным)

while sleep(5); убрать Только надо убедиться, что цформ никто не будет в это время использовать.

Opcode варит AABB дерево %facepalm%
Можно это исправить, но за счёт увеличения размера коллизии левела.

Понятное дело, что варит.

А можно поподробнее?

Xottab_DUTY,
Сварить заранее, в компиляторе.

-StalkMen-, а... Интересный вариант)

Тем более, на сколько я помню, при просчёте лайтмапов он там варится

Итак, нужна ваша помощь. При порте в последнюю 2017 студию, xrsound стал требовать _CrtDbgReport символы. Временно цепанул либы от 2015 студии, из-за чего у большей части юзеров перестанет всё работать. Нигде привязки к этим символам в проекте не нашёл. Может есть у кого идеи, как от этого избавиться?

Neo][,
Там для видимой геометрии, цэ не то

ForserX, функция юзается внутри crt(в xutility, random, etc). А что значит временно цепанул либы от 2015? И покажи оригинальное сообщение об ошибке.


-StalkMen-, не ковырял загрузку уровня в исходниках, но, на сколько я помню по реверсу, именно сгенеренный в компиляторе level.cform и грузится на этом этапе.

В этом и проблема Сгенеренный level.cform просто набор треугольников, из него OPCODE строит свое дерево. Xottab_DUTY хочет ускорить построение этого дерева, -StalkMen- предлагает в level.cform хранить сразу сериализованное дерево OPCODE.


Откатиться с последней версии на 15.6.7. 15.7.1 - еще косячная.
Я бы сказал, что не пересобрали новой студией какую-то lib. OpenAlSoft?
Можно попробовать включить в настройках линкера вывод информации о ходе линковки типа "Link/General/Show Progress"(вроде еще что-то было). Можно будет увидеть, чем занят линкер во время ошибки.

abramcumner, так и я о том же... пытаюсь выяснить почему


Added:
Скорее путанница возникла из-за того, что я в исходном сообщении упомянул просчёт освещения. Имел ввиду именно процесс построения cdb для уровня. Забыл, что там дважды строится cdb.