SkyLoader Это уже отдельный эвалуатор и схема поведения, на которую сталкер переключается при особых условиях. А если схему сталкеру не задавать, то управлять им будет невероятно сложно. Слишком многое нужно учитывать. Прошли уже через это.
-----
Поправлю. Не функция, а метод.
----
Это достаточно всё сложно. Но на вики можно найти статью, которая достаточно подробно всё описывает. Вплоть до создания схемы напарника.
Сообщение было успешно отредактировано singapur22 (21-08-2010 21:34 GMT3 часа, назад)
Продолжу насчет INSERT и REMOVE.
Целый день с ними ковыряюсь и выяснилось, что всё гораздо сложнее.
Я был не совсем прав в своих пояснениях.
Небольшой пример из километровой портянки.
Если записать таблицу так
Код:
t = {[2]=2,[3]=3,[4]=4}
то длина таблицы будет равна 0
Любой insert (кроме 1) в такую таблицу поле то вставит, но длина останется равной 0.
А если записать то же но через :
Код:
for i=2,4 do
table.insert(t,i,i)
end
То длина таблицы окажется равна 4
Т.е., забегу вперед, при определенных условиях подобная таблица (без фактической установки некоторых полей) начинает считаться числовым массивом.
И теперь если написать :
Код:
table.insert(t,1,1)
то, как по хэлпу, остальные значения сдвинуться вниз. Т.е. Перестраивается дерево ссылок.
А это значит, что теперь ключу 2 будет соответствовать значение NIL(бывшее значение для ключа 1), ключу 3 значение 2(бывшее значение ключа 2), 4 - 3 и т.д.
При удалении будет сдвигаться в обратную сторону.
Теперь интереснее.
Если 2 раза подряд удалить поле 3 через remove, в таблице перестает читаться это поле(с уже новым значением), с которым шаг назад прекрасно работало.
Т.е. При определенных условиях таблица снова переходит в разряд хэша.
Так, для дальнейшего не будем удалять второй раз поле 3 и вставим
Код:
table.insert(t,6,6)
Поле вставиться, но длина таблицы останется равной 4.
А если следом вставить
Код:
table.insert(t,7,7)
то длина таблицы окажется равной 7 при как бы отсутствующих(мы их даже не упоминали при конструировании таблицы) полях 2 и 4.
Получается что функция remove идет "на поводу" у insert. Если та определит таблицу числовын массивом, тогда и remove будет корректно работать даже про отсутствующем поле с индексом 1(и как выяснилось и с другими)
Определить зависимость построения полей при которых таблица начинает считаться числовым массивом у меня пока не вышло.
Однако выяснил что ключевую роль играют поля, как бы назвать, переходных битов что ли.
Это поля :
1 - первый бит(2 но не 0, а 1)
4 - два бита (4)
8 - три бита (8)
16 - 4 бита (16)
и т.д. до 65536
В общем если нет уверенности что таблица - это целочисленный, последовательно нумерованый массив, начинающийся с ключа с индексом 1, то лучше этими функциями не пользоваться.
Сообщение было успешно отредактировано Gun12 (21-08-2010 23:42 GMT3 часа, назад)
что-то у нас некий пинг-понг получается из диалогов ...
Говорим о трансфере предмета (сепаратор) в ящик - всплывает некий алайф.
Я о том, что трансфер идет между клиентскими объектами (game_object), ты - о 'can_switch_online'.
Я о том что использую 'set_switch_online' и о том, что для инвентори боксов не обнаружил метода 'can_switch_online', ты - о том, что 'set_switch_online' переволит в он-лайн.
Цитатаsingapur22: На счёт sobj:can_switch_online(true). Если указать его как положительное значение, то объект будет находиться в онлайн, пока не указать противоположное.
1. Наверное мне не нужно пояснять что делают упомянутые методы, тем более ... считаю делаешь это некорректно. Поясню: 'can_switch_online' - собственно свойство, позволяющее получить информацию о возможности перевода объекта в он-лайн или передать флаг о возможности такого перевода. 'set_switch_online' - собственно команда перевода объекта в он-лайн.
Ты применяешь 'can' и говоришь о переводе ("будет находиться") - хотя это только возможность перевода, в отличии от применяемого мною 'set' - собственно перевод в он-лайн.
2. Ты говоришь о 'sobj:can_switch_online(true)' для ящика и игнорируешь то, что я не обнаружил этого метола для инвентарных ящиков ... Зачем тогда поминать про этот метод или не пояснить как/к чему ты его применяешь?
Предлагаю не разбрасываться по частностям не относящимся к сути и тем более вольными с нашими трактовками.
А по поясу: Повспоминал свои давние изыскания и (ИМХО) более оптимального варианта для пояса на 'сейчас', чем имеющегося в Симбионе, не вижу.
Использование трансфера в ящик мало что даст в разгрузке ресурсов, т.к. собственно 'поясной' алгоритм задействуется только эпизодически (дроп/тэйк/трансфер).
Может быть использование некоего реального (например бандажа), а не фейкового объекта, и было бы покорректнее, однако могут быть коллизии в конкретных модах/схемах.
Я пока оставил 'как есть', до обнаружения других признаков для поясных предметов.
1. 'can_switch_online' и 'can_switch_offline' --Имеются почти у всех классов объектов. В том числе и у класса 'CSE_InventoryBox'. IDA PRO это подтверждает.
Собсно именно она мне об этом и сообщила. И так же сообщает, что для данного класса эти методы были добавлены с патчем 1.0004.
2. При установке, возможностей переводов:
offline становится не актуальным, и бокс автоматически переводится в онлайн, так как это единственное разрешённое состояние в данном случае.
Я не спорю, set_switch_online(...) был бы более оптимальным вариантом. Но как не странно, но и указанный пример даёт тот же результат.
А по поясу, я уже оставил это дело как есть (вполне применительно). Посему продолжил работу над детектором. Точнее детектор тоже готов. Осталось разобраться с артами.
Цитатаsingapur22: 1. 'can_switch_online' и 'can_switch_offline' --Имеются почти у всех классов объектов.
Именно ПОЧТИ
ЦитатаВ том числе и у класса 'CSE_InventoryBox'. IDA PRO это подтверждает
В завалах кодов от разрабов немало что можно найти ... Однако подтверждение работоспособности того или иного - пока мы можем найти только на практике.
Спаним инвентори бокс:
local soInvBox = alife():create("inventory_box", vPos, iLvid, iGvid) --/ где vPos, iLvid, iGvid берем хоть от актора хоть 'ручками'.
Применяем:
if soInvBox then
soInvBox:can_switch_online(true)
end
Имеем: Фатальный вылет от отсутствия метода 'can_switch_online' для данного объекта.
Вопрос: К чему же и как ты применял указанные методы, говоря о том, что при этих условиях трансфер предмета от актора в ящик становится возможным? (сорри, не могу найти тот пост в топике ...).
Прим: Каких-либо упоминаний об этих методах/функциях для класса 'cse_alife_inventory_box' в 'lua_help.script' также не обнаружено.
Rat_Revenant
А какая разница?
Разрабами много чего задумывалось и много чего было вырезано. Многое из того, что было задумано разрабами было реализовано модмейкерами.
Если ты под призраками подразумеваешь фантомов - то это от разрабов.
Если некие 'полупрозрачные' ходячие ... - поделки модмейкеров.
Сообщение было успешно отредактировано Artos (22-08-2010 01:45 GMT3 часа, назад)
Rat_Revenant Это ты про уродцев, которые встречаются во многих глобальниках? Типо обычные гражданские, только прозрачные и с как-будто налипшей грязью? Это мододелы шаманят.
Но реализовано, то это полностью разрабами, мододелам остаётся лишь расставить этих призраков по локациям, да пару строчек в конфиге поправить.
win win, если полупрозрачных зомби, то вот почитай статьи: http://stalkerin.gameru.net/wiki/index.php/Новые_монстры http://stalkerin.gameru.net/wiki/index.php/Спавн_через_скрипт
Сообщение было успешно отредактировано Максим Р. (22-08-2010 03:03 GMT3 часа, назад)
Это обычные гражданские, но с шейдером "призрака" на текстуре. Модель эта в архивах есть.
Поделки модмейкеров, это взрывающиеся зомби, зомби-блевуны и электро-химеры.
Artos Именно так и использовал!!! Всё работает, и никаких вылетов.
Это кстати не первый случай, где на практике в аналогичных ситуациях, у нас с тобой совершенно разные результаты. (взять например недавно обсуждаемый health).
Я начинаю сомневаться что мы обсуждаем одну и ту же игру.
Ладно, закрыли тему. В любом случае, alife():set_... наиболее актуален, так как переводит сразу, в отличии от sobj:can_..., который только устанавливает требуемое значение, для следующего цикла апдейта.
Сообщение было успешно отредактировано singapur22 (22-08-2010 02:58 GMT3 часа, назад)
singapur22
Игра то одна (по названию), но ее модификации - конечно разные.
Хм, потеряю еще немного времени на проверку ... Неужели у меня так затронут класс, что 'штатные' методы отключились? Всеж это может аукнуться в самый неподходящий момент. P.S. Перепроверил:
1. Убрал всю папку геймдаты и, взяв исходный 'escape_dialog.script', добавил в диалог выдачи оружия Волком:
Код:
local soInvBox = alife():create("inventory_box", vector():set(81,33,689), 377023, 214)
if soInvBox then
get_console():execute("Create_InvBox:<+>")
soInvBox:can_switch_online(true) --/ применяем метод!
get_console():execute("Create_InvBox:<Info!>")
get_console():execute("flush")
end
2. Запуск игры на патче 1.0004 с оригинальными dll'ками в папке 'bin'.
После диалога с Волком:
Код:
[error]Arguments : LUA error: ...s\stalker\shoc\gamedata\scripts\escape_dialog.script:172: attempt to call method 'can_switch_online' (a nil value)
3. Запуск на патче 1.0005 с теми же условиями.
Результат: см. п.2
4 Запуск на патче 1.0006 опять же с восстановлением оригинальной 'bin'.
Результат: см. п.2
Резюме: В оригинальной игре "STALKER:SHOC" версий 1.0004...1.0006 объекты класса 'O_INVBOX' ("inventory_box") НЕ поддерживают метод 'can_switch_online'.
Сообщение было успешно отредактировано Artos (22-08-2010 04:14 GMT3 часа, назад)
singapur22
Дабы ваш пинг-понг с Artos'ом был более результативным - вот результат независимой проверки:
(патч 1.0004)
Кусок кода из скрипта спавна схрона
Код:
local sBox = alife():create(taynik, pos, lvid, gvid)
local res, switch = pcall(CanSwitchOnline,sBox)
if not res then
news_manager.send_tip(db.actor, "Ошибка перевода в онлайн: "..tostring(switch), 0, "trader", 15000)
return end
--внешняя функцию которую вызываем
Код:
function CanSwitchOnline(sBox)
sBox:can_switch_online(true)
return sBox:can_switch_online()
end
Результат:
Вывод - то ли мы спавним разные (по классу) ящики - давай тогда искать разницу в конфигах, то ли есть какая то деталь отличия в том КАК и ГДЕ ты спавнишь свой ящик (у меня ящики спавнятся по разному - кто вне зоны алайфа, а кто и попадает в зону алайфа сразу поскольку по позиции спавна оказывается недалече от ГГ),
то ли это мистика какая то
Ошибка вылезла в 8 случаях из 8 - перебил весь лагерь новичков и с каждого снимал инфу о схроне.
мой конфиг
Перепроверил очередной раз свой код на тесте.
Прошу извинения. Просьба не бить сильно. Оказалась ошибка в коде (взял не тот серверный объект).
Точнее взял тот, с которого брал координаты. В моём случае, с Волка.
Код:
local sobj = alife():story_object( 6 )
if sobj then
local sbox = alife():create("inventory_box", sobj.position, sobj.m_level_vertex_id, sobj.m_game_vertex_id)
sobj:can_switch_online(true)
sobj:can_switch_offline(false)
db.id_box = sobj.id
end
Далее путём постоянного апдейта, выводил онлайн статус объекта по его айди на монитор.
Как я не заметил подмены, не знаю. Видимо был не внимателен. Ведь не однократно его просматривал.
Знаю:
что level_vertex - это точка на некой "сетке" уровня,
что game_vertex - это точка на некой "сетке" игры,
и есть геометрические координаты точек локации.
Какие отношения между level_vertex, game_vertex и геометрическими координатами? Есть-ли иерархия или они независимые.
И что такое так называемая ai-сетка? Это самостоятельная сетка или это - сетка из точек на других сетках?
Если где-нибудь есть целостное описание этих понятий - буду благодарен за ссылку.
singapur22
Ну вот, значит все таки обошлось без мистики
Слушай я тут хотел уточнить один вещь:
если я соберусь переводить оффлайновый ящик в онлайн через
Код:
function SetSwitchOnline(id)
local osBox = alife():object(id)
if osBox then
alife():set_switch_online(id,true)
alife():set_switch_offline(id,false)
end
end
то значит ли что я смогу затем оперировать с данным ящиком и его содержимым как с клиентскими объектами - и применять к ним клиентские методы? Мне просто надо взорвать мину в ящике, который в оффлайне. (типа кто- то порылся и подорвался).
Gun12
По твоим тестам выходит, что практически любой вариант вставки через insert в таблицу значений по произвольным индексам таит возможность будущей ошибки при попытке обратиться по нужному(известному) индексу и получить его значение, так как по твоим словам из-за применения insert "перестраивается дерево ссылок"?
Просто у меня еще остался вот такой код
с ним проблем пока вроде не было (хотя может просто еще не столкнулся )
И думаю, что на всякий случай его тоже стоит переделать на такой
Код:
if not secrets[sBox.id] then
secrets[sBox.id]={}
secrets[sBox.id]["sec"]= taynik
secrets[sBox.id]["day"]= spawn_time
secrets[sBox.id]["level"]= lname
secrets[sBox.id]["habar"]= true
end
кстати Колмогор в теме Народной соли (на АМК) писал, что обе эти табличные функции, а также table.getn() изначально работают в предположении, что таблица является упорядоченным числовым массивом без пропусков.
singapur22
Теперь почти понятно ... Я опасался что в результате постоянных экспериментов все же что-то затронул у себя и хотелось это выяснить.
И даже подтверждение от erlik'а не успокаивало, т.к. он использовал 'свой' биндер для рюкзачков и не факт, что в этом биндер (код нам неизвестен) методы не отключались ...
Но 'почти' все же осталось, т.к. и в приведенном тобою примере с Волком все же использован исходный от разрабов класс инвентори-бокса, конфиг которого штатен и ... независимо от позиции/координат спавна все же не имеет методов 'can_switch_...'.
Еще раз сорри за чрезмерную дотошность, диспут собственно уже неконструктивен и пора его закрывать. Если конечно не всплывет нечно опять необъяснимое с хитами по инвентору-боксу.
Я бы сформулировал для использования 'table.insert(...)' так:
Если требуется добавить/изменить эксклюзивную запись в массиве - НЕ применяй 'table.insert(...)'. Ведь собственно ключ 'sBox.id' у тебя эксклюзивен и не должно быть множественных записей для него в массиве. Т.о. используя прямую запись 'secrets[sBox.id] = {...}' ты получаешь нужный результат, исключая дублирование и коллизии множественности записи для одного и того же объекта.
Цитатат.к. он использовал 'свой' биндер для рюкзачков и не факт, что в этом биндер (код нам неизвестен) методы не отключались ...
А я проверял не только на своем биндере - я заспавнил по координатам эктора секцию "inventory_box" и и к ней тоже применил can_switch_online(true). Ошибка была идентичной.
----------------------------------------------------
Дублирование и коллизии множественности записи у меня (как мне кажется ) исключаются всегда проверкой на существование поля в таблице. А вот то, что insert и remove могут когда им заблагорассудится сдвигать табличные индексы(тем самым делая эксклюзивный ключ непригодным для использования) туда-сюда - вот это очень нехорошо с их стороны И товарища Иерусалимского...
--------------------------------------------------------------------------------------- MRN$
Вот здесь malandrinus задвинул спич на эту тему. А вообще тебе лучше по интеу покопаться - из разных обрывков глядишь слепишь теорбазис для понимания.
_http://www.amk-team.ru/forum/index.php?showtopic=5525&st=3260
MRN$
Я не достаточный дока в геометрии уровней и использую достаточный для меня базис понятий, поэтому стОит почитать вероятно статьи на википедиях ... Правда не встречал, у сожалению, достаточно внятных и профессиональных, поэтому ссылок не даю.
level_vertex - это 'ячейка' на некой "сетке" уровня;
game_vertex - это 'ячейка' на некой общей "сетке" из всех уровней игры;
position - координаты точки на некой "сетке" уровня;
Позиция естественно может иметь различные координаты внутри level_vertex'а т.к. это собственно точка, а вертекс - площадь.
Связь между level_vertex и game_vertex тоже собственно очевидна.
game_vertex'ы - проиндексированные ячейки общей сетки всех локаций в игре. Индекс game_vertex'а ексклюзивен в игре, т.е. по нему всегда можно определить нужную область сетки.
level_vertex'ы - проиндексированные ячейки сетки конкретной локации. Кол-во индексов зависит от площади локации и естественно 'начальные' индексы всегда есть на всех локациях.
Условно:game_vertex - серия паспорта, а level_vertex - номер паспорта. Одни и те же номера могут быть внутри разных серий. Ну а position - место прописки. В одном паспорте их может быть несколько (смена места жительства), в разных паспортах - одна прописка (живут вместе) ...
Сообщение было успешно отредактировано Artos (22-08-2010 17:46 GMT3 часа, назад)
Добавлю - гейм_вертексов в игре всего 3512 - от 0 до 3511-го. И они не повторяются, так как являются уникальными идентификаторами тех самых общеигровых ячеек на глобальной карте игры.
Для каждого уровня строго определен свой диапазон гейм_вертексов.
А левел_вертексов - никто не считал - так как их больше миллиона. Одни и те же номера левел_вертексов могут совпадать для разных уровней. Что, впрочем, очевидно.
PS: У меня в журнале есть тестовый скрипт для вывода значений игровых вертексов на худ в виде списка.
Эта тема закрыта, публикация новых сообщений недоступна.
Продолжая пользоваться сайтом, вы соглашаетесь с использованием файлов cookie. Страницы сайта могут содержать информацию, запрещенную для просмотра посетителям младше 18 лет. Авторское право на серию игр «S.T.A.L.K.E.R» и используемые в ней материалы принадлежит GSC Game World.
