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

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


Svoboда

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

(изменено)

интересный вопрос возник:

в Cwound_manager:update() и в action_wounded:execute() self.object - один и тот же ?

self.object:name() - возвращает имя непися.

self.object:object( "medkit" ) в первом возвращает аптечку, во втором - nil. В инвентаре у непися при торговле в это же самое время аптечка визуально присутствует.

 

Upd: все оказалось смешнее:

~info~ [xr_wounded] (esc_vagon_wounded):eat_medkit

~info~ [xr_wounded] (esc_vagon_wounded):eat_medkit, found medkit

sv reject. id_parent [5738][stalker:esc_vagon_wounded] id_entity [32274][medkit:medkit32274] [11946]

sv destroy object [32274][medkit:medkit32274] [11946]

~info~ [xr_wounded] (esc_vagon_wounded):eat_medkit, done

~info~ [xr_wounded] (esc_vagon_wounded):update, need use medkit (hp: 31.048185348511)

~info~ [xr_wounded] (esc_vagon_wounded):update, medkit: medkit (32274)

А вот на следующем апдейте ее уже нет.

Изменено пользователем Dennis_Chikin

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


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

Проверте меня, плиз (да, опять регэкспы)

 

ТЧ, utils.parse_waypoint_data() - будет ли вполне эквивалентом:

function parse_waypoint_data( path, flags, pname )
	local t = { ["flags"] = flags }
	for k, v in string_gfind( pname, "|([%w_\\%-%,%*]+)=*([%w_\\%-%,%*]*)" ) do
		if v ~= "" then t[k] = v; else t[k] = "true" end
	end
	return t
end

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


Ссылка на сообщение
(изменено)

Да. При этом бы еще знать бы, какие они вообще бывают.

Но та монстрофункция из utils мне "почему-то" ну вот совсем не нравится.

 

p.s. string_gfind == string.gfind, разумеется.

 

Еще б понять, от чего та "защита" из оригинала способна защитить... Все, что я способен измыслить - либо вылетит/повиснет раньше, либо пройдет эту "защиту" со свистом.

 

Про смысл набора - аналогичный интерес. Как обычно: мож чего-то хотели, но не доделали, мож и вправду смысл имеет, но в оригинале не использовано. А может - как умели - так и написали.

Не, на таком уровне править точно не рискну. Мне достаточно, что это теперь типа инлайнить можно, а не через 5 скриптов вызывать.

Изменено пользователем Dennis_Chikin

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


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

А на 4-й день Зоркий Глаз заметил, что у тюрьмы забыли построить 4-ю стену...

 

В смысле, что, оказывается, дохлые монстры продолжают пытаться переключать схемы, и даже успешно это делают. Например, постоянно включают mob_home (следовательно, до нее было что-то еще ?).

 

По-моему, в этом есть что-то не совсем нормальное...

У кого какие мысли по этому поводу ?

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


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

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

Далее, это просто бесцельная трата ресурсов.

 

Самое поганое, что я не могу понять, откуда оно лезет, и при каких условиях.

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


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

До 2014-го она дожила по тому, что все предпочитают что-то делать параллельно и в глубоком подполье. ;)

И на совместимость всяких правок/адаптаций/аддонов между собой всем тоже плевать.

Это во-первых.

 

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

 

В-третьих - сколько ж можно тащить древний мусор ? Ага, это я про if i~=255 then...

 

Да, кстати, о птичках: кто нибудь знает, что на самом деле делает :GetPhraseScript(), и что именно возвращает ?

 

Ну, local sc = phr:GetPhraseScript()

local phr = d:AddPhrase( что-попало )

local sc = phr:GetPhraseScript() ... повторить 100500 раз - это, понятно, явный мусор же.

А вообще он в каких случаях действительно нужен ?

 

Да, что касается xr_gulag.getGulagState() - "это не бага, это фича !"

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

 

Приходится дублировать руками на месте уже правильно, либо вставлять в тот же xr_gulag дублирующую (привет, совместимость).

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


Ссылка на сообщение
(изменено)

Читал тему. Много думал. Потом читал "шапку" (1-й пост), и снова тему, и опять много думал.

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

 

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

И куда у вас из-за этого исчезают все НПЦ (тоже, в какой версии, и какой игры). А если не из-за этого, то из-за чего ?

По тому как лихорадочно просмотрел все скрипты ТЧ1.0006 и не обнаружил ничего из упомянутого в сообщениях на этой странице.

 

Действительно, ерунда какая-то получается. ©k01jan

 

Может бы мне кто-нибудь компанию в чтении шапки темы составит ?

 

mumie, что касается неписей, на которых смотрит актор, то если бы это был ТЧ, я бы посоветовал обратить внимание на xr_meet.script, и еще пачку других, сходных по смыслу.

Изменено пользователем Dennis_Chikin
  • Нравится 1
  • Не нравится 1

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


Ссылка на сообщение
(изменено)

Вот честно говоря, ни разу не замечал "неповоротливости". Общее тормозилово на фоне развернутого инвентаря на фоне кучи неписей с фонариками на фоне тумана на фоне кривых текстур - это - да.

Оно разве не в настройках задается ?

 

И, соответственно, mouse_sens через консоль должно отрабатывать.

Изменено пользователем Dennis_Chikin

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


Ссылка на сообщение
(изменено)

macron, скорее, наоборот, забыл уже, как оно раньше было. Посмотрю.

 

 

k01jan,

И отдельно:

 

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

 

Вот тоже сколько раз писалось: не делайте ничего по on_death, кроме минимально необходимого. И даже по апдейту после него не делайте. Минимум 2 секунды выждать, и то - это эмпирика, которая на конкретной машине под конкретный движок получена. Ага, особенно, если "перестрелка яростная".

Изменено пользователем Dennis_Chikin

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


Ссылка на сообщение
(изменено)

1.

function fn1( ... ) {здесь могла быть Ваша реклама} end

local t = { ["myfunc1"] = fn1 }

function call_something( name, ... ) if t[name] then t[name]( ... ) end

 

Не подойдет ? А вернется - откуда вызвано. Другое - против идеологии языка, и в общем-то трудно представить: зачем бы оно.

 

2. Я бы не назвал это "работает".

 

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

Изменено пользователем Dennis_Chikin

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


Ссылка на сообщение
(изменено)

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

 

А вот подробности, если что где непонятно, там же могу и объяснить. Здесь не буду, именно по тому, что привязано к соли, а не к чистому сталкеру - то есть, для остальных - бесполезно.



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

function fn( obj )
obj.n_used = ( obj.n_used or 0 ) + 1 -- сколько раз с ним что-то делали
end Изменено пользователем Dennis_Chikin

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


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

db.storage[0].pstor.переменная = значение.

 

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

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


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

Просто не спавнить в "дырявых" местах. Не лечится, кроме как правкой рельефа.

Ну или только соответствующий класс использовать.

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


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

По факту, в итоге выход нашли в том, что спавнится ящик/мешок, а предметы - уже туда.

 

И, да, надо посмотреть, как именно проваливается. Если, классический пример - предметы на крыше элеватора на Кордоне - одно. Если это типа артов, уходящих под текстуры - другое.

 

Кроме того вижу терминологическую путаницу: game_object - это который создался в онлайне. Серверный - это тот, который возвертает alife()

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


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

Для поиска нужного как раз и существует получение объекта через SID и через имя.

 

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

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


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

"Пишет что не знает что condition() обращается к nil" - какая хоть из строк-то ? (Ну лень все внимательно просматривать. ;))

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


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

Вот в этом варианте и не должен.

:condition() есть только у клиентского.

здесь - это - не он, во вторых, клиентский даже еще в онлайн перейти не успел.

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


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

Вешать на циклическую проверку в апдейте, и ждать, когда этот самый local repair_kit = db.actor:object("repair_kit_weapon") появится.

 

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

local tasks_list = {}	-- имя, группа( 50, 200, 1000, 5000 ), функция --

local t50, t200, t1000, t5000 = {}, {}, {}, {}		-- группы { строка для wathdog, функция }
local t50n, t200n, t1000n, t5000n = 0, 0, 0, 0		-- функций в группе
local t50i, t200i, t1000i, t5000i = 1, 1, 1, 1		-- текущая функция в группе
local t50t, t200t, t1000t, t5000t = 0, 0, 0, 0		-- время следующего обновления
local t50q, t200q, t1000q, t5000q = 50, 200, 1000, 5000	-- через сколько обновлять


function task_add( tname, tgroup, f )
	if ( tgroup or 200 ) == 200 then t200n = t200n + 1; table_insert( t200, { f, tname } )
	elseif tgroup == 1000 then t1000n = t1000n + 1; table_insert( t1000, { f, tname } )
	elseif tgroup == 5000 then t5000n = t5000n + 1; table_insert( t5000, { f, tname } )
	elseif tgroup == 50 then t50n = t50n + 1; table_insert( t50, { f, tname } )
	end
end

function task_del( tname, tgroup )
	-- log( "info", "task_delete, task: [%s], gp: %s", tname, ( tgroup or "any" ) )
	if tgroup or 200 == 200 then
		for i = 1, t200n do
			if t200[i][2] == tname then
				t200n = t200n - 1; table_remove( t200, i ); return
	end	end	end
	if tgroup or 1000 == 1000 then
		for i = 1, t1000n do
			if t1000[i][2] == tname then
				t1000n = t1000n - 1; table_remove( t1000, i ); return
	end	end	end
	if tgroup or 5000 == 5000 then
		for i = 1, t5000n do
			if t5000[i][2] == tname then
				t5000n = t5000n - 1; table_remove( t5000, i ); return
	end	end	end
	for i = 1, t50n do
		if t50[i][2] == tname then t50n = t50n - 1; table_remove( t50, i ) end
	end
end

и

function actor_binder:update( delta )
...
	if t200i == 0 then	-- ни чем не заняты ?
		if global_time_ms >= t200t then t200t, t200i = global_time_ms + t200q, 1
			-- kostri_update()	-- используем этот цикл под что-нибудь полезное
		end
	else
		gp_fn =  t200[t200i]	-- выполняем последовательно что там еще есть
		if gp_fn then t200i, amk.oau_watchdog = t200i + 1, gp_fn[2]; gp_fn[1]()
		else t200i = 0		-- и используем остаток

	end	end

 

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


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

А это чтобы 2 раза не вставать.

local global_time_ms = time_global(), ну или типа того...

 

Проверок-то 4 штуки, на 50, 200, 1000 и 5000ms, да и внутри не по разу используется.

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


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

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

AMK-Team.ru

×
×
  • Создать...