Dennis_Chikin

"Смысл сей витиеватой фразы ускользает от меня... " Смысл прост: "мы|они пахали, выискивая крохи информации по всему интернету, чем вы лучше ?" - встречается до сих пор. Так же как "пользуйтесь поиском, на форуме все есть". Опять же свежий пассаж Маландринуса про нудное и неблагодарное занятие. Так вот хочу сказать, что это ни разу не предмет гордости в контесте что кто-то угробил кучу своего времени, собравшись сделать что-то хорошее, и может быть сделал одно, вместо десятка, а может - вообще в итоге плюнул, и так и не сделал ничего. И если кто-то имеет силы/желание - лучше бы десять раз собрать всю эту нформацию и десять раз выложить в разных видах, чтобы время на это БОЛЬШЕ не гробилось ни чье.

Модостроение в целом, как оно сложилось - сложилось безобразно. Форум в определенной степени отражает, да. Вместо того, чтобы перелопачивать форум, было бы полезнее, чтобы те,кто хочет, занимались таки делом. В частности, в той же соли действительно с теми же текстурами - ужас. Чтобы далеко не ходить, могу предложить глянуть хоть на ту же xm8para или FAMAS. Или, что касается картоделания, проблемы в куче модов с локациями "Болото" и "АТП" - ну переделывать эти карты надо. Скриптовая база ужасна, да. ОГСЕ занялись чисткой, в Соли идет генеральная чистка... Когда это кончится - ни кто не знает, поскольку чем дальше в лес, тем толще партизаны. Ну, я могу сказать, что в соли устранили некоторое количество "вечных" безлоговых и "стековых" вылетов. И какое-то количество тормозов. Еще больше осталось. Гулаговых, монстровых, оффлайн, текстурных, шейдерных... Людям, которые сделали справочник - однако спасибо большое, но он уже весьма толст, и местами - хоть в части того же factory - несколько эзотеричен. К картоделам и текстурщикам я даже не суюсь, поскольку "объять необъятное". Структуризация, если бы у кого было время и желание, была бы не лишней. А вообще моя мечта - общая скриптовая и графическая база. Когда кто-то видит нечто, нуждающееся в исправлении, и кладет в нее свой исправленный кусок в формате "- было" "+ стало" P.S. Дядюшка Бобби, что касается солянки, то есть тема "разработка". За текстуры отвечает тот, кто готов что-то сделать с какой-то конкретной текстурой. amik, той текстуры неба, надеюсь, уже нет. Но еще дофига всего осталось. Визуалы неписей, например. Или вот неплохо бы что-то сделать с кустами и камышом - хотя это уже, конечно, не текстуры.

Нормальная соль 19.04, которую я буквально 2 месяца назад скачивал со всех трех ссылок из "Описание мода и ссылки на скачивание" - для ускорения процесса, ага - а потом тупо переименовал файлы - великолепно, быстро и стабильно идет на "Серебряном издании". Ни каких даунгрэйдов не требуется. Требуется скачать, распаковать архив, положить куда сказано, накатить патч. Кажется, патч идет сразу с двумя версиями - для 1.0004 и 1.0006. Более того, следующие версии, что я сейчас и проверяю как раз на "Серебре", адаптаций требовать не будут вообще. Мораль - не пользуйтесь кривыми источниками.

С выбросом будет все не так. Сейчас - под старый, делать нецелесообразно. Вообще правок всего и вся будет очень много. Кто хочет помочь - подключайтесь непосредственно к разработке, берите интересующий вас кусок, и пытайтесь с ним что-то сделать. Единственное но: сейчас вылезло очень много проблем, идущих даже с оригинала. Все те вылеты, которые "ни кто не знает: почему" и прочее. По многим уже знаем. Так вот прежде чем добавлять что-то новое надо таки поправить старое. Чтобы в кои-то веки уже нормально заработало. И, да. То, что код всего накопившегося за годы - ужасен - все как бы в курсе. То, что сама логика этого кода заведомо глючная - тоже в курсе. То есть, "мы тут у себя написали маленький безглючный модик, отсоединив 2 скрипта от таймеров - зацените наш крутой скриншот", и с намерением потыкать пальцем в лохов, которые эти 2 скриптика еще не отсоединили - как-то тоже не требуется. Сделали - молодцы. Давайте будем интегрироватьс тем, что есть. Если по ходу дела еще 10 скриптов и 50 конфигов исправите - все будут только рады.

По поводу голода в Соли нормально все. А вот арты есть такие, что лучше снять. И если Скат-15 - я бы его тоже того, от греха... "только бег постоянный сделал" - вот не трогайте вы ЭТИ параметры. Бег, вес, торговлю... Вы окончательно сводите с ума и так глючный пысовский движок. Есть куча альтернативных способов, гораздо более безопасных. Хотя-бы "народное творчество" внимательно посмотрите, если уж на форуме не дают писать рекомендации по БЕЗОПАСНЫМ правкам. (Задумчиво): сделать, что-ли, чит-пак, все-таки ? К следующей допе ?

Там все смешнее. Часть праметров берется от текущего часа, часть - от следующего, а часть - синтезируется "на ходу". Так что в целях подбора - выставлять одинаковые для 2-х соседних секций, и смотреть, чтобы по ходу не вырался другой конфиг - если выбирается - то ставить в обоих, и всего будет 4 секции. Эмбиенты ждут кого-то, кто приложит к ним руки. Там много вкусного, но большая часть давным-давно не работает. sound_period - скорее именно период между звуками. effect_period - частота того, что не работает - проплывающие клочья тумана, пыль, и прочее. Впрочем, надо медитировать над конфигами "целиком", а не построчно.

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

Поможет - не поможет, но по крайней мере скажет, в чем проблема. По крайней мере если в smart_terrain в первой строке заменить 20 на 1. Плюс what_about нашел решение для некоторых проблем старых древних (еще от ПЫС даже) но надо сначала узнать, что за проблема. Править все подряд может привести к несовместимости сэйвов в лучшем случае.

Посмотрел присланные логи. Мда-ааа... Несколько известных уже крутейших косяков ПЫС, одна ошибка по спавну - Сапсан уже нашел и исправил, но еще не выкладывал. Есть ошибка по АТП. Раньше не видел, но, похоже, вылез какой-то косяк с бандюками темной долины, который правили все подряд аж начиная с DeXX'а, и, видимо, так и не доправили. И еще какая-то неведомая фигня - монстры и бандюки где-то по какой-то причине все время дохнут, а потом все, кому не лень, пруться со всех локаций в попытках занять освободившееся место. Правки ничего не делают, а просто показывают ситуацию. Ну, кое-что, впрочем, исправилось - по-моему, как раз то, что призвана править "правка по респавнеру". Кто смелый - попробуйте ее отключить и воспроизвести известный глюк с недостатком id. Интересно, что получится. Вообще я бы посоветовал уредить респавн через se_respawn.script. Но это поможет не для всего. P.S. Кстати, упомянутые кабаны, галопирующие от ТД на Агропром - вот это точно так и задумано если не ПЫС, то amk. Не знаю, почему их раньше не было. У меня она слишком перекручена в обратную сторону. Лока может неделю пустая стоять - как раз под мой стиль прохождения. Новую игру не надо вообще ни с какой целью - что стряслось - то уже стряслось, что может - все равно стрясется. Правкой олспавна занимается только Архара - Великий и Неделимый. К новой допе авось поправит, если руки дойдут. А так - на экпериментики: тупо и банально находим поиском в se_respaw.script строчку вида "idle_time:setHMSms( math.random(" и ставим что-то по вкусу между тем, что есть, и моим экстремистским idle_time:setHMSms( math.random(48, 96), 0, 0, math.random(self.idle_spawn_min, self.idle_spawn_max)*1000)

Нужен ликбез: Монстры/неписи визуально совершают какие-то движения - скажем, сидят, потом побежали, потом развернулись, еще что-то сделали... С началом/концом каждой фазы наверняка связан какой-то код. Прочитанное намекает, что это - state_mgr*.script. Но там внутри много всего, и все равно непонятно, как это соотносится с наблюдаемым визуально. Задача: узнать, из откуда-нибудь (хоть вывести в лог из того же стэйт-менеджера, лишь бы это было как можно проще): что сейчас происходит визуально. То есть, что начал делать данный непись, делает ли он это, или уже повис, и момент, когда он наконец закончил делать то, что начал, если вообще закончил. Ткните носом во что-нибудь ? Полтергейст, со стэком - я, кажется, нашел архитектурную проблему в более другом месте. Сейчас осмысливаю. Коротко, если вдруг есть возможность заменить у объектов методы can_switch_*() на переменную - должно ощутимо полегчать во многом разном. А вот с состояниями - в том-то и дело, что вылеты. Без логов. Со специфическим визуальным проявлением. Хочется докопаться до причин. Достаточно было бы в нужных местах вставить диагностику: кто последний - тот, очевидно, и виноват. P.S. smart_terrain проще, imho, закрасить, чем отскребать. Это - ад.

(Отдельным постом, для ясности.) Shadowman, скрипты выкладывать имеет смысл для того, чтобы встретившие вылет/затык, и просто желающие потестировать - их положили себе в гэймдату, прошли/конкретизировали место вылета и дали либо саццесс стори, и/или кусок лога уже с осмысленной диагностикой. Для тех, кто готов править скрипты руками или осуществлять еще более осмысленную деятельность - нужны на самом деле diff'ы. На самом деле мне жаль темы "ваши правки" - именно как отладочной - если бы там бы еще грамотно фид-бэк организовать. Ну, это я как человек, испорченный нарзаном - той же pr-базой, мейл-листами и csup того же, скажем, freebsd.org, говорю. Понятно, что сложившийся в модмейкерстве стиль работы - мягко говоря, перпендикулярен. Лог - это для другого. Он для привлечь внимание к сути странного, или например подтвердить отсутствие тех или иных изменений. Это как раз то, что приведено. И то, что выложенным набором скриптов сгенерировано именно что НЕ будет. Суть же неправильности в том, что отрегистрация монстов началась сразу после входа на локацию, и то, что сообщения про отрегистрацию оказались внутри сообщений о работе уборщика. Причем он сам уборщик в это время только еще сталкеров крутит, а до монстов добраться не успел. Впрочем, правильная отработка события там выглядит так:

MAV, на самом деле "хардкор" от рыскающих монстров можно, и даже нужно уменьшить. Расположив их места обитания так, чтобы нормальные люди имели выбор: идти туда, или нет. И перемещение, соответственно, от одного такого места - к другому, тоже в стороне от основных тропинок. Пересекать - иногда можно. Будет польза от бинокля. Сергей, это две стороны одной медали. Много не очень страшных (для опытного игрока), зато нудных(для всех) монстров где попало, vs. сложность охоты на одного действительно страшного. И это не решается правками оружия, артов и регенерации. Но альтернатива - основательное перелопачивание всех-всех локаций.

Белые, голубые, и прочих странных расцветок деревья - это чисто отношение fog_color и hemi_color. Такого есть в количестве и без всяких правок. Первое должно быть примерно на 0.1200-0.1500 меньше, чем второе. А вообще, как рекомендовал The Reaper - подбирать для каждого случая так, чтобы объекты вдали сливались с фоном. Кстати, о птичках - точнее, об резких переходах освещенности: кто-нибудь знает, чем обрабатывается clouds_color, особенно последние 2 значения - скриптами или непосредственно движком ? Если движком, то разница между соседними секциями должна быть не более 0.300, в том числе и для переходов от одного типа погоды к другому. Если все-таки есть скрипт - ткните меня в него носом. Ибо жажду кое-что подправить. dimos, я уже проверил, и даже выкладывал типа демонстрацию. Все distance - это расстояния, по достижении которых начинает отрисовываться то, чему оно соответствует. А цвет - это такая странная штука, у которой более двух ипостасей. До примерно 0.8 она окрашивает предметы, а больше - начинает появляться собственно затуманивание. Засветка - это и есть эффект окрашивания. Upd: 0.1xxx, естественно. Поправил, где заметил. Амбиент, похоже, без разницы. Это - "самосвечение". Подбирать в зависимости от sun_color и hemi_color, чтобы не получить слишком высокую или слишком низкую контрастность: типичный пример - помещение между южным блокпостом Бара и собственно внутренней частью локации при солнечной погоде оказывается как бы не темнее, чем при более мрачной. А если задрать на 0.01 - 0.02 выше некоего оптимума - получаем светящиеся стены. (да, есть что-то общее с туманом и светящимися елками, но те - вдали, а это - вблизи.) Еще момент - большинство параметров берется, внезапно, как некое среднее от начала текущего и от следующего часа, и только несколько - ровно от начала текущего. То есть, при экспериментах надо выставлять одинаковые для 2-х соседних секций. P.S. И цвета - RGB, не RGB, но по крайней мере не в диапазоне 0-1. Скорее коэффициенты какие-то. Upd2: про fog_color криво сформулировал. Там комплекс из fog_color и fog_density. 0.8 - это про fog_density. Аналогично - с rain_*, но там другие значения, хоть и по тому же принципу.

Долго пытался понять - стабильный-ли глюк, или нет... Похоже, да: безлоговый вылет на ДТ в начале или конце выброса. Не критично - ни кто не заставляет пережидать его там, но как-то неаккуратненько. Подозреваемые: два сталкера-нейтрала около вертолета (у меня переодеты в долговскую экзу), тушканы, снорки. Кто напорется, и кому будет не лень - было бы неплохо сократить количество подозреваемых и проверить: это только при выбросе или при ЧУ тоже ?

По поводу вылета у avesamk: получил еще до загрузки ДТ на его сэйве вот такое: [error]Expression : assertion failed [error]Function : CInventory::DropItem [error]File : E:\stalker\sources\trunk\xr_3da\xrGame\Inventory.cpp [error]Line : 220 [error]Description : InSlot(pIItem) Причем вот эта часть: * Game admin_autosave.sav is successfully saved to file 'i:\stalker\data\savedgames\admin_autosave.sav' - Disconnect sv reject. id_parent [0][actor:single_player] id_entity [51471][ammo_9x39_sp5:ammo_9x39_sp551471] [26690] и т.д. - поразительно напоминает максимум того, что мне когда-либо удавалось вытянуть из "Лабиринтового" вылета. Что обращает на себя внимание - очень большое кличество ремкомплектов. Не знаю, исправили или нет, но раньше у меня при таком количестве переполнялся нет-пакет. Shadowman, это хороший метод, если добавить запись в лог. Кажется, есть кандидаты на тестирование. А вот почему у меня этот сейв сам по себе практически неработоспособен - вопрос другой.

Интересно, а насколько осмысленно использовать конструкции вида if string.sub(obj:name(),1,3) == "af_" then ? Sapsan, ага... Что-то такое следовало ожидать. Поражает скорее эффективность обработки регэкспов. Но для получения вменяемого выигрыша здесь придется устроить глобальное переименование всего и вся и перелопатить кучу кода.

К вопросу о призрачных зданиях на АТП (такие же призраки при некоторых условиях могут быть на других новых локациях): это не здания, а рамочки на границах "дальности видимости", где при приближении будут отрисованы деревья. Радикально может быть исправлено только теми, кто занимается картами. Крутить настройки - может помочь, а может и нет - не заниматься же этим при смене каждого часа и погоды ?

У неписей я заметил в основном бинты и наборы типа "4 балалайки, 2 гитары и 5 гармошек" Кстати, не уверен, что тупо сокращение объектов, носимых неписем, и вообще имеющих парент'ов на локации, на что-то повлияет сильнее, чем сокращение общего количества, а также количества и длительности операций, выполняемых над каждым из этих объектов одномоментно. В оффлайне НЕТ инвентаря. Так что резать имеет смысл именно дубли разноцветные, всякие научники/экзы без ПНВ, и всякие извращения самих ПНВ - оставить max 4 вида, и то не для всех. А что касается тайников и общего количества всего - для чего весной код выкладывался ? Кстати, да, его вполне можно подключить и для неписей. Отсутствие инвентаря не мешает удалять и спавнить. Но все-таки думаю, что имеет смысл сделать им полноценную торговлю - когда непись, накопивший n ненужных для выживания предметов, рокируется с неписем, находящимся в соответствующем гулаге около соответствующего торговца, и по достижении места избавляется от хлама. Shadowman, раз: http://www.amk-team.ru/forum/index.php?sho...6545&st=500, с поправкой, что fog_density таки 0.8 и меньше; два: http://gettyfile.ru/629086 По поводу ПНВ я таки подозреваю, что имеют значение сами размеры конфигов, а не то, что есть у неписей. По тому что бандит на свалке, являющийся владельцем 5 предметов, тормозит практически так же неприятно, как Арни, являющийся владельцем трех сотен бинтов.

По поводу варки артефактов я бы таки заменил в amk_mod.script в обоих проверках "> -2" на "> -5". А вот мне интересно: что у нас нынче с Джеймсом творится ? Наемники появляются, но сам Джеймс по прежнему желтый. Как источник неисчерпаемого лута - это, конечно, забавно, но нет ли опять какой-нибудь ошибочки ? upd: Да, вот эта конструкция: amk.start_timer("change_npc_community", math.random(5,10), {npc:id(), "killer"}) - в new_dialog.script - "почему-то" ничего не делает. Вернул у себя взад, хотя и через таймер, npc:set_character_community("killer", 0, 0) P.S. оффтопик, но, не могу не сказать, что результаты правок по текстурам на встроенном видео - внушают. Ставить всем.

Shadowman, ящики действительно дают подтормаживание, особенно на новых локах. Я выкладывал логи, где видно: почему так. Аналогично - трупы, пока не убраны. Кроме того, избыток хлама = лишние, ненужные операции как в amk_offline_alife, так в wather_act. Как и неписи-коллекционеры. Впрочем, по хламу и коллекционерам скоро уже все будет. Upd: ящики - да, все, что можно разбить. Возможно (не проверял) - вообще все перемещаемое. Трупы - штук 5 на локацю - погоды не делают, а уборщик вроде справляется. Вот когда они оставались и копились, скажем, на тех же на Агро/Янтаре, и туда же набегали живые - было уже заметно. Вообще суть засады примерно такая: потестили локу - вроде все хорошо - оставили возможность появления на ней свежего мяса, пока уборщик не почистил ранее настрелянных тушек - у кого-то внезапно начались странности типа тормозов/вылетов. Или, скажем, сделать квест с отстрелом пары десятков каких-нибудь крыс, а после смерти последней добавить в онлайн еще десяток чего-нибудь живого из расчета на то, что тушки ресурсов больше не жрут - это тоже будет плохой идеей.

Терминаторы: по результатам экспериментов выяснилось, что в конфигах должно быть health_restore_v = 0.00x (где x может содержать любое разумное количество нолей или не содержать вовсе) для всего подряд. Сколько раз поиском находится - стлько и править. Тогда реакция на остальные параметры чего угодно где угодно станет осмысленной. Иначе скорость регенерации слишком высока, и вражина убивается либо слишком быстро, либо вообще ни как. Та же ситуация, что и с правками по луту. P.S. впрочем, damages.ltx я у себя все равно поправил - в сторону большего разнообразия.

Это не вылет, но таки баг. Или глюк: собачки, которые должны кушать Лиса (а потом - Проводника) спавнятся почему-то только в 00:00, и прямо на голову Лису. И то, что Сидор теперь не дает спальник и детектор радиации - это так и задумано, или тоже где-то что-то глюкнуло ? also, не вижу трупа вояки по ветке с экспедицией. 1.0006, 20.08.2010 upd: по п.п. 1 и 3 - отбой - был какой-то разовый глюк. При НИ все отработало нормально. По спальнику и детектору вопрос остается - сообщение: "получен детектор" - есть, предметов - нет.

Magnum_357, gamedata\config\scripts\atp\atp_torgash_heli.ltx: ;on_info = {+atp_vert_vzlet} heli_move@fly4 %=arhara_dialog.atp_sedoy_dell% on_timer = 220000 | heli_move@fly4 %+go_heli_torgash% глючный рестриктор удалять как и все остальное глючное. Arhara, я таки не один день с ним дивным сексом занимался. Не знаю, как оно задумывалось, и как оно после последнего патча, но ситуация, когда рестриктор и вертолет живут сами по себе - была. И пока его не отправишь на heli_move@fly4 принудительно - все может работать (вылетать) очень весело.

Я пытался понять, как все это дело работает в xr_logic.script особенно save_logic/load_logic. Вроде как все работает. Но есть в количестве объектов с уже пожизненно отрицательным временем, и с положительным. И оно вполне может внезапно измениться. P.S. А вылет на собственно сохранении, или потом ? Вылет прямо при сохранении. По отрицательным значениям - наверное ты читаешь/смотришь на беззнаковые как на знаковые числа. В этом случае первый бит интрепретируется как минус. sapsan

Это не про ковыряние, но, кто-нибудь, снимите меня с ручника: if wpn_data[obj:section_name()][p_obj:community()] then get_console():execute("load ~DC~: add_item to: "..p_obj:name()..", "..p_obj:community()) local wpn_pri = wpn_data[obj:section_name()][p_obj:community()] get_console():execute("load ~DC~: wpn_pri1: "..tostring(wpn_pri or "nil value")) else get_console():execute("load ~DC~: add_item to: "..p_obj:name()..", common") local wpn_pri = wpn_data[obj:section_name()].common end get_console():execute("load ~DC~: wpn_pri2: "..tostring(wpn_pri or "nil value")) результат: ! Cannot find saved game ~dc~: add_item to: esc_soldier_respawn_10153, military ! Cannot find saved game ~dc~: wpn_pri1: 36 ! Cannot find saved game ~dc~: wpn_pri2: nil value P.S. То есть, понятно, что "end" в данном случае закрывает область видимости объявленных до него переменных, но с чего бы вдруг ? Я вижу в описаниях языка такое свойство "end" для циклов, но не вижу для ветвлений.