Скриптование

[IQDDD 5]

Да, не получится.

[Artos 99]

Vano_Santuri

1. Приведенный пример для АМК-тайменров (именно по игровым минутам) имеет пороком не ограничение разрядности счетчиков, а то, что каждый раз очередной таймер устанавлявается относительно прошедщих игровых минут, которые расчитываются относительно кадендарного дня/часа минуты. Методы level.get_time_days() и ему подобные не завязаны на тайметрах, а тупо привязаны к началу часа, дня, месяца ...

Несложно увидеть, что если таймер будет стартовать в конце колендарного месяца, например 31-го в 23 часа с минутами, то если его срок более часа - то он уже никогда не прекратит отсчет ... точнее его отсчет закончится через месяц.

Это обусловлено тем, что каждый раз очередная проверка таймеров точкой отсчета берет опять же текущие день-час-минуты и если наступило 1-ое число следующего месяца, то новая точка отсчета будет иметь на 31 день мельше игровых минут, чем та, при которой аймер устанавливался.

Так что таймеры AMK (игровых минут!) имеют банальное ограничение: 31 день - они правильно работают ТОЛЬКО один месяц, т.е. до 1-го числа следующего месяца, который наступит в игре ...

 

2. Cо вторым типом АМК-таймеров немного сложнее и как раз эти таймеры упираются в разрядность класса game.time() (xFFFFFFFF ~> 4294967295), т.е. аналогично первым таймерам, эти начнут "врать" через немногим более 49 дней.

 

ИМХО, давно пора отказаться от АМК-таймеров в модах, игра которых предусматривает более месяца игрового времени. Да и ... транжирят ресурсы тоже не слабенько ...

 

 

*Shoker*, ничего в game.time() не накапливается, это все го лишь функция, которая возвращает некое кол-во милисекунд от начала некоего момента. Если вначале отсчет идет от начала игры, то через ~49,7 дней игрового времени эта функция начнет возвращать опять "заново", т.е. попросту будет врать на эти 49,7 дней

 

Добавлено через 7 мин.:

IQDDD, приношу извинения за свою неправоту, относительно флагов оружия. Действительно давняя зашоренность (не только моя) кочует из версии в версию uACDC и читалок/писалок нет пакетов, хотя в игровых скриптах все определяется как нужно, т.е. без ошибок.

Спасибо, подправил и у себя и передам, чтобы и в uACDC было подправлено.

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

 

[Vano_Santuri 33]

Artos, Ясно. Тогда вопрос ребром: а в таймерах Simbion - таких проблем уж точно нет? И какие бы ты посоветовал использовать таймеры?

У меня в данный момент есть от Simbion (только там нужно отучать от колбэков). От xStream - там боле-менее независимо от системы. А вот таймеры от Маландриуса куда-то делись (может у кого остались и может поделиться?)?

[IQDDD 5]

Artos, в таких условиях ставится вопрос о существовании решения. Как вы считаете, должно ли существовать решение этой проблемы?

[Artos 99]

Vano_Santuri, а вот ответ на вопрос ребром врядли обрадует ...

Во-первых, "таймеры от Симбиона" менялись/дорабатывались уже не раз и только в последнем (еще не опубликованном) варианте и свободны от вышеуказанных недостатков и мог бы порекомендовать, но ... они все же составляют единый "пакет" совместно и с системой коллбэков (хотя и не сложно отвязать) и с универсальным хранилищем.

Во-вторых, таймеры от xStream (собственно на базе которых и сделаны нынешние Симбионовские) - это по сути были заготовки, поэтому то и "боле-менее независимо от системы". Как только озаботишься, что таймеры то сохранять нужно и читать из сэйвов - вот и получишь "привязку".

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

Архив с январским вариантом от Маландриуса брошу в личку, ну а дальше - сам ищи и выбирай ответ на свой вопрос.

 

Добавлено через 4 мин.:

IQDDD, если игра различает установленную оптику, а не валит все в одну кучу - значит это можно прочитать и использовать. Именно так и считаю и, как выше уже написал, как раз заканчиваю очередное обновление мода под ТЧ и покопаюсь в кодах для ЗП ... Думаю решение, которое можно будет использовать в скриптах модов есть и будет найдено.

Изменено 19 Августа 2012 пользователем Artos

[7.9 174]

Ограничение счётчика - давняя тема...

 

Опыт казуала:

-- file _g.script

local count_time_fix = 0
function game_time_fix()
    return game.time() + 4294967295 * count_time_fix
end

 

И понятно, что заменил всё game.time на game_time_fix. Что-то около 40 замен получилось.

Когда пробовал, дошёл... вроде до агропрома -- в игре ничего не менялось, всё работало, не вылетало.

 

Понятно, что всё это, может и ничего не значить -- всё-таки, это опыт "казуального скриптера".

Изменено 19 Августа 2012 пользователем 7.9

[Artos 99]

7.9, ... как бы это помягче ... ты сам то понимаешь всю глупость приведенного кода и последующих слов?

 

1. Об'явить некую локальную переменную, которая всегда равна 0 (нулю), чудить с "фикс"-функцией дабы получить на выходе тоже самое, что и голая game.time() - хм ... действительно опыт "казуального скриптера". Тема то давняя, да до сих пор оказывается актуальная ...

2. Проверять отсутвие результата от ничего не делающего "фикса", который и фиксить то должен только спустя почти 50 игровых дней - это сколько десятков раз можно до агропрома прогуляться и ничего не заметить ненормального?

 

и собственно каков смысл сего кода/поста? Как не нужно делать иль еще какой казуальный ... ? ;-)

 

Ну а фиксится ошибка с разрядами (как уже ранее говорилось) просто заменой счетчиков на базе game.time() на использование аналогичных, но 64-х разрядных на базе game.CTime(), что начали делать, но так и не закончили сами разработчики оригинальной игры.

Изменено 19 Августа 2012 пользователем Artos

[IQDDD 5]

Интересуют ограничения на размер хранимых данных в db.storage

Изменено 19 Августа 2012 пользователем IQDDD

[AndreySol 215]

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

[IQDDD 5]

Люди, скажите, у меня где-то трабла, или такое в самом деле бывает.

function test(id)
    local obj = level.object_by_id(id)
    msg(obj:id())
    msg(obj:section())
end

 

Вылетов не вызывает, id верный. Секция отображается как 9x19.

function test_problem(id)
    local sobj = alife():object(id)
    if not sobj then abort([Что-нибудь]) end
    msg(sobj.id)
    msg(sobj:section_name())
end

 

Будучи вызанной сразу после test крашит игрут на вызове sobj.id (не на abort (!)). Как такое могет быть? По одному и тому же id клиент работает верно, а сервер вообще не адекватен.

 

Добавлено через 10 мин.:

В придачу: изменяются ли id'ы после сохранения/загрузки?

 

Добавлено через 31 мин.:

Отвечу на свой первый вопрос.

Следующий код будет работать (пусть id входной параметр (типа "number") - получение ближащей клиентской вещи)

local obj = level.object_by_id(id) -- получение клиента по number
local sobj = alife():object(id) -- получение сервера по number

 

Следующий код тоже будет работать:

local str_id = tostring(id) -- получение строкового представления id
local obj = level.object_by_id(str_id) -- получение по типу "number", который автоматически преобразовался из "string"
local sobj = alife():object(id) -- не меняем

 

Следующий код не будет работать:

local str_id = tostring(id) -- получение строкового представления id
local obj = level.object_by_id(str_id) -- получение по типу "number", который автоматически преобразовался из "string"
local sobj = alife():object(str_id) -- не изменяем

 

Если бы это было в ТЧ или ЧН - я бы не удивился, т.к. у класса alife_simulator метод object() перегружен:

    cse_alife_dynamic_object* object(int id, bool no_assert); // получение объекта по id. 
    cse_alife_dynamic_object* object(int id); // эквивалентно предыдущей функции с no_assert == true. 
    cse_alife_dynamic_object* object(string name); // получение объекта по имени. В ЗП нет!

 

Но в ЗП (в котором и тестируется этот пример) сей функции нет. Но тем не менее разработчики не потрудились убрать и "обёртку" маршалинга в вызов функции на C (или на чём там?). Я негодуэ.

Изменено 19 Августа 2012 пользователем IQDDD

[Struck 61]

IQDDD,

В придачу: изменяются ли id'ы после сохранения/загрузки?

 

Они неизменны на протяжении всей игры. Id пропадает только тогда, когда пропадает(удаляется из игры) объект к которому он был присвоен.

 

А по поводу первого вопроса, если я конечно правильно понял его суть, можешь просто проверять тип передаваемой переменной на эквивалентность числовому параметру.

 

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

 

Исходно в консоль допустим чтобы у меня вылетело типа "На АТП" либо "На подходе к АТП" и т.п.

 

Задумка в том, что мне нужно определить местоположение нужного объекта(клиентского/серверного), то есть где он ошивается.

 

P.S. вариант со спейс рестрикторами не предлагать, мне здесь нужно что-то типа "определения расстояния до...", но кучу проверок(типа distance_to) писать тоже не хочу.

Изменено 19 Августа 2012 пользователем Struck

[7.9 174]

Artos.

Помягче, так помягче...

Смысл того сообщения - "Запасной вариант не помешает".

В своё время, при предварительном тесте класса CTime были обнаружены аномалии.

Где гарантии, что все?

И учтут-ли те которые известны?

 

Код.

Приведённый код -- для проверки (на всякий случай, может и не надо было) последствий замены использования game.time() в исходных кодах, в пределах одного цикла этого счётчика, то-есть, в тех кодах и пределах, какие учитывались в скриптах самими разработчиками. Соответственно, кода с обновлением и сохранением той переменной в нём нет. Но разве это проблема?

 

Например, (казуальный) вариант с обновлением переменной:

local count_time_fix = 0
local count_time_save = game.time()
function game_time_fix()
    if count_time_save > game.time() then
        count_time_fix = count_time_fix + 1
    end
    count_time_save = game.time()
    return game.time() + 4294967295 * count_time_fix
end

 

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

 

[Struck 61]

Вроде как просто(!) определить положение - додумался...забить рядом с текстом нужной местности его x,y,z, и проверять расстояние нужного объекта до этих координат, но как определить где эта местность?(юг, восток, север, запад и т.д.)

[proger_Dencheek 6]

Как сделать это:

Если ГГ умирает, высылается сообщение: Погиб сталкер [Имя ГГ], [Причина], [Локация]

[IQDDD 5]

proger_Dencheek, смотря, какая модель вам ближе: "событийная" или "таймерная". Если событийная, то надо искать коллбек на изменение здоровья актора (по-моему, где-то уже обсуждалось, что даже если навесить биндер на актора, то не работает). Если таймерная, то с определённым периодом проверять здоровье ГГ, и если 0, то вроде есть метод получения последнего хита. Может ошибаюсь.

 

Добавлено через 2 мин.:

Struck, кури массивы и циклы. Создаёшь некоторую базу из точек, можно даже из областей (например, круг, прямоугольник и пр.). Вручную прописываешь сторону света, название и пр. Потом организуешь цикл.

 

Добавлено через 2 мин.:

4294967295 * count_time_fix

Здесь будет переполнение.

Изменено 19 Августа 2012 пользователем IQDDD

[7.9 174]

IQDDD, реально, у меня там предполагается другое число, значительно меньшее...

[Struck 61]

proger_Dencheek, есть скрипт счетчика смертей ГГ...смотри его.(в своих архивах я его быстро точно не отыщу)

 

IQDDD, так для кого пишу то, что кучу проверок и спейс рестрикторов мне делать неохота, нужен алгоритм(!) способа определения стороны света с помощью скажем всеми любимых тригонометрических функций, в зависимости объекта к заданным мною координатам, а спейс рестрикторы, которые ты предлагаешь тут делать(не приоритетно, но предлагаешь), здесь абсолютно ни к чему, т.к. расстояние "до" легко определяется функцией 'distance_to', и городить тут рестрикторы по меньшей мере глупо.

 

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

Изменено 19 Августа 2012 пользователем Struck

[IQDDD 5]

Пфффф... Да не предлагаю я ни какие спейс рестрикторы. А если тебе нужно определить стороны света ПО ОТНОШЕНИЮ К ДРУГОМУ ОБЪЕКТУ, то тут простая математическая задача при условии, что координатные оси уровня располагаются с юга на север и с запада на восток. Если это не так, то нужно ещё вспоминать функции преобразования координат при повороте системы координат.

Изменено 19 Августа 2012 пользователем IQDDD

[Struck 61]

IQDDD, я и прошу дать мне алгоритм этой математической задачи, мне больше ничего и не нужно. На данный момент у меня только координата нужной позиции. Изменено 19 Августа 2012 пользователем Struck

[IQDDD 5]

7.9

А не, нифига там не будет переполнения. Вернее, оно может быть, а может и не быть. Lua - динамический язык, и не ясно, в какой структуре будет представлено то или иное число: с фиксированной или плавающей запятой. Поэтому тут некоторые проблемы наблюдаются. Например, число 2^32 представляется в формате с фиксированной запятой (не уверен, т.к. может быть, что это число преобразуется в формат с плавающей запятой без потери точности.). А 2^64 уже преобразуется в формат с плавающей запятой с потерей точности. Т.о. мы не можем утверждать точность численных операций при значениях, больших 2^32-1. Или даже 2^31-1.

 

Если я не прав, киньте в меня огнеупорный кирпич.

 

Добавлено через 1 мин.:

Struck, а давай ты это сделаешь сам, или обратишься на dxdy.ru.

Изменено 19 Августа 2012 пользователем IQDDD