Kirgudu

@Kondr48, function gui_mechanic_wnd:play_repair_sound() math.randomseed(device():time_global()) local snd_obj = sound_object("scripts\\remkit\\ui_repairweapon_0"..math.random(1, 7)) gz_utils.s_play_no_feedback(snd_obj) end

@mechanicus, кардинальная разница в сюжете не смущает?

@Х_и_м_и_к, active = sr_idle [sr_idle] on_actor_inside = {+top_bor} nil %=xr_effects.hana_ano%вот этот вот "nil" завершает работу данной логики. Окончательно и бесповоротно.Соответственно, раз зайдя в рестриктор, ты сам же запрещаешь повторное его срабатывание.

@Max Warlock, возьми из ngsm_virtual_save функцию chek_obj_tbl и верни её, например, в модуль ngsm, с периодическим вызовом в on_actor_update. Модуль-то ты удалил, но вместе с очисткой глобальной таблицы от удалённых объектов, а это чревато тем, что я тебе в личке описывал. Но лучше всё-таки уделить время и переработать сохранение доп. свойств так, чтобы на апдейте они никак не сказывались.

А зачем их вообще отстреливать (понимай - намеренно)? Вопрос дилетанта, в том смысле, что я настолько далёк от всей и всяческой охоты, насколько это вообще возможно. Они же эти, как их, санитары леса - или нет? Разве что ради процесса или, скажем, ценного трофея...

Никто не обещал, что выбросы начнутся прямо сразу со старта игры. Да, 28 часов (с допуском в плюс или минус), но только после завершения основной сюжетной линии на той или иной локации, чтобы не поломать течение сюжета. Для Болот - после завершения войны между ЧН и Ренегатами и первого перехода на Кордон. Что же касается захвата хутора, отряд союзников не всегда приходит сразу. Это зависит, в том числе, от времени суток (ночью новые отряды не рождаются) и текущих целей группировки. Иногда ускорить процесс ожидания помогает сохранение-загрузка.

@pc-2, попробуй так: local sobj = alife():create("kurevo", vector(), 0, 0, db.actor:id()) level.client_spawn_manager():add(sobj.id, 0, function(id, obj) db.actor:eat(db.actor:object("kurevo")) end) А вообще этот механизм проверен годами, если опять не сработает, значит ты что-то не так делаешь.

Думаю, всё-таки n < 1, c = 14; Что как раз соотносится с тем, что я написал выше. Остальное тоже не противоречит. Интересно, что если передать напрямую слишком большое число (не важно, с десятичной частью или без), где-то в недрах обработчика от фонаря добавляется точка после первого же знака: count_decimal_places(2421212105221221) = 13 а следует это отсюда: string.match(2421212105221278, "%.[0-9]*[1-9]") = ".4212121052212" Забавно. Update. А вообще, как выясняется, там не всё так просто и для моего варианта. Например: function count_decimal_places(n) local r = string.match(n, "%.[0-9]*[1-9]") return r and r:len() - 1 or 0 end count_decimal_places(.0000000045) Результаты промежуточных вычислений такие. n внутри функции: 4.5e-009 r: ".5" На выходе: 1 То есть всё портит внутреннее представление дробных чисел. Как вариант, можно самостоятельно переводить число в строку: function count_decimal_places(n) local r = string.match(string.format("%.20f", n), "%.[0-9]*[1-9]") return r and r:len() - 1 or 0 end Но при большой разнице между кол-вом знаков в форматировании и реальным число начинает искажаться, так как string.format("%.15f", 11.00045) --> "11.000450000000001" Надо признать, что мой вариант также нельзя считать применимым во всех случаях. Вот для строк он работает, а для чисел - как повезёт. Возможно, кто-нибудь сможет предложить правильное решение.

@Kober(BRUC), ЕМНИП, 12. Но это для аргумента-числа. Поправка: всего 14 знаков, из которых следует вычесть число периодов (именно периодов, а не знаков, то есть единственный нуль не играет роли) до десятичной точки. А для строки ограничения нет: count_decimal_places("45.54050657156521651751257251721571257125721512521567215215454654654001") = 68

@Kober(BRUC), В твоём варианте number_after_decimal_point(45.54050001) = 1 @Kondr48, примерно так: function count_decimal_places(n) local r = string.match(n, "%.[0-9]*[1-9]") return r and r:len() - 1 or 0 end должно подойти для входного аргумента и в виде числа, и в виде строки. Завершающие нули (если есть в строке) не учитываются.

@pc-2, ты б внимательно прочёл, что именно написано в логе вылета. "attempt to index global 'sobj' (a nil value)" - скрипт не может получить свойство id переменной sobj, так как sobj ничего не содержит. Эта переменная просто не присвоена. Надо делать так: local sobj = alife():create("kurevo", db.actor:position(), db.actor:level_vertex_id(), db.actor:game_vertex_id(), db.actor:id()) level.client_spawn_manager():add(sobj.id, -1, function(id, obj) db.actor:eat(obj) end)

@Карлан, сделал и протестировал? Молодец! А я вот сделал и протестировал новое, весьма полезное web-приложение, или, скажем, придумал и опробовал новый способ рубки дров топором, вдвое быстрее и проще. Тоже молодец. Только я эти новинки никому не покажу - и в такой моей информации тоже будет толку ноль. Вот ты выложи, что сделал, приведи скрипт (как ты там про тему написал?), мы оценим, сравним с уже имеющимися решениями, опробуем в игре. И тогда можно будет сказать, что ещё при первых твоих постах на эту тему почувствовали неизъяснимую истому, приобрели ощущение рождения чего-то великого, нужного, и просто не смогли выразить это ощущение словами.

Поверь, разобраться несложно. Ага, смотрю, ты уже исправил вылет из-за недостающей функции при лечении у костра.

Да там проще некуда. В момент сохранения из любого скрипта вызвать: SetVar("название_переменной_в_сэйве", твоя_таблица) В момент загрузки из сэйва: твоя_таблица = GetVar("название_переменной_в_сэйве", {}) второй параметр в скобках в данном случае - значение по умолчанию (то есть пустая таблица), если твоей переменной в сэйве не обнаружилось. Сохранять таким образом можно не только таблицы, разумеется, но и простые переменные. Дополнительные данные лучше всего сохранять и читать одновременно с оригинальными. То есть ищешь стандартные методы save/load и в них добавляешь обращение к хранилищу. А ещё можешь заглянуть в тему "Сборочный цех", пройти там по ссылке в пост с модулями Артоса и посмотреть описание к модулю se_stor. Как и куда его надо интегрировать - это можно пропустить (так как это уже мной сделано), изучив только методы сохранения и чтения переменных.

В OGSM CE CF уже больше года интегрировано универсальное хранилище с неограниченным размером сохраняемых данных, возможностью хранения таблиц и т. п. Прочитай readme повнимательнее. Что же касается конкретного применения (с сохранением/чтением именно таблицы) - см., например, bind_stalker.script, методы actor_binder:save()/load{}, в них вызовы методов SetVar()/GetVar()/DelVar(). Если ты основываешься на CF, ничто не мешает воспользоваться уже готовым механизмом. И никакие костыли в виде дополнительных файлов нужны не будут.

Dune media player (любой модели), интегрированный в домашнюю сеть, с выводом изображения на большой телевизор. А для музыки на компе - AIMP.

При написании поста наиболее часто используются всего 2 bb-кода (считаем, что нет необходимости выделять текст жирным, подчёркнутым и т. п., особенно на смартфоне). [quote="ник_того_кому_отвечаем_опционально"]текст цитаты[/quote] [spoiler="название_спойлера_опционально"]текст внутри спойлера[/spoiler]Ник и название спойлера можно не указывать, оставив только bb-код внутри скобок.На практике даже спойлер не обязателен, при краткости постов достаточно обойтись только цитатой. А один код запомнить не сложно.

Если муж готовить не умеет (но с удовольствием потребил на завтрак бы что-то получше и побольше, чем хлеб с колбасой), пусть жена сама решает, должна (может/хочет) она доставить мужу эту радость или не должна. ИМХО.

@Dennis_Chikin, local s = "test" for ss in s:gmatch("s") do print(ss) end ожидаемо возвращает "s". В чём подвох? Или не это имелось в виду?

Посмотрел функцию pick_section_from_condlist более внимательно и, судя по всему, надо признать, что был неправ в своих ранних рассуждениях. Случайное число в функции берётся только один раз, при старте. А это значит, что числа в логике инкрементны, должны увеличиваться с каждым шагом и самое большое (последнее из них) не может превышать 100 (но при этом сумма может быть и больше). Например так: meet_dialog = {~20} dialog1, {~40} dialog2, {~50} dialog3, {~70} dialog4, {~90} dialog5, {~99} dialog6, dialog7В реальности первый диалог будет выбран с вероятностью 20%, второй - 20%, третий - 10%, четвёртый - 20%, пятый - 20%, шестой - 9% и седьмой - 1%. Вот уже эта сумма равна 100%. А вот в такой записи meet_dialog = {~30} dialog1, {~60} dialog2, {~10} dialog3третий диалог не будет выбран никогда (и в 40% случаев не будет выбран ни один диалог), так как попадает в диапазон вероятности первого диалога. Поэтому совет насчёт отсутствия числа в последнем элементе остаётся в силе.

Это потому, что настройки диалога у тебя неправильные. Дело в том, что необходимость выбора того или иного диалога рассчитывается последовательно, а вероятности при расчёте не складываются. Смотри: meet_dialog = {~30} dialog1, {~60} dialog2, {~10} dialog3Первый диалог будет выбран с вероятностью 30% (число сравнивается со случайным числом в диапазоне от 1 до 100, если больше - сработало). 70% - вероятность, что не будет выбран. Второй диалог будет выбран с вероятностью 60%, но относительно 70% вероятности не выбора первого диалога. Общая вероятность выбора второго диалога 0.7*0.6*100% = 42%. Отсюда 30%+42% = 72% - вероятность выбора первого или второго диалога, 28% - вероятность не выбора. Третий диалог будет выбран с вероятностью 10%, но уже от этих оставшихся 28%. Общая вероятность выбора третьего диалога составит 0.1*0.28*100% = 2.8%. Отсюда 72%+2.8% = 74.8% - общая вероятность выбора одного из трёх диалогов. Получается, с вероятностью 100%-74.8% = 25.2% никакой диалог не будет выбран. И даже если у тебя получилось при начале разговора попасть в «правильные» 74.8% - на апдейте, тут ты прав, происходит выбор диалога заново, с некоей вероятностью он оказывается пуст, и в таком случае в скрипте логики происходит вызов функции restore_default_start_dialog(). Возможно, именно она и закрывает диалоговое окно - движкоправы могут сказать точнее. Чтобы условие гарантированно приводило к какому-либо диалогу, необходимо, чтобы последний диалог в цепочке от вероятности не зависел: meet_dialog = {~30} dialog1, {~60} dialog2, dialog3Но и тогда диалоговое окно теоретически может сбрасываться, если во время апдейта новый выбранный диалог будет отличаться от старого - для смены диалога в таком случае вызывается функция set_start_dialog(dialog). Вызывает ли эта функция аналогичное закрытие диалогового окна, мне неизвестно. Надо проверять. Update: Прошу считать данный пост недействительным - причина ниже.

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

На самом деле, довольно легко сделать действительно случайный стартовый диалог. Пишу «вслепую», поэтому извиняйте, если накосячил или вообще предложил лажу. Где-нибудь в xr_conditions пишем такой код: local random_dialog = nil function get_random_dialog(actor, npc, p) local max_count = p and p[1] or 1 if random_dialog == nil or random_dialog.counter >= max_count then random_dialog = {dialog_set = false, counter = 1} else random_dialog.counter = random_dialog.counter + 1 end math.randomseed(time_global()) if not random_dialog.dialog_set then random_dialog.dialog_set = random_dialog.counter == max_count or math.random(random_dialog.counter, max_count) == max_count return random_dialog.dialog_set else return false end end Затем в логике пишем так (пример для трёх равнозначных диалогов): meet_dialog = {=get_random_dialog(3)} dialog1, {=get_random_dialog(3)} dialog2, {=get_random_dialog(3)} dialog3 Важно: 1. аргумент, передаваемый в функцию, должен быть равен общему числу диалогов; 2. функцию обязательно надо использовать в том числе для последнего диалога в цепочке, чтобы не сбился внутренний счётчик; 3. дополнительные условия (например инфопорции) при таком подходе использовать нельзя; 4. данная реализация может быть применима только к одному конкретному выбору случайного диалога. Если необходимо применить аналогичный подход в нескольких местах (с разным количеством диалогов для выбора), из переменной random_dialog надо делать массив, а в функцию передавать 2 аргумента - номер комплекта диалогов и кол-во диалогов в этом комплекте. Соответсвенно и код функции претерпит небольшие изменения. При таких последовательных вызовах функция случайным образом назначит активным один из диалогов. При повторной попытке заговорить счётчик диалогов сбросится и случайный выбор будет сделан заново.

@dPlayer, стартовому диалогу тоже можно задавать условия: meet_dialog = {+info1} dialog1, dialog2

Я пока ничего не хочу, пусть доча сначала окончательно дорастёт, выучится и права получит (причём честно! «Приобрести» не позволю). Будет день, будет и пища. Сейчас могу сказать одно: я рад, что много лет назад после автошколы и экзамена в ГАИ приобрёл себе именно Москвича, а не, скажем, подержаную бэху. У моего друга такой был, в 61-м дорестайлинговом кузове. Шикарная машина, как раз на охоту и в походы ездили. Потом продать пришлось, до сих пор жалеет. Плюс сами крепления пластиковые, довольно хлипкие. Удивляет ещё вот что: о чём думал производитель, проектируя такую систему? Или это в общей тенденции продать побольше запчастей, о чём написано выше? Украдут - и ладно, за заменой опять к нам придут.