04.12.2009, 11:28
О, я рад что к релизу есть интерес, чесслово. 
Отвечу по порядку поступления вопросов.
Если INI файл во время падения сервера был не закрыт, естессна, он на диск не запишется. Поэтому даже в английской части форума, корефеи скриптинга советуют всем закрывать открытые файлы, или базы данных sqlite, если они более не нужны по ходу скрипта. Самым ярким примером неправильного использования является открытие файла или БД при старте игрового режима и закрытие его при завершении. Именно такой способ часто порождает сбой в записываемых данных. Хотя тут может быть исключение - если INI файл не планируется изменять, его можно открыть в начале мода, а закрыть в конце, или вовсе не закрывать. В этом случае данные не потеряются и не испортятся на диске. Все вышесказанное не касается MySQL, т.к. это отдельно работающий процесс.
Я чесслово, не проводил сравнение скорости чтения и нагрузки на процессор INI ридера/райтера и бд MySQL, т.к. MySQL это все-таки отдельный процесс, а чтение/запись INI файлов выполняет самп сервер. Я думаю, если данных в INI файле немного, INI ридер получит их быстрее, но это только догадки.
все верно, в течение нескольких дней функция записи будет добавлена, в том числе и запись/чтение значений Integer и Float.
Насколько мой опыт подсказывает, для игрового сервера нужны INI файлы небольшого размера, но их кол-во может быть довольно большим. Этим я хочу сказать, что секции в небольших файлах как таковые не нужны и их логически можно разделить на несколько файлов. Тем не менее, если кому-то действительно как воздух нужны секции в INI файлах, я позднее сделаю отдельную версию, т.к. скорость ее работы заметно увеличится.
Это написанный с 0 скрипт, не имеющий отношения к другим подобным библиотекам. Если в механизмах этого скрипта есть сходства с другими библиотеками, то наверное потому, что чтение и разбор данных из файла примерно везде одинаковый, разница только в логике.
PAWN может хранить строки как в обычном виде, так и в сжатом. В обычной строке для 1 символа отводится 4 байта, он может хранить и UTF8 символы. В сжатой строке 1 символ занимает всего 1 байт. Я отдал предпочтение сжатому (бинарному) виду, что ЗНАЧИТЕЛЬНО сокращает расход ОЗУ.
Отвечу по порядку поступления вопросов.Quote:
|
Originally Posted by Serafim_sd
очень интересно...
Quote:
и быстрее ли это чем mysql? |
Я чесслово, не проводил сравнение скорости чтения и нагрузки на процессор INI ридера/райтера и бд MySQL, т.к. MySQL это все-таки отдельный процесс, а чтение/запись INI файлов выполняет самп сервер. Я думаю, если данных в INI файле немного, INI ридер получит их быстрее, но это только догадки.
Quote:
|
Originally Posted by Alone_MAF1A
Мм, а запись в файл как я понимаю отсутствует? Ибо я не нашёл...
|
Quote:
|
Originally Posted by xomka
а секции ини поддерживаются? я еще не видел ни разу библиотеки, которая работала бы с секциями.
это типа переделанный под ини djson, верно? и что за сжатое хранение? подробнее? |
Это написанный с 0 скрипт, не имеющий отношения к другим подобным библиотекам. Если в механизмах этого скрипта есть сходства с другими библиотеками, то наверное потому, что чтение и разбор данных из файла примерно везде одинаковый, разница только в логике.
PAWN может хранить строки как в обычном виде, так и в сжатом. В обычной строке для 1 символа отводится 4 байта, он может хранить и UTF8 символы. В сжатой строке 1 символ занимает всего 1 байт. Я отдал предпочтение сжатому (бинарному) виду, что ЗНАЧИТЕЛЬНО сокращает расход ОЗУ.