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 с элементом "скамейка" и расставить где надо, чтобы точно выставлять углы поворотов. вычислить примерно оффсеты места, с которого садиться и место, в котором есть. ТП в первую точку, анимация посадки, тп во вторую точку, анимация "етьбы" - гениально. а чтобы ставить "скамейки" на готовых скамейках, можно сделать элемент безматериальным)

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

я так же не говорю ничего просто так, прямо сейчас нахожусь на своём локале и только что испробовал простую команду портануть себя на 10 клеток вверх применить ко мне анимация удара кулаком результат:я падаю и в падении бью кулаком. Некоторые анимации содержат в себе подобие "кода", я как-то раз какой-то анимацией забор сломал... как называется анимация плавания, может она "особенная" а я и не знаю? попробовал анимации плавания - та же песня, падаю и плыву. уж не знаю что у вас там за чудеса на 1.1, но на 1.0.5 (и предыдущих) никогда на одной только анимации люди не летали

Никакого противоречия:я говорю о том, что адаптация под новый язык для опытного программиста не должна быть проблемой. А эта адаптация необходима, как я уже сказал Луа выбрана скриптовым языком МТА и наверняка с апдейтами (или уже сейчас) будут(есть) какие-то возможности, которые не удастся использовать с каким-то там php модулем. И преимущества Lua я поверхностно озвучил только для того, чтобы смоделировать "сложный" выбор: адаптироваться под ПРОСТЕЙШИЙ язык программирования, или потратить кучу времени на поиски модуля, разборки о том, как и с чем его есть, проблемы с примерами на lua из вики уж я не знаю что там ещё дальше...

не понимаю, как разница в синтаксисах может пугать. Ну разные обращения к массивам, then вместо скобочек и тд, какая разница-то, алгоритмы надо уметь составлять, а не синтаксисы зубрить! Знаешь один язык - знаешь все. Да только на Lua множество удобных плюшек в области работы с массивами, переменными и многим другим+на него МТА и расчитана (с модулем 100% будут проблемы с чем-то сложным, скажем работой с нескольими ресурсами, или мб базами данных...а так же работа с чужими скриптами, или чужая работа с вашими скриптами) вобщем +1 к Lua. P.S видел множество языков, си-подобных, не-си-подобных, павно, сишарп, экшен скрипт и тд, синтаксиса, проще и удобнее, чем в Lua не встречал

да боже ты мой, что все такие упёртые? запусти МТА, напиши простой код(или юзни фриром), примени к себе эту анимацию и зацени, как твой персонаж провалится под землю и вдруг вернётся обратно по её окончании, блок DAMM_Jump или как-то так называется персонаж по оси Z двигается ТОЛЬКО ВИЗАУАЛЬНО. его координаты НЕ ИЗМЕНЯЮТСЯ. в катсценах в игре этого было достаточно PS: для справки, чтобы "лететь вниз", анимация не нужна, элементарная гравитация, но если говорить о катсценах, то там у персонажа отключалась вся физика и все коллизии (неважно как, просто факт)

MX_MASTER, с чего ты взял, что анимация не даст педу упасть?? с анимацией или без, пед всегда физический обьект и будет падать, поддаваться ударам машин и тд. Это же элементарно. Сходи, да протесть, портани педа повыше да примени анимацию, упадёт... в данном случае, как я уже говорил, надо выставлять гравитацию 0, чтобы не падал. Либо заморозить, как предложил Kernell, но помнится мне, что пед дёргается, если его заморозить в воздухе... но если память мне изменяет, то это подходит куда лучше чем гравити. ах да, и ещё: вычислять оффсеты, как разность между координатами при начале и конце анимации? оО это бред, потому, что: таким образом можно вычислить оффсеты токо по x и y, анимаций, которые смещают персонажа по Z вроде вообще не существует (анимацией прыжка например ты никогда ничего не перепрыгнешь, врежешься). Ты же не думаешь, что анимация, при которой персонаж поколено в земле реально смещает его вниз на пол клетки? а анимации из блока SWAT, при которых перс визуально вообще под землю проваливается, реально смещают его под землю?))

нет, этот аргумент просто влияет на анимации, которые сами по себе могут сдвинуть персонажа, например анимация бега(если тру, перс будет бежать, если фолс, то он будет бежать и телепортироваться обратно). а я говорю о том, что если педа(или машину), у которой выставлена гравитация 0 (невесомость), толкнуть, то он/она улетит далеко и надолго

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

Если при этих анимациях персонаж двигается, то идей, как это исправить нет. Но если он просто стоит, исполняя их, то решений масса: 1 выставляем педу/игроку гравитацию 0 и телепортируем чуть выше (0.5 мб) (для отмены просто выставить гравитацию обратно 0.008) 2 создаём любой обьект, делаем невидимым, рассылаем всем клиентам функции об отмене коллизий с ним, аттачим к этому обьекту игрока/педа. И задаём обьекту такие координаты, чтобы анимация смотрелась хорошо. (для отмены придётся заносить ид обьекта в массив или в elementData игроку, чтобы потом вычислять и уничтожать)

ну смотря о каком именно расстоянии идёт речь. можно же взять все возможные маршруты по вей-поинтам и найти наименьший? конечно если под рассстоянием мы подразуемваем половину лос-сантоса то это определённо не слишком оптимизированный вариант... но можно сделать два типа вей-поинтов "большой" и "маленький", если мы имеем дело с маленькиим расстоянием в каких-нить переулках, то бот будет ходить по "маленьким", а если на больших расстояниях, то соотвественно по "большим", которые будут располагаться на дорогах/тротуарах. Вообще мы тут ерундой, чувствую, страдаем, кому охота будет по всей СА расставлять эти самые вей-поинты. Надо взглянуть чем эти "вей-поинты" представлены в сингле и уже из этого составлять алгоритм...

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