Jump to content

Сохранение Account Data при выходе


Recommended Posts

Мне надо сохранить кое-какие данные из клиентской части в Account Data игрока при выходе его из игры. Дело в том, что событие onClientPlayerQuit вообще никак не срабатывает в данном случае. Пробовал через серверный аналог данного события, но т.к. игрок уже вышел, то уже не могу перенести его данные из клиента в сервер. Так вот собственно и вопрос: как можно сохранить, например getElementData из клиентской части в сам Account Data, и именно при выходе это все отловить?

Link to comment

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

Ты точно проверил, что onClientPlayerQuit не срабатывает, потому что он должен срабатывать.

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

Link to comment

onClientPlayerQuit (как и onClientPlayerJoin) не срабатывают для источника события, то есть для того игрока, который выходит (заходит).

и об этом в их описании написано.

Link to comment
сохранять нужно периодически, а при выходе может быть любой глюк/косяк и прочее, и данные могут не сохраниться. Проверено.

Откровенно говоря не знал, что при выходе может и не сохраниться что-то.

Ты точно проверил, что onClientPlayerQuit не срабатывает, потому что он должен срабатывать.

Да он не срабатывает, но правда теперь понятно почему. Клиентский выход действительно не работает на источник, на вики даже написано было, а я провтыкал этот момент :(

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

Если это частенько делать, т.е. отправлять и записывать в аккаунт-данные игрока информацию из клиента, это может повлиять на производительность сервера? Ну там лаги, падение FPS и т.п.?

Link to comment

Разве что отправлять будеш через каждые пару миллисекунд :) Лучше всего сохранять данные по мере их изменения: потратили денюжку - сохранили денюжки, увеличили уровень - сохранили уровень и т.д. Хотя если данные меняются очень часто, то тут уж лучше сохранять по времени.

Link to comment

Собственно, не секрет. Мне нужно сохранять показатель сытости в моей системе голода. Голод падает периодически, -1 единица в 5 секунд. Поэтому приходится записывать данные каждые 5 сек, и, естественно, для каждого игрока. Наверное, придется тогда править скрипт, раз ты говоришь каждую минуту достаточно.

Link to comment

Почему не посчитать на сервере сколько времени прошло с того момента как игрок последний раз ел, разделить на 5 и сохранить когда он выходит?

Link to comment

lil Toady, если бы я знал как сохранить клиентские данные игрока при выходе из игры, мне бы не понадобились никакие расчеты со временем и делением на 5, и даже эта тема в придачу. А т.к. тут сказали что выход иногда может не сработать корректно, да и клиентский выход не канает должным образом на источник события, то я и ищу другие методы. В общем, ты наверное первые посты не прочитал, а если знаешь как сохранить это все правильно при выходе, был бы очень признателен.

Link to comment

Ну я же это и написал в предыдущем сообщении :( Меняй эту стату спокойно, сколько хочешь, на клиенте, но сохраняй через сервер посчитав на сколько оно изменилось за определённый отрезок времени. Это как, если бы меня не было дома, я бы всё равно мог посчитать сколько прокукукала кукушка на настенных часах, за время моего отсутствия.

Link to comment

У тебя скрипт пополнения уровня голода (закусочные) только на стороне клиента выполняется? Если да, то подсчета на серве мало, все равно нужен синхр или в момент увеличения значения голода или опять же периодически.

Link to comment

Почему бы просто не создать таймер на сервере где будет цикл в котором и будет весь процесс изменения уровня сытости?

OnPlayerQuit у меня всегда корректно на сервере срабатывал.

Link to comment

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

Link to comment
  • 1 month later...

Вот и не удивляюсь почему почти все сервера загружены клиентскими скриптами. Зачем вообще хранить информацию о голоде на стороне клиента?

Link to comment

Почему бы не хранить её в element data? Полный массив для синхронизации, например: setElementData(player, "status", {голод, сон, ярасть, недо*б}) ? Отпадет надобность в ручной синхронизации вообще.

Или вообще, голод можно (и даже логически правильно) хранить в sedPedStats, только если они синхронизируются с сервером.

Link to comment

Чем это оно небезопасно? Попытками нападения на процесс гта_са со стороны редакторов памяти? Я не понимаю. Если ты про это, тогда

1) проверку данных на сервере никто не отменял

2) ребятки, играть совсем небезопасно! вот некоторые спидхаки юзают... это - проблема покрупнее. по сравнению с не, никому не сдавшийся ролеплейный голод - пшик.

Link to comment
Ну например 1.0.5 уже взломали и вставляют свои клиентские скрипты.

Так я именно поэтому и говорю что хранить данные нужно на сервере. А принимаемые данные обрабатывать как на php.

Насчёт

2. Разрешать использовать setElementData с клиента не безопасно

В PHP $_GET, $_POST тоже не безопасно использовать, теперь их не юзать? :mrgreen:

Ну и соответственно если setElementData взламывается, кому и что помешает также вызвать нужный ему триггер? (Да и вообще любой способ синхронизации). Придерживаться правил web и проблем будет гораздо меньше :wink:

Link to comment
В PHP $_GET, $_POST тоже не безопасно использовать, теперь их не юзать? :mrgreen:

Ну тогда не использовать Ajax и вообще не пользоваться JavaScript :mrgreen:

А вообще плохое сравнение. Скорее с triggerServerEvent можно сравнить.

Ну и соответственно если setElementData взламывается, кому и что помешает также вызвать нужный ему триггер? (Да и вообще любой способ синхронизации). Придерживаться правил web и проблем будет гораздо меньше :wink:

Поэтому я компилю все клиентские скрипты.

Link to comment
Поэтому я компилю все клиентские скрипты.

Так какое отношение имеет твой скрипт к внедрению нужных функций в клиентсую часть. Твой скрипт будет просто сложнее просмотреть, а для взлома тех или иных функций вообще твой скрипт не понадобится.

Link to comment
Так какое отношение имеет твой скрипт к внедрению нужных функций в клиентсую часть. Твой скрипт будет просто сложнее просмотреть

В этом разделе MX_Master уже писал как усложнить декомпиляцию.

а для взлома тех или иных функций вообще твой скрипт не понадобится.

Каких ещё тех или иных функций? Мы говорим не о функциях MTA, а о том что можно обойти проверку клиент.скриптов и использовать свой код.

Изначально говорилось о Data (Element и Account).

Допустим есть скрипт банк системы, у игрока деньги храняться в Element Data. Злоумышленник обходит защиту, переписывает скрипт банка и всё, он мультимиллионер (как пример, хотя я уверен такие найдутся).

Link to comment

Kernell, У тебя как всегда не верные представления о реализациях. Почему так ограничено всегда всё представляешь? Не обижайся конечно, но ты всегда спешишь с ответами. У меня изначально немного иные представления о мемхаке. Некому нечего не нужно будет переписывать. Взломав память не исключай дебаг, в котором легко отслеживаются все функции вызванные в клиенте. Помимо отслежки и их вызов (в том числе и те функции которых нет в клиентсом скрипте). Если тебе будет проще понять, считай что это runcode под именем любого ресурса с клиента.

Конечно же заявлять о такой возможности будет на столько же не до конца корректно, на сколько и утверждать что setElementData небезопасна. Хотя в принципе в этом нечего такого нет. Вероятность взлома клиент-части всегда существенна, какой бы защита ни была. Именно поэтому моя политика не при каких условиях не упускать фильтраций со стороны сервера.

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...