Перейти к контенту

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


Svoboда

Рекомендуемые сообщения

@HellRatz, каким макаром? story_id имеет отношение к уже существующему объекту, либо в игровом мире, либо в all.spawn. Т.ч. что бы обратиться по story_id, объект должен уже быть в одном из этих мест или в обоих.

 

5 minutes ago, HellRatz said:

А мне надо по координатам.

Ну, можно сначала переспаунить из all.spawn, как я показал, а потом телепортировать на нужные координаты, если у тебя хотя бы xray extensions.

 

Поделиться этим сообщением


Ссылка на сообщение

@Graff46, потому, что alive() у серверных объектов есть только у живых, т.к. сказать:

if obj and ( IsStalker( obj ) or IsMonster( obj ) ) and obj:alive() then

@lordmuzer вон там выше указал, у кого этот метод есть.

Поделиться этим сообщением


Ссылка на сообщение
4 hours ago, Graff46 said:

Как мне получить статус диалога (окна) (активен или нет)

Используя IsShown()? Я вон там вижу даже метод, который этот метод использует. 

 

4 hours ago, Graff46 said:

переменная super_dlg не зануливается после закрытия диалога

А что делает? Насколько я вижу - это локальная переменная в функции start. 

 

4 hours ago, Graff46 said:

перехвать в методе __finalize - ничего недал?

Это вопрос? Перехват чего и что он должен был дать? 

  • Согласен 1

Поделиться этим сообщением


Ссылка на сообщение
1 hour ago, Graff46 said:

 И ф-ция старт её возвращает, после закрытия окна эта переменная не нил

Почему она должна стать nil? Есть код, который присваивает nil той переменной, которой было присвоено возвращенное значение? 

 

1 hour ago, Graff46 said:

 Я надеялся что ф-ция __финализ вызовется когда окно "убирается"

finalize вызывается, когда уборщик мусора удаляет этот объект. А удаляет он его, когда на него больше никто не ссылается. 

  • Согласен 2

Поделиться этим сообщением


Ссылка на сообщение
4 hours ago, Kirgudu said:

Но если я не прав - с удовольствием посыплю голову пеплом.

Прав, прав. story_id через нетпакет устанавливается. Единственное, что нужно помнить устанавливающим, что движок его зарегистрирует только при следующей загрузке сейва. Т.е. после сейв-лоада, ну или при переходе на другую локацию, что то же самое. 

Поделиться этим сообщением


Ссылка на сообщение
4 hours ago, Zagolski said:

зачем заспавненному неписю вообще устанавливать story_id

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

 

4 hours ago, Zagolski said:

Вроде даже при перезапуске игры.

Точно не только при перезапуске игры. Но это относится к оригинальному движку. В NLC, к примеру, понятия не имею, как оно будет, что там переписали и поменяли. 

Поделиться этим сообщением


Ссылка на сообщение

@Graff46, это для установления контроля за мобом. Т.е. он будет выполнять то, что ты ему скриптом скажешь. Например бежать в определенном направлении.  Для примера, посмотри вот этот скрипт

https://github.com/dsh2dsh/op2ogse/blob/3f7514f804eaf1dc875cc3ce8513d8537dd53bc2/gamedata/scripts/dsh_battle_radius.script#L135

Это аналог mob_home, только без путей. Там как раз используется такой захват контроля над мобом, что бы заставить его вернуться внутрь.

 

Поделиться этим сообщением


Ссылка на сообщение

@dPlayer, в оригинальном движке этот класс умеет выдавать поршень, только если он есть в нетпакете. Т.е., например, если объект на этом классе будет в all.spawn. Ну или спаунить и через нетпакет прописывать ему поршень. Притом, даже этот вариант имеет свои подводные грабли. Например, лежит ПДА на этом классе и через all.spawn или нетпакет ты указал ему поршень. Если этот ПДА подберет какой-нибудь непись, то он получит указанный поршень. Если после этого ты откроешь диалог с этим неписем или обыщешь его труп, то актор тоже получит этот поршень, не смотря на то, что ПДА он не брал.

 

  • Полезно 1

Поделиться этим сообщением


Ссылка на сообщение

@Graff46, насколько я помню, имя берется из двух мест, в разных случаях. Первое место - это нетпакет. Второе место - клиентский объект,  m_game_name в CInventoryOwner. Я не знаю, можно-ли через xray extensions добраться к этому месту.

 

  • Согласен 1

Поделиться этим сообщением


Ссылка на сообщение
2 hours ago, Graff46 said:

В каком случае из нэт-пекета имя ГГ берется?

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

2 hours ago, Graff46 said:

Имя, в иной ситуации, читается из сейва.

Именно так. Поэтому

2 hours ago, Graff46 said:

можно ли переименовать ли ГГ нэт-пакетом?

Полностью - нет. См. начало. Да и вообще, про переименование нетпакетом я ничего не могу сказать, не пробовал. Все, что я могу сказать, что в нетпакете есть имя и оно используется. Можно так переименовать или нет - не знаю. У меня переименовывается через прямой доступ к свойствам, а не через нетпакет.

 

Поделиться этим сообщением


Ссылка на сообщение
22 minutes ago, Graff46 said:

Редактирование движка? Через X-Ray Extensions не сделать?

Не знаю. Я экспортировал эти свойства для скриптов.

 

23 minutes ago, Graff46 said:

Интересно как, "напрямую" или через пакет?

В смысле как? Просто читает из сейва

https://github.com/OGSR/OGSR-Engine/blob/f170c7ba6632c02c8b5d763cd182ba9a106caddb/ogsr_engine/xrGame/InventoryOwner.cpp#L178


    load_data        (m_game_name, input_packet);

 

25 minutes ago, Graff46 said:

У нас в методе биндера ГГ

При чем тут биндер. Под клиентским объектом я подразумевал движковый клиентский класс.

 

27 minutes ago, Graff46 said:

будто бы в метод сейва вообще передается не тот пакет, который мы получим от ГГ методом STATE_Write

Именно так. В save() передается клиентская область сохранения, а не серверный нетпакет. Точно так же и в load() передается не нетпакет, а клиентская область сохранения.

 

Поделиться этим сообщением


Ссылка на сообщение
18 minutes ago, Graff46 said:

А имя ГГ в этой области?

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

 

Поделиться этим сообщением


Ссылка на сообщение

@Капрал Хикс, в se_item.script, в on_register и on_unregister всякие предметы регистрируются в task_manager, что бы их потом искать. Вот тебе похоже туда же нужно.

 

  • Полезно 1

Поделиться этим сообщением


Ссылка на сообщение
5 hours ago, _Sk8_AsTeR_ said:

Никто таким не занимался? Нет мыслей куда копать?

Можешь попробовать покопать вот этот скрипт:

https://github.com/dsh2dsh/op2ogse/blob/master/gamedata/scripts/dsh/dsh_walking_stalkers.script

Он периодически выгоняет сталкеров из лагерей, что бы они шли в другие.

 

  • Спасибо 1

Поделиться этим сообщением


Ссылка на сообщение

@_Sk8_AsTeR_, ты же просил покопать что-нибудь, а теперь подробности... Насчет подробностей - это скрипт нужно изучать. А вкратце, все начинается в periodic_job(). Обходятся все смарты, из них выбираются не эксклюзивные сталкеры. Чем дольше сталкер в лагере, тем вероятнее, что он будет выгнан. Формируется список тех, кого нужно выгнать и выгоняются. Запускается таймер на следующий обход и так по кругу. Сомневаюсь, что ты сможешь использовать этот скрипт как есть, но что бы покопать - подойдет.

 

Поделиться этим сообщением


Ссылка на сообщение

@Баба ЯГА, это делается с помощью метода клиентского обьекта set_dest_level_vertex_id( lvid ). Непись пойдет на этот lvid, если в процессе его какой-нибудь скрипт не пошлет куда-нибудь в другое место.

 

  • Полезно 2

Поделиться этим сообщением


Ссылка на сообщение
6 hours ago, Norman Eisenherz said:

хранятся только значения, которые невозможно прочитать без знания их типов?

Именно так.

 

Уже все изобретено до вас. Найди m_netpk  и не изобретай велосипедов.

 

Вообще совет и не только тебе. Прочитайте эту и соседнии темы с самого начала.

  • Согласен 1

Поделиться этим сообщением


Ссылка на сообщение
  • Недавно просматривали   0 пользователей

    • Ни один зарегистрированный пользователь не просматривает эту страницу.
×
×
  • Создать...