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

[RayTwitty 486]

@Карлан,

~1:58

Изменено 7 Октября 2015 пользователем RayTwitty

[User_X.A.R26 261]

 

 

у меня были проблемы с его компиляцией под х64

Можно было просто взять оригинальные, не правленные кривыми руками GSC никем, сорсы BugTrap. Там есть нормальный конфиг для x64

[Карлан 1 049]

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

[HESH 64]

@Дизель, самая "страшная" защита на сегодня - Denuvo, используется, если мне не изменяет память, только в BFHL.

[Tron 53]

Можно было просто взять оригинальные, не правленные кривыми руками GSC никем, сорсы BugTrap. Там есть нормальный конфиг для x64

Нет, это как раз уже новая версия. - см. дату последнего коммита.

Как я понимаю, у них была ~эта(создание страницы 29 июня 2006 г)

 

 

​Edit:Добавлена дата

Изменено 7 Октября 2015 пользователем Tron

[-StalkMen- 159]

@Карлан,

Сколько у вас весит pdb от xrGame?

[Карлан 1 049]

@-StalkMen-, ~110

[-StalkMen- 159]

Странно, у нас пдбшник занимает почти 1 ГБ!
ЗП, vs 2013, с ключом /Zi, релиз без оптимизации...

Это крайне затрудняет компоновку

 

Кому не трудно, поделитесь своими результатами.

[Карлан 1 049]

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

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

 

header:

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;
}
}

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

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));
}

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

 

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

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

[Полтергейст 37]

 

 

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

Для скриптовых вызовов это полезно, но что будет, если подобное произойдёт при чтении параметров движком из system.ltx?

[Карлан 1 049]

 

 

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

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

 

 

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

 

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

[RayTwitty 486]

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

 

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

[Карлан 1 049]

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

[Forser 47]

Из описания LuaFix RvP:

--Дополнительные\возвращенные пространства имен

        os
        io
        package         --так же тут находится глобальная функция require
        debug

Из кода RvP:

#define LUA_IOLIBNAME	"io"
LUALIB_API int (luaopen_io) (lua_State *L);

#define LUA_OSLIBNAME	"os"
LUALIB_API int (luaopen_os) (lua_State *L);

#define LUA_DBLIBNAME	"debug"
LUALIB_API int (luaopen_debug) (lua_State *L);

#define LUA_LOADLIBNAME	"package"
LUALIB_API int (luaopen_package) (lua_State *L);

И:

int open(lua_State *L){
    luaopen_os(L);
    luaopen_io(L);
    luaopen_package(L);
    luaopen_debug(L);
...
return 0;}

В 1.0007:
 

static const luaL_Reg lualibs[] = {
  {LUA_IOLIBNAME, luaopen_io},
  {LUA_OSLIBNAME, luaopen_os},
  {LUA_DBLIBNAME, luaopen_debug},
  {LUA_LOADLIBNAME, luaopen_package},
   ...
};

Вопрос: как я понимаю, в 1.0007 уже присутствуют данные операторы? 

Изменено 8 Октября 2015 пользователем Forser

[Карлан 1 049]

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

 

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

[Полтергейст 37]

 

 

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

Ничто не мешает сделать эти функции под другими именами. Оставить оригинальный r_float, а добавить не вылетающий r_float_safe.

[Карлан 1 049]

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

[Dennis_Chikin 3 658]

utils.cfg_get - они слегка не для этого, во-первых; во-вторых - это таки действительно надстройка над кривыми функциями движка.

 

И безопасная движковая функция, не требующая 100500 проверок, таки имеет смысл. Вот что и как она возвращает - имеет смысл подумать. Возможно, 2 значения, либо переменная, в куда читать - в аргументе, а возвращает - как в C - количество элементов.

[Карлан 1 049]

 

 

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

 

 

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

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

 

 

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

[Dennis_Chikin 3 658]

ini_file() ... section_exist() ... line_exist() ... r_что-то-там() - кривизна неземная.
Вместо того, чтобы просто вернуть успешность.
Про строки - вообще см. п2.0 правил.

Что до триллеров, то на дворе шел 2015 год, однако мы до сих пор не имеем стабильных экзешников, в которых есть просто функция save( ptr )/load( ptr )

 

"Почему кривизна?" - ты действительно считаешь, что 4 скриптовых операции на чтение ОДНОГО значения, с альтернативой упасть с совершенно невнятным логом  - это нормально ?

Изменено 10 Октября 2015 пользователем Dennis_Chikin