подскажите плиз если я в левл едиторе изменю положение спавн обьектов то они в игре изменят положение? (В смысле не level.spawn а all.spawn)? приоритет где больше скажем так?
Вычисление макимального левел вертекса по соответствующему гейм-вертексу для данной локации дает число = 3971, однако, один из монолитовцев (спавн из all.spawn), имеет путь, с точкой в 3981-й левел-вертекс. И то, что в оригинальной игре это никак не вызывает ошибок и доп.проверка валидности этого вертекса - говорят о вполне корректном значении, которое лежит за пределами вычисленного диапазона доступных вертексов.
Само собой. При определении макс. левел-вертекса, мы ведь только определяем центральный левел-вертекс максимального гейм-вертекса. А сколько их ещё находится там же, не известно.Вот график гейм-вертекса, и находящихся в нём левел-вертексов:
Где, зелёный квадрат - гейм-вертек, красные квадраты - левел-вертексы.
Определяя левел-вертекс, по гейм-вертексу, мы получаем центральный левел-вертекс. В данном случае, под номером 40. А ведь их ещё несколько в диапазоне гейм-вертекса.
По сути, определив количество левел-вертексов в пределах одного гейм-вертекса, можно посредством математических действий, определить и действительный макс. левел-вертекс. Но... Фиксировано ли количество левел-вертексов, в пределах гейм-вертекса?! Оно ведь может быть и разным. Разве что, пробегаться по всем гейм-вертексам (от минимального, к максимальному), и так же не хитрым мат. подсчётом, определять их размеры. Так как левел-вертексы начинаются с нуля, то составить мат. действие не составит труда.
Это только предположение, и как вариант. А по сути, нужно всё полностью проанализировать. И наконец определиться в зависимостях гейм и левел-вертексов. Как они связаны? И что вообще из себя представляют левел-вертексы?
Казус валидности со значительным превышением макс. значения, мне тоже не даёт покоя.
отредактировал(а) singapur22: 04-07-2011 13:10 GMT3 час. Проект "Mobile Manager" закрыт, в связи со стечениями неблагоприятных обстоятельств, и последующей потерей всех файлов и справок текущего проекта.
singapur22
Предлагаю отвлечься от упрощений, так только запутаемся.
Исходные данные (кратко):
1. Гейм-вертексы (Gv) являются элементами структуры (сетки) глобальной карты. Их последовательность непрерывна для всей карты. Каждая локация имеет некий диапазон Gv, присущих только этой локации.
2. Левел-вертексы (Lv) - элементы структуры (координатной сетки) каждой конкретной локации, собственно и определяющие позиционирование на локации.
3. Взаимосвязь между Gv и Lv жесткая, но условна и определена при компиляции всей глобальной карты с локациями. Кол-во Lv соотносящихся с конкретным Gv для каждой локации свое и различно.
Понятно, что перебирая все Gv и определяя некий Lv, являющийся условно центром области сопоставленной с данным Gv, мы получаем некую сплошную область (собственно почти равную рабочей площади локации). Однако,
как минимум из однозначно определенного валидного кол-ва Lv, находящихся внутри области, остается неопределенным периметр, т.е. области тех Gv, которые приходятся на края локации. Эта полоска/кайма и является искомой целью, т.к. немало объектов располагаются именно по краям карт (переходы, пути, и т.п.)
Цель: Получить достаточно безопасный (для процесса игра) метод/инструмент определения рабочего диапазона левел-вертексов и на краях карт, для безопасного использования как для спавна объектов, так и для их перемещения.
К сожалению метод определения валидности Lv как в ЗП, в ТЧ отсутствует. Метод определения по доступности координат элемента координатной сетки приводит к фатальным ошибкам при выходе за рабочую область.
Теоретически можно методом итерации и фиксации в логе проверенных индексов Lv получить некие крайние значения, но ... это будет частный случай для конкретного набора скомпилированных локаций и не универсален.
Требуется безопасный метод ... Пока в тупике ...
Artos Попробывал снимать координаты валидных левел-вертексов, вне диапазона определяемого общеизвестной функцией. По большей части, получил вообще казусные результаты. Координаты выдавались в основном вне геометрии. Тоесть, или ниже геометрии, или выше её. Но многие, просто за пределами локации. Некоторые выдавали дублирующие координаты. Тобишь находятся в тех же координатах, что и некоторые из пределов диапазона. Короче, некая свалка вертексов (вне диапазона), разбросанных по всей локации, возможно даже не привязанных к графам. Возможно, это вообще мусор, образовавшийся неидеальностью компилятора локаций.
Тут уже дело вопроса. А нужно ли их юзать?! Может стоит ограничиться теми левел-вертексами, которые находятся в пределах определяемых гейм-вертексов?! Тем более, размеры гейм_вертексов, не на столько велики, чтобы визуально было заметно несоответствие макс. значения. Да и определение всего дипазона левел-вертексов не происходит только у одного (последнего) гейм-вертекса.
Ещё бы не мешало узнать, как производится компиляция вертексов. Пронумеровка, я так понимаю, производится во время компиляции, а не во время построения локации. Если так, то в каком порядке она производится?! Возможно ли такое, что макс. гейм_вертекс, может оказаться не с краю локации, а по её центру, или где ещё, в её пределах?!
отредактировал(а) singapur22: 04-07-2011 17:24 GMT3 час. Проект "Mobile Manager" закрыт, в связи со стечениями неблагоприятных обстоятельств, и последующей потерей всех файлов и справок текущего проекта.
singapur22
Думается что востребованность есть и будет, поясню.
Если не принимать в расчет ошибки кодеров при заселении локаций и определения точек в путях, то все одно остается и оригинал игры и куча нынешних модов, которые сидят на потенциальных ошибках.
Не так давно, расчистив очередной пласт заглушек от разрабов, на Янтаре обнаужилась ошибка, при которой Зомби прописан камп в несуществующий вертекс. Начав копать далее увидел, что достаточно большое кол-во точек путей с разных локаций явно заглушены разоабами. Им присвоен или гейм-вертекс заведомо за пределами глобальной карты (51048) или левый левел-вертекс (-1).
Установив заглушку от использования подобных путей по принципу предварительной валидации точек пути по принадлежности к рабочему диапазону левел-вертексов локации - всплыло немалое кол-во огрех метода.
1. Выше уже упоминал о монолитовце, которому прописана точка пути на самом краю локации (Управление монолитом). Эта точка лежит как раз на всего десяток индексов выше максимума. В итоге запрещение этой точки привело в вылету по стеку из-за постоянных дерганий схемой. Отключать же схему - рушится геймплей.
2. На локации Саргофага точки для вертушек с тем же десантом лежат выше диапазона на ~4000 (~1%) ...
3. Немало точек для направления взгляда также уводят за вычисленный диапазон.
... и т.д. и т.п. Вспомним уходящих в даль на Янтарь Круглова и д.р.
То, что ты обнаружил дублирование координат и пр. 'мусор' - стОит помнить, что координатная сетка местами слоеная. Как еще НП могут передвигаться по разным этажам домов ...
Вот за алгоритм компилляции не скажу, тут нет пока достаточных познаний. Однако уровень до компиляции имеет уже координатную сетку, которая служит основой AI-сетки. Конечно нумерация зависит от конечно выбранной точке отсчета (начала координат). А вот порядок ... хм ... если вспомнить локацию "Кишка", то можем совсем запутаться, локации часто далеки от близких к классическим кругам и прямоугольникам. Математический просчет 'от формы' тут врядли возможен.
Пока только идея:
Если мы можем вычислить расстояние между центрами соседних гейм-вертексов -> можем вычислить средний шаг между ними для любой локации.
Если можем узнать кол-во левел-вертексов, укладывающихся в этот шаг -> можем вычислить среднюю плотность и уже ориентировочно кол-во вертексов с учетом края ('окаймления'), т.к. имея ориентировочный шаг между гейм-вертексами -> можно накинуть на края по пол-шага (иль для надежности чуть менее).
Но оптимальным все же было бы найти безопасный метод для валидации любого разумного индекса.
Пока же ... чуть больше -> тихая смерть треда.
Strchi, если ты изменишь положение spawn-объектов в редакторе, выполнишь команду Compile --> Make Game, из полученных файлов level.spawn собирёшь all.spawn (например aiwrapper'ом (-s)) и положишь его в папку с игрой (если у SDK отдельная папка) так, что он не будет перекрываться другим файлом all.spawn, тогда положение объектов в игре изменится.
По поводу приоритета, вроде, level.spawn не влияет на объекты в игре.
у меня еще вопрос, как сделать такую приятную графику как в солянке? (нехочу чужие файлы брать оттуда) а настроить все сам, (в смысле не текстуры а шейдеры?) я так непонял насчет настройки шейдеров (например перенос из билда 2215 тех самых r2 с тенями и динамическим освещением?) просто я думал сделать зорю утреннюю чтобы тени были как надо! (Красота русской природы))):-)
Приступил к редактированию автоматов и нашёл такую строчку: min_radius = 30 ; [] for AI - эта строчка что делает и этот коммент что обозначает? И ещё хотел спросить, какая строчка отвечает за точность при одетом глушителе? Dark Skripter, подскажи пожалуйста, в ui_wpn_params.script что надо править если я изменял скорострельность, удобность и точность собираюсь?
отредактировал(а) Dmitriy_Dark_Stalker: 06-07-2011 14:53 GMT3 час. Лишь коснется лууунный свет меня,
И в волка оообращусь вмиг я!
Разрежет тииишь ночную воой,
Вновь я теряяяю облик свой!
Я вот скачал ACDC. Решил попробывать путь сделать. в way на escape сделал свой путь. поставил его к нужному нпс, а он просто по зоне гуляет. Расскажите как пути сделать для НПС или ссылку дайте на обучение.
добавлено спустя 5 минут
И есть где-нибудь учебник по SDK? Ничего там понять не могу...
отредактировал(а) VOva-VIP: 06-07-2011 16:31 GMT3 час.
отредактировал(а) Angel from Hell: 08-07-2011 11:31 GMT3 час. Труд свободных скриптеров-любителей тяжел и утомителен, полон ошибок и багов, но в то же время интересен, захватывающ и благороден.
Upgrades mod build 1.006 готов. В журнале есть новое видео.
Подробнее в журнале.
VOva-VIP есть там! компиляций уровня в игру нажми в игре параметры задай название и качество (чем меньше тем быстрей) батник в сдк создай и пропиши @start bins\compiler\xrLC.exe -название карты (с тире) которое прописал в параметрах и в кордоне например l01_escape надо в параметрах прописать чтоб в сингле был измененный! если что в ПМ мне пиши!
Mehanik Yar Метод level.set_time_factor(number). Скорость течения времени в игре. Где, number -- коэффициент скорости (во сколько раз быстрее, должно проходить время в игре, чем в реале).
Проект "Mobile Manager" закрыт, в связи со стечениями неблагоприятных обстоятельств, и последующей потерей всех файлов и справок текущего проекта.
Mehanik Yar Вот функции на основе метода**5001618d69873ce82a42** level.set_time_factor(F)
news_manager.send_tip(actor, "%c[0,-170,-45,-170]ТАЙМФАКТОР СТАНДАРТНЫЙ: "..F, nil, nil, 10000)
end[/code]
karavan а как, если можно? :-) Я просто решил сделать например, если на тебе вблизи монстр напал какой-нибудь. Все конечно если монстр мощный начнут патроны высаживать все. А вот если бы можно было быстро доставать нож и быстро им махать. Куда интереснее, да и патроны тратить не надо.
Эта тема закрыта, публикация новых сообщений недоступна.
Продолжая пользоваться сайтом, вы соглашаетесь с использованием файлов cookie. Страницы сайта могут содержать информацию, запрещенную для просмотра посетителям младше 18 лет. Авторское право на серию игр «S.T.A.L.K.E.R» и используемые в ней материалы принадлежит GSC Game World.
