Evgeni_Degerev

Очень бы хотелось увидеть tar/gz архивированние скриптовыми функциями, а также работу с gz-иповаными файлам не лету Тестировал систему акквов в ревизии 17xx (мб 1746?) встроенную систему аккаунтов с большими обьемами данных тогда и обнаружил потерю производительности при работе с БД. С того времени было применено не меньше 2х ревизий оптимизаций встроенной БД, точно не помню, но раньше при запросе/установке данных через (get/set)AccountData поиск аккаунтов проходил в цикле проверяющем соотвествие каждого аккаунта, что позднее было заменено на sql-запрос. И еще как минимум одна ревизия, изменяющая запросы чтения/записи.

http://bugs.mtasa.com/view.php?id=5613

Возможно я был не так понят, попробую внести ясность: - система может работать полностью независимо, интеграция создана только для совместимости с ресурсом admin, ему подобными и системой привелегий MTA. Разумеется, однако данные аккаунта полностью загружаются в память при первом обращении к нему, далее идет простое обращение к таблице, аккаунт освобождается если игрок вышел с сервера. Недостатком является то, что если к аккаунту было обращение в тот момент, когда в него не был залогинен игрок он не будет выгружен, а только синхронизирован с диском по таймауту. тесты эквивалентов getAccountData / setAccountData , вызываемых удаленным скриптом показывают скорость в 2-3 раза быстрее ( чтение в 2, запись в 3 ... если не ошибаюсь ) у меня расчет на то что http будет использоваться только администраторами, в противном случае привелегия подключения через http будет доступна всем игрокам. С момента создания моей системы было несколько коммитов улучшающих встроенную систему аккаунтов, однако переходить не неё обратно не вижу смысла. ИМХО можно улучшить сущствующую систему, создав аналог executeSQLQuery для internal.db, конечно, сделав его разрешенным только для группы . Т.к бы не помешали бы в ней запросы поиска/обновления групп данных, а также BEGIN,END,COMMIT и т.д. Истину глаголишь... Есть одна глупая идейка для встроенной БД - можно создавать таблицу вида < TEXT ACCOUNTNAME, TEXT SERIAL, TEXT REGISTER_IP, BOOL AUTOLOGIN, BLOD ACCOUNT_DATA > и хранить в ACCOUNT_DATA все данные игрока в виде JSON, чтобы не увеличивать количество записей в таблице. Не помню точно как выглядит структура internal.db, да и нутром чую что не все так гладко как написал.. но а вдруг? PS: Прошу строго не судить за слишком явный бред. PSS: очень нехватает spoiler или offtop bb-кода. Добавлено: Это не метод, а лишь один из вариантов решения проблемы sqlite, в том виде в каком понял. Что идейка с уменьшнием числа записей глупая писал еще ранее, т.к сомневался Кроме того эта идея является взаимоисключающей с предложением расширенного доступа к БД.

Надеюсь, что в релиз 1.0.5 вKлючат юникод

У меня в моде сделана полная имплементация всех функций данной системы и полная интеграция с ней. За основу брал доработанный ini-враппер, кроме того включил ряд возможностей миграции ( в/с sqlite ) и добавил туда жалкое подобие структурированных запросов Стандартную систему перестал использовать после 3х-кратной полной потери данных. Воспроизвести проблему не удалось.

Ах да, одну вещь я забыл упомянуть. Способ с getGameSpeed я проверил сразу же, как только заметил, что кто-то балуется со скоростью, да только это ничего не дало: функция все время возвращала 1, то есть тут дело не в скорости игры, а, как бы сказать, в быстродействии что ли... Например можно сделать через помощью махинации с xxx.dll ( не уверен ) когда-то, когда ставил 2х ядерный ЦП без переустановки OS получил такой баг в гта - ускорение всего вообще не понял как это произошло ( игра потре:Oла 50% цп ), но вышенаписанная библиотека сыграла там не последню роль. Имя dll-ки не d3d9 название афишировать тут не буду. Если ВСЕ в т.ч и скриптинг работает быстрее, почему бы не устроить проверку с помощью setTimer и getTickCount?

Знаю нескольких человек, которые собирались создать сервер/мод... разумеется ни павн/луа, ни скриптовых функций сампа/мта они не знали, однако LUA/MTA посчитали более удобным и функциональным.

ИМХО: gzip сжатие для мап/конфигов/клиент-файлов не помешает. Кроме того, существует модуль LUA для работы с gzip на лету

а Сетевой модуль обновил?

Однако: 1) конкуренция - двигатель прогресса 2) больше людей перейдут с сампа на мта 3) всех порвем, как туалетную бумагу и даже используем также