_Призрак_

Используй не game_graph():vertex, а game_graph().vertex (через точку). В этом случае ты делаешь не вызов функции, а обращение к полю объекта

Скорее всего уже задавали, но беглый поиск не помог. Где и когда можно посмотреть это чудо? Я вижу кто то был на закрытом показе - будут ли еще показы и как на них попасть? Трейлер очень понравился

@dsh vector() 1 в 1 транслируется в вызов конструктора FVector (ну или какой там класс). Если в конструкторе по умолчанию (т.е. FVector()) не инициализируются поля то значит там в любом случае будет мусор, хоть ты создал вектор через C++, хоть через Lua. А то что у тебя на одном движке нули, а на другом случайные числа то это легко объяснить - в обоих случаях у тебя мусор в переменных, просто в одном случае у тебя повезло словить 3 нуля, а в другом нет. Или на одном была отключена оптимизация (в этом случае все переменные инициализируются нулем). Почему могло получиться случайно 3 нуля? Потому что если посмотреть на память приложения, то количество нулевых байт будет в сотни раз больше чем любых других из-за специфики программ @drksnc Да, асемблерная вставка означает: pClass->PHGetSyncItem(0)

Тут не все так просто. Если просто передавать позицию и применять ее то движения будут дерганными из-за задержки сети. Для того чтобы это заработало так как нужно, нужно ковырять как в классе CActor реализована интерполяция (файл Actor_Network.cpp). Скорее всего ее можно будет ±копипастой применить к обычным НПС.

@UnLoaded, Скорее всего раньше в скобках было какое то условие, а потом программист поленился удалять if и просто оставил true в качестве условия. Здесь нет никакой магии (Кроме области видимости, но это скорее всего не причина такой конструкции)

Приходит, но все же я бы попросил бы определение "нормально сделанных ботов". ​ Тут я могу поспорить. Да, можно просто сказать что количество пакетов будет большим, но мы можем посчитать насколько. Каждого НПС можно представить как игрока, за которого играет компьютер. Соответсвенно большое число пакетов = (число ботов + игроков) * среднее число отправляемых пакетов в секунду. Итого если мы имеем кооперативное прохождение (сколько это человек? 2-4?), мы можем без проблему заполнить карту еще 30 ботами (а скорее всего и большим числом) без проблем с сетью. К тому же, насколько я знаю, в планах ребят которые делают кооп (или было в планах) - введение системы алайфа в мультиплеер. У нас есть сервер который обсчитывает всех(?) ботов в онлайне, но каждому клиенту отправляет информацию только о НПС в радиусе алайфа. Сколько у нас на пике ботов может быть в радусе алайфа (возьмем стандартный в 150м)? 20? 30? Не думаю больше. Вот и вся проблема большого числа пакетов. Поправьте если я не прав. Какие? Просто если мы говорим про диалоги/передача предметов, то это не является большой проблемой для исправления. Ну для обычных игроков задержки тоже гадят. Поэтому у них происходит предсказывание траектории движения и т.д. Тоже самое включаем для мобов и все, проблема решена.

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

Для того чтобы определить есть ли значение в массиве его в худшем случае нужно полностью перебрать (сложность O(n)), а в случае хеша алгоритмическая сложность точно ниже (скорее всего что то типа O(logn), но я точно не знаю, зависит от реализации, сужу по тому как это сделано в других языках/системах. Есть базы данных где доступ осуществляется вообще за константу)

А можно узнать сакральный смысл двойного arg? Почему не local t = arg or {...} ?

А можно ссылку на бенчмарки, исследования по этому поводу?

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

std::function не подойдет? Или я не понял проблему

Это не ответ на мой вопрос. Elz написал что модульность каким то образом связана с производительностью. Про удобство разработки у меня вопросов нет

Может я что то не понимаю, но как модульность связана с производительностью? И что вообще в твоем понимании модульность?

А зачем?

Прости? Очень интересно высказывание, почему ты так решил?

Возвращаясь к вопросу о получении имени сохранения. Есть способ проще. Даже два. 1) Мы можем сохраниться двумя способами - через меню или через консоль/квик_сейв. Через меню мы можем отследить (как это сделать все понятно надеюсь). А в игре можно попробовать отследить статик, который показывается после сохранения - на нем как раз написано имя сохранения. Сложность алгоритма минимальна 2) Можно при старте игра при помощи FS класса считать все файлы в папке saves (точнее считать имена файлов и дату изменения). Как только мы в биндере актора происходит вызов метода save() то мы взводим флаг и на следующем апгрейде опять просматриваем папку с сохраниениями на предмет изменений. Сложность алгоритма зависит от количества файлов в папке

klesov1407 Можно. Но это затратно и по времени написания кода и затратно по ресурсам процессора

Во первых почитай про область видимость переменных. Например такой код выдаст ошибку: local a=1 if a==1 then local b =15 end b = b+1 С руганью на то что мы не создали переменную b. Почему? Мы создали ее в условии, но эта переменная удалится при выходе из условия. То же самое с циклами и функциями. Можно сделать глобальную переменную, которая будет видна везде. Тогда нужно просто не писать local перед именем переменной. Но это плохой стиль программирования и может вызвать колизию Так же я не уверен что у тебя при старте будет инициализирована переменная my_flag_1. Сделай так:

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

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

local tbl = { ["ammo_9x18_ap"] = 3, ["wpn_pm"] = 2 } check_items(tbl) function check_items(t) db.actor:iterate_inventory( function (dummy, oItem) if t[oItem:section()] and t[oItem:section()]~=0 then t[oItem:section()] = t[oItem:section()]-1 end end ,nil) for k,v in pairs(t) do if v!=0 then return false end end return true end

Artos Вы верно шутите. Вместо красивой прогулки по саду, длинной в 100 метров, вы выбираете путь через горы. Зачем нужно использовать нет-пакеты, устанавливать самописные каллбеки, вместо использования кода на 2 строки, который предложил вам Charsi?

Но у остальных же все работает. И у меня работало, хотя и с ПДА. Почему тебе не запомнить класс окна и не получать его каждый раз?

Статик нужно деаттачить при закрытии инвентаря. При закрытии вызывай inventory_wnd:DeattachChild(wnd)