Viнt@rь

Автор:Viнt@rь(Spectrum project) Версия: Сталкер Зов Припяти[1.6.02] Размер: 1.2 МБ Список изменений/нововведений(Описание): “Дело было вечером, делать было нечего…” Делал для себя, но решил адаптировать под чистый сталк и выложить на всеобщее пользование Данная вещичка представляет собой набор инструментов и фич Инструменты: Отладчик/Дебагер скриптов Повелитель зоны Вывод лог-сообщений(текстов) Показ координат и остальная статистика ГГ Редакторы: путей и all.spawn Особенности: Автономность Опциональность Управление выводом логов Вся подробная информация о том или ином в РИДМИ, что в архиве Совместимость и возможные проблемы: Так как у меня широкоформатник, то настраивал положение и тп элементов опций под свое разрешение(1680х1050), на не широкоформатниках наложение элементов может выглядеть не корректно (но вроде бы проверял на разрешении (1280х1024), то критичных смещений элементов нет) ссылки на скачивание: ССЫЛЬ Использовались наработки след. Авторов Singapur22, Gun12, Xmk – Показ координат и тп. Shoker – Повелитель Зоны ЗП Редакторы путей и all.spawn – авторов не нашел Artos – некоторые фишки с кодом Отдельное спасибо: Artos и ColR_iT – за ответ на вопрос о фиче с полями таблиц Если нашли вылеты, недочеты и тд, или, если есть пожелания и идеи, по расширению данного набора инструментов, не стесняйтесь, отписывайтесь в этой теме… ЗЫ. Сильно не кричите, не бейте и не ругайте за описание ЗЫЫ. В архиве, так сказать, в подарок , идет редактор LUA скриптов(лично я пользуюсь им, так как в нем есть встроенная проверка синтаксиса, и советую выставить такие настройки шрифта: Courier New - Обычный - 10) Кажись все, вродь ниче не забыл...

Возвращает ли эта функция несколько значений которым равен ключ? тоесть key1 = value1, value2, value3... и еще: параметры number, string&, string& для чего здесь? глядя на пример использования: result, idx, value = ltx:r_line(section,i,"",s) возникает вопрос, что функция возвращает в result и почему передаваемые параметры по типам не совпадают с тем что написано в описании функции, что выше в цитате

ColR_iT, Artos, спс В принципе, я догадывался, что с полями таблиц можно такое творить, мне интересно было узнать, можно ли такое делать именно с такой формой обьявления переменной(local vName="vName"; vName="vName"). ЗЫ Artos, да, чет не подумал заглянуть в твои скрипты)) обычно оттуда и тяну все интересное/полезное/нужное, а тут совсем вылетело из головы)

Artos, есть одна идейка, сделать свой дебаггер/отладчик так сказать, точнее, усовершенствовать его, и выложить в люди, облегчить конечному пользователю использование данной вещички, вот с помощью таких "извратов" не надо будет создавать там к примеру 300 строк(каких то) за ранее и заставлять пользователя вписывать все под себя(к примеру в окне опций вкл выдачу/запись логовых функций из данного скрипта или нет(я имею ввиду инициализацию кнопок и тп)), сделать, так сказать, автономность, от пользователя останиться лишь закинуть скрипт куда надо и добавить в табличку, или в список в *.ltx(пока не определился), да и для себя тоже интересно, получиться ли такое или нет))

Ребят вопрос, возможно ли в LUA такое: ... for i=1,3 do local vName_..i = "vName_"..i end ...

Ребят, подскажите плз или дайте ссылку на то, как пользоваться функцией level.add_dialog_to_render(CUIDialogWnd*) (ЗП) нид срочно прикрепить к окну инвентаря элемент, просто создать кастомстатик не выход, так как в любом случае окно инвентаря накладывается поверх кастомстатика элемента Добавлено через 34 мин.: Разобрался как этой функцией запустить и вывести на экран оконный класс, довольно легко, но это можно сделать и более легкими путями. В общем все равно элемент остается под окном инвентаря, я так понял что можно мне нужный элемент приарттачить(хз как правильно пишется слово) к окну инвентаря, но не пойму как это сделать, будьте добры, подскажите плз

Vano_Santuri ВОТ! все что осталось из таймеров-хранилищ от xStream, все остальные паки/скрипты на хостингах были удалены, в том числе и наработки malandrinus

*Shoker*, у нас тоже был баг изза restrictor_type = 0, но повисал, судя по всему, апдейт актора, так как все остальное работает исправно, советую тебе попробывать restrictor_type = 3 - самый обычный(стандартный), пыс только его и используют(почти), а у нас, после исправления всех типов на 3 с 0, перестал повисать апдей актора.

*Shoker*, я имел ввиду как я показывал ранее, а с table.insert да и вообще со всеми table.***** 1. они очень медленные 2. у меня изза инсерта походу переполнение происходит и потом начинаются баги, что апдейт актора глохнит и сейвы бьются... да и вообще при начале разработки новостей везде использовались функции table.**** в итоге были повисания, баги(как изза инсерта, что я описал выше), и вылеты...

*Shoker*, вродь с table.insert(spammers, objId) -- Добавляем спамера. должно быть норм... хотя не уверен Vano_Santuri, и всетаки table.insert советую пренебречь(в последнее время начал опасаться этой дьявольской функции ) по поводу заполнения спамеров в таблицу:

*Shoker*, вот тебе пример ... local sTime = Time[math.random(#Time)] ... Таблица: Time = {"недавно","несколько минут назад","минут десять назад",...}

*Shoker*, ты ошибаешься) даже в таблице со строковым содержимым есть порядковые номера этих строк))) потому эти функции работают корректно

Vano_Santuri, небольшое предложение по function give_spamm(objId)

Artos, а разве хранение всех данных о нпс в еще одной табличке не даст той же нагрузки, что и проверка? К тому же, как я сказал ранее, радиус алайфа ну черезвычайно маленький(сделать больше - будут лаги), а ведь только онлайновые нпс обновляются... К чему я веду, к тому, что нпс в онлайне на локации мало, а убийств/смертей нпс еще меньше, тоесть проверка выполняется вообще мизерное кол-во раз(правда если ГГ не начнет гамселить всех и вся), так зачем же тогда создавать и заполнять еще одну табличку... если можно получить НПС из стораджа и из него уже "вытянуть" инфу... Твою точку зрения я понял и я с ней согласен, но все же... Если бы, все обьекты (хотя бы одной)локации были онлайн, то, то, что ты предлагаешь, надо делать в первую очередь, так как события происходили бы по всей локе постоянно, а не только там, где находится ГГ, и в таком случае проверка действительно выполнялась бы через чур часто... Лично у меня, в данном случае, это наблюдатель, для новостей типа видел/слышал, потому, такой вариант мне подходит, нет, даже больше, такой вариант для меня идеален Сорри, чет понесло в оффтоп...

Artos, да я знаю что можно имитировать, даже в голове крутиться как это сделать (по идее даже лучше пысовского варианта получиться, он терь будет фразы говорить в тему), просто не хотелось ломать голову, а сделать "на всем готовом", но, видать не судьба...

Vano_Santuri, а зачем вообще такой геморой? Свободно можно отсекать всех нпс и выбирать самого ближнего к трупу, не заполняя таблицу всеми нпс, которые вокруг. О таблице всех нпс на локе, зачем? радиус алайфа ну совсем мизерный... Мой совет, при убийстве нпс, просто искать живых нпс в определенном радиусе. Я давно заметил, что у тебя, сендером, берется первый попавшийся нпс, но ведь можно сделать так, что при каждом пробеге цикла будет искаться нпс, который ближе всех к трупу, ну тоесть:

Artos, спасибо. По поводу Сидора, да я отслеживал открытие закрытие окна торговли с помощью actor_menu.script, но при этом Cидор не переводится на другую схему, в смысле: if xr_logic.try_switch_to_another_section(self.object, self.st, db.actor) then return end

Вопрос глуповатый, но все же, подскажите пожалуйста, зачем регать инфопоршни в спец. файлах? И обязательно ли это, проверял на ЗП, разницу между зареганым и не зареганым инфопоршнями не заметил, так в чем же подвох, обьясните плз)))

Tris, ты даже не удосужился полезть в скрипты, почти, любого мода, так как во многих из них используются функции сохранения/загрузки переменных, например: скрипты Artos`a, амк мода, и тп, включая оригинальный, пысовский, скрипт xr_logic в котором есть функции эти функции: 1.pstor_store(obj, varname, val) - сохранение переменной varname с значением val в пстор obj 2.pstor_retrieve(obj, varname, defval) - -загрузка переменной varname из пстора obj, если такой переменной нет, то вернет defval в крайнем случае, можно воспользоваться сохранением/загрузки твоей переменной пакетом, выполнять действие на сейв/лоад актора.

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

Artos, ну так проблема в том что и вылета с логом нет(даже нечего показать), тоесть даже не заметно когда что то повисает в игре, игра продолжает функционировать, скрипты проверял все на чистом ЗП работают безотказно. К тому же, как говорят свои же, такая проблема появилась/была замечена еще как только были расставлены зоны убора оружия на локации(но они не обратили внимания), тогда скриптов в моде почти небыло... Сам я пришел в команду, когда локация была заселена, и при тестировании/прохождении для себя, я не заметил такого бага, столкнулся с ним при повторном тестировании всего и вся, по завершению работ на локации(сюжета), если бы хотя бы не повисал какой то процесс, то мне бы легче было найти причину ошибки... Логику проверили раз 10... ЗЫ если чесно, то я бага не заметил после тех двух изменений, но сегодня тестировал еще один член команды, он раз 10 наткнулся на такой баг, при том в самом начале игры, я же натыкался на него когда как. Я понимаю, что без логов гадать нечего, но и лога то нету, был бы я бы выложил... В последствии не знания что делать, я в надежде получить хотя бы какой то ответ обратился сюда. И еще раз повторюсь, проблемой является поломка зон убора оружия/работы дверей, следуя из этого можно сказать, что повисает биндер актора, так как останавливаются все таймера, не проверяется на то, в зоне ли убора оружия актор, бьются сейвы...

Немного дополню свой предыдущий пост: 2 проблемы искоренили(в последствии такой баг стал очень редким, но все же). Первой причиной было, как мне кажется, переполнение таблицы в скрипте(точно не ясно, что именно было причиной, но за комментировав все вызовы скрипта, частота получения бага понизилась, но все же... и остался тот же вылет, при загрузке сейва, сделанного во время бага) Второй причиной было то, что зоны убора оружия имели тип 0(restrictor_type = 0), после исправления всех типов зон на 3, частота бага еще больше понизилась, но опять таки полностью избавиться от него не удалось. ЗЫ Пробовали убирать все скрипты, но это не вариант, да и на чистом ЗП они норм работают, как мне говорят с тимы, такое с зонами убирания оружия и дверьми было еще в самом начале, когда на локации небыло ничего кроме них. ЗЫЫ Повторю суть проблемы еще раз Если поиграть/побегать по локе, то через время, прийдя в зону убора оружия, оно не убирается, в добавок двери не пашут, в смысле нету надписи открыть/закрыть, их можно толкать, а они будут шататься... С чем это может быть связано, прошу знающих людей подсказать/помочь, заранее спасибо. ЗЫЫЫ Мде, вышло что не дополнил пост, а переписал с дополнением, заранее извиняюсь. Сорри не видел, что Artos ответил, но все же может быть сюда зайдет кто то, кто сталкивался с такой проблемой.

*Shoker*, т. point_look у вертолета используется только тогда, когда он стоит на месте. проверил, не в скорости дело(

Так как раньше тема называлась "скриптирование, спавн и логика" и более подходящей темы для моего вопроса нет, то я задам его сдесь. Мб кто знает почему на движке ЗП вертолет, после пролета по паре точек, начинает лететь криво, тоесть: вот он спавнится, летит нормально мордой вниз хвост вверх, но при пролете через пару точек он начинает менять свое положение противоположно - морда вверх и хвост вниз, и потом летит так постоянно? Что пробывал: 1) делал точки как в ТЧ 2) все скрипты/конфиги были взяты из ТЧ и переделаны/адаптированы под ЗП Результат: все тоже самое