Скриптование

[Tris 9]

Пытался написать скрипт, чтобы антирадар можно было использовать только в том случае если есть определённый предмет, только вот незнаю что написать вместо этого: --можно использовать антирадар-- Если кто знает очень прошу помощи.

function use_antirad()
    if not db.actor:object("predmet") then
        this.spayn_item("antirad")
        news_manager.send_tip(db.actor, game.translate_string("st_antirad_no_predmet"))
        if db.actor:object("predmet") then
            --можно использовать антирадар--
        end
    end
end

Изменено 25 Октября 2011 пользователем ColR_iT
Пользуемся тегами!

[ColR_iT 171]

FLIKER, а у тебя смарт с одной работой? Если нет, то для работы "пожарника" в файле gulag_xxx.script в функцию load_job нужно писать условие приёма на данную работу. Вот на примере работы Шустрого:

t = { section = "logic@esc_lager_kamp1",
            idle = 0,
            prior = 16, state = {2},
            online = true,
            in_rest = "", out_rest = "",
            predicate = function(obj_info)
                            return obj_info.profile_name == "esc_shustryi"
                        end
        }
        table.insert(sj, t)

[_Призрак_ 11]

Tris

В программировании очень популярен псевдокод. Перевожу твой скрипт на псевдокод:

функция:
   Если нет предмета "Предмет" то
      Создать в рюкзаке предмет "Антирадар"
      Отослать сообщение
      Если есть предмет "Предмет" то
         --что-то
      конец
   конец
конец

 

А теперь найди ошибку в логике функции

[FLIKER 0]

ColR_iT, у меня смарт сделанный в СДК на основе схемы General Lager. В нем три работы guard, ну часовой короче. 3 НПС ходят в точках и всё, а вот камп не работает почему то.

[ColR_iT 171]

FLIKER, постой, ты хочешь сказать, что в смарте три работы часовых и ты хочешь, чтобы они сидели у костра? По моему ты переоценил возможности движка Сталкера...

Логику kamp, что ты написал в custom_data твоего НПС, он будет использоваться лишь в том случае, если не попадет под гулаг по тем или иным причинам.

 

Добавлено спустя некоторое время...

В нем три работы guard...

Ты бы определился 3 или 4...

В общем из предоставленной тобой информации, могу посоветовать изменить логику одному НПС так:

[smart_terrains]
none = true

[logic]
active = kamp

[kamp]
center_point = ds_lager_kamp_1
radius = 3

Изменено 25 Октября 2011 пользователем ColR_iT

[FLIKER 0]

ColR_iT, под гулагом 4 НПС, 3 из них часовых, каждый выполняет свой путь. А 1 должен пользоваться схемой "Kamp", но он просто уходить и всё. Вот так понятно?

Спасибо.

Изменено 25 Октября 2011 пользователем FLIKER

[strelok200 0]

Я поставил логику раненого, но почему он встает? Если допустим артефакт активировать?

[*Shoker* 322]

Кто знает, почему в Сталкере разработчики, при определении расстояния от одного вектора к другому, используют преимущественно функцию v1:distance_to_sqr(v2) -- квадрат расстояния между v1 и v2, а не обычную?

Изменено 25 Октября 2011 пользователем *Shoker*

[abramcumner 1 145]

*Shoker*,

типа квадратный корень долго извлекается Ускоряют

[*Shoker* 322]

abramcumner

Ну похоже что так

Собстно я сейчас ищу методы ускорения определия дистанции ГГ до объекта.

 

Есть таблица, там в среднем около 200 объектов - аномалий, и нужно каждый апдейт (возможны небольшие погрешности) сравнивать их дистанцию до игрока. Остановился на использовании distance_to_sqr, но потери времени всё равно очень большие, за 1 апдейт в среднем 600-900 "мсек" теряется (не знаю в чём определяется значение profile_timer())

 

Я вот думаю, каким макаром можно ещё это ускорить ...

Изменено 25 Октября 2011 пользователем *Shoker*

[7.9 174]

200 - много!

 

У меня схожая задача, использую простой distance_to(), на производительность не проверял.

 

Суть: "Безобъектный сферический рестриктор" - БДС или ЦДС - "центр, дистанция, скрипт"

 

1. Вся локация разбита на зоны (до 20 проверок),

2. Скрипт зоны подключает\отключает ещё от 10 до 20 проверок.

3. Всего одновременных проверок: не более 50.

4. Главное при переключении между зонами - рестриктор должен быть активным в соседних зонах.

 

 

Но это не ускорение - оптимизация.

Изменено 25 Октября 2011 пользователем 7.9

[Artos 99]

*Shoker*

Скорость/ресурсоемкость в первую очередь определяется алгоритмом! Выбор конкретных функций и соответственно их суммарная скорость - производная от алгоритма.

 

1. Учись задавать вопросы так, чтлбы было желание ответить.

На вопрос типа: "Кто знает, почему в Сталкере разработчики ..." - кроме как ответа: "Поди к ним и спроси!", мне, например, давать не хочется ...

А вот вопрос: "В чем отличия/преимущества одного метода по сравнению с другим(и)" - и смыслом наполнен и задуматься заставляет и поделиться мнением/навыком побуждает!

 

2. Ты не задумывался над тем, что расстояние может быть и отрицательным? Конечно оказаться внутри сталкера/монстра/предмета ГГ не может, но внутри рестриктора, аномалии и т.п. - запросто!

Вычисление расстояния до некоей зоны и сравнение с аналогичными - имеет смысл в связке с радиусом зоны до центра которой (иль до периметра) измеряешь.

Есть еще и 2D-расстояние (distance_to_xz) - это чтобы и с высотою не промахнуться, ежели например, кто-то 'на 2-ой этаж забрался' ...

 

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

Не знаю, что там у тебя с ГГ и аномалиями, но то, что ГГ может за некий период (напримет 15 сек) отбежать на некую лимитированную его возможностями дистанцию, дает возможность периодические (15 сек, а не 20 мсек!) делать выборки из общей таблицы и работать только с 'доступными' объектами/аномалиями. (Пример в известном тебе моде при обходе аномалий неписями ...). Т.о. вернулись в начало: оптимальный алгоритм всегда выигрывает ...

Изменено 25 Октября 2011 пользователем Artos

[Dennis_Chikin 3 658]

Возникло такое странное ощущение, что или я чего-то не понимаю, или set_relation() работает только для актора.

 

Гляньте, кому не лень...

 

[Artos 99]

Dennis_Chikin

Заглянув в тему "Справочник по функциям и классам" (иль в lua_help.script) - можно увидеть, что работает с гейм-объектами. Если у тебя не работает - ищи причину у себя в неправильном применении метода.

Работоспособность метода не только для ГГ - подтверждают и оригинальная игра и моды ...

Изменено 25 Октября 2011 пользователем Artos

[Malandrinus 615]

Dennis_Chikin,

или я чего-то не понимаю, или set_relation() работает только для актора.

По идее, работает для CInventoryOwner, к коим относятся актор, сталкеры, монстры и торговец (отдельный класс, единственным представителем является Сидор).

Только правильно ли ты эту функцию используешь? Вот нормальное описание, которое всё руки не доходят выложить в справочник.

    void set_relation(enum ALife::ERelationType <relation>, game_object* <who>) // установка отношения 
    // на самом деле это просто установка персональной благосклонности (что можно напрямую сделать с помощью set_goodwill)
    // в соответствии с параметрами из секции "game_relations" 
    // (это как правило файл "config\creatures\game_relations.ltx", входящиё в system.ltx)
    // константа           | параметр в секции game_relations |  значение в оригинальной игре
    // --------------------+----------------------------------+------------------------------
    // game_object.enemy   | goodwill_enemy                   | -1000
    // game_object.neutral | goodwill_neutal                  |  0
    // game_object.friend  | goodwill_friend                  |  1000

[abramcumner 1 145]

Ну и в конечном итоге новое значение благосклонности обрезается, чтобы попадать в отрезок

personal_goodwill_limits = -1000, 1000

 

То есть запросто что-то может не так работать, если менялся game_relations.ltx

 

Добавлено через 24 мин.:

Ну и кстати функции relation и set_relation не симметричны.

set_relation устанавливает личную благосклонность или лучше писать "личное отношение"(personal_goodwill) из game_relations.ltx

 

а relation возвращает attitude из game_relations.ltx приведенный к перечислению ERelationType. Только приводится в соответствии с константами

;пороговые значения для отношения персонажей

attitude_neutal_threshold = -400 ;когда attitude меньше значения, то выставляется ALife::eRelationEnemy

attitude_friend_threshold = 500 ;когда attitude меньше значения, то выставляется ALife::eRelationNeutral, иначе ALife::eRelationFriend

 

ну и general_goodwill тоже возвращает attitude только в численном виде.

 

Так что проблемы скорей всего в этом. То есть на отношение влияет еще куча слагаемых.

Изменено 25 Октября 2011 пользователем abramcumner

[Artos 99]

Все же стОит для простых смертных дать попроще пояснение, а то и запутаться могут:

1. Метод 'set_relation' применим к гейм-объектам гуманоидов (сталкеры/торговцы) и монстров.

2. Метод устанавливает одно из трех типов 'отношений': друг/нейтрал/враг.

3. Применение:

а) oNPC1:set_relation(game_object.friend, oNPC2) или oNPC1:set_relation(0, oNPC2) - сделать NPC2 другом NPC1

б) oNPC1:set_relation(game_object.neutral, oNPC2) или oNPC1:set_relation(1, oNPC2) - сделать NPC2 нейтралом NPC1

в) oNPC1:set_relation(game_object.enemy, oNPC2) или oNPC1:set_relation(2, oNPC2) - сделать NPC2 врагом NPC1

Ну а расчеты от чего зависят и чему равны конкретные численные значения goodwill'ов - это уже тема иная ...

[Dennis_Chikin 3 658]

Код, даже не мой - полез разбираться, почему фигня происходит:

    for npcId, npc in pairs(db.storage) do
        obj = level.object_by_id(npcId)
        if obj and IAmAStalker[obj:clsid()] and npcId ~= second_speaker:id() and obj:alive() then
            if obj:see(first_speaker) then
                obj:change_goodwill(math_floor(25-(5+5*difficulty)), first_speaker)
            end
            if obj:relation(second_speaker) == game_object.enemy
              and obj:relation(first_speaker) ~= game_object.enemy then
                obj:enable_memory_object(second_speaker, false)
                obj:set_relation(1--[[obj:relation(first_speaker)]], second_speaker)
            end
            if second_speaker:relation(obj) == game_object.enemy then
                log("info", "transfer_medkit, %s and %s are enemyes", second_speaker:name(), obj:name())
              if obj:relation(first_speaker) ~= game_object.enemy then
                log("info", "transfer_medkit, change relations")
                second_speaker:set_relation(1--[[first_speaker:relation(obj)]], obj)
                second_speaker:enable_memory_object(obj, false)
                log("info", "transfer_medkit, %s and %s now are enemyes: %s", second_speaker:name(), obj:name(), tostring(second_speaker:relation(obj) == game_object.enemy))
              end
            end
        end
    end

лог:

! Cannot find saved game ~info~: [dialogs] transfer_medkit, val_escort_bandit_halfdead and val_prisoner_captive are enemyes
! Cannot find saved game ~info~: [dialogs] transfer_medkit, change relations
! Cannot find saved game ~info~: [dialogs] transfer_medkit, val_escort_bandit_halfdead and val_prisoner_captive now are enemyes: true
! Cannot find saved game ~info~: [dialogs] transfer_medkit, val_escort_bandit_halfdead and val_escort_nap1 are enemyes
! Cannot find saved game ~info~: [dialogs] transfer_medkit, change relations
! Cannot find saved game ~info~: [dialogs] transfer_medkit, val_escort_bandit_halfdead and val_escort_nap1 now are enemyes: true

Изменено 26 Октября 2011 пользователем Dennis_Chikin

[_Призрак_ 11]

Есть ли на данный момент возможность повернуть объект типа physic_object? Пытался выбирать кость и хитовать ее - не подходит. Смотрел m_net_utils, но судя по коду возможности изменить direction у объекта при помощи нет_пакетов еще нет. А можно ли как нибудь по другому?

[Artos 99]

Возможность изменить 'direction' при помощи нет пакетов как раз есть, но .... не с помощью общего модуля ' m_net_utils'. Этот параметр находится в секции 'cse_abstract' нет=пакета и доступен только в методах STATE_Write|Read для конкретных классов объектов.

Для изменения требуется навык начальной 'перепаковки' нет-пакета (аналогично перепаковкам аномалий/ламп).

В 'se_item.script' имеется класс "se_item". Добавив в него соответствующие методы ты сможешь получить доступ к 'packet' с секцией 'cse_abstract' объекта. Ну а далее - дело техники ...

 

А вообще для физ объектов стОит вспомнить наличие 'ph_shell' и 'apply_force', дабы не хитовать, а прикладывать усилия в соотв.направлениях.

 

Добавлено через 4 мин.:

Dennis_Chikin

1. Если ты (или кто-то ...) считаете такую строку кода валидной:

second_speaker:set_relation(1--[[first_speaker:relation(obj)]], obj)

- то вопросы о нерабочести такого кода стОит задавать себе, а не в топиках.

2. СтОит все же различать отдачу команды и результат ее выполнения! Дав команду на изменение отношения одного к другому - как минимум требуется дождаться следующего апдейта (этого объекта) и только тогда проверять: изменилось ли отношение ...

Это также как и со здоровьем (health) и аналогичными параметрами - изменяем, а результат только позже проявляется.

Изменено 26 Октября 2011 пользователем Artos