Dennis_Chikin

Локации кривые. Там должно быть деление на какие-то хитрые области и переходы между ними. Размеры областей ограничены. Что-то на предмет освещения и отрисовки картинки за препятствиями. Подробности надо узнавать у тех, кто занимается картами. Сейчас для обхода этого безобразия приходится far_plane ставить не меньше 280 метров. Эта же фигня вызывает переполнение и вылет при отрисовке стрельбы (когда изменение дальности оказывается больше, чем сама дальность освещения от выстрела.) also, эффект с неотрисовкой поверхности можно заметить на входе в бар со стороны свалки, в баре же за забором, на АЭС (даже в оригинале). Astarot, погода для болот в оригинальной соли происана в файле weather_indoor.ltx ХЕМУЛЬ36RUS, классика жанра неработы того и сего в погоде - недоступность прописанного. Взаимосвязь между различными файлами погодных конфигов - это ад. Единственный выход - выставлять принудительно одну единственную погоду, переходы запрещать, размножать одну секцию на все часы, и тогда только экспериментировать с изменениями. За основу брать default1.

Есть непись. В олспавне ему запрещено браться под смарты. Олспавн трогать не хочется, но непися надо запихать в смарт. Можно переписать custom-data, но это как-то некрасиво. Можно (и, наверное, когда-то придется) переделать проверку условий для взятия под смарт. Но я вот вижу в ковыряемом файлики типа gamedata\config\scripts\sak\esc_fox.ltx содержимым вида: [smart_terrains] esc_stalker_camp = {-val_x18_door_open} sak_lager = {+val_x18_door_open} Сейчас такое впечатление, что они не работают. Но зачем-то ведь были ? И если бы их как-то задействовать - это было бы то, что доктор прописал. Как ?

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

С конфигами ситуация такая: Во-первых, мусор - он и есть мусор. То есть, все хвостовые пробелы, развесистые комментарии - они неполезны, поскольку тупо тормозят чтение и обработку. По чуть-чуть, но пара мегов мусора - это секунда-другая загрузки и сколько-то отожранной памяти. Во-вторых, каждая секция вида: [xxxx]:yyyy при чтении разворачивается во все предыдущие yyyy и что там было перед ними. То есть, добавляя одну секцию в жалкие 2 строчки мы на самом деле добавляем не 2, а много. Иногда и несколько сотен. Собственно, чем мне не нравится ООП - так именно этим: каждый ствол, который ни кому и никогда не понадобится, реально жрет. В принципе же особой разницы "изнутри" между 10-ю конфигами разноцветных бандитских курточек и 1 конфигом с теми же 10 бандитскими курточками нет. В памяти это все равно пара-тройка мегабайт и секундный лаг при входе бандита в онлайн. Отсюда, все бесполезное или одинаковое нужно убирать. Развесистость конфигов - в принципе, это уже вопрос устройства операционной системы. Есть некий оптимум между размером файлов, их количеством, и длинной пути к этим файлам. Сотня файлов в одном каталоге по десятку килобайт каждый - это примерно и есть этот самый оптимум. Та же сотня файлов, растащенная по сотне каталогов, даст тормоза вполне неиллюзорные. Если файлов будет не 100, а 100000 по 100 байт каждый - ну, дождаться запуска игры мало у кого терпения хватит. По скриптам - скорее наоборот. Большую часть надо делить, а потом выбрасывать дублирующиеся куски. Сейчас они и места дофига жрут, и тормозят в том числе из-за того, что выполняется много операций вполне бессмысленных. Скажем, перебор имеющихся у неписей предметов, да и просто проверки на живость, раненность, взаимное расположение чего попало относительно чего попало, и прочее. svn - штука хорошая, но его надо кому-то поддерживать. Сейчас - неактуален от слова совсем. Вообще же смысл его в том, чтобы видеть только изменения.

Взаимодействие схем будет еще меняться, несколько раз. Обыск трупов, перезарядка, смена оружия, реакция на врагов и гранаты - в том числе. Сейчас по сути имеем несколько разных модов, которые в принципе конфликтуют. Вставить все нужные проверки - ни какого железа не хватит. Надо весь AI в единый блок собирать. UPD: Я не вижу проблемы с подствольником. Если включен обычный режим - заряжаются, разряжаются, стреляют - обычные патроны. Если включен подствольник - все ровно то же самое происходит с гранатами. Проверял на LR300 и L86. Вот то, что либо текстура подствольников, либо текстура l86 с подствольником - кривая - это - да. Как и прицелы к АК/Famas/xm8_para. А 762x51 - вообще само по себе невалидное имя для патронов.

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

Вот интересно, почему local sim = alife() и далее по тексту - можно писать, а с vector() такое не прокатывает ? Универсальное правило есть какое-то ?

Mass, ограничения на емкость крайне желательны, да. Если раскомментировать строчку -- self:validate_jobs() -- dc -- А таки надо поправить ВЕЗДЕ ! в xr_gulag.script - в логе будет много интересного. В оригинале - неправленной соли вообще имеет место связка операций, ведущих к вылетам по нехватке работ. Поле правок вылет вроде ушел, но есть характерные "дергания" по периодическому выгонянию неписей из смарта/добавлению обратно. По запятым - на самом деле, можно, но некрасиво, да. Но вообще будет правиться. Банально как мусор. idle_after_death - по-моему, ошибочно - как раз наоборот. Это - период времени. А idle_after_death_end - это собственно время после смерти: if job then job["idle_after_death_end"] = amk.game_milliseconds() + ( job["idle_after_death"] or job_idle_after_death ) * 1000 end Вообще, готовлю большую пачку скриптов, где при появлении странного (в основном - в путях) неписи будут ругаться в лог, вместо того, чтобы молча виснуть. Но их, блин, много... 2ma666y, ну так выше же писалось: чаще всего - при попытке скриптов из разных плохо интегрированных аддонов последовательно удалить один и тот же предмет без проверки его существования. Скажем, аптечка удаляется сначала из xrs_medic (в стадии исправления), xrs_ai/xrs_bandage (оторвано нафиг, выложено вместе с "наркоманским" xrs), death_manager (исправлено ), да еще и где-нибудь в диалогах. А если труп попал в аномалию - будет еще и удаление всего(включая ту же аптечку) вместе с трупом. То же самое по патронам, оружию, гранатам, и еще куче всякого. Также, несколько ошибок в amk_offline_alife: сначала один и тот же предмет оказывается в базе, потом в "торговле" делается попытка несколько раз его удалить. Также неписю может попасть чужой предмет, и тоже удалиться. Кстати, с этим, и с удалением оружия без патронов связано пропадание оружия у неписей вообще (сначала удаляются "ненужные" патроны, потом - "бесполезный" ствол - хорошо, если не чужой).

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

Пока - никуда, если это не связано непосредственно с выкладываемым в разработке. Не думаю, что вот прямо сейчас кто-то напишет о чем-то таком, что не было бы известно и не будет исправлено в ближайшем будущем. Если ставятся файлы из темы разработки, и после этого появился вылет, которого раньше не было - можно мне в личку, например. С 20 последними строчками лога сразу. Только проверить, что вылет - действительно новый. Треть времени за последний год я убил, пытаясь найти в ИЗМЕНЕНИЯХ причину вылета, живущего в соли изначально. Ну и последняя неделя тоже в основном ушла на попытки понять, имею ли я вылет благоприобретенный, или "штатный". Если вылет на ООП, или еще каком аддоне - писать их авторам. Если поверх аддона поставили что-то еще - тогда писать сразу в спортлото. Upd: SergeT, ну, техподдержка - это вроде как понятно, что к тебе. Надо просто где-то шапку соответственно поправить, и прибить гвоздями. Возможно, и здесь, и в закрытых "вылетах". Но темы вылетов то для просьб о помощи вроде тоже были не предназначены - там о новых, и способах борьбы с этими новыми. Новых - давно нет - все древние.

Чаще всего - прилетел game_object туда, где ждали что-нибудь другое. Как правило - строку или number.

Наверное сюда вопрос: правильно ли я понимаю, что npc:critically_wounded() возращает не false/nil примерно на время, когда проигрывается анимация ранения ? Что она вообще такое на самом деле ? а npc:wounded() - это когда хиты непися ушли за некое пороговое значение (и кстати вот здесь примерно он должен лечь совсем ?) Как оно связано с конфигами ?

Никак. Ждать, когда я этот кошмар с переодеваниями, размазанный по всей гэмдэйте, переделаю полностью. Но там будет скорее жесткое сокращение всего и вся, и отдельная табличка, куда можно будет чего-нибудь добавить. Однако для добавления надо модели с текстурами, и желательно, чтобы они при этом были хоть чуть менее кривыми, чем сейчас. Mass, да. Ошибок в олспавне - куча. Вот, кстати, часть фиксов из того, что здесь выкладывается, не трогая собственно олспавн:

Запутался... Вручаем неписю в руки что-нибудь. Скажем, item:enable_attachable_item( true ). Вручилось. Непись замечательно проигрывает с этим предметом анимации - ест/пьет/на гормошке играет. Вдруг, внезапно, непись умирает. Что будет идеологически правильно: сделать enable_attachable_item( false ), ничего не трогать вообще, удалить итем нафиг, что-то еще(что именно) ? Код, который смотрю, делает первое. Причем, похоже, после того, как по on_death удалил сам предмет. Что странно. Ну, то есть, function action_foo:finalize() item = npc:object( "figovina" ) if item then enable_attachable_item( false ) end end удаление вызывается в on_death() из мотиватора раньше, чем вызовется action_foo:finalize(). P.S. На всякий случай переформулирую: я правильно понял, что в :finalize() схемы предмет можно дисейблить, только если выполнение схемы прервано нештатным образом, но непись при этом жив ? И, кстати, объект, наверное, стоит не получать прямо здесь по секции, а где-то хранить, на случай, если их c такой секцией окажется несколько ? А удалять у мертвого непися можно в любой момент, при условии, что он (предмет, да и непись тоже) ни кем и ни чем больше не трогается ? P.P.S. Аналогичный вопрос для случая с on_net_destroy(): с предметами в руках у неписей в этот момент, наверное, ничего делать не стоит ?

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

Получил сейчас вылет с интересной диагностикой, и нашел по нему вот это: http://www.amk-team.ru/forum/index.php?sho...25&st=2318# Интересно, тогда как-то разобрались с проблемой ? Чем-то похоже на обсуждавшееся вчера-сегодня ночью с регэкспом и обращением к _G[чего-то-там] Добавлено через 43 мин.: Artos, однако module, fname = string.match(func, '(%w+)%.(%w+)') превращает, например, arhara_dialog.lysyi_sms в dialog.lysyi. Так что тоже не самый удачный вариант. Гм... даже не подумал, что "_" - это разделитель и в смысле регэкспов. Очевидно, надо строки просить. Upd: Ага, спасибо за "|". Но пока оставим как есть, наверное, и будем ругаться/вылетать тупо по обнаружению отсутствия файла/функции. А то там всего можно ожидать... Пару раз на попытках сделать "защиту" уже обжегся - проблему непосредственно в месте обнаружения проходило, зато потом чудеса начинались.

Artos, оффтопить, так офтопить...

Я им где-то уже подкручивал. Не помню где. К сожалению, это не спасает от бреда, прописанного в логике явно. Ага, самого Волк, зазывно машущий руками с 10 метров, не то, чтобы раздражает, а даже, я бы сказал, несколько пугает...

Artos, Да, и здесь - тоже. Только гибрид чей-то правки с оригиналом: если нет модуля/функции - идем смотреть xr_effects, а не xr_conditions. И вообще много где, кроме как в этом фрагменте. Идея везде она и та же. А исполнение - разное. Как размножается код в модах ? В основном, копипастом. Потом где-то что-то меняется немножко. Конструкции получаются порою странные. И кроме того, что получилось, надо еще понять - а чего вообще хотели-то, когда делали. Кстати, по xr_logic - в приведенном куске нил возвращать вообще безопасно ? Или лучше на рабочий стол сразу нафиг ? О, как ! Значит все еще чудесатее, чем казалось сначала. Надо будет сравнить с оригиналом полностью и построчно, пожалуй.

По-хорошему тут, наверное, даже не string.match() надо бы, наверное. Поскольку ну очень сложно представить на входе нечто отличное от строки "myscript.myfunc" А порядок вызова точно правильный ? По тому что при внимательном рассмотрении простыни обнаружено как _G[fname], так и +G[module][fname]... Все. Кажется, дошло... Где-то крепко попутано имя функции, имя файла, и модуль... Надо по шагам разбирать всю простыню. 8( P.S. а отжигов в исходном вообще в количестве. Ну солянка же... Со всего инета все подряд, напихано как попало. Один разворот cs:wnd():SetText(string_format("%02d:%02d", time_h, time_m)) на 40 строк с аццкой логикой и десятком регэкспов чего стоит...

Несколько слов о скорости и оптимизации: в цикле проверяем: local v = { ["x"] = 1, ["y"] = { ["y"] = 1 } } local x = v.x local y,z for i = 1, 65535 do y = x end for i = 1, 65535 do y = v["x"] end for i = 1, 65535 do y = v["y"]["y"] end y = x: 260.15713500977, y = v.x: 553.06848144531, y = v.y.y: 952.81982421875 for i = 1, 65535 do y = v["x"]; y = v["x"] end for i = 1, 65535 do z = v["x"]; y = z; y = z end for i = 1, 65535 do y = v["y"]["y"]; y = v["y"]["y"] end for i = 1, 65535 do z = v["y"]["y"]; y = z; y = z end y = v.x: 931.75006103516, y = z: 698.38153076172, y = v.y.y = 1820.8509521484, y = z: 1122.001953125 Ну и так далее... Сложносочиненные таблицы на надцать уровней вложенности с надцатью обращениями в цикле на 100500 итераций - сами понимаете...

медитирую на код: local module, fname = string.match( func, "(.+)[.](.+)" ) func = _G[module][fname] if func then func() end Это я чего-то не понимаю, или действительно так надо ? KD87, ну, скобка потерялась при копировании. А вот что не так - не работает. И вообще говоря, если в _G оно не вывернуто как-то хитро, то должно таки [fname][module]. Или как ?

Ага, дошло. Я ж там в итоге проще сделал, чем думал сначала. Вот дифф ТОЛЬКО по варлабу:

Они теперь на своих местах, и не грозят вылетом "из-за слабого железа и посторонних правок" Разумеется, в чистой солянке 14.08 как минимум. Были просто вылеты без лога. Техподдержкой принципиально не рассматриваемые. Ибо рэндом. То, что причиной была химера, насильно впихиваемая с периодичностью цикла апдейтов в чужой смарт - я увидел уже при работе над новой допой. "Народная Солянка" от 14.08, она же от 3.09. Проблема: в смарт емкостью 19 неписей назначено 20. Результат - повисание смарта либо непися (что успеет раньше) с вылетом "stack overflow" или вообще отсутствием лога.

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