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

[Zander_driver 10 333]

не я это придумал, а умные люди пришли к этому многие десятки лет назад. Этот принцип реально помогает упростить жизнь

Да знаю я. про принцип. По моим же наработкам можете увидеть что понимаю о чем речь идет, наверное.

Я откровенно не понял про "мифы и стереотипы".

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

 

А если ты можешь залезть в движок, то зачем тебе скриптовый парсер?

Хм, вы серьезно?

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

Неужели надо опять поднимать тему того, зачем это было нужно?

Твой парсер - это не "чисто скриптовое создание", с которого начался разговор.

Именно оно и есть. Любой нормальный код сопровождается данными как я уже говорил.

что за задачу вы собираетесь решать вот этим извращённым способом?

В моем случае, ответ на этот вопрос звучит так:

Я желаю иметь возможность скриптовыми инструментами делать с окном/контролом/статиком и проч. все, что только возможно/имеет смысл с ним вообще делать. Все в принципе возможные действия. Зачем? Чтобы на основе этого набора возможностей создать функционал для полностью скриптовой разработки любого интерфейса какого угодно назначения и функциональной нагрузки. Само собой в сопровождении файлов данных в конфигах. Зачем мне такой функционал? Стоит посмотреть на возможности инвентаря "Судьбы Зоны" например. Или, если не убедило, инвентарь какой-нибудь ММОРПГ-игры из относительно новых. Да и весь интерфейс впрочем.

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

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

Даже совсем не для того я бы сказал.

[Malandrinus 615]

делать полностью скриптом" - я имел в виду именно скрипт использующий вышеупомянутый принцип.

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

 

Но зачем-то вот прикрутили к движку еще и скрипты.

Примерно до 2004 года никаких скриптов в движке не было. Т.е. совсем. А окошки, диалоги и всё прочее было примерно в том же виде, как и сейчас. Даже и сейчас в ванильном варианте игры подавляющее большинство всего задаётся чисто данными. Даже в немногих скриптовых окнах оригинала собственно скрипты носят роль чисто формальную - инициализация на основе внешних данных, т.е. вызовы парсера, т.е. в сущности ровно тоже самое, что делает внутри сам движок.

 

Я желаю иметь возможность скриптовыми инструментами делать с окном/контролом/статиком и проч. все, что только возможно/имеет смысл с ним вообще делать.

Для этого можно спокойно создать окно на основе xml, а потом доделать что надо скриптами.

 

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

Даже совсем не для того я бы сказал.

Хм. И для чего же его разработали?

[Сусаль 1]

Как сделать рандомное оружие у НПС в Сталкер ТЧ...

[Zander_driver 10 333]

Тогда ты сам себе противоречишь

Нет. ltx-конфиг не занимается созданием интерфейса, он просто хранит данные и все. Интерфейс рисует скрипт, читая при этом данные из конфига. Разве не могу я такой процесс называть "чисто скриптовым созданием"? Я считаю, что могу.

 

 

Примерно до 2004 года никаких скриптов в движке не было

Я же не про историю, а про то, для чего они на самом деле нужны.

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

 

 

Хм. И для чего же его разработали?

Для хранения массивов текстовых данных с форматированием. Теги там всякие для того же.

Вот массивы строк в папке text, в сталкере - вполне логичны и уместны, ничего не имею против.

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

 

@Сусаль,

1. Во всех профилях нпс убрать оружие из спавна (я у себя вообще весь лут оттуда убрал, он там не нужен)

2. Скриптом при создании серверного объекта нпс, выдавать ему оружие. Учитывая результаты вызова math.random, его группировку, ранг и что хотите еще.

Серверными объектами нпс занимается se_stalker.script, если что

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

[advisor890 1]

Возможно ли как-нибудь сделать чтобы в local obj = alife():object("имя_объекта") определялось сразу несколько объектов? Допусти alife():object("имя_объекта") оr alife():object("имя_объекта_2"). Ну или как-то по другому?

[Eugen81 1 008]

@advisor890,

for k, v in ipairs( {"имя_обжа_1", "имя_обжа_2", "имя_обжа_3"} ) do
	obj = alife():object(v)
	if obj then -- если надо выполнить одно действие для всех обжей
	-- if obj and obj:name() == "имя" then -- если надо выполнить разные действия для каждого обжа 
		-- здесь что то делаем
	end
end

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

[Malandrinus 615]

Интерфейс рисует скрипт, читая при этом данные из конфига. Разве не могу я такой процесс называть "чисто скриптовым созданием"? Я считаю, что могу.

 

Разумеется не можешь! Разделение кода и данных - это в первую очередь разделение труда: программиста и дизайнера. Данные редактирует дизайнер, он не программирует при этом. Скрипт же редактирует программист. Редактирование данных - это задание конечного результата. Редактирование скрипта - это изменение алгоритма достижения результата. Второе существенно сложнее первого, именно поэтому разделение данных от кода упрощает работу: написав код парсера один раз мы больше этим не занимаемся, а занимаемся только более простым описанием данных. Ты написал парсер для чего? Чтобы и со своим парсером для каждого диалога что-то писать скриптами?

 

Мне кажется, я уже повторяюсь, и даже странно, что это надо повторять. Разве это не очевидно?

 

 

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

 

И что? Какое это отношение имеет к окнам и диалогам? Работа с ними как была, так и осталась неизменной с тех времён, когда скриптов не было. Скрипты ввели в основном для ограничения поведения неписей, т.е. для написания/модификации поведенческих схем.

 

 

Для хранения массивов текстовых данных с форматированием

 

Это универсальный язык хранения любых данных в текстовом виде. Тебе видимо словосочетание "промышленный стандарт" действительно ни о чём не говорит. XML - это повсеместно используемый стандарт. Не просто в "куче мест", а вообще повсеместно. Его удобство редактирования руками вообще не при делах. В наше время никто даже не рассматривает всерьёз вопрос удобства редактирования голого текста. Причина проста - ручное редактирование текста всегда существенно медленнее визуального. Именно поэтому я считаю, что правильный путь - это не написание ещё одного парсера под другой текстовый формат, а написание инструментов визуального редактирования.

[UnLoaded 313]

 

 

... а написание инструментов визуального редактирования.

 

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

 

[Malandrinus 615]

@UnLoaded,

 

наверное оффтопик здесь, но раз уж зашла речь о визуальных инструментах.
редактор окон Вполне юзабельный, хотя нарекания есть и автор походу забил на развитие.
редакторы диалогов:
1. упомянутый в составе SDK. Достаточно убогий, но тем не менее обладает свойством полноты, т.е. позволяет сделать в принципе всё.
2. здесь программа для редактирования много чего, в том числе и диалогов. Описания нет, не тестировал.
3. S.T.A.L.K.E.R. Plot Manager за моим авторством. Я пытался сделать максимально удобно. Получилось или нет, не мне судить. Несмотря на некоторые недоработки, как редактор диалогов программа вполне юзабельна.

4. ?? В этом посте упоминалась некая Clee, но ссылок уже нет.
 
Кроме того можно упомянуть визуальные утилиты для работы с ltx. В шапке этой темы можно найти парочку визуальных редакторов конфигов и NPC Creator.
Кроме того в той теме можно найти и другие утилиты. Я например видел генератор квестов и редактор артефактов, хотя и не смотрел подробно.

 

Т.е. как видим, народ в целом работает по созданию визуальных редакторов. Это и есть правильный путь.

 

 

[Zander_driver 10 333]

 

 

Разумеется не можешь!

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

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

Тогда у меня есть визуальное приложение-инструмент которое работает на основе файлов *.ortd - даже не ищите в сети что это такое) если и найдете, это не оно.

 

 

 

Ты написал парсер для чего? Чтобы и со своим парсером для каждого диалога что-то писать скриптами?

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

Возможность динамической надстройки функционала так сказать.

 

 

 

Тебе видимо словосочетание "промышленный стандарт" действительно ни о чём не говорит.

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

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

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

[FonSwong 33]

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

У меня просто была создана таблица в отдельном скрипте в древовидном виде(многовложенная) с некоторыми параметрами окон, и при открытии каждого окна скрипт считывал с таблицы с помощью циклов что закрыть, а что открыть, проходился по обёрткам и задавал необходимые параметры для каждого объекта.

Если бы смог все объекты инициализировать то так бы и оставил. Удобно ведь. Минимальные параметры добавил и готово...

Сразу не ответил, т.к. какой-то сразу негатив пошёл, мол как так-то всё в скриптах.

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

[Malandrinus 615]

 

 

мне как то казалось, что говоря о том "чем" мы что-то делаем, следует иметь в виду то, где реализуется алгоритм.

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

 

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

 

@FonSwong,

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

[FonSwong 33]

Так и придётся, это я уже понял.

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

А уж как удобнее скриптеру, то он и выберет.

Единственное что, используя лишь скрипты придётся обработчик делать.

[SK0RPY0N_O89O 341]

Помогите решить ошибку:

local condition = ((((item:id() % 10) * 10)+math.random(0,10))/100) * condition_modifer 
if npc ~= nil and character_community(npc) == "zombied" then
condition = condition * zomb_mod
end

Lua Checker выдает:

 

 

Checking C:\Games\STALKERZP\gamedata\scripts\death_manager.script:

death_manager.script (302): mismatched input 'local' expecting 'end'

 

 

Что это значит?

[abramcumner 1 146]

, может после return свои строчки добавил?

[SK0RPY0N_O89O 341]

@abramcumner, Поставил end после return и ошибка пропала.

[Zander_driver 10 333]

 

 

Поставил end после return и ошибка пропала.

Только это означает что ваши строчки выпали из функции в которой был return. Хотя возможно, так и надо...

[TIGER_VLAD 361]

Всем привет. Как можно заспавнить НПС через скрипт и там же установить путь к логике(не используя all.spawn). Платформа: ТЧ. Помню где-то тут видел, но вот сейчас найти не могу. Спасибо.

[dsh 3 824]

@TIGER_VLAD, самый простой вариант - сделать для него секцию, в ней указать "custom_data". Универсальный вариант - создать непися через alife():create() и любым, удобным для тебя, способом записать в его нетпакет нужную custom_data.

[TIGER_VLAD 361]

@dsh, 1 способ не подходит. 

записать в его нетпакет нужную custom_data. 

Как раз так и пробовал. Вот по этому примеру:

 

 

-- Спавн БТР. На основе АМК
--Параметры вызова: 
--позиция x,
--позиция y,
--позиция z, 
--левел вертекс, 
--гейм вертекс,
--файл логики без расширения .ltx. !!!ДОЛЖЕН находиться в config\scripts\btr!!!
-------------------------------------------------------------------------------------------------------------
function btr(posx,posy,posz,lvid,gvid,logic)
    local obj = alife():create("btr",vector():set(posx,posy,posz),lvid,gvid)         --тут вместо бтр, спавню нпс - agr_soldier_veteran
    local packet = net_packet()
    obj:STATE_Write(packet)


    -- свойства cse_alife_object
    local game_vertex_id = packet:r_u16()
    local cse_alife_object__unk1_f32 = packet:r_float()
    local cse_alife_object__unk2_s32 = packet:r_s32()
    local level_vertex_id = packet:r_s32()
    local object_flags = packet:r_s32()
    local custom_data = packet:r_stringZ()
    local story_id = packet:r_s32()
    local cse_alife_object__unk3_s32 = packet:r_s32()


    -- свойства cse_visual
    local model_visual = packet:r_stringZ()
    local cse_visual__unk1_u8 = packet:r_u8()


    -- свойства cse_ph_skeleton
    local skeleton_name = packet:r_stringZ()
    local cse_ph_skeleton__unk1_u8 = packet:r_u8()
    local cse_ph_skeleton__unk2_u16 = packet:r_u16()
    local health = packet:r_float()
    
    --устанавливаем логику
    custom_data = "[logic]\ncfg = scripts\\btr\\"..logic..".ltx"


    -- теперь заполняем нужные параметры
    -- свойства cse_alife_object
    packet:w_begin(game_vertex_id)
    packet:w_float(cse_alife_object__unk1_f32)
    packet:w_s32(cse_alife_object__unk2_s32)
    packet:w_s32(level_vertex_id)
    object_flags = bit_not(5)    -- ~5 = 0xfffffffa
    packet:w_s32(object_flags)
    packet:w_stringZ(custom_data)
    packet:w_s32(-1)
    packet:w_s32(cse_alife_object__unk3_s32)


    -- свойства cse_visual
    packet:w_stringZ(model_visual)
    packet:w_u8(cse_visual__unk1_u8)
    
    -- свойства cse_ph_skeleton
    skeleton_name = "idle"
    packet:w_stringZ(skeleton_name)
    packet:w_u8(cse_ph_skeleton__unk1_u8)
    packet:w_u16(cse_ph_skeleton__unk2_u16)
    health = 1
    packet:w_float(health)
    
    -- считываем скорректированные параметры
    packet:r_seek(0)
    obj:STATE_Read(packet, packet:w_tell())

    return obj
end

 

 

Но, не работает.

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