KagerA

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

а какой в этом смысл-то вообще? Можно на сервере взять всех игроков в радиусе (где-нить 50-100 клеток) и разослать, (как я и делал), какой смысл грузить канал и отправлять серверу длиннющий массив из нужных игроков, вся информация в котором серверу итак известна? возможность отправлять пакет конкретным игрокам всегда существовала, а фразу "отправляй ОДИН пакет ВСЕМ игрокам" я не понимаю ни в каком контексте). По поводу ссылочек от Disinterpreter:жаль, что этот перфоманс браузер видимо не выдаёт никакой информации по поводу нагрузки на канал, только цпу... но вот с двумя следующими функциями наверное можно что-то получить - как минимум попытаться измерить количество и размер пакетов, которые МТА использует для дефолтной синхронизации гранат, может когда-нибудь займусь, если интерес появится

Давно уже ничего для МТА не кодил, но вдруг стало интересно, насколько оправданной была одна из моих старых затей. Интересует собственно то, что в названии темы, но я всё же задам вопрос поконкретней после небольшой предыстории: Когда я баловался с МТА, меня в первую очередь интересовала возможность добавления новых элементов геймплея и как-то раз я написал несложную систему "каштомных" снарядов, вместо заводских projectiles. (банально на клиенте создавался объект, который плавно перемещался, просчитывая коллизии каждые 100 мс как материальная точка, на которую действует гравитация). Получается создал одновременно на всех клиентах "снаряд" в одинаковой позиции, с одинаковым начальным вектором движения, ну и вообще поведением, получил вполне себе реальный предмет, который все видят. Потом и несложный алгоритм синхронизации прикрутил - в зависимости от пинга игрока добавлять искусственные задержки или наоборот просчитывать снаряд наперёд. Вообщем получилось довольно весело, поиграли несколько вечеров с парой друзей, покидались всякими осколочными гранатами и баскетбольными мячами на моём сервере, пинги 50-150, всё смотрится естественно и синхронизировано, никто не жалуется на задержки, но нагрузка-то никакая, нас всего трое. Вопрос в том, насколько это оптимизировано в сетевом контексте, вот пожалуй ещё конкретней: клиент вызывает triggerServerEvent("onPlayerThrowSuperBanana",localPlayer,x,y,z,rotXY,rotZ,force); - позиция игрока, два угла, чтобы обозначить направление и сила броска. (думаю можно опустить x,y,z и спрашивать позицию у сервера) сервер получает информацию, пересылает её всем игрокам в нужном радиусе и на этом сетевая часть заканчивается. Насколько это затратней, чем просто синхронизировать, как игрок метает обычную гранату из gta sa? Что если целый дм-мод построить на том, как 30 игроков будут "кидаться" чем-либо каждую секунду? Я понимаю, что обычная синхронизация в МТА это алгоритм посложнее, чем на все кнопки по tcp пакетику отправлять, но всё-таки такое событие как бросок гранаты вряд ли дожидается каких-то очередей и возможно схоже с тем, что я делал при помощи triggerServerEvent? в сетевых технологиях не особенно разбираюсь.

если речь идёт не том, что 3д линия это по сути 3д-шный "плэйн" и его чисто в силу этого невидно допустим снизу или сверху, а именно о том, что эти линии иногда напрочь отказываются рендериться, то я сталкивался с такой проблемой. Сейчас поведаю: я долго тестил и искал закономерности, когда линию отображает, когда нет, и заметил следующее: прорисовка линий зависит от того, стреляет ли кто-нибудь поблизости, а так же кто какое оружие держит! (вобще-то я уверен, что это зависит от чего-то друого, а эти странности - лишь последствия, но не суть), тестов было много и всех результатов я не помню, но помню точно следующее: если я буду стрелять допустим с М4 - линии видно со всех ракурсов. Поставил стреляющего бота - линии тоже рисуются когда я смотрю на него. Поставил бота, бьющего кулаком - линии не рисуются. Поставил двух ботов, дерущихся на кулаках - всё рисуется. Я сделал странный, но рабочий дебаг таким образом: приаттачил на клиенте у игрока к самому себе двух бессмертных дерущихся ботов (повыше над головой, так, чтобы на них никак нельзя было взглянуть). Звучит это просто по-идиотски и я бы сам ни за что не поверил в такое, но этот дебаг мне отлично послужил - линии всегда прорисовывались, со всех ракурсов. Я с этим вроде всего пару дней разбирался и наверняка можно придумать куда более простое решение, эксперементируйте. P.S это было ещё в 1.0.4 (если не в 1.0.3 вобще!), и до сих пор по-моему не исправили - возможно этого даже нет на баг-трекере, P.S.S был ещё один баг с 3д линиями - если на экране есть маркер типа cylidner, то линии рендеряться неправильно (чаще всего их не видно вообще, но порой они появляются, но не в нужных позициях) и я так же не уверен по поводу того, исправили ли это.

а в чём собственно главное предназначение такой утилиты (если бы она была реализуемой) ? просто запись видео с экрана игры с бОльшим фпс чем фрапс? оО Не думаю что, сохранив качество записи фрапса, можно увеличить фпс впринципе. Более разумный и интересный вариант это запись "демок" (вычислять все нажимамемые клавиши, позиции, точки прицеливаний и записывать в массив, затем воспроизводить с ботами), да только это всё равно никуда не отправишь (разве что, записал "демку", воспроизвёл и записал на фрапс), частенько будут возникать баги и подлагивания во время воспроизведения, да и производительности клиента это тоже будет требовать значительной...

да, насчёт "двойного удара" я тоже часто задумывался, просто хотелось без долгих тестов проверить, насколько он сказывается на машине в сравнении со стандартной синхрой (в том смысле, что если всего на 10%, то хрен бы с ним, а если в два раза, то не стоит), но видимо всё-таки второй вариант. насчёт "про-игроков" прекрасно понимаю, но если бы речь шла о полной перестройке динамики стрельбы (а следовательно и скилла), то это даже не актаульно. я вобще хотел это выяснить не ради своего занятного скрипта, а просто на будущее. При создании скрипта, не знаю, какой-нибудь туррели, эта информация очень полезна.

Кастомная синхронизация стрельбы - если кто не пробовал, то наверняка задумывался, наверное. Я имею ввиду написать скрипт, который через триггеры станет сообщать серверу о каждом "настоящем" попадании в цель, отлично подходит для снайперской винтовки например. дело в том, что я видел всего один сервер с подобным скриптом, что же до него, то там всё более или менее играбельно, но изредка теряются пакеты и один игрок получает пулю от другого через минуту или две после выстрела. Но сего скрипта я не читал, может там кто-нибудь накосячил, может слабый хост, может быть всё, что угодно. Дело в том, что я, потехи ради (формально ради изучения триганометрии в "полевых" условиях), недавно написал скрипт, который создаёт абсолютно новую систему прицеливания и динамику стрельбы и сильно расширяет характеристики оружия, добавляя такие характеристики, как разброс (прицел, увеличивается, пули летят более хаотично), отдачу (прицел задирается вверх при стрельбе), приближение (насколько приближается камера при прицеливании), количество пуль при выстреле (для дробовиков) и несколько других, менее важных фишек. Работает всё вот так: все махинации по поводу разброса и тд делаются на клиенте, то есть "настоящую" пулю видит только сам стреляющий, если он попадает (именно попадает!) в цель, то сообщает серверу об этом, который отбирает у раненого хп. Кроме того клиент хранит в массиве здоровье всех игроков и хитро его обновляет. При этом, если он попал в цель, то сразу в связи с этим обновляет свой массив - таким образом стреляющий сразу узнает, убил он, или ранил (и если убил, то он сообщает серверу, что он убил, а не ранил). Так вот вопрос - насколько это оптимизированно и можно ли использовать такое на паблике слотов, скажем, на 32, не забьётся ли канал и тд? И сильно ли влияет на оптимизацию такой аспект, как дамаг оружия? например если я выставлю М4 урон 10, то этот вояка убьёт жертву, послав 10 сообщений серверу, если же дамаг будет аж 30 - потребуется всего 4.

а толку? насколько мне известно, в сэмпе дефолтный лимит фпс 25 кадров, при изменении которого и без того лагучая синхра даёт сбои. Хотя я и не могу сказать на 100% по поводу новой 0.3...

эх, читаете мысли, Kernell ='(. Неделю уже, эксперементируя с атмосферой раздумываю, как можно "скрасить" систему освещения. При некоторой комбинации градиента неба, погоды, времени суток и отсутсвующей к сожалению createLight с вощможностью указать радиус, форму, силу света, можно было бы сделать отличную Horror атмосферу со всякими фонариками и тд... я кстати не совсем понимаю, что даёт createShader. Как им пользоваться? Неужто можно, скажем шейдер плитки наложить на поверхность оО? dxDrawImage ведь не предусматривает таких сложных деформаций, максимумм поворот. Или этим просто можно добиться других "концентраций" цветов чтоли, например наложить определённый шейдер поверх экрана чтобы сделать игру в зелёных, скажем, тонах?

чтобы показать скрипт надо высчитывать оффсеты для начала и конца анимации относительно лавки... Ну смотри, если выставить updatePosition -> false то персонаж визуально будет двигаться, но координаты меняться не будут. То есть он по сути стоит на месте (соотвественно коллизии ни на что не повлияют), но визуально будет двигаться "сквозь" обьект и нормально на него присаживаться. Таким образом надо применить анимацию с updatePosition->false и на самом последнем её кадре нужно отменить анимацию и телепортировать игрока туда, где он должен оказаться(на лавку тобиш). Если правильно всё посчитать, стык будет практически незаметным, единственное, что камера дёрнется при телепорте (можно сделать на этот момент кастомную, приаттаченную камеру через setCameraMatrix в onClientPreRender, но это уже другая история) _______________________ x,y,z = координаты игрока x2,y2,z2 = координаты позиции, которая находится чуточку впереди от игрока time = время, за которое проходит анимация setPedAnimation(ped,"блок","анимация",-1,false,false,false); setTimer(setElementPosition,time,1,ped,x2,y2,z2); как-то так.

Как же нельзя? Updateposition - false и по окончании телепорт на лавку и следующую анимку

и в чём же сложность синхронизировать отмену коллизии вручную? оО всего-то лишь нужно вызвать функцию у всех клиентов сразу+вызывать у клиента при заходе на сервер.

насчёт зависания при сохранении идей нет... а вот насчёт неспособности удалить обьекты, загляни сюда viewtopic.php?f=123&t=32519 была у меня такая же проблема

очень занятное замечание (проверил у себя), то есть по сути надо всего-лишь встать на скамейку и применить анимацию) а анимация посадки это и впрямь тема: сделать edf с элементом "скамейка" и расставить где надо, чтобы точно выставлять углы поворотов. вычислить примерно оффсеты места, с которого садиться и место, в котором есть. ТП в первую точку, анимация посадки, тп во вторую точку, анимация "етьбы" - гениально. а чтобы ставить "скамейки" на готовых скамейках, можно сделать элемент безматериальным)

попробовал с ботами - тоже самое. Ты уверен, что видел это именно на примере собственного кода, а не на каком-то фрироме с ресурсом "супермен"? интересно всё-таки, может ты это можешь воспроизвести