Редактирование движка X-Ray

[Карлан 1 050]

 

 

  RayTwitty писал(а):

Бро, тебе видос записать? Или может сам почитаешь про отличие между "Построением" и "Перестроением"?

Видос было бы неплохо. Отличия я знаю, у меня комп такой деревянный что-ли? Ни разу за полминуты не строил на релизе, мне было бы действительно интересно посмотреть.

[Карлан 1 050]

@RayTwitty, хе, видимо разные машины, у меня уже двадцать пятая минута пошла, в принципе могу тоже пруфануть также, только не знаю будет ли кому прикольно двадцать минут в монитор втыкать.

[Карлан 1 050]

@-StalkMen-, ~110

[Карлан 1 050]

@-StalkMen-, у меня тоже с /Zi, но оптимизация включена (/О2).

Слишком избитая тема, давно пора ее выложить, а то регулярно всплывает:

 

header:

bool exist(LPCSTR S, LPCSTR L, bool section_only);

bool exist(LPCSTR S, LPCSTR L, bool section_only);

cpp:

bool CScriptIniFile::exist(LPCSTR S, LPCSTR L, bool section_only) { if (inherited::section_exist(S)) if (section_only) return true; else if (inherited::line_exist(S,L)) return true; else { Msg("! ERROR: Can't find line [%s] in section [%s]", L, S); return false; } else { Msg("! ERROR: Can't find section [%s]", S); return false; } }

bool CScriptIniFile::exist(LPCSTR S, LPCSTR L, bool section_only)
{
if (inherited::section_exist(S))
if (section_only) return true;
else
if (inherited::line_exist(S,L))
return true;
else
{
Msg("! ERROR: Can't find line [%s] in section [%s]", L, S);
return false;
}
else
{
Msg("! ERROR: Can't find section [%s]", S);
return false;
}
}

Заменяем все функции где THROW3 на подобное:

float CScriptIniFile::r_float (LPCSTR S, LPCSTR L) { bool exist = this->exist(S, L, false); if (exist) return (inherited::r_float(S,L)); }

float CScriptIniFile::r_float (LPCSTR S, LPCSTR L)
{
bool exist = this->exist(S, L, false);
if (exist)
return (inherited::r_float(S,L));
}

Есть одно исключение, его пишем так:

u32 CScriptIniFile::line_count (LPCSTR S) { bool exist = this->exist(S, NULL, true); if (exist) return (inherited::line_count(S)); }

u32  CScriptIniFile::line_count (LPCSTR S)
{
bool exist = this->exist(S, NULL, true);
if (exist)
return (inherited::line_count(S));
}

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

 

Кому не понятно - при ошибке функция ничего не делает, просто скидывает инфу в лог об ошибке, какую - очевидно.

И еще не знаю кому как, но я просто пишу типа IC float r_float(LPCSTR S, LPCSTR L) {return this->exist(S, L, false)?inherited::r_float(S,L):0;}

[Карлан 1 050]

 

 

  RayTwitty писал(а):

Не при всех вариантах выполнения кода, будет возращен правильный результат (float, bool т.п.). Грубо говоря - нет дефолтного значения для возврата, если параметр не найден. Не думаю, что игра вообще будет работать с этим кодом, если каких-то параметров не будет хватать в конфиге.

Да, я думаю это все понимают, нужно возвратить дефолтный тип значения, я же указал пример в инлайновой функции:

 

 

  Карлан писал(а):

return this->exist(S, L, false)?inherited::r_float(S,L):0

 

@Полтергейст, ничего не произойдет, скинется инфа в лог, но движок не этими функциями читает конфиги, функции чтения конфигов зашиты в xrCore, в данном скрипте функции сделаны для экспорта, и я явно указал в каком классе следует добавлять подобные функции. Не думаю, что стоит подобное делать и в xrCore, так как игра валится еще до самого запуска, и получается если эррор в этом случае убрать, то в теории времязатраты увеличатся.

[Карлан 1 050]

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

[Карлан 1 050]

@Forser, это пространства имен луа, они присутствуют еще со времен расширений луа от RvP, здесь разумеется тоже есть, как и крутой C API, с помощью которого можно наладить отличную взаимосвязь между *.script и *.dll.

 

А я стукну себя пяткой в грудь, дернул в полном функциональном виде ui-интерфейсы из ЗП в ТЧ.

[Карлан 1 050]

@Полтергейст, utils.cfg_get_number в целом решает эту задачу (конечно нагроможден, но я использую), получается некий аналог READ_IF_EXISTS, на который тоже можно обратить внимание. Бритва Оккама.

[Карлан 1 050]

 

 

  RayTwitty писал(а):

Не вижу смысла в данной модернизации.

 

 

  Dennis_Chikin писал(а):

над кривыми функциями движка.

Еще один триллер?

 

 

Меня вот больше интересует, кто-то сделал нормальный экспорт всяких массивов? Вот которые в iterate_* или *_count(), что суть одно фаберже. Никто не делал массовый экспорт подобных массивов, там по сути один стейт надо возвратить и все, но я не пробовал пока. Разумеется в ассоциативном виде.

[Карлан 1 050]

@Dennis_Chikin, как это? alpet же сделал, вот там примерно так, я для себя обвязал сделав удобный и понятный интерфейс. Для всего сверх удобного надо дофига писать на  c api, я бы может и писал, но я не знаю как нормально (я делаю так, как нормально по моему), тут вот в теме еще не один любитель городить костыли, чего же ты хочешь? В любом случае можешь показать пример.

[Карлан 1 050]

@Forser, ты проявляешь чудеса компетентности:

 

https://msdn.microsoft.com/ru-ru/library/dn502518.aspx

 

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

[Карлан 1 050]

@HESH, я ж любя, никого не хотел задеть, я на том же уровне... Сударь. Так что извольте.

 

 

  HESH писал(а):

Да и не прибедняйтесь, вы на порядок больше меня знаете в плане ковыряния движка.

Здесь дело не в том кто сколько знает, дело в том, что это справочная информация доступная в понятном и подробном виде на русском языке.

[Карлан 1 050]

@Forser, @HESH, он же на геймру уже давно выложил, я где-то полгода назад смотрел, что там интересного?

[Карлан 1 050]

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

 

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

Изменено 5 Ноября 2015 пользователем Карлан

[Карлан 1 050]

@Graff46, да, вполне возможно, и скорость кстати говоря выше ожидаемой, я себе сделал несколько функций которые перегружает и ltx и xml, местами сделал нормально, но что-бы все сделать по хорошему надо там подольше посидеть, а мне без острой надобности пока. Я тут, к примеру, когда-то писал о пространстве для работы со строками, которое я себе добавил, вот по аналогии можно с чем угодно поступить в подобном роде. Но в некоторых местах это будет весьма нетривиальное занятие.

вот тут кое-что можно прочесть http://pastebin.com/dXjwaFLv, в принципе по вектору развития не много прибавилось, сейчас в основном работаю над оптимизацией того что есть, то есть убираю все уродские скриптовые костыли с помощью движка, количество ВСЕХ скриптов уже сейчас меньше чем в среднестатистическом глобальнике, то есть вся обвязка уже достаточно ясно видна, хоть и есть еще около 10 кандидатов на ликвидацию .

[Карлан 1 050]

 

 

  SkyLoader писал(а):

Причину бага с глитчами камеры в ЗП я так найти не смог.

Такова селяви.

 

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

[Карлан 1 050]

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

[Карлан 1 050]

@CAHCAHbl4, на оригинале, доказано практикой, максимальное количество объектов 16580355, сильно сомневаюсь что не хватит для чего-то. То что хочешь сделать ты на раз-два не выйдет.

[Карлан 1 050]

"86 раз используется ID()."

 

" не понял как скажется увеличение пространства памяти ObjectProperties"

никак не скажется, можешь сразу объем пакета пару гигов сделать, тоже нормально.

[Карлан 1 050]

@Graff46, посмотри функцию CTexture::LoadImpl, сделай загрузку из других мест, но не забывай добавлять пути в конфиг, у меня работает корректно, но не текстуры, я в общем о принципе, текстуры я не пробовал.

 

А как пользоваться новыми методами надо в движке и смотреть, ну либо по старинке "вслепую" 150 способов и все в логи.

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

Изменено 22 Ноября 2015 пользователем HellRatz