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

Справочник по функциям и классам

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

 

 

Решил выложить - вдруг кому пригодится

Спасибо. Пригодилось и очень.
Хотя бы потому, что дало ответ на множество вопросов (вообще не освещённых в разделе ХУДа). Осталась лишь одна "непонятка".

 


В чистой версии (от 1С) шрифты Letterica16Russian (и 18Russian)
переназначены на текстуры Letter_16 (18), где русские символы тоже присутствуют. Конкретнее (из fonts.ltx):
[ui_font_letterica16_russian]
texture = ui\ui_font_letter_16_1024
и т.д.
Разницу в именах вижу, пойду разбираться с "кракозябрами".
Ещё раз Спасибо!

 

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

Внезапный такой вопрос: от чего зависит (и где вызывается) :load() для монстров ?

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

 

Upd: эффект явно связан с se_monster, и вдумчивой ревизией я, наверное, и проблему найду. Но сама суть эффекта пока что загадочна.

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

Каковы ограничения движка на количество сохраняемой информации? Каким образом возможно сохранять неограниченные размеры? На сколько упадет скорость загрузки если сохранять где-то порядка 5-15Мб?

 

@Elz, я не об этом.

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

@Карлан, упадет намного (личные наблюдения), ибо чем дальше в лес, тем толще партизаны, сохранять приходится больше. Сейв из оп-2 весит макс мега 4, а там столько всего... А ты предлагаешь по 15 метров сохранять... Ужасно, бро.
Нуок, del

 

 

Пусть пост висит. Сам удалю.

BFG

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

2 Карлан: вообще-то вопрос скорее в тему с++.

Если сохранять/читать фиксированными блоками, причем в один файл - будет практически мгновенно. Построчно/побайтно - медленно и печально. Традиционно медленными являются сами вызовы/служебные операции, действия с 1000 файлов - это очень медленно. С 10000 - невменяемо.  Операция с  1 байтом - не сильно быстрее операции с 100kb.

 

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

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

@Dennis_Chikin, в этом мой вопрос и есть. Каким образом можно нормально сохранить, т.к. на этот самый re-load я это все повесить и хочу. Если нормального варианта не найдется, то тогда буду опять с опорой на xml, откуда при старте буду считывать основной вес данных.

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

Вопрос весьма расплывчат. Даже непонятно, относится ли он к работе с файлами, или к организации данных.

Как бы в идеале, чтобы все было быстро, у тебя должен быть организован непрерывный блок, скажем, полученный через malloc() (ну или массив таки блоков), который ты пишешь/читаешь через read() или pread() / write(), а потом накладываешь структуру, и разбираешь все в один проход.

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

И, да, взятую память ни кому никогда больше не отдавать.

 

Это я тебе как человек, писавший/правивший всякие ata* и прочие burncd с raid'ами рекомендую. И забить на "совместимость" с 49.5битным процессором неведомого производителя, работающим на троичной логике, со старшим байтом в середине слова. :)

 

Но, разумеется, тебе сейчас именно xmlы генерить/парсить и насоветуют, как "идеологически правильный" подход.

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

Каковы ограничения движка на количество сохраняемой информации?

Ограничения всем известны:

1. Сохранение только данных объектов.

2. Каждый объект сохраняет только один кусок данных в виде нетпакета 8 кб, куда также входят и его собственные данные.

Итого чисто теоретически можно сохранить

8 кб * 64 кб = 512 Мб, но на практике конечно в разы меньше. И разумеется всё чанками по нескольку килобайт.

 

Каким образом возможно сохранять неограниченные размеры?

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

 

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

 

На сколько упадет скорость загрузки если сохранять где-то порядка 5-15Мб?

Не знаю, попробуй. Думаю, что при описанном способе не очень сильно просядет. Изменено пользователем Malandrinus
  • Спасибо 1
 

Плагины Total Commander для работы с игровыми архивами:

Архиваторный плагин (для работы с одиночным архивом): link1 link2

Системный плагин (для распаковки установленной игры): link1 link2

 

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

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

Ссылка на комментарий
@Карлан, в движке ты этого не сделаешь, учитывая все имеющиеся ограничения. И только не luabind, а Lua. Почему плох такой вариант? Есть конкретные причины?
 

Плагины Total Commander для работы с игровыми архивами:

Архиваторный плагин (для работы с одиночным архивом): link1 link2

Системный плагин (для распаковки установленной игры): link1 link2

 

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

@Malandrinus, да почему сразу плох? Я в целом новичок, и просто пишу проконсультироваться. Я действительно не знаю как лучше было-бы хранить такие объемы. Теперь узнал, как технически реализовать знаю, спасибо. А луабинд я сказал к тому, что мне надо будет все эти данные в движке читать, либо как-то пересматривать реализацию в сторону полного скриптового управления, пока не знаю.

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

Если имя файла с дополнительными данными будет совпадать с именем штатного сейва с добавкой постоянного суффикса - всё будет как надо - пара: штатный сейв + файл (связанных с ним) дополнительных данных.

 

Пример:

savename1.sav

savename1db.sav

savenameA.sav

savenameAdb.sav

Изменено пользователем 7.9
  • Не нравится 1
  • Согласен 1

всё легко

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

Если "дополнительные данные" связанны с "текущим состоянием игры", а они связанны, этот вариант самый оптимальный. Реализовать (давно) можно с использованием расширения Lua от RvP

А хранить данных надо действительно много...

Изменено пользователем 7.9

всё легко

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

Нет, ну если уж трогать непосредственно движок, то почему бы и не потрогать код сохранения/загрузки ?

Весь вопрос в том, что именно мы хотим сохранять, и как оно выглядит внутри игры. Сохранению контекста объектов и нетпакетам - отказать.

Сделать плоскую таблицу, иметь ее в виду как последовательный кусок памяти, и тупо писать/читать поблочно. Вот прямо в новосозданный сэйв. Ничего лучшего не придумали. Скорость будет выше, чем у копирования средствами системы.

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

Очередной забавный вопрос: se_monster:on_death() / se_stalker:on_death() при каких-то условиях вообще вызываются, или это кто-то просто для красоты добавил ?


Так, я вообще не понял этого юмора...  При net_destroy()/net_spawn(), то есть, при переходе offline/online, у монстров load() тоже не вызывается. Init() -> reload() -> reinit() -> netspawn(). По крайней мере в солянке. Это значит, что все, например, сохраненное в pstor - того...

 

А в оригинале-то оно работает ?

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

@Dennis_Chikin, нет, в оригинале тоже не работает. При переходе оффлайн/онлайн данные биндера очищаются. Не помогает даже

function se_...:keep_saved_data_anyway()
  return true
end
И так не только у монстров :)
  • Спасибо 1
Ссылка на комментарий

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

Да. Каких здесь еще подробностей не хватает ? dc

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

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

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

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

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

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

Войти

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

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

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

AMK-Team.ru

×
×
  • Создать...