SkyLoader Это уже отдельный эвалуатор и схема поведения, на которую сталкер переключается при особых условиях. А если схему сталкеру не задавать, то управлять им будет невероятно сложно. Слишком многое нужно учитывать. Прошли уже через это.
-----
Поправлю. Не функция, а метод.
----
Это достаточно всё сложно. Но на вики можно найти статью, которая достаточно подробно всё описывает. Вплоть до создания схемы напарника.
отредактировал(а) singapur22: 21-08-2010 18:34 GMT3 час. Проект "Mobile Manager" закрыт, в связи со стечениями неблагоприятных обстоятельств, и последующей потерей всех файлов и справок текущего проекта.
Продолжу насчет INSERT и REMOVE.
Целый день с ними**50236ea8aab1bb10eeba**e]t = {[2]=2,[3]=3,[4]=4}[/code]
то длина таблицы будет равна 0
Любой insert (кроме 1) в такую таблицу поле то вставит, но длина останется равной 0.
А если записать то же но через :
[code]for i=2,4 do
table.insert(t,i,i)
end[/code]
То длина таблицы окажется равна 4
Т.е., забегу вперед, при определенных условиях подобная таблица (без фактической установки некоторых полей) начинает считаться числовым массивом.
И теперь если написать :
[code]table.insert(t,1,1)[/code]
то, как по хэлпу, остальные значения сдвинуться вниз. Т.е. Перестраивается дерево ссылок.
А это значит, что теперь ключу 2 будет соответствовать значение NIL(бывшее значение для ключа 1), ключу 3 значение 2(бывшее значение ключа 2), 4 - 3 и т.д.
При удалении будет сдвигаться в обратную сторону.
Теперь интереснее.
Если 2 раза подряд удалить поле 3 через remove, в таблице перестает читаться это поле(с уже новым значением), с которым шаг назад прекрасно работало.
Т.е. При определенных условиях таблица снова переходит в разряд хэша.
Так, для дальнейшего не будем удалять второй раз поле 3 и вставим
[code]table.insert(t,6,6)[/code]
Поле вставиться, но длина таблицы останется равной 4.
А если следом вставить
[code]table.insert(t,7,7)[/code]
то длина таблицы окажется равной 7 при как бы отсутствующих(мы их даже не упоминали при конструировании таблицы) полях 2 и 4.
Получается что функция remove идет "на поводу" у insert. Если та определит таблицу числовын массивом, тогда и remove будет корректно работать даже про отсутствующем поле с индексом 1(и как выяснилось и с другими)
Определить зависимость построения полей при которых таблица начинает считаться числовым массивом у меня пока не вышло.
Однако выяснил что ключевую роль играют поля, как бы назвать, переходных битов что ли.
Это поля :
1 - первый бит(2 но не 0, а 1)
4 - два бита (4)
8 - три бита (8)
16 - 4 бита (16)
и т.д. до 65536
В общем если нет уверенности что таблица - это целочисленный, последовательно нумерованый массив, начинающийся с ключа с индексом 1, то лучше этими функциями не пользоваться.
отредактировал(а) Gun12: 21-08-2010 20: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(...) был бы более оптимальным вариантом. Но как не странно, но и указанный пример даёт тот же результат.
А по поясу, я уже оставил это дело как есть (вполне применительно). Посему продолжил работу над детектором. Точнее детектор тоже готов. Осталось разобраться с артами.
Проект "Mobile Manager" закрыт, в связи со стечениями неблагоприятных обстоятельств, и последующей потерей всех файлов и справок текущего проекта.
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
А какая разница?
Разрабами много чего задумывалось и много чего было вырезано. Многое из того, что было задумано разрабами было реализовано модмейкерами.
Если ты под призраками подразумеваешь фантомов - то это от разрабов.
Если некие 'полупрозрачные' ходячие ... - поделки модмейкеров.
Rat_Revenant Это ты про уродцев, которые встречаются во многих глобальниках? Типо обычные гражданские, только прозрачные и с как-будто налипшей грязью? Это мододелы шаманят.
Журнал
- модель M79
- модель HK SL-8
- модель Milkor m32 WIP
Но реализовано, то это полностью разрабами, мододелам остаётся лишь расставить этих призраков по локациям, да пару строчек в конфиге поправить.
win win, если полупрозрачных зомби, то вот почитай статьи: http://stalkerin.gameru.net/wiki/index.php/Новые_монстры http://stalkerin.gameru.net/wiki/index.php/Спавн_через_скрипт
отредактировал(а) Максим Р.: 22-08-2010 00:03 GMT3 час.
Это обычные гражданские, но с шейдером "призрака" на текстуре. Модель эта в архивах есть.
Поделки модмейкеров, это взрывающиеся зомби, зомби-блевуны и электро-химеры.
Artos Именно так и использовал!!! Всё работает, и никаких вылетов.
Это кстати не первый случай, где на практике в аналогичных ситуациях, у нас с тобой совершенно разные результаты. (взять например недавно обсуждаемый health).
Я начинаю сомневаться что мы обсуждаем одну и ту же игру. :-)
Ладно, закрыли тему. В любом случае, alife():set_... наиболее актуален, так как переводит сразу, в отличии от sobj:can_..., который только устанавливает требуемое значение, для следующего цикла апдейта.
отредактировал(а) singapur22: 21-08-2010 23:58 GMT3 час. Проект "Mobile Manager" закрыт, в связи со стечениями неблагоприятных обстоятельств, и последующей потерей всех файлов и справок текущего проекта.
singapur22
Игра то одна (по названию), но ее модификации - конечно разные. ;-)
Хм, потеряю еще немного времени на проверку ... Неужели у меня так затронут класс, что 'штатные' методы отключились? Всеж это может аукнуться в сам
singapur22
Дабы ваш пинг-понг с Artos'ом был более результативным - вот результат независимой **50016ea8aab1bb10eeba**actor, "Ошибка перевода в онлайн: "..tostring(switch), 0, "trader", 15000)
return end [/code]
--внешняя функцию которую вызываем
[code]
function CanSwitchOnline(sBox)
sBox:can_switch_online(true)
return sBox:can_switch_online()
end [/code]
Результат:
Вывод - то ли мы спавним разные (по классу) ящики - давай тогда искать разницу в конфигах, то ли есть какая то деталь отличия в том КАК и ГДЕ ты спавнишь свой ящик (у меня ящики спавнятся по разному - кто вне зоны алайфа, а кто и попадает в зону алайфа сразу поскольку по позиции спавна оказывается недалече от ГГ),
то ли это мистика какая то :-)
Ошибка вылезла в 8 случаях из 8 - перебил весь лагерь новичков и с каждого снимал инфу о схроне.
мой конфиг
Знаю:
что level_vertex - это точка на некой "сетке" уровня,
что game_vertex - это точка на некой "сетке" игры,
и есть геометрические координаты точек локации.
Какие отношения между level_vertex, game_vertex и геометрическими координатами? Есть-ли иерархия или они независимые.
И что такое так называемая ai-сетка? Это самостоятельная сетка или это - сетка из точек на других сетках?
Если где-нибудь есть целостное описание этих понятий - буду благодарен за ссылку.
Gun12
По твоим тестам выходит, что практически любой вариант вставки**50076ea8aab1bb10eeba**x.id, {sec=taynik, day=spawn_time, level = lname, habar=true})[/code]
с ним проблем пока вроде не было (хотя может просто еще не столкнулся )
И думаю, что на всякий случай его тоже стоит переделать на такой
[code]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[/code]
кстати Колмогор в теме Народной соли (на АМК) писал, что обе эти табличные функции, а также table.getn() изначально работают в предположении, что таблица является упорядоченным числовым массивом без пропусков.
Разработки: "Тотализатор","Kill-zone", "Mega-bomba", Mega_gravi",
"Рандомные тайники(а также декодер, мины+диалоговый аддон"), "Выбрасываемый рюкзак", "Аналоговые часики на худ"
singapur22
Теперь почти понятно ... Я опасался что в результате постоя**50216ea8aab1bb10eeba** = {sec=taynik, day=spawn_time, level = lname, habar=true})[/code] дабы не разводить код на несколько строк.
Я бы сформулировал для использования '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
Разработки: "Тотализатор","Kill-zone", "Mega-bomba", Mega_gravi",
"Рандомные тайники(а также декодер, мины+диалоговый аддон"), "Выбрасываемый рюкзак", "Аналоговые часики на худ"
MRN$
Я не достаточный дока в геометрии уровней и использую достаточный для меня базис понятий, поэтому стОит почитать вероятно статьи на википедиях ... Правда не встречал, у сожалению, достаточно внятных и профессиональных, поэтому ссылок не даю.
level_vertex - это 'ячейка' на некой "сетке" уровня;
game_vertex - это 'ячейка' на некой общей "сетке" из всех уровней игры;
position - координаты точки на некой "сетке" уровня;
Позиция естественно может иметь различные координаты внутри level_vertex'а т.к. это собственно точка, а вертекс - площадь.
Связь между level_vertex и game_vertex тоже собственно очевидна.
game_vertex'ы - проиндексированные ячейки общей сетки всех локаций в игре. Индекс game_vertex'а ексклюзивен в игре, т.е. по нему всегда можно определить нужную область сетки.
level_vertex'ы - проиндексированные ячейки сетки конкретной локации. Кол-во индексов зависит от площади локации и естественно 'начальные' индексы всегда есть на всех локациях.
Условно:game_vertex - серия паспорта, а level_vertex - номер паспорта. Одни и те же номера могут быть внутри разных серий. Ну а position - место прописки. В одном паспорте их может быть несколько (смена места жительства), в разных паспортах - одна прописка (живут вместе) ...
Добавлю - гейм_вертексов в игре всего 3512 - от 0 до 3511-го. И они не повторяются, так как являются уникальными идентификаторами тех самых общеигровых ячеек на глобальной карте игры.
Для каждого уровня строго определен свой диапазон гейм_вертексов.
А левел_вертексов - никто не считал - так как их больше миллиона. Одни и те же номера левел_вертексов могут совпадать для разных уровней. Что, впрочем, очевидно.
PS: У меня в журнале есть тестовый скрипт для вывода значений игровых вертексов на худ в виде списка.
Разработки: "Тотализатор","Kill-zone", "Mega-bomba", Mega_gravi",
"Рандомные тайники(а также декодер, мины+диалоговый аддон"), "Выбрасываемый рюкзак", "Аналоговые часики на худ"
Эта тема закрыта, публикация новых сообщений недоступна.
Продолжая пользоваться сайтом, вы соглашаетесь с использованием файлов cookie. Страницы сайта могут содержать информацию, запрещенную для просмотра посетителям младше 18 лет. Авторское право на серию игр «S.T.A.L.K.E.R» и используемые в ней материалы принадлежит GSC Game World.
S.T.A.L.K.E.R. 2
