Перейти к контенту

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


Рекомендуемые сообщения

 

 

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

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

Ссылка на комментарий

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

Добавлено RayTwitty,

Не стОит.

Ссылка на комментарий

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

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

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

 

 

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

Изменено пользователем Tron
Ссылка на комментарий

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

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

 

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

Ссылка на комментарий

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

Добавлено RayTwitty,

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

Не думаю, что игра вообще будет работать с этим кодом, если каких-то параметров не будет хватать в конфиге.

  • Нравится 1
  • Полезно 1
Ссылка на комментарий

 

 

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

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

  • Согласен 1
Ссылка на комментарий

 

 

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

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

 

 

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

 

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

Ссылка на комментарий

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

 

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

  • Согласен 5
Ссылка на комментарий

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

Ссылка на комментарий

Из описания 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 уже присутствуют данные операторы? 

Изменено пользователем Forser
Ссылка на комментарий

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

 

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

  • Спасибо 1
Ссылка на комментарий

 

 

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

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

Ссылка на комментарий

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

Ссылка на комментарий

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

 

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

Ссылка на комментарий

 

 

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

 

 

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

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

 

 

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

Ссылка на комментарий

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

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

 

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

Изменено пользователем Dennis_Chikin
Добавлено RayTwitty,

Почему кривизна?

В движке ты тоже самое сделаешь, те же функции ведь.

Ссылка на комментарий

Создайте аккаунт или авторизуйтесь, чтобы оставить комментарий

Комментарии могут оставлять только зарегистрированные пользователи

Создать аккаунт

Зарегистрировать новый аккаунт в нашем сообществе. Это несложно!

Зарегистрировать новый аккаунт

Войти

Есть аккаунт? Войти.

Войти
  • Недавно просматривали   0 пользователей

    • Ни один зарегистрированный пользователь не просматривает эту страницу.
×
×
  • Создать...