Zander_driver

Совсем обленились... Ну для начала можно было тут прочитать Если мало, вот пример... function Custom_Caption(cap, st, use_icon) --вызов дополнительного сообщения local icon_tip = use_icon or "ui_iconsTotal_esc_blockpost_case_to_trader" local task_texture, task_rect = get_texture_info(icon_tip) local stl = "iconed_trade_info" if st then stl = st end db.actor:give_talk_message(cap, task_texture, task_rect, stl) end Вот такая функция принимает на входе 3 аргумента. 1) текст, что написать 2) (необязательно) шаблон вывода из XML файла "config\ui\talk.xml" или "config\ui\talk_16.xml". Если не указан, ставит iconed_trade_info по умолчанию. 3) (необязательно) выводимая текстура. Если не указано, то берет текстуру ui_iconsTotal_esc_blockpost_case_to_trader

@dPlayer, использовать метод give_talk_message.

Это совсем неплохо имхо, лодка в сталкере смотрится уместнее, чем все колесные транспортные средства.

Дополню, как я бы решал подобные задачи =) 1 предмет - физ.объект с указанным визуалом, т. не-инвентарный предмет вообще. Прикреплен к террейну за кость модели, так что ни сдвинуть, ни взять, ни уничтожить или куда-то деть его нельзя. У модели чтобы был бокс взаимодействия с игроком, т.е. на жмаканье "F" на ней она все же реагирует и дергает несложный скрипт, в котором проверяется, получен ли главгероем искомый квест. 2 предмет - инвентарный, с таким же визуалом. Когда ГГ по квесту жмакнет F на первом предмете, первый предмет удаляется, а второй спавнится актору в рюкзак. До тех пор первый лежит как нерушимая недвижимость и по нажиманию F лишь проверяет, что "еще не время". как-то так.

Смутно припоминаю, что где-то, когда-то видел пост @Malandrinus, с описанием добавленной в ХЕ функции, позволяющей получить список имен костей существующих в модели, мировой или худовой. Сейчас вот кинулся искать - не нахожу почему-то, ни в шапке, ни поиском по теме. Ткните носом, где она, или хотя бы как называется.

Приношу всем извинения за то что пропадал неделями и месяцами в последнее время. А так же хочу сообщить: Началась работа над ОЧЕНЬ МАСШТАБНЫМ обновлением мода "Судьба Зоны". В связи с этим, открыт дополнительный набор в команду закрытого бета-тестирования. Тестировать надо будет много... В закрытый бета-тест поступило обновление - Судьба Зоны 0.5.1

@sergei30, Вообще-то, там же. В actor.ltx. Но может лучше разобраться в какой мод играете. Ума не приложу зачем здесь менять этот параметр

Допустим задача. Засунуть объект в слот, скриптом. Можно: 1) Написать в движке/взять готовый движковый метод. Для взятия указанного объекта в слот. Вызываем его - цель выполнена. 2) Написать комплекс скриптов, которые удаляют то что в слоте сейчас, удаляют то что из инвентаря надо положить в слот, затем спавнят то что надо положить в слот - т.к. слот пуст, оно туда автоматически запрыгивает, затем спавним то что из слота извлекли в инвентарь, и еще не забыть всякие свойства-параметры вроде заряженных в ствол патронов и нацепленных глушителей не потерять. Вот это - костыль. Куча действий для достижения искомой цели окольными путями, с выполнением кучи всякого, не относящегося к поставленной задаче напрямую. Однако работает, и поставленную задачу - выполняет.

Если утрировать предмет спора до безобразия... @Serge!, полагает, что классом водителем можно считать лишь того, кто имеет в кармане водительское удостоверение, выданное уполномоченной для этого структурой в соответствии с законными процедурами. @Malandrinus, полагает, что классом водителем можно считать любого, кто сел за баранку и стал ее крутить, нажимая еще и на педали. И с ним я склонен согласиться, но это не важно... Назвать что угодно можно как угодно, и любые критерии применять для того чтобы определять, является ли рассматриваемый объект водителем или не является. Я все же склонен считать что если машина поехала - значит за рулем водитель. А проверять у него наличие водительского удостоверения, это вообще-то не моя обязанность. Я доехать хочу. Точно так же, если мы с чем то можем использовать методы и подходы ООП, значит это ООП, и то с чем мы эти методы и подходы реализуем, мы будем называть классами. И даже не обязательно в Lua писать "class" при этом.

Не все и не всегда Но временами они и в самом деле поднимают ненужную панику. Как то раз я в течение двух лет пользовался компьютером без всякого антивируса, активно пользуясь интернетом. Проблем никаких не было, тот компьютер исправно работает до сих пор. Операционная система в норме и не менялась.

Хосспаде да сколько можно. Начнем с того что все что вы изложили в своем посте, я и так знаю, и думаю что всякий, кто понимает ООП немного лучше чем "это что-то непонятное", понимает ситуацию в Луа вполне адекватно. А во вторых, сами же цитируете меня. Это не Луа. Неужели не видно?

@*Shadow*, вроде файлы отвечающие за миникарту вообще в патчах не менялись, так что должна быть совместима с 20-м так же как с любым другим. В шапку темы добавлена информация о создании страниц в ПДА. Так же, просьба сделать шапку темы видимой на всех страницах этой темы.

Название, наверно?

Ну если прям вообще новый класс, то это через движок. И никак иначе. А если на основе существующих, то не такой уж он новый. Так ведь будет все по разному, для разных классов. нпс, монстр, пистолет, аптечка, ящик с хабаром - у каждого свои нюансы и подробности, хотя все это игровые объекты.

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

И что ж теперь, "Луа-ООП" и ООП назвать нельзя?

Ну в данном случае, так и делается. В некоторых случаях, если заранее известно что надо будет искать определенный элемент таблицы, проверять есть ли такой или нету, можно записывать данные не в значения, а в ключи таблицы. Например: local tbl = {} tbl["text_1"] = true tbl["text_2"] = true if tbl.text_1 then -- Наши действия... end Плюс такой конструкции в отсутствии цикла, но это не всегда применимо, требуется изначально затачивать таблицу под такие действия.

Долг, Наемники, Военные, Военсталкеры. Не занимаются обменом артефактов, поэтому у них такого диалога не бывает никогда. Янтарь и Сахаров пока не доступны. Про выброс, давно было вот здесь: http://www.amk-team.ru/forum/topic/13348-sudba-zony-kovyriaemsia-v-fajlakh/page-10#entry1032224

А на что мне обижаться? вопросы вполне резонные, обидного ничего в них не вижу. Абсолютно согласен, в данной теме это оффтоп, и потому прошу модераторов перенести этот и предыдущие посты, начиная с поста #410 включительно В тему: Судьба Зоны: Ковыряемся в файлах Там им будет самое место. Ну и, учитывая что пост под перенос, на прозвучавшие вопросы отвечу тут же. Точно так же, как если бы это был любой другой мод или оригинал. Все то, что можно вычитать в туторах на эту тему по сталкеру ТЧ, точно так же будет работать и в СЗ. 1. Те же действия, которые нужны для подключения новой локации к оригиналу ТЧ или любому моду на его основе 2. Зарегистрировать новую локацию в скриптах СЗ, в тех местах где есть список локаций мода с какими либо данными. (Просто добавить свои данные).

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

Находится на тестировании в команде ЗБТ.

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

Да, работают. По поводу изменений графа, сетки. Можно и нужно однажды сделать так, как хочется, и затем уже приступать к спавну гулагов при помощи пушки мододела, не меняя граф и сетку более никогда. Спавн аномалий, тайников и зверья происходит динамически, используя ту сетку что есть в наличии. Тут уж можно переделывать столько раз, сколько заблагорассудится, скрипты каждый раз будут работать с тем что есть на данный момент. sdk не приемлю, для установки гулагов и их работ использую "пушку мододела", все остальное, как уже говорилось, спавнится динамически. На те локации, и те сетки, графы, что есть в наличии, какими бы они не были.

Работать-то оно наверно будет без проблем, но мне глаз резануло) Обычно переменные с названием se_obj подразумевают серверный объект. А функция level.object_by_id возвращает клиентский. Потом при копании спустя время в своем же коде, попытках его модифицировать, развить, написать новый на его базе. Такие ляпы приводят к риску внезапных и порой трудновычисляемых багов.