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

[Zander_driver 10 166]

 

 

А теперь обратный вопрос есть у меня Как можно функцией в ствол запихать N количество патронов?

Посмотреть методы класса game_object, что-то про set_ammo_elapsed

[vampirnik77 121]

@Zander_driver, Да именно. Но тип патронов не установить. Нужно попробовать капнуть через нет пакет.

Изменено 8 Апреля 2016 пользователем vampirnik77

[Zander_driver 10 166]

Тип патронов именно через нетпакет и ставится

[Logger 1]

всем привет , у меня такой вопрос (даже 2):
1) Подскажите функцию чтобы через нет пакет сменить direction предмета (при спавне через alife:....)
2) Как узнать vector  (направление) на обьект относительно другого обьекта (грубо говоря делаю самонаводящиеся ракеты (нужно узнать направление в котором находится target цель относительно установки))

 

[Romann 614]

 

 

грубо говоря делаю самонаводящиеся ракеты

В вертолётах Кирага есть ПЗРК с самонаводкой - подсмотри там в скриптах.

[Zander_driver 10 166]

 

 

Как узнать vector (направление) на обьект относительно другого обьекта

http://www.amk-team.ru/forum/topic/7450-spravochnik-po-funktciiam-i-klassam/#entry249938

вспоминаем векторную математику и присматриваемся к методу sub.

[FonSwong 33]

Не понятно почему, но у меня вообще не получается скриптово создать CUIScrollView(), в то время как CUIListBox() дочерний от скрола успешно создаётся...

Собственно не суть, могу и его использовать.

Сам вопрос: у меня есть поля с текстом(заполняется автоматически разной длины текста), при большом объёме текст вылазиет, а размер окна с текстом остаётся таким же, и когда появляется новое окно ниже, верхнее залезает на нижнее.

Как можно увеличивать размер окна с текстом по мере того как увеличивается объём текста(чтобы начало следущего окна было там, где уже нет текста), или же какой-то другой способ побороть это есть? Ну и при смене разрешения так же может залезать.

Изменено 11 Апреля 2016 пользователем FonSwong

[naxac 2 372]

@FonSwong, в ЗП в классе CUITextWnd для этого есть метод AdjustHeightToText. В ТЧ такой же метод добавлен в класс CUIStatic в проекте X-Ray Extensions, в чистом его нет.

[FonSwong 33]

В общем я уже пожалел что решил перенести с .xml файлов полностью на скрипты.

При попытке приаттачить CUIScrollView, CUIEditBox, CUIEditBoxEx к чему либо - тупо вылет.

У CUIListBox почему-то скролл слева а не справа.

Может конечно я сам туплю, но как можно ошибиться в двух строках:

self.scroll_chat	= CUIScrollView()
self	                : AttachChild(self.scroll_chat)

Жесть какая-то...

Изменено 12 Апреля 2016 пользователем FonSwong

[Malandrinus 611]

@FonSwong,

 

В твоём коде самом по себе ошибки нет, но твой контрол скорее всего недоинициализирован. Создай его по-человечески с инициализацией через xml и не парься.

 

А зачем было полностью переходить на скрипты? Можешь как-то обосновать необходимость этого?

 

Я кстати встречал подобные экстремальные замашки и почему-то в основном среди скриптёров-новичков. Из подобного припоминаю один запущенный случай, когда человек создавал диалоги исключительно скриптами, полностью игнорируя xml. Зачем? Ну вот так хотелось, может считал, что это круто или что-то в этом роде. Что это не даёт никаких преимуществ, что создаёт совершенно несопровождаемый код, и такие диалоги невозможно редактировать никакими редакторами, а только вручную, человека не волновало.

[FonSwong 33]

@Malandrinus, ды когда прописываешь в .xml ведь не сделаешь полносью динамическим наполнение, вот я и того, подумал что посредством лишь скрипта организовал бы...

А hint(то что появляется при наведении) можно как-то скриптом сделать?

Что даёт SetAutoDelete(boolean) до сих пор не пойму?

Где можно увидеть все опции для прописки в xml файлах для окон?

Изменено 13 Апреля 2016 пользователем FonSwong

[naxac 2 372]

Где можно увидеть все опции для прописки в xml файлах для окон?

В исходниках: xrGame\ui\UIXmlInit.cpp

[FonSwong 33]

 

 

В исходниках: xrGame\ui\UIXmlInit.cpp

как-то мне это не особо помогло, глянул- ничего не понял, вопрос актуален:/

[Zander_driver 10 166]

 

 

В твоём коде самом по себе ошибки нет, но твой контрол скорее всего недоинициализирован. Создай его по-человечески с инициализацией через xml и не парься.

А еще можно создавать по человечески и нормально инициализировать скриптами и без использования xml

 

 

Что это не даёт никаких преимуществ, что создаёт совершенно несопровождаемый код, и такие диалоги невозможно редактировать никакими редакторами, а только вручную, человека не волновало.

http://www.amk-team.ru/forum/topic/13216-sborochnyj-tcekh/#entry959170

Почему у меня такое ощущение, что я догадываюсь о каком новичке идет речь.

[Malandrinus 611]

А еще можно создавать по человечески и нормально инициализировать скриптами и без использования xml

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

 

 

Почему у меня такое ощущение, что я догадываюсь о каком новичке идет речь.

Нет, я говорил совершенно о другом человеке (и вообще странно, что ты счёл, что я бы мог назвать тебя новичком=). Раз уж ты привел в пример твою наработку, то это как раз не скриптовое создание, а также создание с помощью данных. Просто ты реализовал для этого альтернативный парсер. Замечу при этом, что истинно динамические диалоги, т.е. с созданием на лету диалога с произвольным графом, так всё равно не сделать. Поэтому выходит, как я и сказал, попросту другой механизм разделения кода и данных, не xml + движковый парсер, а ltx + скриптовый парсер.

 

На мой взгляд, перечисляемые в твоём посте недостатки xml преодолеваются с помощью нормальных инструментов редактирования. Утилита из SDK - это как раз пример крайне плохого инструмента. Я пытался сделать лучше, на мой взгляд получилось неплохо. Будут силы и время, доработаю свою утилиту до приемлемого состояния.

 

 

когда прописываешь в .xml ведь не сделаешь полносью динамическим наполнение

 

А что значит "полностью динамическим"? Ты всерьёз собираешься скриптами менять ВООБЩЕ ВСЕ параметры окна или контрола?

 

 

 

Что даёт SetAutoDelete(boolean) ...?

Когда ты размещаешь окно как дочернее, то установка этого параметра в true приведёт к тому, что это окно удалится автоматически при удалении своего родительского.

Изменено 15 Апреля 2016 пользователем Malandrinus

[UnLoaded 313]

 

 

когда прописываешь в .xml ведь не сделаешь полностью динамическим наполнение, вот я и того, подумал что посредством лишь скрипта организовал бы

Согласен с Malandrinus'ом - что мешает создать окно на основе xml-описания, а затем скриптово крутить\вертеть его как хочется ?

[Zander_driver 10 166]

Разделение кода и данных - вполне себе правильная вещь.

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

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

Я попробую проиллюстрировать свою мысль.

Допустим мы выводим некий элемент на худ. Как мы можем это сделать? Вот 3 варианта:

    --##################################################################################
    -- #1 где-то в каком-то файле лежит такой код:
    STATIC = CUIStatic()
    STATIC:Init(10, 10, 156, 24)
    STATIC:InitTexture("empty_texture")
    get_hud():AddDialogToRender(STATIC)
    
    --##################################################################################
    -- #2 где-то в папке скриптов лежит модуль управления худом
    --- где то в его начале лежат настройки
    local static_x, static_y, static_width, static_height = 10, 10, 156, 24 --- эти настройки можно сопровождать комментариями
    local static_texture = "empty_texture" --- пояснящими что для чего и зачем
    --- * * *
    
    -- далее где-то в файле такой код:
    STATIC = CUIStatic()
    STATIC:Init(static_x, static_y, static_width, static_height)
    STATIC:InitTexture(static_texture)
    get_hud():AddDialogToRender(STATIC)
    
    --##################################################################################
    -- #3 где-то в папке конфигов лежит файл настроек
    -- а в папке скриптов лежит модуль управления худом, и в нем есть что-то такое
    function Load_params()
        local ltx = system_ini()
        local static_x = ltx:r_u32("секция_настроек", "static_x")
        ...
        return static_x, static_y, static_width, static_height, static_texture
    end
    --- * * *
    
    -- далее где-то в файле такой код:
    local static_x, static_y, static_width, static_height, static_texture = this.Load_params()
    STATIC = CUIStatic()
    STATIC:Init(static_x, static_y, static_width, static_height)
    STATIC:InitTexture(static_texture)
    get_hud():AddDialogToRender(STATIC)

 

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

Во втором варианте данные вынесены в начало файла, сопровождаются яснопонятными комментариями и назначение их понятно любому кто не поленится заглянуть в этот файл. Хотя это все еще, файл кода. Как бы.

В третьем варианте данные вынесены в ltx-конфиг, и читаются оттуда. Бонус для тех кто по каким то психологическим соображениям боится открывать файлы *.script, не более того. Хотя это конечно актуально и дает массу плюсов.

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

 

Чем отличаются эти 3 (4) варианта? Что, в каких то из них есть разделение кода и данных, а в каких то нет? мне представляется что это ошибочный стереотип, т.к. данные - есть во всех 4-х вариантах, и код выполняет одну и ту же задачу. Разница между ними заключается в простоте доступа к изменению этих данных.

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

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

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

 

 

 

И вот после этого таки вернемся к "чисто скриптовому созданию".

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

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

Ну и наконец. xml как "хранилище данных" - это просто ужас что такое. Горбатое нагромождение тегов и неочевидных правил, неудобное для чтения и редактирования. Просто для того чтоб хранить данные использовать это? Да ну бросьте. ltx-конфиг подходит для этого не сопоставимо лучше, хотя бы потому что организован в простой и понятной структуре "ключ = значение". И каждую пару ключ-значение можно сопроводить каким угодно комментарием. что еще надо для хранения данных?

 

назвать тебя новичком

Я сам себя новичком считаю. Новичок - тот кто с интересом учится новому, тот кто всегда допускает вероятность что чего-то не знает, И когда находит незнакомое то с интересом изучает.

 

то это как раз не скриптовое создание, а также создание с помощью данных

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

И опять про возможность доработки функционала, доработки кода... я в своем моде использую диалоги, которые будучи построенными в игре, содержат тысячи и десятки тысяч фраз. Вы же не думаете что я все их в ltx описывал?

 

Замечу при этом, что истинно динамические диалоги, т.е. с созданием на лету диалога с произвольным графом, так всё равно не сделать

Если в движке убрать сохранение диалоговых графов, чтобы он запрашивал их создание при каждом обращении к нпс, то как раз этим способом - можно.

 

На мой взгляд, перечисляемые в твоём посте недостатки xml преодолеваются

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

Возвращаясь к вышеприведенному примеру со статиком на худе, и беря в качестве испытуемого какого-нибудь допустим ученика 5 класса, троечника-прогульщика который впервые для себя решил покопаться в файлах игры и что-то там сделать.

В чем он разберется быстрее, в ltx-кофиге состоящем из пар ключей и значений, сопровождаемых комментариями на русском, или в непонятной xml-мешанине тегов?

 

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

Ну так вот господа. Тот программист который писал код по варианту #1, он тоже тешил себя мыслями что "кто не скриптер - тот не разберется".

А на самом деле есть просто плохой код и хороший. И промежуточные стадии конечно

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

 

Ты всерьёз собираешься скриптами менять ВООБЩЕ ВСЕ параметры окна или контрола?

А почему бы собственно нет?

 

 

Изменено 15 Апреля 2016 пользователем Zander_driver

[Malandrinus 611]

@Zander_driver,
Данные разумеется есть всегда. Идея отделения их от кода в том, чтобы менять их, не меняя код. Если данные смешаны с кодом, то по очевидной причине, придётся менять код, чтобы менять данные. Поэтому твой пример кода №1 - это как раз типичное грубое смешение кода и данных. В том числе, хотя и менее плохо, вынесение данных в отдельный блок кода, поскольку и тогда придётся править файл кода. В идеале должен быть отдельный файл данных, чтобы его правка вообще бы не трогала ни одной строчки и ни одного файла кода. Собственно, так и задумана работа с файлами игры.
 
Я откровенно не понял про "мифы и стереотипы". Для начала, не я это придумал, а умные люди пришли к этому многие десятки лет назад. Этот принцип реально помогает упростить жизнь. Данные легче менять, чем код. Меняя данные мы описываем результат, а код - это описание процесса достижения результата, и его изменение заведомо более сложное, нежели данных. Заключается это в массе мелочей: необходимость отладки, больше возможностей по внесению ошибок, больше усилий на понимание и т.п. Это касается как написания, так и всех этапов последующего сопровождения.
 

xml как "хранилище данных" - это просто ужас что такое

 
Это промышленный стандарт, для которого не надо делать парсеры, поскольку они уже есть во множестве. Редактирование же в свою очередь не должно быть руками. Нужны адекватные инструменты, о чём я тоже говорил. Применительно к разным задачам модостроя такие инструменты уже появились или появляются. И это - правильный путь.
 

В чем он разберется быстрее, в ltx-кофиге состоящем из пар ключей и значений, сопровождаемых комментариями на русском, или в непонятной xml-мешанине тегов?

 
Быстрее того и другого разберётся в инструменте визуального редактирования.
 

Если в движке убрать сохранение диалоговых графов

 
Но сейчас то нельзя. Чтобы это сделать, тебе надо залезть в движок. А если ты можешь залезть в движок, то зачем тебе скриптовый парсер? Я бы тогда уж сделал парсер движковый, пусть и не на xml, а на ltx. В любом случае, что ты хочешь мне доказать? Ты же делаешь инструмент как раз для архитектурно правильного разделения кода и данных, так о чём вообще спор? Твой парсер - это не "чисто скриптовое создание", с которого начался разговор. Хотелось тебе сделать всё по своему - право твоё. Хотя я бы и не стал так делать, а направил бы усилия на развитие инструментов для того же xml (что я и делаю по мере сил). В любом случае, здесь разговор вообще не об этом.
 
Твой пример №1 - вот то, о чём я говорил. Люди продолжают так делать сплошь и рядом: окна, диалоги, что ни попадя. Конкретно то, что я имел в виду, это когда человек создавал каждую фразу отдельным вызовом функции и отдельными ручными вызовами пришпиливал к ним предусловия, инфопорции и т.п. Это - зло в чистом виде.
 
 

> Ты всерьёз собираешься скриптами менять ВООБЩЕ ВСЕ параметры окна или контрола?
А почему бы собственно нет?

Лучше бы ответил не ты, а @FonSwong. Потому что это конкретный вопрос, а не "вообще". Практически всегда, когда я задаю конкретный вопрос "что за задачу вы собираетесь решать вот этим извращённым способом?" ответа либо нет, либо он так и звучит "а вдруг надо будет" или "а почему бы и нет". Лично я уже давно излечился от этого и решаю только те задачи, которые передо мной реально возникают.

[advisor890 1]

Я использую функцию проверки близости к аномалии вызываемую через bind_anomaly_field.scripts

Вот функция:

 

function anom_field_update(anomaly) 

if db.actor then 

local act_pos = db.actor:position() 

local anom_pos = anomaly:position() 

if act_pos:distance_to_sqr(anom_pos) < 4 then 

--[[Код который выполняется если ГГ на расстоянии менее 2 метров от аномалии, 

переменная anomaly содержит объект-аномалию, параметры которой можно считать]] 

end 

end 

end

 

Теперь мне допустим нужно после "< 4 then" вывести на мини карту метку обозначающую аномалию к которой я подхожу.

Я так понял мне нужно сделать проверку секции конкретной аномалии, а потом выводить на мини карту через level.map_add_object_spot_ser(obj.id, "blue_location", text)? Или все же как-то по другому?

[Malandrinus 611]

@advisor890,

идея примерно как ты написал, хотя реализация будет сложнее. Поскольку метку на объект надо ставить только один раз, то надо держать массив помеченных аномалий, и периодически их все проверять на предмет того, что актор вышел из радиуса. Если вышел, то метку снимать и удалять из массива. Кроме того, лучше наверное использовать не level.map_add_object_spot_ser, которая ставит постоянную метку, а level.map_add_object_spot, которая ставит метку, не сохраняющуюся в сейве.