Форумы Архив » Свалка Вопросы и ответы (ТЧ по 11.09.10)

Скажите, а как называется музыка которая играет в меню Priboy story ? Очень нужно узнать название

singapur22

Появилось немного времени и попробую сеейчас описать процесс доступа к параметрам из 'cse_abstract' на примере создания лампочки (удобен тем, что и не сильно влияет на остальные объекты/игру и методы все работают).

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

А вот про cse_abstract, давай.

Вот поумнее и поковарнее этого кровососа сделать - вот этим стОит заняться. 'Мозги' ему нужно добавлять (AI-схему) а не анимашки! (ИМХО)
дело говорит, можно начать с простого, это подкрадывание кровососа сзади втихушку, а потом как долбанет по башке и почти все жизни сносит нафиг.

Mehanik Yar, ты видел, что написал Дезодор по поводу этого? Он сказал, что DLLки ломал помимо скриптов. Правда я не знаю зачем, но беспокоить не буду больше.

singapur22
И НЕ соглашусь с твоей фразой об удобстве хранения дополнительных акторских данных в его же юзердате. 'НЕ соглашусь' именно с фразой, а не сутью, т.к. БЕЗ оговорки/предостережения эта фраза больше вреда приносит! Очень удобно, но и очень опасно!
Сам наелся с ней и еще долго буду разгребать коды сборки (остатки АМК и других) от этого "удобства".

То, что наиболее удобно сохранять и брать из юзердаты актора - это верно, НО(!) на сколько?
Есть ли минусы у этого варианта? Чем грозят эти минусы, есть ли они имеются?

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

---

SkyLoader
Станный ты ... Вначале кинулся искать способ реанимировать поцелуйчик. Теперь, получив от Дезодор'а ответ как сделал он, понял, что тебе (и другим неопытным) реанимировать неудастся.
Зачем же теперь распространять табу на копания с кровососам на все и всех?
Mehanik Yar высказал абсолютно здравую мысль, к твоему поцелую это не имеет отношения. Реализуемо это и без ковыряния в dll'ках ... Да и только ли Дезодор'у это подвластно? :-) Кому понадобится - расковыряет не хуже.
Давай не будем муссолить тему поцелуйчиков по каждому поводу. Без практических результатов, вопросов/ответов это уже злостный оффтопик.

Ладно, попытаюсь сам поковырять. Главное узнал как, теперь все норм.

---

---

тебе (и другим неопытным)

---

...

---

Ну может ты и прав. Потому что у меня есть вопрос: если у меня есть в таблице, например, 3 любых непися, то я могу у всех них взять юзердату и спавнить на их координатах мой предмет?

SkyLoader
Задавая вопрос, старайся подумать:"А достаточно ли он внятен и информативен для других?"
Как понимать твое 'у меня есть в таблице, например, 3 любых непися'? Что у тебя там в таблице? Скрины неписей, их идентификаторы, собственно их юзердаты иль еще только тебе ведомое?
Если неписи - то обычно под этим и понимают объекты неписей, т.е. твои искомые юзердаты.
Если идентификаторы, то возможность 'взять их юзердаты' зависит от этих идентификаторов. По игровому, стори- идентификаторам нет проблем. По имени - скорее всего ...
Итак получив юзердаты объектов (неписей) и не важно серверные иль клиентские - бери их координаты и спавни сколь угодно ... Вот только один предмет ты можешь заспавнить только раз, а не размазывать по трем ... :-)

Есть у кого-нибудь пример сохранени**50016ea8aab1bb10eeba**unt = {}
Если то сё тогда
count = count + 1[/code]
Кажется, я локальную не правильно задал.Если что - поправьте.
Как этот плюс один сохранить, чтоб не сбивалось при загрузке игры?.Читал где-то про это, но как-то не очень понятно.Так что желательно примерчик показать, если есть, так легче усваивается:-)

Artos Собственно, опасности не вижу. Да и определить её, тем более пустыми размышлениями **50096ea8aab1bb10eeba**labla:__init()
self.key = 75
end

аналогично

local bla = blabla()
bla.key = 75[/code]

С одной лишь разницей, что во втором примере, ключь добавляется отдельному объекту класса.
Если данного ключа у какого либо объекта не наблюдается, просто возвращается nil.
Тут главное не промахнуться, и не переустановить уже имеющийся ключ, установленный двиглом. Но и здесь я проблем не вижу. Все списки уже имеющихся ключей имеются в файле lua_help.script

Stalk15
Ты хоть сам прочти что написал!
Совсем уже не хотите головой думать, когда пишите? 8-)
О какой таблице ты вопрошаешь, ещели в коде одни числовые переменные видны.
В кодах и 'count_o' и 'count' ... и что тебе трЭба сохранять?

---

singapur22
Ты упустил самую 'малость', которая многим модмейкерам доставила и доставляет немало огорчений/хлопот.
Размер СОХРАНЯЕМОГО стораджа актора (db.storage[db.actor:id()].pstor) имеет ограничение по объему НЕ более 8196 байт.
Если учесть, что при штатном прохождении игры этот объем заполняется 'штатными' данными примерно до 4-5 килобайт, то тебе на все про все (удобство хранения) остается не так уж и много (все конечно в сравнении).
Превышение объема грозит тем, что при сохранении чрезмерной таблицы ты получишь битый сэйв.

---

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

Stalk15
Попробуй разобраться с этим. Не таблицы, но данные сохранять можно, только не очень много - экономь "юзердату актора". Описание: Функции для записи данных в сохранения. Пишет-читает: числа, строки, дату-время, логику.
http://file.qip.ru/file/r6rMnuyb/u_online.html

Artos
Я старался, что-бы не поперёк того, что я видел в оригинале было - а там гдето проверки какие-то видел.... вот и ограничился...

Artos

---

Размер стораджа актора (db.storage[db.actor:id()].pstor) имеет ограничение по объему НЕ более 8196 байт.

---

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

Хотя... А почему бы и нет. Ведь тот же Сидор, всегда имеет своё существование (он ведь бессмертный). А посему, тоже вариант. Надо попробывать.

Попробывал. Всё пучком. :-)

Artos, в таблице находятся юзердаты РАНДОМНЫХ 3-х неписей, мне надо взять юзердату каждого непися и 3 раза спавнить (т.е. 3 раз

Artos
Ошибся, в посте исправил.

MRN$
Я видел твой скрипт.Но я не понял, к**50016ea8aab1bb10eeba**storage[db.actor:id()].pstor[name]
return yds2CTime(name)
end
end[/code]

Stalk15

Так писать число, строку или логику:
datawrite(name,action,value)
action - должен быть, но действует только на числа: 0 - просто записать, 1 - прибавить к тому, что есть, 2 - умножить на то что есть;
записанное читать так:
dataread(name)

Так писать время:
datawrite(name,action,yy,mm,dd,hh,mn,sc,msc)
action - должен быть для порядка, любой.
записанное читать так:
dataread(name, datatype)
datatype - любое значение, только не нил

Там внутри небольшое ридми есть.
(ладно, позже сделаю примеры на все случаи, сброшу в ПМ)

singapur22
Это не общая проблема, т.к. объема стораджа вполне хватает исходной игре и мелким модам. Точнее тем модам/модмейкерам, которые не сохраняют досточных объемы данных из своих кодов.
Вспомним историю и пройдем дальше:
АМК-мод: Добавлен алкоголизм, добавлена возможность зомбирования контролерами. Т.к. и кол-во выпитого и кол-во контролеров и зомбированных ими неписей не ограничено - это привело к переполнению сэйвов и их краху.
Уже тогда командой АМА была введена в моде и предварительная проверка объекма перед записью стораджа и разгрузка от лишних данных ...
Сейчас множество модов юзают сторадж актора. Рандомные тайники, рандомные награды, маячки со списками хабара и т.д. Все это приводит к балансировке на грани краха сэйвов при использовании 'удобства' хранения и сохранения в юзердате актора.
Отвечу на твой вопрос:

---

... где модмейкеры сохраняют данные своих скриптов?

---

- Совсем малоопытные, как Stalk15 , нигде, пока им не подскажут.
- поопытнее - юзают сторадж актра (пока недосохраняются до крахов сэйвов).
- опытные - начинают 'размазывать' данные (хранить децентрализованно) по самим объектам игры.
- набившие шишки, но не бросившие затеи сохранять много - да хоть у Сидорыча могут хранить, хотя часто используют доп.предметы для этого (флешки и т.п.).

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

Artos Вопрос стоял не о том, где ты сбудешь СОХРАНЯТЬ данные, а в том, можно ли использовать userdata объектов, для текущего хранения их данных, дабы не создавать глобальных переменных, или не передавать данные из файла в файл, которые между собой только и связаны их использованием. Не для сохранения в сейв, именно для текущего хранения, пока не будет произведена перезагрузка. А если трэба ещё и сохранение в сейв, то это уже другая тема, так как в любом случае, пока ты их не пропишешь в сохранки, сохраняться они не будут.
В течении онлайна, новые данные можно держать в акторе, а сохранять в той же флэшке. Суть от этого не меняется. Что ты их будешь держать в глобальной переменой, что у актора. Но согласись, второе значительно удобней.

Stalk15
Для твоего част

Artos Почему вы так нервно реагируете на поцелуй кровососа?))) Он вас не кусал??))
Если вам не нравится этот вопрос, не отвечайте не него, кому надо тот его и помусолит. Тема открыта не для вас лично и вы здесь не хозяин! Посмотрите на свои посты, вам не интересно и вы говорите все завязываем...с чего вдруг? Вы кто?
Не хотите помогать по данному вопросу не помогайте, вас лично НИКТО не просит.
п.с. не думайте что все вокруг идиоты.
==========================================
Пишу в ЛС, наши разборки некому не нужны, да и порядок будет :-).

Как отключить сообщение о помощи от беса,или крота?

and_modern

Не в тему сегодняшнего обсуждения, но вот столкнулся со странной проблемой - может кто сталкивался.
Спавню (одновременно) два объекта на одной координате - то есть передаю им одни и те же цифры.
При спавне на текущем уровне все нормально - оба объекта на одном месте.
Перешел на другой уровень - (объекты предварительно уже были там заспавнены с начального уровня ) и вижу такую картину - один объект в одном месте, другой фиг знает где - метров на сто от него. Хотя одна-две пары(из почти двух десятков) все таки были на своих местах. Отчего может быть такой разброд и непопадание в одни и те же координаты? И собственно как же тут быть?
--------------------------------------------------
Кстати заметил зависимость реагирования объектов на хит от их визуала: рюкзак - практически не реагирует - у меня получилось только один раз попасть в нужную точку, чтобы каллбек сработал.
Динамитный ящик - чтобы каллбек сработал нужно стрелять по краям, по центру - не реагирует.
Маленький лабораторный ящик - так и не среагировал ни разу. Дипломат, сейф, кейс, деревянный ящик, контейнер - к хиту чувствительна фактически вся площадь визуала.

SkyLoader
Ну очень информативно твое уточнение по 'РАНДОМНЫМ' как будто это чем-то помогает.
Что тебе следует сделать (один из вари**50016ea8aab1bb10eeba**_2:game_vertex_id())
My_Table[soObj .id] = "непись_3"
soObj = alife():create("непись_3",непись_3:position(),непись_3:level_vertex_id(),непись_3:game_vertex_id())
My_Table[soObj .id] = "непись_3"
end
[/code]

erlik На счёт хита. Смею предположить, что объекты в Сталкере имеют два типа коллайдеров. Движковый, и скриптовый. Движковый, это тот, который отслеживает хит и воспроизводит, озвучку попадания и маркеры хита (дырки), (имеется практически у всех объектов с установленным визуалом .ogf), а так же удаляет хитующий предмет (если пуля). Скриптовый, который ставится в скриптах, и уже там используются его результаты. Видимо размеры коллайдеров не синхронизируются. И скриптовый коллайдер имеет меньшие размеры, чем движковый. Они явно должны быть одинаковыми. В итоге, движковый коллайдер удаляет хитующий предмет раньше его входа в скриптовый коллайдер. Проверить можно путём хитования не пулями, а ножом. Нож в данном случае проходит в глубь любого объекта без удаления онного.

P.S. Это только предположения.

Artos, под понятием РАНДОМНЫЕ я понимал некий перебор айди, и если вот к примеру отсеялось 3 каких-то непися, вот их то я имею ввиду.
Как узнать, сколько в таблице значений? (например {a,b,c,d} - т.е. 4 значения).

SkyLoader
'...--тут я вставил 3 неписей' - как? Зная структуру таблы, можно уже попробовать отт

Darien Fx,
**50016ea8aab1bb10eeba**ей
table.insert(table, obj)
...--а дальше знаешь[/code]

Получаем доступ к 'cse_abstract' объекта
(на примере cse_alife_object_hanging_lamp):

Предполагаем, что для нашего объект**50106ea8aab1bb10eeba**ocal soHLamp = alife():create("aem_lamp", vPos, iLvid, iGvid) --/ aem_lamp - секция[/code]
Если доступен метод se_lamp:on_register(), то можно увидеть момент, как заспавненный объект регистрируется в игре.

2. Ставим 'метку' о необхоимости доступа к 'cse_abstract'. Метка может быть как с информацией о требуемом значении параметра, так и целой табличкой с параметрами:
[code] soHLamp.direction_new = vector():set((0,0,3.14) --/ метка-значение[/code]
или
[code] local tParams = {
direction = vector():set((0,0,3.14),
... = ...
}
soHLamp.repaсk = tParams --/ метка-таблица[/code]
3. Переходим к методу se_lamp:STATE_Write(packet), в который добавим проверку наличия флага перепаковки и обработку флага:
[code]
function se_lamp:STATE_Write(packet)
if self.repack ~= nil and self.repack.direction ~= nil then --/ проверка наличия флага
local tP = self:Get_cse_abstract(packet) --/ читаем в таблицу параметры 'cse_abstract'
tP.direction = self.repack.direction --/#!# изменяем параметр
self.repack.direction = nil --/ удаляем флаг
self:Set_cse_abstract(tP, packet) --/ запоминаем параметры 'cse_abstract'
end
cse_alife_object_hanging_lamp.STATE_Write(self, packet)
end[/code]
4. Методы чтения и записи (при необходимости) т.е. перепаковки:
[code]--/ чтение cse_abstract (чтение пакета oPk в таблицу tP)
function se_lamp:Get_cse_abstract(oPk)
local tP = {} --/ создаем чистую таблицу
oPk:r_seek(0)
tP.dummy16 = oPk:r_u16()
tP.section_name = oPk:r_stringZ()
tP.name = oPk:r_stringZ()
tP.s_gameid = oPk:r_u8()
tP.s_rp = oPk:r_u8()
tP.position = oPk:r_vec3()
tP.direction = oPk:r_vec3()
tP.respawn_time = oPk:r_u16()
tP.object_id = oPk:r_u16()
tP.parent_id = oPk:r_u16()
tP.phantom_id = oPk:r_u16()
tP.s_flags = oPk:r_u16()
tP.version = oPk:r_u16()
tP.script_version = oPk:r_u16()
tP.unused = oPk:r_u16()
if tP.unused > 0 then --/#?# читаем остаток, возможно, что иногда это не верно
tP.tExt = {}
for i=1, tP.unused do
tP.tExt = oPk:r_u8()
end
tP.spawn_id = oPk:r_u16()
tP.extended_size = oPk:r_u16()
end
return tP --/> таблица с параметрами 'cse_abstract'
end[/code]
[code]--/ запись cse_abstract (из таблицы tP в пакет oPk)
function se_lamp:Set_cse_abstract(tP,oPk)
--/ запись таблицы (если перепаковываем)
oPk:w_begin (tP.dummy16)
oPk:w_stringZ(tP.section_name)
oPk:w_stringZ(tP.name)
oPk:w_u8 (tP.s_gameid)
oPk:w_u8 (tP.s_rp)
oPk:w_vec3 (tP.position)
oPk:w_vec3 (tP.direction) --/#!# Именно это изменяем
oPk:w_u16 (tP.respawn_time)
oPk:w_u16 (tP.object_id)
oPk:w_u16 (tP.parent_id)
oPk:w_u16 (tP.phantom_id)
oPk:w_u16 (tP.s_flags)
oPk:w_u16 (tP.version)
oPk:w_u16 (tP.script_version)
oPk:w_u16 (tP.unused)
if tP.unused > 0 and tP.tExt ~= nil then --/ запись остатка
for i=1, tP.unused do
oPk:w_u8 (tP.tExt)
end
oPk:w_u16 (tP.spawn_id)
oPk:w_u16 (tP.extended_size)
end
end[/code]
5. Собственно все.
Если не требуется перепаковка, то менять в таблице tP ничего не следует, а ее содержимое можно использовать для различных целей.

Данный материал (коды) вполне работоспособны и могут быть использованы конкретно для ламп.
Однако именно для ламп помимо перепаковки рассмотренного параметра требуется изменение и других параметров, что не рассмотено в данном материале.
Для других объектов требуется изменить наименование класса (se_lamp) под соответствующий объекту.

---

P.S. исправил оЧепятку soHLamp.repaсk

возможно ли сделать чтоб определенный НПС помечался на карте например как техники, проводники торговцы как ЧН ЗП?