Dennis_Chikin

Чтобы загнать непися в укрытие - это надо самому руками сначала найти укрытие, что-то типа local cover = enemy and npc:best_cover( npc:position(), enemy:position(), 20, 15, 100 ), и потом руками же загонять туда непися, типа if cover then send_to_nearest_vertex( npc, cover:level_vertex_id() ) end и проверять, дошел/не дошел, либо есть что-то более интеллектуальное, "спрятаться наилучшим образом", и чтобы сам дальше "соображал" ? ТЧ интересует.

Гм, а разве поиск и захват подстроки - не полностью взаимоперпендикулярны ? При условии, что вообще нашлось то, что подходит под шаблон ? %|* - внутри шаблона захвата - должен захватить и | тоже, если дальнейшее совпадет с остатком шаблона. В шаблоне поиска, но до захвата - найтись, если есть, и быть пропущенным. %d+%|[^%|]+ - тут все понятно. Захватываем то, что на надо. %p* за пределами шаблона захвата - как раз поиск разделителя, без его захвата. Это для parse_data(). Для parse_zone_data() вместо %d+ будет [^|]+ (и, кстати, за такие секции зон надо давать 10 лет строгого расстрела, так же как за секции всех прочих объектов и за имена файлов). Ну а для syndata - вообще без ключа, просто пары state@sound|state@sound должны быть... То есть, просто "([^|]+)%p*", по-хорошему. Я просто пытаюсь изобрести осмысленную строку, где первый | имеет смысл, и не могу. Вот это и озадачивает.

Artos, все равно не понял: в xr_wounded что-то типа: То есть, нет стейта - то и все entry в таблице той же hp_state н нужно. Опять же в parse_data() у тебя захват: for sField in sStr:gmatch("(%|*%d+%|[^%|]+)%p*")то есть, |10|st1@snd1 - она так и хватается, а дальше из нее выдирается ^| и далее по тексту. А почему не поиск/захват "%|*(%d+%|[^%|]+)%p*" ? P.S. С abort(), чтобы изнутри неписевых схем отрабатывал - разве что более другой движок. Иначе в лучшем случае будет сообщение в логе, а дальше - все равно висяк, с которым и сохраниться можно.

Интересно, а в соли (да и в оригинале) в моделях действительно есть анимации waunded_1_out и waunded_1_idle_0 ? Вообще, ни кто не пытался просматривать state_mgr_animation_list.script на осмысленность содержимого, и заодно вернуть ему читаемый вид ? Там же ахунг какой-то, особенно, в строчках idle: то явно не хватает "{", то "}", причем везде - в разных местах. Одно что общее количество - четное. И, кстати, дайте уже кто-нибудь "дочесоточный" скрипт (и вообще куда-нибудь ссылку выложите), а ? Денис, ты в скайп то хоть заходи иногда. Петрович. Запустил. Не люблю я это дело. Мешает только, а пользы - не так уж много.

[error]File : E:\stalker\sources\trunk\xrCore\Xr_ini.cpp [error]Line : 352 [error]Description : <no expression> [error]Arguments : Can't find variable строка in [секция] Здесь есть, но в виде частного случая. Попытка чтения несуществующей переменной вида ini:r_string( секция, строка ) (или r_float, r_bool и т.д.) 1. Убедиться, что переменная действительно зачем-то нужна. 2. Исправить код на local v -- или иное if ini:section_exist( секция ) and ini:line_exist( секция, строка ) then v = ini:r_string( секция, строка ) else более вменяемая диагностика end 3. Поправить конфиг при необходимости (см. п1)

Artos, по вариантам: state == {} - это нормально ? Захват первого | в подстроку - он зачем оставлен ? P.S. В абсолютном большинстве случаев abort из xr_logic.script не срабатывает. Так что передавать что-то неотловленное раньше, и непися/секцию/имя строки в parse_condlist и иже с ним - малополезно.

"Или могут быть варианты через | ? (запамятовал)" Разделитель. Там в итоге получается тоже таблица, как и в parse_data(). Вот что и где с ней дальше делают - не смотрел еще. Но шаблон все равно странен. И, естественно, сразу возникает мысль: либо такое действительно зачем-то нужно, либо это запчасть от чего-то еще, но недоделанное/обрезанное. И тогда если переписывать - нельзя ли упростить, либо чревато ахтунгом, если ЭТО в исходном виде переваривает нечто, что я еще не нашел, но где-то есть, а новый вариант на такое рассчитан не будет. То есть, если трогать, то надо разбираться, как же оно все-таки работает, и зачем ?

А вот я тут опять не понимаю, и опять с регэкспами. На этот раз соседний с parse_data xr_meet.parse_syn_data. Ну, то есть, st1@snd1|st2@snd2 он, положим, разгребет. Но там в поиске шаблон какой-вообще чудовищный, и мне интересно, что будет, если он по ошибке таки получит что-нибудь, реально начинающееся на | ?

Очевидно, в консоль была введена команда ":LAST INTO ID for [%s] = [%s], max [%s]" Например, при помощи get_console():execute( ":LAST INTO ID for [%s] = [%s], max [%s]" ) А потом также выведена команда "flush".

Ну а теперь profile_timer() в руки, и мерить варианты. И кстати, проверить случай с 50|{=best_pistol}psy_armed,psy_pain|20|=best_pistol}psy_shoot,psy_pain

"Вертикальная черта относится к классу %p" О, спасибо. Нет, оптимизировать так, по-моему, нельзя. Звук может быть не прописан. Как минимум, %@?([^%|]*), и проверка на ~= "". А с оптимизацией надо смотреть, и во многих случаях строки на разбор вообще не отдавать, сразу подставляя готовые таблицы. upd: И, кстати, сначала выделять только значение и строку, а строку потом уже еще раз разбирать. С учетом последующего (xr_meet.script) - что-то типа вот такого: ...мда, и моя любимая привычка с копипастом строк, не проверив имена переменных... Либо dist в цикле, либо d в tonumber(), разумеется.

Я не понял, куда делась ведущая вертикальная черта во второй подстроке. С которой позиция будет не 3, а 1.

Опять регэкспы, и опять я чего-то не понимаю: на входе: 50|{=best_pistol}psy_armed,psy_pain@wounded_psy\ |20|=best_pistol}psy_shoot,psy_pain@{=best_pistol}wounded_psy_shoot,wounded_psy Разбираем: for name in string.gfind( s, "(%|*%d+%|[^%|]+)%p*" ) do t_pos = string.find( name, "|", 1, true ) s_pos = string.find( name, "@", 1, true ) dist = string.sub( name, 1, t_pos - 1 ) if s_pos then state = string.sub( name, t_pos + 1, s_pos - 1 ) sound = string.sub( name, s_pos + 1) else state, sound = string.sub( name, t_pos + 1 ), nil endПолучается как раз 2 подстроки, так, как я разделил "новой строкой".Из первой и вправду получается позиция, два состояния и звук. А из второй ?

Ага, написано же, 1280x1024 или 1024x768. Широкоформаты не исправлены. Соответственно, в *16.xml не хватает много чего разного, и столько же лишнего. Папку crosshairs конечно же надо перенести в textures\wpn.

Поскольку тема о "невозможности" исправить "эсто-о-о-о-нскую" загрузку соли ползает из раздела в раздел, но затухать не собирается - вот слепок с рабочего каталога, который вот прям счаз. Конфиги - читерские, квесты половина не работает, по локам через болото до агры дойти можно, на свалку - не пробовал, половина функционала в биндсталкере не подключена, лог при выходе пишется аж пару минут... Тем не менее, представление о скорости загрузки дает. Более собранная, кстати, грузится ЕЩЕ быстрее. Но она прямо сейчас не рабочая, так что ее не даю. Здесь - только основа. Предназначено в основном для BFG и SergeT. Чисто позагружаться в разных местах/побегать по паре лок. Ну и для всех разработчиков для посмотреть, как сделаны апдейты, таймеры и прочие нетпакеты - живьем. И как править эсто-о-онское же открытие/чтение файлов. https://dl.dropboxusercontent.com/u/27871782/load_test.7z (35 мегов !) (Включение паузы во всех режимах не проверял, возможно, для самого первого запуска надо будет поправить в game_options.script, дальше она сама правильный конфиг создаст.) Исправление тормозов при загрузке рядом с большим количеством неписей, и лагов при их входе в онлайн (что, а общем-то, одно и то же) - править звуковой конфиг. Да, разрешение - 1280x1024, под широкоформатники xml'ы и текстуры не правил. Совместимости по сэйвам - нет. Вообще ни с чем. Ставить поверх чистой 03.09

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

Упрощенный менеджер погоды: https://dl.dropboxusercontent.com/u/27871782/level_weathers.7z Требуются добровольцы на тестирование. Сэйвы совместимы сюда, но не обратно. Чистая соль, совместимость с чем-либо еще - в зависимости от этого "еще". Что внутри: плоский, вероятность выбора погод задается в скрипте очевидным образом (доли от всех допустимых), в weather_transition_list можно писать целевые погоды просто через запятую, без двоеточий и индексов, для любой доступной - любые из доступных. Текущая погода всегда "участвует в конкурсе" на общих правах. Смена погоды вычисляется заранее, так что можно добавить в новости "прогноз погоды". "Вечная ночь" вроде как случаться не должна. К сожалению, от согласования погод по дождю, солнцу и плотности облаков руками ни куда не деться, если не править сам движок. Так что не все, что можно написать в конфиге, следует в нем писать.

Вот всякое желание что-либо делать пропадает... 8( "Вечная ночь", level_weathers.script: -- HACK: transition was initiated at wrong time so undo it if self.cycle_idx[self.dyn_weather] == nil then self.dyn_wather = tmp_dyn_weather endИсправить: self.dyn_weather = tmp_dyn_weather

Вопрос разработчикам всех веток: sol_sound.script кто-нибудь использует ? 14.08 я вижу только дергание апдейта. И сдается мне, что очереди там рабочие весьма условно.

Таки а почему-бы кому-нибудь уже не попробовать банально прописать проваливающимся артам jump_height побольше ? 0.5 для большинства достаточно. P.S. Переполнение нетпакета - это не арты, а новости. Впрочем, да - метки на сваренных, но неподобранных артах таки жрут.

Artos, Про ошибки хочу подробностей. Ну, кроме как про выкинуть остатки "псевдосовместимости" в виде подсчета количества переменных, которые низачем не нужны, но знатно тормозят. По поводу ограниченности - это еще всякую лабуду типа векторов сохранять ? Не, не нужна. Их все равно надо чуть не при каждой операции руками копировать, и при этом черт его знает, что у них там внутри. А модифицируется это в дальнейшем, если бы оно было зачем-то надо, просто тупо проверкой размера нетпакета после записи очередной переменной, и если больше максимально разрешенного размера - создаем другое хранилище, и продолжаем писать уже в него. Теперь возвращаемся к преобразованию таблиц в строки: С учетом того, что в луа для этого нет адекватных средств - оверхэд получается просто чудовищный. Сами данные при этом также разбухают (ага, тэги, да и просто num в strZ). Далее, получив строку, не лезущую в остаток пакета, я так понимаю, предлагается применить к ней string.sub(), в обрамлении некоторой логики ? Опять же, оверхэд. В то время, как при поэлементной записи делить ничего не надо - просто продолжать писать в другой. И так же и читать. Да, записаны данные получаются "рыхло". Сэйв увеличивается в размере. Но поскольку это происходит уже не в скрипте - это будет всяко быстрее. Zander_driver, а добавить контроль размера пакета после записи каждой строки, и писать его в лог - не ? Естественно, что при записи в него 8 кил - переполнится.

простейшая модификация оригинала: Загрузка - аналогично. Дальнейшая модификация путем скрещивания с "универсальным хранилищем" для толстых таблиц - очевидна. Осталось придумать, для чего бы могли понадобиться эти толстые таблицы.

sapsan, не нужно оно. По крайней мер в соли - точно.

https://dl.dropboxusercontent.com/u/27871782/xr_logic.7z К вопросу о преобразовании таблиц в строки и обратно, и прочем мусоре в нетпакете. А также о лагах. Оставлено куча старья "для совместимости" с недочищенным. Это, например, тип boolean в загрузке/сохранении, varname в функциях работы с pstor(и сами функции ) и все функции fname, имеющие своего двойника с fname1. https://dl.dropboxusercontent.com/u/27871782/bind_mteleport.7z - а это - к вопросу о толстых таблицах и netpacket-pda. Оставлено то, что требует лезть в allspawn. А так обращения к pstor нужно отсюда просто выкинуть. Ну и варку артов еще не оттестил.

По большому счету, даже выделенное хранилище совсем не нужно как таковое, со своим собственным API. Имеет смысл воткнуть его непосредственно в save_all/load_all. Все равно они вызываются исключительно при сохранениях/загрузках, но зато - всегда. А тем более не нужны постоянные бессмысленные конвертации таблиц в строки и обратно при передаче между функциями - в любом случае передается ссылка. Это просто-напросто трата памяти и времени. И даже при загрузке/сохранении получается опять же то же самое двойное/тройное преобразование, которое ведет лишь к разбуханию сохраняемых данных. Итого, всего лишь добавить к оригинальным float, bool, строка и объект еще один тип - таблица. ergo, прямо там и отслеживать размер пакета, и при необходимости начинать новый, что с таблицей - на много проще, чем с длинной строкой. P.S. А в соли мы вообще занимались полной ерундой, сохраняя мнимую "совместимость" сэйвов, когда все равно по куче других причин каждое дополнение == новая игра. И, кстати, меня слегка уже поддостало даже в той же соли выковыривать отовсюду кучу заведомо бессмысленных переменных, и еще более бессмысленных "конвертаций". В нетпакете у актора там хранить реально почти нечего.