Artos

@HellRatz, то ли я что-то пропускаю в пояснениях, то ли ты не внимательно читаешь... Всевозможную теорию я уже перечитал десятки раз и как подключать устанавливать/настраивать SDK с приблудами и подключать свою локацию к игре имею представление и практику. Но(!) мне нужно не просто взять свои несколько локаций и засунуть в игру (как ты показал), а к УЖЕ имеющимся оригинальным локациям подключить свою. Причем(!) так, чтобы уже имеющиеся локации НЕ изменяли свою геометрию/сетки/... Куда, когда и как вписывать в конфиги свою новую карту тоже знаю (game_graphs.ltx, game_levels.ltx, game_maps_single.ltx) и уже все сделано. Локация подготовлена и могу хоть отдельной игрою ее запускать, хоть прикрепленной к прежним картам. Но, загвоздка в том, что объединяя все локи в один гейм.граф, у меня съезжают все вертексы за картой станции (l12_stancia) и уже без глобальной переделки спавна и конфигов/скриптов игры запустить общий мод не удается. Описываю по шагам свои действия:

Респавн - это и есть "скриптовой" спавн, только периодический и по определенным условиям. Если научился спавнить, то научись использовать таймер, и им уже заново ре-спавнить твоих монстров твоими же скриптами. А по-серьезному, в том же AMK-моде в игре добавляются свои респавнеры, которые и занимаются дополнительным респавном как и те, которые из алл.спавна. Вот и смотри как эти респавнеры сделаны, раз лень в алл.спавн что-то писать (хотя это как раз очень просто).

1. Мною все же поставлена задача не лишь бы запихнуть спавн в обновленную геометрию, а попытаться оставить оригинальные локации (и соответственно спавн в них) в исходном виде. Это позволит мне использовать все коды мода как в вариантах с исходной игрой, так и при различных модификациях базирующихся на оригинальном гейм.графе. 2. Учитывая, что у меня в моде очень немало новшеств неведомых движку/SDK, задачка по переносу спавна очень непроста (хотя конечно решаема). Очень непросто научить иль обойти ограничения для новых (псевдо)классов объектов и т.п. 3. По иронии, даже упрощенный перенос спавна не прокатит, т.к., например, в оригинале игры (и у меня) в упомянутом заключительном гейм-вертексе 2791 расположен переход с бункера на радар (name = exit_to_radar_01) и при усечении карты станции (l12_stancia) на один вертекс компилятор уже не может поместить этот переход на карту и просто его вырезает. - т.о. придется заново добавлять и переход и менять его обвязку (точку возврата и пр.) Я уже не говорю о том, что немало использований именно гейм-версексов локаций в кодах мода... Например, спавнятся и закрываются новые переходы между локациями или используются телепорты, используются динамические пути (walks) и т.д. Пересбор кодов сделает их полностью несовместимыми с оригинальной игрою. Хм... Я бы рад не трогать, но заставляет "трогать" сам аи-враппер (иль ai-compiler), т.к. без запуска "-g <имя_карты>" для всех оригинальных карт он отказывается выполнять "-m", т.е. не построив таблицы соответствия с сетками ИИ всех включенных карт, отказывается сливать их в единый гейм.граф. Если есть способ заставить его использовать "то что есть" - прошу указать, т.к. нигде не смог найти про это... В описании к аиврапперу имеется куцее упоминание - но ни где не нашел ни описания формата "указываемого" файла, ни примеров использования этой возможности... Тоже так думаю, однако на практике именно это и происходит при вынужденном (пере)построении ИИ-графа и таблицы соответствий именно (и только!) для карты станции (см. раннее цитируемый кусок лога). AICompiler пишет в логе чуть иначе:

@Карлан, тут все же не флудиловка и в шапке ясно указано: "Перед тем как задать вопрос прочтите следующую информацию: ..." В ФАКах и на Вики прекрасно все рассказано и часто даже разжевано, пора бы отвыкать от репетиторства... и от глупых вопросов (гулаг<vs>респавнер, дистанция<vs>радиус).

@Карлан, у тебя банальная ошибка. Попробуй просто "человеческим языком" прочитать свой Lua-скрипт: table.insert(aParam.key, value) - Вставить в (суб)таблицу (точнее добавить в конец) 'aParam.key' элемент 'value'. - а теперь вопрос к написавшему сею строку: "А он позаботился создать эту (суб)таблицу, перед тем как в нее что-то добавлять?" (собственно лог на это и указывает, говоря об отсутствии требуемой таблицы!) А для твоей задумки требуется простое: aParam[key] = value - чтобы получить {key1 = value1, key2 = value2...} Вот только вряд ли ты таким макаром получишь желаемое, т.к. key = math.random(100) может генерить далеко не эксклюзивные ключи и при их добавлении в {key1 = value1, key2 = value2...} у тебя уже имеющиеся будут затираться новыми...

@CuJIbBEP, спасибо что откликнулся, а то думаю уже никому до стандартных карт нет дела ;-) Уточняю: 1. Исходный материал для карт беру из чистой игры (SHoC v1,0004/6) и ничего не добавляю. Т.е. по-сути, пытаюсь перекомпилировать геймграфы уже имеющихся в игре локаций, когда-то скомпилированные разрабами GSC, чтобы к ним подключить свою дополнительную. Верификация aimapcheck проходит без ошибок. 2. Если смотреть в пак локаций "Stalker_Map_Pack_for_SHoC_1.0004" (by Kostya V), то там присутствует эта же локация l12_stancia (как понимаю с перекомпилированным графом) с теми же 129-ю вертексами. Т.е. усечения 5-го у него не возникало, и он подменяет только level.gct и с ним уже создан новый общий game.graph. Аналогично и в других модах с перекомпилированными графами оригинальных локаций в которых не изменяли их геометрию и AI-сетку. Вот мне и непонятно, у меня одного, вместо 4-х ошибочных вертексов выходящих за пределы AI-сетки, почему-то возникает 5-й (например из-за версий/настроек (де)компиляторов) и он усекается? Или же я все же что-то не так делаю? Если не сложно, может у кого-то есть уже подготовленная l12_stancia от оригинальной версии игры(!) для включения в oбщий пак - был бы благодарен если дадут ссылку на скачать. Хотя хотелось бы понять причину и далее не наступать на грабли... Собственно непонятно, если на гейм-вертексе отсутствует AI-сетка - то почему компилятор усекает этот вертекс? Баласт не всегда требуется вычищать... Есть ли возможность указать чтобы какой-то не усекался?

@Dennis_Chikin, проверить возможность создания партикла вроде как не имеет решения. Единственное что может как-то обезопасить - распарсить скриптом particles.xr и проверить наличие в нем нужной строки. Однако, если партикл состаавной, то и это может не спасти от ошибки. @Старлей, скриптовые (как и обычные) диалоги оперируют идентификаторами, а не самими текстами. Убери game.translate_string и будет тебе "как исправить".

@Хемуль36рус, советую почитать теорию по тайникам (инвентори-боксам). Кратко: - тайники в оригинале состоят из двух составляющих: левел-визуал (как объект уровня) и сам тайник - не имеет визуала (точнее имеет прозрачный) и может быть заспавнены где угодно (хоть в воздухе), но спавнится по координатам левел-визуала. - если спавнить тайник со своим визуалом (динамит/ящик/рюкзак/...), то чтобы не "проваливался" сквозь динамические объекты - можно закрепить, например, за кость (fixed_bones, спавн в игре потребует работы с net-пакетами).

Возникла проблема, прошу помочь разобраться... Суть: Захотелось к стандартным локациям ТЧ (SHoC) добавить автономную тестовую локу, дабы на ней экспериментировать "как в игре". Заодно почистить мусор ы game.graph от баластных записей mp-локаций. Все вроде бы тривиально, но застопорила проблема: при создании level.graph для l12_stancia теряется один гейм-вертекс и вместо того, чтобы иметь 129 (как в оригинальной игре) - остается 128, и соответственно "плывут" все последующие за этой точкой локации, что требует пересборки всего алл.спавна и координат в нем. Непонятно почему у всех (в оригинале и модах даже с новыми локами) такого смещения с исчезновением вертекса нет? Везде 1-й свободный вертекс для новой локи прогнозируется как 2792, а не 2791. В логе при компиляции аи-враппером это усечение выглядит так:

К сожалению, автор вопроса задал шараду без необходимых пояснений/данных... Предполагаю, что все это относится к менеджеру торговли и автор вопроса задался целью сохранять в сэйвы и считывать из них свои параметры. Однако, позабыл (или не знает), что скрипт, отвечающий за это (trade_manager.script) и алгоритм работы с ним подразумевает периодическое(!) обновление при каждой(!) смене секции логики. Штатные параметры этого модуля запоминаются движком и меняются по заложенному алгоритму. А вот "пользовательские" данные, даже будучи запомненными и восстановленными, при первой же смене/переинициализации логики непися будут заменены на дефолтные (см. вызов: trade_manager.trade_init(npc, trade_ini) из xr_logic.configure_schemes). Т.о., в первую очередь нужно менять алгоритм самого менеджера, а уж как и где хранить/восстанавливать доп.данные - дело вторичное и имеет немало готовых вариантов. @Viнt@rь, если мое предположение о менеджере торговли верно, то нет особого смысла в кастомном хранилище и в экономиях байтов... У неписей почти ничего не запоминается в pstor и его (не менее 7-ми кило) вполне достаточно даже для очень богатого и разветвленного ассортимента. ;-) P.S. И модулях Artos'а (конкретно в lua_helper.script) имеются функции работы с pstor'ом объектов/неписей (SetVarObj/GetVarObj_Table/...), аналогичные всем что тут упоминались...(+ с компрессией) и хранить/считывать таблицы совсем не сложно и нет смысла ломать голову над ними, если данные в таблицах строки/числа/булевы... Тебе нужно над другим поломать голову ;-)

Хм, что-то смахивает на чесание пяткой уха... 1. В ЧН/ЗП доступно пространство 'os' и не сложно получить реальную дату (и/или время): os.date() 2. В ТЧ несколько посложнее, но также не сложно добавить это пространство имен (см. xrLuaFix и аналогичное). 3. В "финальном" варианте явно ошибочен патерн, вероятно должно быть: '(%d+)\%d+)\%d+)\.+' 4. Довольно странные определения билда и фикса... Получается что, когда запустил игру - тогда и билд сделан с фиксом?! Все же 'build' и 'fix' - некие даты, когда были созданы коды или изменения к ним, а не "дата создания запущенной игры"... 5. Насиловать ради некой даты файловую систему с файлом настроек - хм, а ежели взглюкнет? (не каждый знает как восстановить) ;-) ИМХО, безопаснее насиловать фейковый файл: get_console():execute("cfg_save tmp") --/ запись настроек в файл 'tmp.ltx' или вообще использовать готовый файл-лог из соотв.папки: getFS():update_path("$logs$", "xray_"..user_name()..".log") P.S.

@Карлан, (без желания обидеть): 1. СтОит почитать ФАКи и топик "Справочник по функциям и классам". 2. Включить собственную думалку, отбросив шоры... Метод story_id() для объектов игры возвращает именно число (s32), естественно отбрасывая незначащие нули, которое является значением, присвоенным объекту при его спавне или изменением посредством net-пакетов. Какое значение (число) присваивать кому-то/чему-то и по каким правилам - решает сам разработчик/модмейкер. Главное чтобы оно было уникальным и в диапазоне 0...0x8fffffff (0...4294967295) Таблица "[story_ids]" - является конфигом и может правиться кем угодно и как ему угодно (с соблюдением отдельных правил). Она вообще может отсутствовать, как в ЧН иль ЗП. В эту таблицу разработчики/модмейкеры заносят нужные им значения story_id своих персонажей иль предметов и сопоставляют им строку, которая может применяться в описаниях/условиях для квестов. Комментарий разработчиков игры "Номер SID-а состоит из номера уровня + номер персонажа (2 цифры)." - чисто технический и даже уже с первой же строки ими же нарушается: 000 - сид предмета (кейса с доками), а не персонажа. И ничто(!) не мешает этот "порядок" не соблюдать. Все это критично только для квестов и записям для них. Кол-во незначащих нулей можно ставить "по-вкусу"... P.S. В твоем случае (последний тут показанный вариант) обязан был быть отрицательный результат - твой файл (my_mod) имел синтаксическую ошибку в функции (test_sid) и был просто проигнорирован игрою. Однако, при вызове из диалога строки: <action>my_mod.test_sid</action> - обязана была быть ошибка c вылетом и соотв. записью в логе... Т.о. нужно бы заглядывать в лог и показывать его тут, при описании своих действий/кодов/результатов.

@Карлан, говоря "никакого результата" - стОит уточнять, т.к. и отрицательный результат (если таковой есть), несет информацию! Исходя из того, что ты пытаешься получить story_id у своего собеседника, то НИКАК не может быть никакого результата. Функция sN:story_id() - обязана вернуть хоть какой-то результат в виде числа (хотя бы 4294967296) или ругнуться в лог. Если у тебя отсутствует вызов твоей функции test_sid(s1,s2) - то и разбирайся с диалогом... Примечание: параметр 'story_id' не является "номером из game_story_ids". Упомянутая табличка является массивом соответствий собственно выбранного параметра (числа) со строкою, прописываемых "ручками", и используемых, например, для заданий. Не следует это путать.

Нужно правильно ставить условия. Ну как можно сравнивать: if s1:id() == (db.actor or ... - т.е. тип данных 'number' с 'userdata'?!

@proper70, чудной ты, право... (для чистого ТЧ с добавками по выводу в лог) 1. Берем обрез и подходим к новичку сидящему у костра в деревеньке на Кордоне. 2. Стреляем ему в голову. Имеем в логе:

Бессмысленно убеждать того, кто не хочет этого и не хочет думать... Нет НИКАКОЙ разницы в аргументах коллбэков, возвращаемых для неписей (гуманоидов) иль монстров иль даже физических объектов. Вот только ты думать не хочешь или проверить, когда что возвращается. Вот тебе лог по-сути с чистой игры ТЧ:

Абсолютно ложное утверждение! То, что в чистом ТЧ чего-то не используется - не аргумент, там много чего не используется. А ссылка на Солянку - улыбает. ;-) Даже для монстров в далеком 2008-м уже были сделаны моды на "умное выпадение частей" при отстреле по костям... Совет(ы): 1. Проверь, а тот ли аргумент ты обрабатываешь? 2. Перепроверь, не подменяешь ли где-то в своих кодах это значение... (тем более если у тебя Солянка). 3. Загляни в коды ЗП, в которых уже по твоей хотелке почти все сделано. а портировать можно напрямую ( по-сути все совместимо).

@proper70, подсказка: 1. Смертельный хит (его коллбэк) всегда предшествует смерти (коллбэку). 2. В схеме хита (xr_hit.scrip) в сторадж неписю (db.storage[self.object:id()]) при каждом коллбэке записывается/обновляется табличка 'hit', куда заносится идентификатор обидчика. 3. В ЗП, в эту же табличка добавляется запись 'deadly_hit', т.е. смертельный ли хит. 4. Ни что не мешает добавить в эту же табличку (иль еще куда) информацию о кости (bone_index) и уже в коллбэке смерти читать табличку 'hit' и определять от кого и от чего погиб...

@Dennis_Chikin, если не обращать внимания на контекст - то и не будет понятно... Твой пример вероятно выдран из скрипта мода "грави-пушки" (by Malandrinus & Kirag) и 'ps' - является объектом ( ps = obj:get_physics_shell() ) к которому применимы методы его класса ('physics_shell'). А заглянув в азбуку мододела (lua_help.script) иль в соотв.топик, можно увидеть какие аргументы потребны для работы с соотв.функцией/методом этого класса. 'Глобальное' определение переменных в данном случае оправдано, т.к. это применяется в биндере гравипушки и переменные используются в разных методах биндера. Нет под рукою исходных скриптов, но мною используются как 'self.lvel' и 'self.avel' (линейная и угловая скорости), т.е. "ограниченная глобальность". ;-) Ну а с нотациями у разрабов игры туго не только с векторами...

@Viнt@rь, вообще-то чтобы себе и другим не городить проблемы/головоломки, стОит подобные строки, требующие распарсивания, создавать придерживаясь шаблона, а не "может быть таки, иль эдак, иль еще как-нить..." . Основное при решение подобных задачек: определить критерии/признаки, по которым и создаются патерны, удовлетворяющие всем критериям во всех ситуациях. Судя по тому что ты описал, можно говорить о следующих основных критериях: - 1-й обязательный разделитель содержит символ(ы) ':' и/или '=' , т.е. один из или оба символа - 2-й обязательный разделитель содержит символ ':' итого имеем что-то типа: s1,s2,s3 = str:match('%s*([^=|:]+)%p*([^:]+)%p*(.*)') - написано для одновременного разбиения строки по двум разделителям. Если не потребно - слить всегда проще... Также, тобою не оговорена возможность наличия в словах символа '_' (подчеркивания), что может потребовать усложнения, т.е. замены '%p' на более сложный, исключающий символ подчеркивания, или оперировать для слов: '[%w|_]'. Ну и т.д. ... можно подумать о пробелах внутри и в конце и др.условиях, наличие которых только тебе ведомо. @*Shoker*, тема не простенькая, и в первую очередь нужно не употреблять невнятный жаргонарий... Например, говоря об игровом объекте (obj = level.object_by_id(,,,) - получили онлайновый объект) не ставить телегу впереди лошади: "существует объект, к которому биндер присвоен". В данном случае, биндер - объект класса, а obj - является свойством биндера, хотя и порожден движком. Если это понять, то легче будет и далее понимать... Итого, имеем примерно это (применительно, например, к сталкеру/монстру): - Движок создает клиентский объект, который передается в биндер (биндится). - Класс биндера создает объект (который часто обзывают биндером), завязывая на одно из своих свойств 'self.object' переданный ему клиентский объект. - ... в игре, оперируя методами биндера, мы автоматом работаем с присвоенном ему клиентским объектом: апдейты, коллбэки и т.п. Ну а теперь что произойдет, если запомнить 'self.object' (aka 'obj') где-то в табличке иль ином месте? Ярким примером этого - присвоение db.storage[npc:id()].enemy = enemy (!!!) в xr_combat_ignore.script и последующая работа во многих скриптах с этим линком. Линк естественно будет ссылаться на клиентский объект. Ну а теперь, в игре этого сталкера удалили иль телепортировали на др.локацию. Естественно срабатывает метод биндера xxx_binder:net_destroy() , который НЕ удаляет клиентский объект(!), а разрушает связь этого объекта с биндером. С этого момента уже проблематично что-либо сделать с объектом, не получив ошибки, не говоря уже о том, что сборщик мусора вскорости удалит отживший свое объект класса биндера. Сам клиенский объект может и существовать некоторое время, если связан линком, вот только толку от него никакого (биндер уже не апдейтит его), а только вред. Применительно к практике, в этом топике уже обсуждалась порочность создания таких линков на объекты (на примере упомянутого выше enemy), и желательности замены их на идентификаторы (id) клиентских объектов. Итого, без причины не увлекайтесь созданием "долгоиграющих" линков на объекты. Безопаснее хранить идентификатор, перепроверяя его актуальность и по которому не сложно получить собственно нужный объект. Хотя и тут подводный камень, т.к. идентификатор удаленного объекта запросто может быть занять другим игровым объектом, но это уже иная история... ;-)

@losiara, твой вопрос касался возможности "регулировать взаимоотношения" монстров и human'ов (сталкеров), и в частности "менять взаимодействие между например гражданским зомби (класс монстров) и сталкером зомбированным (класс сталкеров), таким образом, что бы они в игре не нападали друг на друга". Взаимоотношения (групп) имеют как минимум две составляющие: а) монстр(ы) не враждебны к сталкерам и б) сталкер(ы) не враждебны к монстрам, и эти две составляющие могут иметь место по-одиночке и одновременно. Что имеем: 0. Сталкеры (species = human) строят свои взаимоотношения по табличке 'communities_relations', где нет места монстрам, т.е. только гуманоиды, а все монстры враждебны. Монстры, а монолитовцы в этом отношении отношении относятся к ним (species = zombie), регулируют свои взаимоотношения по табличке 'monster_relations' и тут можно только с актором и/или сразу со всеми гуманоидами менять отношение. Вот поэтому и не дружат все сталкеры с монстрами и монолитом, а контролер и монолит не враждуют. 1. Для сталкеров существует схема "combat_ignore", в которой можно задать условия, чтобы сталкер(ы) не воспринимали врагами других неписей (монстров и/или сталкеров). Также, для них есть схема 'danger' (см. xr_danger.script), в которой также можно задать условия,чтобы не "возбуждались"... Имеется для них и схемка 'threshold' с параметрами 'ignore_monster' и 'max_ignore_distance' (см. stalker_generic.script) и в логике позволяющий игнорировать монстров. Все это и дает возможность тебе регулировать "а) старкер не враждебен к монстрам". Однако, для того, чтобы указать конкретную группировку монстров, придется поработать над добавлением в "combat_ignore" возможности читать параметры с указанием группировки и игнорировать ее. 2. Для монстров такого выбора нет, кроме упомянутого mob_alife_mgr.script, и которым можно регулировать "б) монстр не враждебен к сталкерам". Т.к. в оригинальном виде этот скрипт дает возможность выставлять "невраждебность" только сразу ко всем неписям, то и помянул про необходимость доработать скрипт, чтобы он смог обрабатывать новые потребные тебе параметры. Вот тогда ты сможешь управлять взаимоотношениями 'монстр<?>сталкер' как тебе хочется (далее работай головой и со скриптами). ;-) P.S. По показанной тобою доработке скрипта нет смысла говорить, т.к. все же нужно понимать что за условие тебе необходимо и как его реализовать, чтобы оно работало, но не корежило все остальное. Добавленный тобою параметр "в тупую" дублирует 'npc_friendly', т.е. по его наличию монстр опять же не будет отпущен в алайф для всех(!) неписей. Тут, как минимум, требуется не булев-параметр, а строка с именем группировки, и чтобы в функции 'alife_control' обрабатывалось условие, что "если есть враг, но его его группировка соответствует заданной новым параметром, то не отпускать в алайф", т.е. не будет включен 'issue_combat_event'.

@losiara,@ColR_iT, и др. В игре есть хитрый файлик mob_alife_mgr.script, который управляет возможностями нахождения монстров под схемами (управляться скриптами) или же быть отпущенными в алайф (под управление движком). В этом файле прописано возможность читать 4 параметра из конфигов (всегда, дружелюбен всем, дружен человекам, дружен актору). В принципе, ничего не мешает добавить свой параметр (типа 'dog_friendly') и, немного подправив скрипт, иметь возможность в схемах монстров, чтобы они не враждовали с псами... Ну, и меняя/добавляя параметр(ы), можно "подружить" с какой группировкой требуется... При желании, можно прописать обработку сида (story_id) и делать невраждебным конкретного монстра/сталкера.

Вынужден признать свою ошибку относительно возможности отображения надписи для именных КПК в ЧН (CS) и ЗП (CoP) через параметры объекта. К сожалению, в ЧН/ЗП в движке напрочь вырезана эта возможность и надпись отображает только то, что прописано в к конфиге строкою 'inv_name'. Под ТЧ отображение именных надписей работает, но требуется спавнить КПК не сразу в тело, а вначале спавнить "на землю" и менять параметры и уже после этого вкладывать КПК владельцу (=>трансфер). В противном случае возникает двойная проблема: - сразу после спавна КПК не отображается "именным"; - после сэйв->лоад уже "именной" КПК как бы исчезает из трупа, т.е. невидим, хотя и находится в инвентаре (но это отдельная история).

@Malandrinus, я практик, а не теоретик ;-), конечно же не только проверял, но и использую на практике (в SIMBION'e). Не проверял только такие случаи: - КПК спавнится, когда владельц уже мертв; - КПК спавнится, когда у владельца уже имеется имеется свой именной КПК; Во всех остальных случаях не было никаких проблем. В моде в модуле офф-лайн-алайф (аналог AMK'шного), в котором неписи занимаются собирательством и "подметают" все на локациях, при продаже хабара, не продают именно свой КПК, отличая его по метке 'original_owner'. Также, при сборе актором различных КПК, различаются безхозные и именные КПК, опять же по этой метке. Снятие метки снимало "персональность" найденного КПК. У игроков в мод бывали случаи, когда при попадании в аномалию актор терял свой КПК... Искал потерянное (скриптами) именно по метке, и возвращал. А при отсутствии - просто спавнил новый и метил - КПК становился: "КПК Меченный". (это в ТЧ). (к вечеру гляну непроверенные ситуации, и применительно с ЧН)

@AndreySol, приведенная тобою секция с дублями 'skeleton_flags' - ТУФТА. 1. Не может имя параметра повторяться дважды в одной секции. Хотя значения этих параметров в сэйве/игре - бинарная последовательность и не имеют имен, но ACDC не может / не должен дублировать имена. 2. Значение 'skeleton_flags = 1' - подтверждает "туфту", т.к. это должно быть отображено в 16-тиричном формате (hex). Да и не может набор флагов составлять 1 (единицу)! ... Подозреваю, что кто-то по ошибке скопипастил дубли строк не в то место...