Malandrinus

В ЧН можно и то и другое. Создай на худе окно и делай с ним что хочешь. Можно цифрами время вывести, можно текстуру со стрелкой вращать. В ЗП вращение текстур убрали, так что только цифрами. Жалко, без скриптов там никак не выйдет.

Так и должно быть. При перечислении пар в хеш-таблице порядок не определён, и это документированное поведение. Для того, чтобы иметь определённый порядок, заведи массиво-подобную таблицу: t = {a,b,c,d} и перебирай циклом со счётчиком for i= 1,#t do ... end Вообще-то там ещё STL есть. На мой взгляд Lua с его одной-единственной стандартной структурой данных - это просто верх простоты по сравнению с С++ с его шаблонами и generic programming.

Значит я был не прав и можно записаться в тушканчики =) Но всё таки есть один минус, похоже, что в отличие от группировки никак не сменить вид в процессе игры. Впрочем, это наверное и не надо. Ну, по правде говоря я бы не заморачивался и рассчитывал бы на минимальное разрешение. Но уж если делать самопальный автоперенос, то можно сообразить что-то такое: сначала убираем из строки служебные последовательности для цвета. Можно использовать регулярные выражения Lua. Они хоть и упрощённые по сравнению с общепринятыми, но это скорее всего получится. Только надо выдранные куски сохранить, чтобы потом вставить обратно. Или, в качестве альтернативы, вручную пропускать их на следуюшем этапе. Рассчитываем среднюю ширину символа. Шрифты на взгляд не моноширинные, так что придётся по средней считать. Берём запас на ширину окошка, чтобы компенсировать погрешность. Ищем пробелы, предшествующие окончанию текущей строки, и заменяем на "\\n". В процессе поиска придётся запоминать предыдущий найденный пробел. Также по хорошему надо учесть разные хитрые ситуации, когда есть слова, длиннее ширины строки, и ещё если эти слова стоят в начале строки и т.д.

Попробуй \\n, может получится

Guzerus, нет такой группировки monster. Если заглянуть в файл game_relations.ltx, то увидим две таблицы: одна - только для отношений между группировками сталкеров. Монстров там нет. Другая - для отношений между монстрами. Кроме монстров там ещё есть actor и human. Т.е. актора можно подружить с монстрами, а других сталкеров - только всех сразу. Одного никак, разве что в логику исключения проставлять. Но это надо в скрипты лезть.

Guzerus, монстры группировок сталкеров не различают. Для них есть только сталкеры и актор.

qwertyuiop, в каком смысле начал? Если не трудно, поделитесь результатами начинаний.

Есть идея. Если сделать однопатронные пачки, то тогда по дропу пачки можно попытаться ловить выстрел. Или сделать на основе гранатомёта и ловить по дропу гранаты (а может по спавну фейковой). Вот только думаю, можно ли сделать конкретную разновидность патронов невидимой в инвентаре? А где пишет?

Ага, колбек на дроп, понятно. К сожалению, это работает только для пачки или для гранат. Опять же, как определить, что не выкинули, а зарядили в ствол ? Данные объекта, что же ещё. Там могут быть и строки, поэтому и размер гуляет. Только для клиентского объекта никто не составлял формат записи и чтения. Это сделано только для серверного и то больше в виде побочного эффекта разбора all.spawn. А нет желания эту информацию оформить в виде статьи в "справочнике"? Это не префикс, это просто стволы для мультиплея со своими именами.

кровоSTALKER, я что-то не понимаю. Где ты в xr_sound нашёл функцию get_safe_sound_object ? В ЧН была, а в ЗП нету такой. Как у тебя может "не играть", если это попросту не должно запускаться?

Monnoroch, если не ошибаюсь, db.storage содержит все объекты, причём как записи с ключами - id. Как там найти, скажем, сталкеров? Так что отдельная таблица для сталкеров, ну или для "целей вертолёта" не помешает.

Можно про использование боеприпаса подробнее? Живые неписи управляются анимацией, потому оболочка есть только у дохлых. Полагаю, надо дать ему время помереть =) Дверь - это физический объект с костью, за которую её можно открыть. А насчёт неиспользования физики в скриптах оригинальной игры. Я думаю, там не до того было. см. выше. Кроме того: 1. Это метод, который своему названию соответствует. Здесь речь идёт о силе. 2. Третий аргумент - время действия в миллисекундах. 3 мс - как бы маловато =) Насчёт управления понял. Родилась встречная идея, как может быть можно определить "удержание" правой кнопки. Можно попробовать дать много патронов, и заставить стрелять очередью. Если между апдейтами число патронов уменьшается - значит держим кнопку. В этом случае можно придать патронам смысл "заряда". Зачем оно им вообще надо? Думаю - это лишнее. А цели - это только сталкеры? Почему бы не зарегистрировать в биндере сталкера и актора при выходе в онлайн каждого непися и не занести их в таблицу? Это ведь не сложно. В этой таблице будет десятка три записей максимум. Другое дело для физических объектов так не сделать. Таскать же можно почти всё, что под физикой: собственно физические объекты, инвентарные предметы, всё оружие, арты, тушки. Регистрировать всё - можно попытаться, но как-то уж очень глобальный мод выходит. А перебор - не вариант. Это же фриз нехилый.

lekzd, кроме того, что таб - это неудобно, он ещё и занят кучей других модов. Надо искать другие способы. Опять же остаётся проблема определения того, что перед тобой лежит предмет. На локации объектов довольно много, перебирать их все в момент нажатия - плохой вариант.

lekzd, я как-то думал про гравипушку. Когда с физикой развлекался, то это первое, что пришло на ум. Но там масса мелких вопросов. Первое. Вот лежит перед тобой предмет, и тебе надо его подцепить. Как ты узнаешь, что он перед тобой лежит и ты на него нацелился? Дальше. Допустим, ты сделал некий девайс, вероятно на основе обычного ствола. Тебе нужны три действия: поднять, отпустить и кинуть. Значит надо определять нажатость на курок (левая кнопка) и как-то ещё нажатость правой кнопки для кидания. Насколько я знаю, отдельный выстрел пока никому отследить не удалось, особенно, если патронов нет =) Остальное по сути дело техники: уравновесить гравитацию для предмета, подтащить его, держать перед актором и дать ему пинка. Это всё нудно, но реализуемо наверняка, а вот те проблемы - без понятия как сделать, особенно с управлением.

lekzd, если уж подтащить удалось, то пусть висит перед актором сам предмет. Зачем его удалять? Так и как определять предмет под курсором? Из примитивных способов на ум приходит перебор всех онлайновых с определением того, что попадает в конус взгляда.

Monnoroch, если надо просто пнуть предмет, то лучше пользоваться не хитом, а методами класса physics_shell. Импульс в параметрах хита хоть и есть, но действовать на живых не будет, поскольку они под анимацией. Импульс вроде как подействует только тогда, когда хит будет смертельный и начнёт действовать регдолл анимация (собственно физика). Впрочем не уверен, надо проверить. В любом случае для тушек и физических объектов смысла заморачиваться с хитом нет - что им до химического или "кусачего" урона? А через физическую оболочку можно так: obj:get_physics_shell():apply_force(x,y,z) здесь метод хоть и называется "приложить силу", но на самом деле имеет смысл "добавить импульс", т.е. тот-же смысл, что и параметр impulse класса hit. Чтобы изменить скорость объекта на V надо приложить импульс, равный m*V. m - масса. Физическую массу можно узнать методом mass. Чтобы пнуть предмет в вертикальном направлении со скоростью 10 м/с делаем так obj:get_physics_shell():apply_force(0,obj:mass()*10,0) Только учтите, что наличие оболочки надо обязательно проверять. Вспомнил вот. Хит тоже можно использовать, поскольку он даёт возможность пнуть в произвольную кость, что с помощью оболочки не сделать. Я так пытался управлять вращением объекта, пинал в две разных кости в противоположном направлении с равным импульсом =)

Monnoroch, Gonarh, злые вы =) По поводу "сначала учи, потом пиши". Рекомендую взглянуть, как реализована (разработчиками) функция _g.IsMonster в ТЧ и как она же в ЗП. Увидели? Следуя озвученному правилу, им бы следовало застрелиться, а не выпускать такое в свет. Насчёт оффтопа. Ну не здесь про скрипты, допустим. А где тогда? На форуме есть более адекватное место?

Голосую всеми конечностями. Ещё бы всё программеры взяли за правило прилично оформлять свой код. Впрочем, думаю коммунизм наступит раньше =) Насколько мне известно, в случае индексации от единицы и без разрывов хеш-таблицы вообще не используются, а значения хранятся просто как массив. Впрочем, это только внутренняя оптимизация. Ничто не мешает и в этом случае считать таблицу Lua ассоциативным массивом общего вида. Ничто из этого =) Поскольку это формат файла, т.е. способ интерпретации непрерывной последовательности байтов. Когда ты читаешь эти данные из файла, то просто выбираешь для их хранения наиболее удобную структуру. На мой взгляд что-то вроде такого: ini_data = { [<имя секции 1>] = {[<ключ 1>] = <значение 1>, [<ключ 2>] = <значение 2>, [<ключ 3>] = <значение 3>, }, [<имя секции 2>] = {[<ключ 4>] = <значение 4>, [<ключ 5>] = <значение 5>}, -- и т.д. } Т.е. как видишь не одна таблица, а их комбинация. Хотя на кой надо хранить в программе все данные из внешнего файла? Кроме того, формат файла допускает и отступление от такого вида. Как ты верно заметил, внутри секции можно получать данные не по ключу, а по номеру строки. Это надо главным образом для того, чтобы читать секции такого вида: [some_section] value1 value2 value3 ; и т.д. т.е. в этом случае вид "ключ/значение" не соблюдается. Используется это в частности для обхода ограничения, которое не позволяет получить список секций в файле. Я могу завести специальную секцию, в которой таким образом перечисляю идущие далее секции, как бы регистирую их. В этом случае, адекватной структурой данных для этой секции будет список, массив или множество. Можно задать и направление и импульс. Вроде как пример был в "справочнике" в этом посте.

Garry_Galler, Внесу небольшое уточнение насчёт порядка расположения объявлений в модуле. В принципе, порядок не должен быть так важен. Дело в том, что последовательность работы с модулем следующая: При первом обращении модуль загружается и компилируется. При этом происходит выполнение операторов, которые находятся в глобальной области. Объявления таблиц и функций - это по сути своей выполняемые операторы, поэтому в этот момент (при загрузке модуля) важно, чтобы объявление А, которое использует объект Б, стояло бы после объявления объекта Б. Когда загрузка модуля закончена, то все задекларированные объекты - это по сути записи в таблице и как такового порядка уже не имеют. Поэтому после загрузки модуля уже не важно, в каком порядке таблицы и функции расположены в файле - они могут ссылаться друг на друга без проблем. Вот иллюстрация сказанного. Пусть это будет файл my_module.script: local a = 1 local b = a * 2 local t = {} t.a1 = b -- объявления a, b, t должны быть строго в таком порядке, поскольку выполняются последовательно при загрузке модуля function fun1() fun2() -- можно ссылаться на ещё не созданную функцию end function fun2() end -- если я вызываю fun1 снаружи, то вызов my_module.fun1() должен сработать без проблем -- поскольку сначала произойдет загрузка модуля и создадутся и fun1 и fun2, -- а только потом произойдёт собственно вызов -- а вот так нельзя, поэтому дальше закомментировано --[[ function fun11() fun22() end fun11() -- этот вызов произойдёт при загрузке модуля до объявления функции fun22, поэтому будет сбой function fun22() end ]] Хотя конечно в любом случае не стоит превращать код в малочитаемую кашу и всё-таки надо как-то упорядочивать объявления.

Нет. То, что я сейчас описал - это голый Lua. Будет работать где угодно. Luabind естественно опирается на эти синтаксические возможности. Добавляет к этому предопределённые конструкторы/деструкторы, глобальную функция создания, наследование. Ну в принципе это и средствами Lua тоже можно сделать, но там это просто готовое есть. Кроме того, если здесь строится на базе таблицы, то в Luabind - на базе пользовательского объекта. Естественно, в основном он нужен для экспорта сишных классов. "Просто классы" Luabind как бы приводит к своему стандарту оформления.

Monnoroch, Конструкция вида: function <имя_класса/таблицы>:<имя_функции/метода>(<список_аргументов>) <тело функции> end это на самом деле комбинация из двух синтаксических украшений. Приведённый код эквивалентен следующей конструкции: <имя_класса/таблицы>.<имя_функции/метода> = function(self, <список_аргументов>)<тело функции>end Или иными словами в таблицу просто добавляется ещё одна пара с ключом <имя_функции/метода> и значением типа "function". Сама функция при вызове подразумевает наличие первого скрытого аргумента self. В случае использования при вызове нотации с двоеточием: t:fun(<список_аргументов>) это в свою очередь эквивалентно записи t.fun(t, <список_аргументов>) Т.е. при вызове таблица/объект подставляется в качестве первого неявного аргумента, который соответственно станет неявным аргументов self в объявлении выше. Короче да, самопальный класс =)

Monnoroch, нет конечно. И вообще смысл колбека - не вызывать что-то, а напротив быть вызванным чем-то, чтобы дать в этот момент что-то сделать дополнительное. Поэтому меня и удивило немного, что on_death вызывает смерть. Однако работает, а kill_entity не работает, я только что проверил. Кстати, в ЗП для серверного класса добавили метод kill, видимо как раз для решения этой проблемы.

Garry_Galler, это как бы не специальный метод для убиения, а коллбек серверного объекта на смерть. Т.е. он автоматом вызывается при смерти непися. Весьма неожиданно, что он сам по себе вызывает смерть неписей. Я не пробовал, но может быть можно использовать метод kill_entity класса alife_simulator.

Зачем здесь функция вообще? release либо удалит либо вылетит, так что что-то там возвращать смысла нет. Здесь более уместны аналогии с STL. Там строки - это объекты класса и сравниваются по содержимому.

Ray, стиль дурной, согласен. Но к ошибке в данном случае это не приведёт, поскольку как обычно локальные переменные перекрывают глобальные. Сама функция внутри себя становится недоступна, но в данном случае рекурсия не нужна. ЗЫ: Это индикатор =) К концу недели способность рожать "длинные мнемоничные идентификаторы" сильно снижается.