Система ALife. Логика поведения игровых объектов

[Dennis_Chikin 3 658]

    elseif cond_name(c.name, "on_npc_in_zone") then
      if utils.npc_in_zone(level.object_by_id(c.npc_id), db.zone_by_name[c.v2]) then
        switched = switch_to_section(npc, st, pick_section_from_condlist(actor, npc, c.condlist))
      end
    elseif cond_name(c.name, "on_npc_not_in_zone") then
      if not utils.npc_in_zone(level.object_by_id(c.npc_id), db.zone_by_name[c.v2]) then
        switched = switch_to_section(npc, st, pick_section_from_condlist(actor, npc, c.condlist))
      end

А, в смысле, function cfg_get_npc_and_zone() ?

Которая берет по sid, и перекладывает туда id ?

 

Орригинально...

Изменено 29 Декабря 2015 пользователем Dennis_Chikin

[abramcumner 1 158]

А, в смысле, function cfg_get_npc_and_zone() ? Которая берет по sid, и перекладывает туда id ?

Да, она. Получает на входе сид и заполняет структуру для дальнейшего использования. Все правильно и хорошо сделано.

[Dennis_Chikin 3 658]

На дворе шел 2016 год.

А мододелы так и вызывают из логики функции типа

 

my_function1()

local obj = alife():object( "my_object1" )

local actor = db.actor

...

end

 

...

my_function100500()

local obj = alife():object( "my_object100500" )

 

особенно замечательно, когда используется не имя, а спавн из скрипта с переписыванием sid, или, еще лучше, сохранение id созданного объекта в pstor к актору.

 

 

Так вот, кому лень смотреть xr_logic.scritp, просто запомните:

вызываемая в 99% скриптов, работающих с логикой xr_logic.try_switch_to_another_section( self.object, self.st, db.actor ) - передает туда, как видно из аргументов, актора, сторейж и свой объект.

Далее вызывается pick_section_from_condlist( actor, npc, c.condlist ) или что-то подобное, где actor и npc - внезапно, именно то, что было передано в качестве актора и объекта.

И когда ваше условие выполняется, то в вашу =my_script.my_function100500() передаются они же.

 

Так что достаточно написать my_function( v1, v2 ), и в v2 у вас волшебным образом будет искомый объект. Игровой или серверный - зависит от того, откуда вызывалось, но в любом случае достаточно local obj = alife():object( v2:name() )

Если, конечно, у вас в олспавне еще и имена не дублированы, ну а если уж понаплодили дубликатов - вылетов будет в количестве и без этого.

 

Из засад же присутствует то, что когда вы вызываете pick_section_from_condlist() откуда-нибудь из se_zone.script и прочих se_что-попало, то ни какого db.actor во время загрузке этих ваших зон и прочих смартерейнов еще не существует. Так что ни выдавать атору инфо в этой "логике", ни рассчитывать, что кто-то где-то его получит - право, не стоит. Подумайте - не перенести ли такие действия в более другое место.

 

 

Да, а вообще, в xr_logic заглядывать время от времени полезно. Ну и в смысле читаемости, возможно, кому-то поможет вот такой вариант: https://dl.dropboxusercontent.com/u/27871782/xr_logic.script

Изменено 20 Июня 2016 пользователем Dennis_Chikin

[Expropriator 2 118]

 

 

my_function1() local obj = alife:object( "my_object1" ) local actor = db.actor ... end

В ЗП есть масса уже готовых сценариев вызова функций из конфигов логики. Хотя и такими, мы еще продолжаем баловаться.

[Dennis_Chikin 3 658]

Если очень ты не хочешь

слушать вредные советы,

то тогда тебе не надо

50 сравнений строк

делать в каждом из апдейтов...

 

Не знаю, кто и когда успел родить сей шедевр, но вот нашел совершенно замечательное:

if self.st.active_section == "sr_idle@nil" then ...

elseif self.st.active_section ~= nil then ...

 

Ага, это те самые рестрикторы, апдейт которых вызывается из каждого апдейта актора. А их в среднем на локации где-то вот с полсотни и есть.

Так вот, в каждой схеме, в свою очередь, имеется апдейт. Ну или эвалуатор. Или еще какое чудо. В котором, обычно, вызывается xr_logic.try_switch_to_another_section()

Так вот, если мы переключаемся на любую другую секцию, или даже схему (все равно секция будет другая), то оно вернет true.

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

[Dennis_Chikin 3 658]

В продолжение о чудесах народного модотворчесва, а также в некоторых местах и собственно оригинала:

 

код типа local ini = xr_logic.get_customdata_or_inifile( блабла )

if ini:section_exist( "logic" ) then что-то делаем

else делаем что-то другое

end

- совершенно бессмысленный, поскольку если в олспавне не прописана секция logic - она будет подставлена из config\scripts\dummy.ltx

И это идет с оригинала.

 

Поскольку там поле active = nil - все дальнейшие сравнения в апдейте с какими либо иными строками - столь же бессмысленны.

 

Проверяйте нужную вам секцию после xr_logic.initialize_obj(), а далее - как описано в посте выше - из схем при получении true из xr_logic.try_switch_to_another_section()

[AKKK1 6]

Вроде тема подходит.

Использование функций времени ДЛЯ усложнения и разнообразия поведения НПС как в гулагах так и находящихся под собственной логикой.
Рабочий функции выглядят примерно так..

 

 

function time_test() Название функции
if level.get_time_hours() == 7 then если время равно 7 часам
return true функция возврашает true
else
return false в любое другое время возврашает false
end
end

Для использования в схемах поведения НПС(логике) функция должна быть помешенна в файл S.T.A.L.K.E.R gamedata scripts xr_conditions
при использовании функции в логике НПС
[logic@наименование_секции_логики]
active(активация секции) = kamp(имя схемы)@имя_секции
[kamp(имя схемы)@имя_секции]
on_info = {=time_test} [sleeper(имя схемы)@имя_секции] при условии что игровое время равно 7 часов ровно переключение на секцию [sleeper(имя схемы)@имя_секции]
center_point = camp_center
path_walk = camp_center_task
soundgroup = esc_lager
meet = meet@lager
[sleeper(имя схемы)@имя_секции]

 

 

В этой секции можно использовать все что угодно sleeper может быть kamp, walker и т.д (с разными путями прописанными в алл спавн).

 

Важно переключения происходят когда функция вазвращает true переключения не срабатывают если объект находится в офлайне.

 

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

 

Из этого следует что нам нужно создать такие условия при которых объект в любой момент времени сможет находится только в одной (конкретной)схеме поведения.

Спасибо IG-2007 за объяснение принципов.

 

C помощью этих функций (поместив их в xr_conditions.script).

 

 

- шаг первый ------

function time_testoww()
if level.get_time_hours() >= 6 and level.get_time_hours() <= 24 then
return true
else
return false
end
end

function time2_testoww()
if level.get_time_hours() <= 3 and level.get_time_hours() >= 0 then
return true
else
return false
end
end

-- второй

function time_testoww1()
if level.get_time_hours() >= 8 and level.get_time_hours() <= 24 then
return true
else
return false
end
end

function time2_testoww1()
if level.get_time_hours() <= 5 and level.get_time_hours() >= 0 then
return true
else
return false
end
end

-- третий

function time_testoww2()
if level.get_time_hours() >= 10 and level.get_time_hours() <= 24 then
return true
else
return false
end
end

function time2_testoww2()
if level.get_time_hours() <= 7 and level.get_time_hours() >= 0 then
return true
else
return false
end
end

-- четвертый

function time_testoww3()
if level.get_time_hours() >= 12 and level.get_time_hours() <= 24 then
return true
else
return false
end
end

function time2_testoww3()
if level.get_time_hours() <= 9 and level.get_time_hours() >= 0 then
return true
else
return false
end
end

-- пятый

function time_testoww4()
if level.get_time_hours() >= 14 and level.get_time_hours() <= 24 then
return true
else
return false
end
end

function time2_testoww4()
if level.get_time_hours() <= 11 and level.get_time_hours() >= 0 then
return true
else
return false
end
end

-- шестой

function time_testoww5()
if level.get_time_hours() >= 16 and level.get_time_hours() <= 24 then
return true
else
return false
end
end

function time2_testoww5()
if level.get_time_hours() <= 13 and level.get_time_hours() >= 0 then
return true
else
return false
end
end

-- седьмой

function time_testoww6()
if level.get_time_hours() >= 18 and level.get_time_hours() <= 24 then
return true
else
return false
end
end

function time2_testoww6()
if level.get_time_hours() <= 15 and level.get_time_hours() >= 0 then
return true
else
return false
end
end

-- восьмой

function time_testoww7()
if level.get_time_hours() >= 20 and level.get_time_hours() <= 24 then
return true
else
return false
end
end

function time2_testoww7()
if level.get_time_hours() <= 17 and level.get_time_hours() >= 0 then
return true
else
return false
end
end

-- девятый

function time_testoww8()
if level.get_time_hours() >= 22 and level.get_time_hours() <= 24 then
return true
else
return false
end
end

function time2_testoww8()
if level.get_time_hours() <= 19 and level.get_time_hours() >= 0 then
return true
else
return false
end
end

--десятый

function time_testoww9()
if level.get_time_hours() >= 0 and level.get_time_hours() <= 21 then
return true
else
return false
end
end


-- одиннадцатый

function time_testoww10()
if level.get_time_hours() >= 2 and level.get_time_hours() <= 23 then
return true
else
return false
end
end

-- двенадцатый

function time_testoww11()
if level.get_time_hours() >= 4 and level.get_time_hours() <= 24 then
return true
else
return false
end
end

function time2_testoww11()
if level.get_time_hours() <= 1 and level.get_time_hours() >= 0 then
return true
else
return false
end
end

--==========================

 

Логика охранника 
Охраняет,  ходит,  спит, сидит у костра.

Смена схем каждые 2 часа.

 

 

 

;охранник

[logic@esc_lager_zoneguard1]
active = walker@esc_lager_zoneguard1

[walker@esc_lager_zoneguard1]
on_info = {=time_testoww} walker5@esc_lager охраняет
on_info2 = {=time2_testoww} walker5@esc_lager
path_walk = guard_walk1
path_look = guard_look1
meet = meet@zoneguard_novice_lager1

[meet@zoneguard_novice_lager1]
meet_state = 10| wait@talk_hello
meet_state_wpn = 10| threat@threat_weap
victim = 10| actor
victim_wpn = 10| actor
use = true
use_wpn = true
meet_dialog = escape_lager_guard_start_dialog


[walker5@esc_lager]
on_info = {=time_testoww1} sleeper10@esc_lager
on_info2 = {=time2_testoww1} sleeper10@esc_lager ходит
path_walk = guard_walk4
meet = meet@lager

[sleeper10@esc_lager]
on_info = {=time_testoww2} kamp5@esc_lager спит
on_info2 = {=time2_testoww2} kamp5@esc_lager
path_main = mod6
meet = meet@lager

[kamp5@esc_lager]
on_info = {=time_testoww3} walker1@esc_lager_zoneguard1 сидит у костра
on_info2 = {=time2_testoww3} walker1@esc_lager_zoneguard1
center_point = camp_center
path_walk = camp_center_task
soundgroup = esc_lager
meet = meet@lager

[walker1@esc_lager_zoneguard1]
on_info = {=time_testoww4} walker6@esc_lager снова охраняет и т.д
on_info2 = {=time2_testoww4} walker6@esc_lager
path_walk = guard_walk1
path_look = guard_look1
meet = meet1@zoneguard_novice_lager1

[meet1@zoneguard_novice_lager1]
meet_state = 10| wait@talk_hello
meet_state_wpn = 10| threat@threat_weap
victim = 10| actor
victim_wpn = 10| actor
use = true
use_wpn = true
meet_dialog = escape_lager_guard_start_dialog

[walker6@esc_lager]
on_info = {=time_testoww5} sleeper11@esc_lager
on_info2 = {=time2_testoww5} sleeper11@esc_lager
path_walk = guard_walk4
meet = meet@lager

[sleeper11@esc_lager]
on_info = {=time_testoww6} kamp6@esc_lager
on_info2 = {=time2_testoww6} kamp6@esc_lager
path_main = mod6
meet = meet@lager

[kamp6@esc_lager]
on_info = {=time_testoww7} walker2@esc_lager_zoneguard1
on_info2 = {=time2_testoww7} walker2@esc_lager_zoneguard1
center_point = camp_center
path_walk = camp_center_task
soundgroup = esc_lager
meet = meet@lager

[walker2@esc_lager_zoneguard1]
on_info = {=time_testoww8} walker7@esc_lager
on_info2 = {=time2_testoww8} walker7@esc_lager
path_walk = guard_walk1
path_look = guard_look1
meet = meet2@zoneguard_novice_lager1

[meet2@zoneguard_novice_lager1]
meet_state = 10| wait@talk_hello
meet_state_wpn = 10| threat@threat_weap
victim = 10| actor
victim_wpn = 10| actor
use = true
use_wpn = true
meet_dialog = escape_lager_guard_start_dialog

[walker7@esc_lager]
on_info = {=time_testoww9} sleeper12@esc_lager
path_walk = guard_walk4
meet = meet@lager

[sleeper12@esc_lager]
on_info = {=time_testoww10} kamp7@esc_lager
path_main = mod6
meet = meet@lager

[kamp7@esc_lager]
on_info = {=time_testoww11} walker@esc_lager_zoneguard1 возврат в начало
on_info2 = {=time2_testoww11} walker@esc_lager_zoneguard1
center_point = camp_center
path_walk = camp_center_task
soundgroup = esc_lager
meet = meet@lager

 

 

Для каждого из 12 секций могут быть прописанны свои диологи и квесты.

И это всего 1 состояние гулага а может быть несколько.

При выходе в он лайн НПС окажеться именно в той секции которая соответствует времени выхода.

 

Добавлю в оригинале только 3 работы гулага охраняют, ходят, сидят у костра.

При попытках использования потребуеться добавить

sleeper в работы гулага и точку сна  mod6 в аллспавн.

Изменено 24 Июня 2016 пользователем BFG

[Dennis_Chikin 3 658]

Вообще, что касается функций, проверяющих какие-либо условия, стоит доработать xr_logic.script по аналогии с выполнением функций xr_effects по-умолчанию либо из явно заданного модуля. Просто перенести 1:1.

 

А вот что касается размножения time_test7, ...8, 9.6.6.666 и т.д. - аргументы прекрасно передаются, так что вполне достаточно одну time_test(), поскольку parse_infop() совершенно все равно, что разбирать.

 

P.S. Перечитал сейчас свой пост от декабря прошлого года. Вот интересно, зачем я сейчас опять пишу все то же, что очевидно из того первого ? Наверное, по тому, что 8 месяцев отвечал разным людям на все те же вопросы, которые там разобраны, и по тому, что наблюдаемый эффект - скорее отрицательный.

Изменено 24 Июня 2016 пользователем Dennis_Chikin

[AKKK1 6]

@Dennis_Chikin,

 

стоит доработать xr_logic.script по аналогии с выполнением функций xr_effects по-умолчанию либо из явно заданного модуля. Просто перенести 1:1.

Честно не понимаю чем не устраивает xr_conditions.script или вы(ты) хочешь чтоб все функции вызываемые из схем логики располагались в одном файле ?

И привести использование этих функций к одному стандарту ?

Если так то я только за.

 

 

А вот что касается размножения time_test7, ...8, 9.6.6.666 и т.д. - аргументы прекрасно передаются, так что вполне достаточно одну time_test(), поскольку parse_infop() совершенно все равно, что разбирать.

Dennis_Chikin   я в скриптах  ноль нулевой ))  и ни когда этого не скрывал .

Но попытаюсь все таки скубатурить  то что понял из твоего(вашего)  поста.

 

Предлагается заменить все функции типа  function time_testoww9()  одной с передачей аргументов.

Вот так это видеться мне ...

Пишиться одна функция function имя_имя()  в которой  все нужные условия учтены.

Тоисть  все 12 функций сведены в одну которые для каждой из 12 передают нужные аргументы, а именно.....

Аргумент допустим 1time   если время то  TRUE

Аргумент допустим 2time   если время то  TRUE

Аргумент допустим 3time   если время  то  TRUE

 

Тогда при использовании в секциях логики

function time_test() тут нужный аргумент ?

 

[logic@esc_lager_zoneguard1]
active = walker@esc_lager_zoneguard1

[walker@esc_lager_zoneguard1]
on_info = {=time_test} walker5@esc_lager охраняет
on_info2 = {=time_test КУДА ВСТАВЛЯТЬ АРГУМЕНТ ДЛЯ } walker5@esc_lager
path_walk = guard_walk1
path_look = guard_look1
meet = meet@zoneguard_novice_lager1

Денис если вы сможете написать такую функцию то многие спасибо скажут когда поймут что это дает .

 

 

Как ни странно я не закончил .

Но продолжу чуть погодя )).

 

Извиняюсь за цитирование предыдущего поста но я пост писал часа 2 ))). 

 

Вот новое хотя фиг знает но 5 лет назад этого в статьях про логику не было.

 

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

 

 

 

Где то тут я видел попытки узнать население гулага.

 

НУ и вызов любой функции при юзе объекта.

 

on_use = {+info -info =func !func ~number} %+info -info =func% <название_схемы> - определяет, что произойдёт, если актор взаимодействует с объектом.

Изменено 25 Июня 2016 пользователем AKKK1

[Dennis_Chikin 3 658]

function pick_section_from_condlist( actor, npc, condlist )

...
		if c then	-- ВСЕ условия выполнены; выдаем инфо/вызываем функции, как просили
			for i, v in ipairs( cond.infop_set ) do
				if v.func then	-- вызываем функции из %=func%
					c, f = string_match( v.func, "(.+)[.](.+)" )	-- c больше не нужно
					if f then 			-- c - скрипт
						c = _G[c]
						if c then f = c[f] end
					else f = xr_effects[v.func]	-- f определено в xr_effects
					end

Если нужно вызвать функцию, то вот здесь выбирается, откуда ее вызывать.

А вот проверка условий:

			elseif v.func then	-- вызывается функция из xr_conditions.script
				f = xr_conditions[v.func] or abort( что-то там )

- то есть, просто здесь надо доработать аналогично тому, что выше.

 

Передача параметров в вызываемую функцию - типичный пример из оригинала, gulag_escape.ltx:

on_info = {=gulag_population_le(esc_lager:6)} walker@esc_lager_defend_new1

Соответственно, функция с проверкой из оригинала же:

-- true, если  в указанном гулаге народу меньше чем надо.
function gulag_population_le(actor, npc, p)
	return ( not p[1] or not p[2] ) or ( xr_gulag.getGulagPopulation( p[1] ) <= p[2] )
end

Проблема с онлайном/офлайном здесь в том, что используется xr_gulag.getGulagPopulation, которая только для онлайна.

Для того, чтобы работало и в офлайновом гулаге тоже, надо что-то типа

function get_population( name )
	local strn = name and alife():object( name )
	local g = strn and strn.gulag
	return ( g and g.population_comed ) or 0
end

- но это уже отношения к логике не имеет. Изменено 25 Июня 2016 пользователем Dennis_Chikin

[AKKK1 6]

@Dennis_Chikin,

 

Честно не понял как мне  12 функций времени  свести в одну вызываемую из логики функцию c определенными значениями для каждой из 12  значения  true и  false .

[naxac 2 447]

@AKKK1, наверно как-то так:

function has_hours_interval(actor, npc, p)
  local t1, t2 = unpack(p)
  if not (t1 and t2) then return false end
  local h = level.get_time_hours()
  return h>=t1 and h<t2
end

Ну, еще дописать обработку, если интервал из разных суток берется (например, между 20 и 3 часами).

В логике будет так:

{=has_hours_interval(4:7)}

Изменено 28 Июня 2016 пользователем naxac

[Карлан 1 049]

Поскольку я полный лох в логике, то начал ее изучение с чего попроще, с монстров и рестрикторов. Сейчас репорт о хомах. Изначально вообще возьмем что это движковая фишка и схема лишь оболочка, как и паника например (ее я вообще вырезал, так как пустышка), посему, чтобы достичь корректной динамики в этой схеме можно добавить установку пляски не только вокруг путя, но и вокруг вертекса. Это делай раз. Далее меня всегда бесили "невидимые" стены выставляемые хомам, это позволяло их с легкостью убивать и добавляло им феноменальной тупости с т.з. игрока. Делай два.

 

Итак, в движке я расширил функции сет_хом и добавил возможность установки пляски вокруг вертекса, и еще добавил функцию активен ли хом в данный момент.

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

1. Добавил возможность установки пляски вокруг вертекса.

2. Удаление хома если монстр видит своего врага (еще коммент приведу :

     --// TODO: надо еще сделать проверку на то какой враг крутой, и если круче, чем моб, то не давать уйти в алайф, чтобы, допустим, две драных собаки не нагоняли мужика в экзе с фн

)

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

 

Теперь о колоссальных плюсах. Я добавил функцию для CSE_Abstract, которая позволяет объекту задать имя скриптом, следовательно мы можем создать рестриктор БЕЗ ЛОГИКИ, от него для хома нам нужно только имя, далее спавним сколько угодно монстров и заполняем им кастом дату (или если оверрайды не нужны то можно прямо движковый хом ставить), где устанавливаем им специальный флаг (st.obj_point           = cfg_get_string    (ini, section, "obj_point")) - это сид или имя объекта, в данном случае нам нужно поставить имя объекта и схема сама поставит его вереткс.

 

Отсюда получаем возможность полностью динамически управлять хомами, и, самое главное, это никакие не костыли, а корректные расширения движка и вменяемая обвязка. Сейчас можно создать где-то 10-15 рестрикторов (без всяких community и capacity, они только ограничивают, хотя потенциально нужны для контроля), запустить в каждый рестриктор по 5-10 хомов, и далее циркулировать им кастом дату (поинт) с ресетом схемы, в результате они будут перебегать с одного места на другое не теряясь и не тупя из-за чего попало, как это было на костылях вроде in/out рестрикторов или general_lair (или как его там ).

 

Я все проверил.

 

Финита!

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

[Expropriator 2 118]

@Карлан, это кому адресовано? Если ты лох в логике, то я дважды лох. Я думал, что Хом - это что то из разряда геометрической статики, а оно видишь как закрутило.

[Карлан 1 049]

@Дизель, это всем адресовано. Я занимаюсь рефакторингом кода, и какие-то общеполезные вещи стараюсь фиксировать в надлежащих темах, чтобы и другие видели, и, если в этом тоже разбирались или разбираются, то могли высказать свои дополнения или какие-то исправления для моего изложения.

 

Достаточно осознать, что в оригинале монстры не сохраняются, и копать их логику становится значительно проще. Кроме как в кампе и волкере, из используемого, ничего заумного нет, в основном движок (до которого скриптеру особого дела нет, если это не я) и немного математики (mob_kicker например). Кстати к некоторых схемах есть то самое выбрасывание в алайф если монстр почуял врага и у него нет френдли оверрайда, почему не сделали это в хоме я не понял, сразу возвратить в хом (не дожидаясь общего ресета), как я написал выше, по окончанию бойни труда не составляет, так как скриптовую логику мы ему не удаляем, она вся остается и служит нам отличным флажком, а вот движковую всю напрочь, тут да .

[Карлан 1 049]

Это снова я. И снова я разбираюсь в логике. Теперь у меня на столе был sr_teleport. В общем задачи которые себе ставил, это сделать возможность делать из него аномалию, которая еще бы и объекты перебрасывала если я захочу. В общем вот так. Как оказалось все не так трудно, и даже сделать переброс на другие локации очень просто, но я пока не сделал, так как там уже надо делать всякую муторную работу по вычислению координат вручную, а тут всего делов взять левел граф и уже все работает.
 
В движке ничего не добавлял. В оригинальной игре вроде нельзя сделать переброс обычных объектов, так как там только телепорт актора есть.
Результат:

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

Код привести не могу, так как, исходя из предыдущего опыта, выкладывание моих работ тут остро порицается, а я ухожу на отдых.

[Kondr48 314]

 

Карлан, а есть какой-то практический смысл от этих постов? Раз уж движок при этом не изменялся, почему бы и не поделиться? Кем интересно это порицается.

 

[hi_flyer 75]

 

 

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

Верно, alife():teleport_object появился в расширенных версиях движка вроде xray-extensions. 

[Карлан 1 049]

Карлан, а есть какой-то практический смысл от этих постов?

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

 

Раз уж движок при этом не изменялся, почему бы и не поделиться? Кем интересно это порицается.

Администрацией. Я как-то попытался, по рукам сильно дали, дальше поговорка про коня. Скорее всего на своей площадке на днях дропну, чтобы никому не мешать и никого не нервировать.

 

Offtop.

[HellRatz 2 892]

Администрацией. Я как-то попытался, по рукам сильно дали, дальше поговорка про коня.

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