Сообщений в теме: 1486

[Ilias]

Ilias, я правильно понял: есть скрипт отправляющий запрос на клиенты с определенной частотой, для которого один и тот же клиент подключённый в разные моменты времени должен считаться как два разных клиента?
При подключении клиента на сервере генерируете специальный ID (Просто счетчик, постоянно возрастающий с каждый подключением), отправляете этот специальный ID клиенту, после чего, на каждый ваш запрос он должен отвечать вместе с этим специальным ID

Клиент отключается, получить этот id не получиться, только из сохранённых данных ища по соотнесённым clientID|steamUID.. (для этого придётся обрабатывать каждое подключение, отключение),  это и есть журнал, посоветовали назад что я написал :)

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

Сообщение отредактировал Ilias: 13 December 2017 - 02:21

[vlad333000]

Клиент отключается, получить этот id не получиться

Клиент не ответил с данным ID в течении N-го времени - "закрываем" ID

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

Не зависимо от версии скрипта, он в обязательном порядке должен поддерживать определенный программный интерфейс... если скрипт его не поддерживает (Ну или не поддерживает ни один из возможных), то шлите этот клиент на 3 веселых буквы с фразой "Your version not supported"

Сообщение отредактировал vlad333000: 13 December 2017 - 02:31

[Ilias]

Клиент не ответил с данным ID в течении N-го времени - "закрываем" ID

больше ресурсозатрат.и ненужные задержки (при определении отключения наример)

Не зависимо от версии скрипта, он в обязательном порядке должен поддерживать определенный программный интерфейс... если скрипт его не поддерживает (Ну или не поддерживает хотя бы один из возможных), то шлите этот клиент на 3 веселых буквы с фразой "Your version not supported"

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

Сообщение отредактировал Ilias: 13 December 2017 - 02:39

[vlad333000]

вы не поняли, скрипты могут включаться, переконфигурироваться, выключаться на любом vm по ходу игры, это записывается, и учитывается для соей работы другими скриптами

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

[vlad333000]

переконфигурироваться

В каком плане? "Менять алгоритм работы" или "Менять интерфейс"?

[Ilias]

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

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

В каком плане? "Менять алгоритм работы" или "Менять интерфейс"?

И то и другое, иногда вместе :) , когда как

 

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

Сообщение отредактировал Ilias: 13 December 2017 - 02:52

[vlad333000]

И то и другое, иногда вместе  , когда как

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

будет знать что не нужно ждать ответа если клиент отключился

Функция обратного вызова, ни какого ожидания... отправили запрос - забыли, клиент захотел - отправил ответ, который сам вызовет нужную функцию

[Ilias]

Функция обратного вызова, ни какого ожидания... отправили запрос - забыли, клиент захотел - отправил ответ, который сам вызовет нужную функцию

работает только если ответ может не требоваться

[vlad333000]

работает только если ответ может не требоваться

Работает в любом случае... что вам мешает в функцию обратного вызова запихать продолжение кода функции, которая отправила запрос? Ответ: только ваша голова

[Ilias]

Работает в любом случае... что вам мешает в функцию обратного вызова запихать продолжение кода функции, которая отправила запрос? Ответ: только ваша голова

(нужно бы мне перестать редактировать сообщения после отправления)

я было начал расписывать, но проще говоря: Я в курсе что есть другие схемы и принципы устройства систем, и да, вещи типа того что вы сейчас упомянули очевидны, но строю по своим системам, поэтому обычно приветствую прямые ответы и задаю конкретные вопросы,

в роле всё же ответа: Например запрос клиенту отправился из sheduler-а (кустомного).

Сообщение отредактировал Ilias: 13 December 2017 - 03:43

[vlad333000]

Ilias, еще раз прочитав все выше описанное, мой вам прямой ответ с моей колокольни: ваша задача не решаема...
1. Система имеет полностью хаотичных характер и писать в ней код можно только на основе генератора случайных чисел (Основываясь на ваших словах, у вас даже core-функционал хаотичен)
2. Вы отказались от создания специального ID для уникальной идентификации подключения (Других вариантов я не знаю), т. к. ваше:

больше ресурсозатрат.и ненужные задержки (при определении отключения наример)

В корне не верно т. к. это не ресурсоемкий процесс, да и дело происходит в системе, которая и так требует траты колоссальных ресурсов на поддержание себя в актуальном состоянии

[Ilias]

 

вы не сонны случаем?

придётся видимо тогда журнал сделать

здесь это (решение) либо id уникальный для каждого подключения (системный) либо поочерёдная обработка каждого подключения, отключения

Клиент отключается, получить этот id не получиться, только из сохранённых данных ища по соотнесённым clientID | steamUID .. (для этого придётся обрабатывать каждое подключение, отключение),  это и есть журнал, посоветовали назад что я написал

(поочерёдную обработку каждого подключения можно заменить на таймер 

Клиент не ответил с данным ID в течении N-го времени - "закрываем" ID

, но это будет использовать больше ресурсов и вставит ненужные задержки)

 

понятие "хаоса" подразумевает неописанное состояние непредсказуемой системы, видоизменяемость,модульность,и перенаправление не определённо непредсказуемые вещи, а в этой системе состояние всегда точно описано.

Сообщение отредактировал Ilias: 13 December 2017 - 14:47

[Ilias]

 

спасибо за ответ по поводу directplay id

[SteelRat]

 

Ilias, я правильно понял: есть скрипт отправляющий запрос на клиенты с определенной частотой, для которого один и тот же клиент подключённый в разные моменты времени должен считаться как два разных клиента?
При подключении клиента на сервере генерируете специальный ID (Просто счетчик, постоянно возрастающий с каждый подключением), отправляете этот специальный ID клиенту, после чего, на каждый ваш запрос он должен отвечать вместе с этим специальным ID

Клиент отключается, получить этот id не получиться, только из сохранённых данных ища по соотнесённым clientID|steamUID.. (для этого придётся обрабатывать каждое подключение, отключение),  это и есть журнал, посоветовали назад что я написал

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

 

 

К чему такие извращения

// server side EHs
addMissionEventHandler ["PlayerConnected", {
	params["_id", "_uid", "_name", "_jip", "_owner"];
	diag_log text format["PlayerConnected: Client connected: %1" , _this];
}];

addMissionEventHandler ["HandleDisconnect", {
	params["_unit", "_id", "_uid", "_name"];
	diag_log text format["HandleDisconnect: Client disconnected: %1" , _this];
}];

Сообщение отредактировал SteelRat: 13 December 2017 - 17:08

[Ilias]

 

?

(оно и есть

n_sycs=0;
a_sycs=[];

addMissionEventHandler ["PlayerConnected", {
	a_sycs append[_owner,[n_sycs,_name,_uid]];
n_sycs=n_sycs+1}];

addMissionEventHandler ["HandleDisconnect", {
	a_sycs deleterange[a_sycs find _owner,2]
}];

(типо того))

(хотя спс за HandleDisconnect, посмотрел на отличие от PlayerDisconnected, полезно знать)

Сообщение отредактировал Ilias: 13 December 2017 - 17:34

[SteelRat]

Если мне память не изменяет с этим хандлером

addMissionEventHandler ["HandleDisconnect", {
	a_sycs deleterange[a_sycs find _owner,2]
}];

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

 

То есть, если для миссии определён этот хандлер, то не зависимо от настроек в конфиге миссии, после дисконекта игрока, в игре остаётся его бот, то есть тело не удаляется автоматом, этим нужно будет озаботиться вам самим.

 

Каким образом? Ну например определить в обработчик события алгоритм, который продержит бота в игре некое количество времени, которое понадобится прессующему, что бы добраться то тела, и от души над ним поглумиться, например отрезать яйца, ну как пример).

 

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

А если же игрок успеет вернуться до того как тело будет удалено, отдать игроку его, ещё живого перса. Результат для игрока может оказаться с сюрпризом.

[Schatten]

SteelRat, если обработчик события HandleDisconnect возвращает false и в description.ext disabledAI = 1, то остаётся труп, который можно удалить командой deleteVehicle.

[Ilias]

SteelRat, если обработчик события HandleDisconnect возвращает false и в description.ext disabledAI = 1, то остаётся труп, который можно удалить командой deleteVehicle.

если disabledAI==0 то остаётся бот (не умирающий от отключения), а если код в handleDisconnect возвращает true то не остаётся ничего?

[Schatten]

Пожалуйста Войдите или Зарегистрируйтесь чтобы увидеть скрытое содержание

,

If this EH code returns true, the unit, previously occupied by player, gets transferred to the server, becomes AI and continues to live, even with description.ext param disabledAI = 1;

Сам не проверял.

[SteelRat]

 

SteelRat, если обработчик события HandleDisconnect возвращает false и в description.ext disabledAI = 1, то остаётся труп, который можно удалить командой deleteVehicle.

если disabledAI==0 то остаётся бот (не умирающий от отключения), а если код в handleDisconnect возвращает true то не остаётся ничего?

 

Я имел ввиду то что если вы определили этот хандлер, то арме становится пофигу что вы напишете в конфиг миссии по поводу инициализации AI.

 

То есть, после дисконекта игрока владельцем бота становится сервер и управление ботом передаётся AI, и не зависимо от того активировали вы AI в конфиге миссии или нет.

Сообщение отредактировал SteelRat: 14 December 2017 - 00:00