Malandrinus

Vano_Santuri, Биндер, методы reload, reininit, respawn. Почитай, что-ли, мою статью про object_binder, я там это вроде как всё разбирал. Есть ещё метод в виде класса client_spawn_manager статья здесь. В виде Святого Духа... Нет, ну в самом деле, а что-то есть в Lua, кроме объектов?

Vano_Santuri, Ага, представил себе живо картинку. Надевает себе Меченый новый костюмчик, только разбежался - раз, толчок в спину. Что, такое? Оборачивается - никого. Подпрыгнул - раз, пинок под зад такой, что аж на два метра подлетел... А если серьёзно, то нереально сделать. Физика на актора не действует.

Влад, В acdc есть вся нужная информация. Достаточно иметь нескомпилированную версию acdc (сырец на Perl-е), знать серверный класс объекта и иметь любой рабочий пример с нетпакетами (например создание аномалии или вертолёта от Бардака).

Garry_Galler, Если важен конечный результат, а не метод, то можно просто пересоздать список с новыми размерами и старым содержимым.

Garry_Galler, У меня получилось только менять высоту. Изменение ширины работает криво: ширина элемента меняется, что видно по форме выделения, а вот скролбар остаётся на месте. Если на самом деле удалось, то не мог бы запостить рабочий фрагмент?

Министр, Может всё-таки имеет смысл придерживаться сбалансированного подхода: стирать, но не сразу. Ставить стандартную метку на сообщение: "было, юзай поиск", или что-то в этом роде. И стирать помеченные сообщения, скажем, через несколько дней при отсутствии разумной реакции. Стирать сразу и молча - это как-то... слишком уж жёстко. Возможно, человек уточнит вопрос, или просто зарытая в "минус 123-м посте" информация всплывёт наружу и получит новое описание. Если же нет, и автор поста просто будет сидеть и ждать, что ему всё разжуют и в рот положат - тереть безжалостно. Помнится, когда я сам задавал вопросы здесь и на офф. форуме, то было принято как-то отписывать о результатах поиска или изысканий. Понятно, что это не может быть обязательным, заставить это делать никого нельзя. Но это - правило хорошего тона в подобном сообществе, некая "плата" за пользование общественным сервисом =)

Garry_Galler, Да именно это. Нет, к сожалению, это не выйдет.

Ирбис, используй любое средство для поиска файла, содержащего искомую строку. Я предпочитаю Total Commander. Ответ на этот и подобные ему вопросы займет у тебя не больше минуты.

Niko1995, Это не НПС.

Dennis_Chikin, для клиентского объекта - метод kill, для серверного - метод on_death. Остальное - выясняешь самостоятельно.

Сказал бы хоть, что делал. Это ошибка при чтении параметров настройки анимации ходьбы. Ссылка на эту секцию указана в параметре секции непися step_params. А далее там таблица. Вот пример для сталкеров (с комментариями из оригинальной игры): [stalker_step_manager] ; order: left, right ;-------------------------------------------------------------------------- ; animation Cycles | time1 | power1 | time2 | power2 | ;-------------------------------------------------------------------------- dmg_norm_escape_0 = 1, 0.2, 1.3, 0.65, 1.3 dmg_norm_walk_fwd_1 = 1, 0.2, 0.2, 0.65, 0.2 ...... Вероятно, что-то там накосячил (может случайно) в этой секции.

dimos, Это вот такое перечисление (взято из отладочного билда 2947) enum RestrictionSpace::ERestrictorTypes { eDefaultRestrictorTypeNone, // 0 eDefaultRestrictorTypeOut, // 1 eDefaultRestrictorTypeIn, // 2 eRestrictorTypeNone, // 3 eRestrictorTypeIn, // 4 eRestrictorTypeOut, // 5 }; in - это понятное дело куда входить не надо. out - откуда не надо выходить, но таких в природе не встречается. Отличие default (0,1,2) от "просто" (3,4,5) понять сложно. Рестрикторы с default вроде где-то там регистрируются, но зачем - я не знаю. Может они действуют на всех, потому и default. 4 и 5 тоже нигде не встречаются. Видно, что 0 и 3 - по идее одно и то же - просто зона, а не рестриктор (ограничитель). В игре они используются вроде как для одних и тех-же объектов. Однако, по моим ощущениям eRestrictorTypeNone (3) игнорируется игрой вообще, в то время как eDefaultRestrictorTypeNone (0) для чего-то может использоваться (что собственно и может вызывать проблемы). Как именно используется - этого я не знаю.

ФеНиКс, Для этого есть комбинированная операция mad (mul + add): pos = pos:mad(dir, dist) Могут начаться проблемы из-за несоответствия нового положения и вертекса уровня. Так что может потребоваться вычислить новый вертекс уровня. Для этого можно использовать функцию: level.vertex_in_direction(<вертекс уровня, от которого ищем>, <вектор направления поиска>, <расстояние>) Господа новички, Честно говоря, обленились вы последнее время. Задаёте вопросы, на которые в этой же теме отвечали неоднократно. Это отбивает всякое желание помогать. Надо понимать, что прочтение всей этой темы и архивной в придачу является обязательным делом, прежде чем пытаться задавать здесь вопросы. Да, это займет день или может даже несколько. Но levelup после этого гарантирован. И неплохо бы научиться пользоваться поиском. Если ни того ни другого не осилили - скажу прямо - делать здесь нечего.

Gonarh, "Вы просто не умеете их готовить..." =) Да вроде как работает чекбокс и без особенных проблем.

Garry_Galler, Я думаю, что так и придётся сделать. С восстановлением состояния кнопок не должно возникнуть никаких проблем. У меня нормально задавалось начальное состояние кнопок: видимость, включённость и пр. Немного общей информации в тему. Покопавшись немного я обнаружил интересный факт. Начало новой игры отнюдь не всегда означает, что все объекты будут созданы заново. Вот например то-же окно инвентаря (и вероятно все остальные стандартные окна) остаётся тем-же самым объектом вплоть до выхода из программы. Это означает в частности, что если вы поместили на это окно свою кнопку, то эта кнопка там останется даже после загрузки другого сохранения. Похожим образом ведут себя диалоги, инициализированные скриптами. Диалог инициализируется один раз при первом запуске и остаётся таким вплоть до выхода из программы. Вероятно есть и другие компоненты с таким же поведением. Так работает некая оптимизация, хотя на мой взгляд это совершенно лишнее. С другой стороны, никак не выйдет поместив на стандартное окно свою кнопку радостно работать с ней и после загрузки новой игры. Не выйдет! Более того, это может вызвать проблемы даже после того, как инвентарь просто скрылся и открылся заново. Дело в том, что окно инвентаря экспортировано самым минимальным образом. После того, как оно скрывается, скриптовая обёртка для него благополучно помирает (несмотря на то, что внутренний объект остаётся). Если вы не сохранили нигде ссылку на кнопку, то уже никак не вытащить обратно. Если сохранили, то нет никакой уверенности, что в этой ситуации всё работает согласованно, поскольку такого рода трюки никак не были предсмотрены разрабами. Так что нет никаких гарантий, что ваша кнопка будет работать как надо. Я бы предпочёл поступать по возможности аккуратнее: открылось окно - навесили кнопку, закрылось - тут-же отцепили и почистили за собой. Собственно я так и сделал, и проблема вроде как решилась.

Garry_Galler, Я таки понял, что за вылет имелся в виду. Похоже, что имеется некая проблема с деаттаченными окнами. В итоге код вышел не такой тривиальный, как я думал в начале. Однако, вроде работает. 1. Используются теги action для служебных инфопоршенов открытия и закрытия инвентаря. Может это и не обязательно, но так выглядит более упорядоченно. [spoiler=изменения в config\gameplay\info_portions.xml] <info_portion id="ui_inventory"> <disable>ui_inventory_hide</disable> <action>inventory_addon.on_show</action> </info_portion> <info_portion id="ui_inventory_hide"> <disable>ui_inventory</disable> <action>inventory_addon.on_hide</action> </info_portion> 2. Используется пустое скриптовое окно для а) получения сообщений от создаваемых контролов б) для корректного удаления контролов. После отсоединения контрола от окна инвентаря присоединяем его к этому служебному, и вроде как всё удаляется без проблем. Пример см. ниже. В верхнем левом углу создаётся чекбокс, по нажатию делается невидимым. [spoiler=Файл inventory_addon.script] inventory_wnd = nil attached_btn = nil rec_wnd = nil class "stub_wnd" (CUIScriptWnd) function stub_wnd:__init() super() self:Init(0,0,1,1) end function stub_wnd:__finalize() end function stub_wnd:btn_action() attached_btn:Show(false) end function on_show() rec_wnd = stub_wnd() inventory_wnd = level.main_input_receiver() attached_btn = CUICheckButton() attached_btn:SetWndRect(10, 10, 50, 25) attached_btn:InitTexture("ui\\ui_btn_02") attached_btn:SetStretchTexture(true) attached_btn:SetText("test") inventory_wnd:AttachChild(attached_btn) rec_wnd:Register(attached_btn,"btn") rec_wnd:AddCallback("btn", ui_events.BUTTON_CLICKED, rec_wnd.btn_action, rec_wnd) attached_btn:Show(true) end function on_hide() inventory_wnd:DetachChild(attached_btn) rec_wnd:AttachChild(attached_btn) attached_btn = nil rec_wnd = nil end кровоSTALKER, только в пределах того-же уровня, что и ГГ. Надо, чтобы метод серверного объекта can_switch_offline возвращал false. Stalk15, А хоть что-то известно о твоём НПС? Пока это выглядит как "сделай то, не знаю что"

Народ, кто мне объяснит, что не так с доп. кнопками на окне инвентаря? Я долго не тестировал, но вроде как работает без особых проблем. Кнопка создаётся, по обработчику нажатия отсоединяется и, соответственно, исчезает.

Stalk15, а второй объект-то задал? npc - это должен быть клиентский объект-собеседник. Непонятно, откуда он у тебя возьмётся в той функции, которую ты вызываешь.

Stalk15, Чего там подробнее расписывать? Функция простая, как валенок. Вызвать её, и все дела. Добавлено через 209 мин.: Jurok, Есть проблемы с удалением объектов в онлайне, а раз ты наблюдаешь за ним визуально, значит объект точно в онлайне =) Попробуй перед удалением перевести объект в оффлайн, а ещё лучше удалять объект, находясь на другой локации.

Stalk15, db.actor:run_talk_dialog(npc) работает на расстоянии до 3-х метров.

Dennis_Chikin, Опять меня запутал. Разве в упаковщике патронов лишние пачки не удаляются? Но ведь с остальными предметами так не выйдет. И при чём здесь таблицы? sapsan, Я как-то задался целью выяснить разницу между "прямым" индексированием и "хешированным" в случае использования целочисленных индексов. Вроде как должна была быть разница в случае упорядоченного или случайного заполнения. Никакой разницы не обнаружил. По всей видимости вычисление хеш-функции от целого числа довольно малозатратная операция, как и сравнение на равенство, и существенно вклада в общее действо "операция индексации Lua" не вносит. Ну и естественно, доступ по ключу-строке на порядок медленнее. Медленнее только для случая, если точно знаешь индекс. Если же не знаешь - нужно искать перебором, что будет медленнее доступа по индексу-строке (если перед этим таблица не была отсортирована и не использовать бинарный поиск, хотя, при большой таблице, даже в этом случае хеш-доступ может выиграть за счет одноразового расчета местоположения данных по ключу) sapsan

кровоSTALKER, Убрать из апдейта и поместить в более подходящее место. В данном случае - в колбек на взятие предмета.

valdemar093, недосоздал по видимому. Там ещё надо помудрить с нетпакетами. Вот пример от Бардака, про аномалию там тоже есть. З.Ы.: Странно, сходу не нашёл никакой статьи на эту тему, хотя где-то вроде видел.

Dennis_Chikin, Я как-то проводил замеры и выяснил, что выгода в применении таблицы в этом случае начинается при количестве ветвлений где-то в районе 7-8 (точной цифры не помню). Если всего два варианта, как в твоём примере, то смысла использовать таблицу нет, посколку время выборки (с использованием хеш-таблицы, помните?) хоть и почти постоянное, но больше, чем просто ветвление по условию. Но надо не попасть в ловушку. Используя цепочку if-else плюс незатейливый копипаст можно запросто написать что-то в этом роде: if <вычисление длинного выражения> then elseif <вычисление того-же длинного выражения> then и т.д. Ясно, что в этом случае условное выражение будет вычисляться в среднем "длина цепочки пополам" раз, что может эффективно убить всю производительность. Добавил: ожидаю 1 на пару сотен позиций, или штуки 4-6 до полусотни Признаться, не понял, что имеется в виду. Добавил 2: Думал сначала, что понимаю о чём ты, но теперь запутался окончательно. Вот расстреляй меня, но не понимаю твой вопрос. Какой-то запутанный пример, и мысль про "одну большую таблицу", и что имеется в виду под "делить её"... Не въезжаю =(

PavelSnork, Если б мишки были пчёлами... Слушай, ну включи логику на минуту. Если бы можно было, зачем тогда GSC делать новый движок для ЧН, а потом для ЗП?