xStream

Некорректно выразилась. Имелась ввиду основа связки С++ - ЛУА: экспорт функций, классов из С++ в ЛУА. Я просто привыкла к этому, на этом можно всяческие трюки сделать (включая работу с памятью, потоками и прочими интересными штуками). Здесь же, в сталкере, приходится иметь дело "с тем, что есть".

Ну, инструментарий появился со времени, когда я последний раз занималась сталком, - это ж замечательно! Я отстала от жизни. Тем не менее, это инструменты, а речь шла о довольно примитивных техниках. ЗЫ Все, точно завязываю Вернусь с чем-нить интересным, если вспомню. Просто некоторые вещи из Луа в принципе не подходят к сталкеру

Сложно, если там логика сложная и вылезло какое-нибудь переполнение стека Простое и отлаживать просто, бесспорно. Все зависит от мозгов программиста - чем он наполнит это все дело ЗЫ Завязываю оффтопить

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

[offtopic] Ну как бы никто не спорит Я немножко увлеклась "жизненным" примером: у меня 3 подчиненных, так что работать в команде надо уметь. Я придерживаюсь довольно строгих правил и требую от других того же (code guideline). Получается пока довольно эффективно. Начиная от именования переменных, до самодокументирования кода. Так что вопрос о "единственно верном способе программирования" явно выходит за рамки этого топика, да и ненужно это. А вот использовать возможности языка тогда, когда это не вредит ни красоте, ни скорости, ни гибкости - вай нот? [/offtopic] Кстати, вспомнился вопрос оптимизации - зачастую лучше потратить память и выиграть в скорости, создавая временные, часто используемые, контейнеры и переменные. Это в тему топика. Тогда и не придется заниматься экономией на циклах (30% быстрее и т.п.), так как итерация по 100 элементам - совершенно не то же самое, что по 10 000, к примеру. Это применительно и к сталкеру. Была мода в свое время пробегать по всем ИДшникам игровым с 1 до 65к, проще сделать один раз и составить таблицу, откуда удалять элементы и добавлять их туда уже по колбекам регистрации/разрегистрации. Это просто пример и мое имхо. Возможно, я отстала от жизни.

Честно говоря, считаю, что "прятать" логику - очень дурной тон. Я про оператор индексации. В С++ схожая ситуация, но там оно более очевидно и потому используется широко. Типизированный язык как никак. А вот спрятанный алгоритм поиска введет в недоумение не-автора. Что при работе в команде зачастую - очень нехорошо. Согласна с Артосом: лучшее - враг хорошего. Быстрее и проще решить частный случай, чем клепать универсальный, никому не нужный код, который использован то будет всего пару раз. И в то же время, если код пишется в команде, то про красивость и ясность забывать нельзя - сэкономишь на одном, потеряешь на другом.

Честно, не встречался ни один язык с "выборками интервалами". То, что тебе надо - поиск по массиву. В терминах ЛУА можно составить таблицу, каждый элемент которой содержит минимум и максимум, и значение. А там уж бегать по нему, пока не попадется нужное. Или, как я выше писала, ключ - функция, которая вернет тру или фалс; если тру, берем значение и останавливаем перебор. Это более универсальное решение

Мне кажется, здесь проще всего составить функцию, в данном конкретном случае: деление на 10, получение целой части, отнимание 5, умножение на 500, обрезание с помощью min & max

Без кода, принцип: Есть некая непись, она составляет рейд, причем в каждой точке (ключевой) планирует некое действие (например - отдельную схему, выполнение квеста и т.п.). Действие - функция (у меня подставлялась в экшн), а параметры - "настройка действия" (типа надо пойти и найти такой-то предмет, отыграть такую-то анимацию и бляблябля). В результате я получала для непися таблицу с парами "функция - параметры". Ну и непись отправляется под схему. При смене состояния (непись дошел до цели, например) делается next из таблицы, пишется в переменные (self.четотам, например). В эвалюаторе/экшене просто выполняется сохраненная функция с параметрами. В результате получается разнообразное поведение, в зависимости от того, что происходит вокруг непися и на контрольных точках. А схема - одна. Ну и никаких захардкоденых графов. Когда таблица "исчерпана", рейд завершается и непись возвращается в исходную (ну или какую выберет) точку. ------ Поздно, я уже ответила

Зачем? В зависимости от надобности. Пример был даже приведен. У меня было, например, одно место, где использовалась очередь колбеков - таблица, в которой ключ являлся ссылкой на функцию, а значением была таблица, передаваемая этой функции. Вполне удобно оказалось - заранее составляем таблицу, потом просто используем. Так программировалось поведение в рейде, при изменении условий, очередь перестраивалась заново. Своеобразный планировщик получался.

Не знаю, насколько это актуально, но я часто использовала в последних своих изысканиях по сталкеру (но это относится к ЛУА в целом) следующее свойство: ключами и значениями у таблиц в ЛУА может быть что угодно. В качестве ключей можно использовать другие таблицы или функции! Это было откровение, и оказалось удобно. Еще одним хорошим методом увеличения гибкости кода является использование безымянных функций, в частности, когда их передаешь как аргумент в другие функции. (Был уже пример, как я понимаю, - итератор). Получается неплохое такое приближение к полиморфизму в С++ (учитывая, что с помощью метатаблиц в ЛУА можно сымитировать классы и их поведение). Или, например, можно написать итератор по таблице, который будет выполнять функции, хранящиеся в таблицах-значениях, в зависимости от других значений этих таблиц или даже ключа (или выполнять ключ, если он является функцией). В общем - гибкость бешеная. Код, обычно, сокращался раза в 2-3. Есть только минус - отлаживать гораздо сложнее

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

Осталось только убрать сталкеров, посадить меченого на вертолет и устроить воздушное побоище

1)При загрузке игры каждому неписю вызывается onregister метод серверного объекта. Ну и в нем, непись отправляет в общее хранилище свои данные. Запись проще - реалтайм, как надо сохранить инфу, сразу в него и пишем, при сохранении все это попадет в сейв. 2)По ид я имел ввиду следующее - если брать непися с ИД=10 и послать налево, а непися с ИД=11 направо, томожет получиться смешно - 10-й стоит справа, а 11 слева, вот и пойдут "крест-накрест". Только это и ничего более.

а для того и нужен верхний уровень, чтоб определять кого куда и что бы не было конфликтов. то есть составлять наборы данных, исходя из которых непись переходит под ту или иную схему Пример: когда отправляем одного быть снайпером, то в таблицу "снайперов" добавляем непися и точку, которую он пасет. Если из другого сквада снайпер попрется туда, ему достаточно проверить, а не занято ли там. Довольно просто. И вообще неписи будут стараться держать дистанцию относительно друг друга, а в пределах сквада - не сильно разбредаться и будет получаться действие в группах. Твоя ошибка в том, что ты пытаешься конечные действия представить, а надо наоборот - составляем глобальную картину и "высший разум" раздает "задания" учитывая состояние неписей, их вооружение и вообще все что угодно. Я говорил, что реально не надо запариваться о том, что бы синхронизировать неписей. Под действием управляющих сигналов "сверху" они будут рядом, но без сильной синхронизации, просто "будет совпадать" то, что мы видим, с тем, что подразумевается, но на деле - неписи каждый под своим GOAP работает, просто мы корректиируем их поведение, но не жестко. То есть - детали реализуют неписи, мы указываем общую цель. Не забывай, как работает планировщик.

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

Ого, баталия. Уважаю, что называется. Делюсь наработками/идеями для группового взаимодействия: 1) такого взаимодействия, как показывает практика не нужно! достаточно создать видимость. 2) приняв подобную идею, приходим к уровню логики, который выше уровня логики отдельного непися (в ЧН что-то подобное - сквады и группировки, но очень тупо реализованное) 3) для такого уровня требуется собственное хранилище (я использую распределенное - каждый непись в себе хранит "свою" часть общего состояния, что позволяет сохранять и загружать эти состояния не боясь переполнить pstor), в котором хранится информация о "расстановке сил" какие неписи каких группировок где находятся, на базе информации формируются "сквады" (гы) по расстоянию друг от друга, по целям и т.п. 4) для каждого сквада производится распределение - кому из неписей какую роль "отыгрывать", например, снайпера выбрали (по оружию) и послали к каверу недалеко от тех неписей, которых приняли за один сквад. Точно так же и с остальными поступить. 5) все это сводится к ручному манипулированию эвалюаторами - выставление тех или иных в true (просто чуть-чуть модифицируем код эвалюаторов) 6) как следствие - неписи двигаются сами по себе, но внешне это выглядит как групповое действие. Подобную вещь я делал, когда заменял боевую схему: неписи стараются кучковаться, но не сильно, стараются не стоять друг у друга на линии обстрела, меняют укрытия и т.д. и т.п. (ролик на ютюбе, хоть и сумбурный, показывает это) Или торговля - две таблицы, одна "мастер-слейв", другая "слейв-мастер" (для быстрой выборки). Одна схема, но с ветвлением - если мастер, то играть одно, а если слейв - другое. Получается синхронное взаимодействие. Так же спокойно восстанавливаются эти пары при загрузке игры (п.3), что позволяет даже после загрузки продолжать наблюдать торговлю. Иначе после перезагрузки игры теряются таблицы пар и каюк Так что верной путей идете, товарищи. PS 2Kirag: к id объектов низзя привязываться для выбора направлений. Так как получится каша. И да, у ПЫС боевая схема в движке, для сталкеров, и она не такая уж и простая. Другое дело, что не очень адекватная. PPS 2Kirag: тебе с десантом могу предложить вариант такой: составляешь единожды таблицу, кого надо "забрать" и у вертолета смотришь, чтоб таблица была пустая, тогда улетать. У написей же делаем схему, где эвалюатор выдает true, если непись в такой таблице, ну а в схеме - что угодно, например, пробежать от 2 до 5 секунд, присесть пострелять во врага 2 секунды, метнуться в сторону и все это в виде графа с переходами по ребрам из одного состояния в другое. Можно усложнить - если отслеживать через таблицу у кого из группы какое состояние, запрещать переход в какое-либо состояние, если более 70% группы в таком состоянии уже находятся. Не суть, главное - когда добегает непись до цели (проверка расстояния, например), то удаляем себя из этой таблицы, а на finalize экшна непися ... еще раз удаляем себя из таблицы (на тот случай, если финалайз вызван переходом в оффлайн, например, считаем, что добежали), вставить его же собственное удаление через alife():release(), или если вылеты, то косвенными способами - через промежуточные функции и таблицы. Итог: бегут неписи, постреливают, шхерясь и абсолютно несинхронно, к вертушке и один за другим исчезают "в ней" после чего вертушка деловито завывая улетает Главное - запоминать состояние таблицы в сейве.

[offtop] - хочу велосипед. - могу предложить тандемную модель, с зонтиком и фумигатором... Зачем человеку то, что он не просил? Извините, но не удержался. ЗЫ это не конкретно к посту N6260 относится, а вообще - такие советы сплошь и рядом. [/offtop] Сообщение от администратора _And_ Стрим, так ведь адаптировать не все могут и умеют (и еще меньше хотят этим заниматься)- а там все готовое и практически без багов. Был бы где-нить более подходящий набор выложен - указал бы на него. Как-то так

stalkers not blind - старый и не очень хорошо реализующий эту задачу мод В амк Ред75 сделал куда более адекватную схему, на рестрикорах

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

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

вот и говоришь "Перепробовал все" Ладно, от сердца отрываю... в state_mgr_animation.script запихни вот это куда-то в середину: npctrade = { prop = { maxidle = 5, sumidle = 5, rnd = 100 }, into = { [0] = "norm_hello_0" }, out = nil, idle = { [0] = "stend" }, rnd = { [0] = { "net_0_0", "idle_0_idle_3", "idle_0_idle_2"} } }, а в state_lib.script - это: npctrade = {weapon = "strapped", movement = move.stand, mental = anim.free, bodystate = move.standing, animstate = "stand", animation = "npctrade" }, PS А вообще, если хочешь знать все анимки - ставь таки сдк, а то много мимо пропустишь. Например, там можно делать .anm файлы и делать летающие аномалии, или облет камеры

Плохо пробовал Открываешь Actor или Level эдитор и там у непися просматриваешь анимки.

есть, ищите и обрящете

Monnoroch, Про БТР и вертолеты - обратись-ка к LostStranger'у или OffBar. Он под этими никами известен. Он тебе все-все расскажет и про езду бтра и про полет вертушки и даже про полет ГГ на этой самой вертушке (это относится и к Мастер с обрезом) Торговля, имхо, в первую очередь и должна быть зрелищной - ясно, что за действо происходит, у меня, например, жмут друг другу руки при встрече. А что там внутри происходит - пофигу ваще. Kirag, а не пробовал глядеть амк? или ты думаешь, там просто бтр с логикой? у него, например, и он-хит мы добавили с Ред75. (кстати, тоже обратись к OffBar'у, избежишь огромного количества ошибок и неприятностей при разработке) n6260, а я уж и не помню, что я там отцитировал, оставляли б оригинал шютка