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

[_Val_ 2 225]

Если активен, проверяем дальше

Такс...А если он внезапно станет неактивным? Ну вот прямо в момент проверок? В сталкере много чего творится странного...

Не - вы сами парни запутались и меня путаете.

1. Проверяется активность гулага, проверки поршней нет.

Если гулаг неактивен, переходим в первую секцию.

Если активен - переходим к дальнейшей проверке.

2. Если есть поршень, переходим во вторую секцию.

Но судя по исходнику мы должны перейти в неё при неактивном гулаге.

Вот же человеческий вариант))

{=gulag_inactive(esc_lager)} section1, {=gulag_active(esc_lager) +esc_infop1} section2

Изменено 25 Августа 2015 пользователем _Val_

[abramcumner 1 157]

@_Val_, в теории такое конечно можно провернуть - засунуть в условия к секции1 функцию, которая меняет состояние гулага. Но с таким подходом ложное переключение логики - самая маленькая из проблем.

 

А так вся эта строка проверяется сразу целиком, на потом не откладывается.

 

В сталкере много чего творится странного...

Ну я бы сказал моддеры творят много странного. В движке все достаточно стройно и логично. Когда выполняется логика больше никто ничего с игровыми объектами не делает. Только то, что прописано в самих скриптах/логике.

 

{+info1} ? {+info2} section_new

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

[{+info1} {+info2}] section_new

Изменено 25 Августа 2015 пользователем abramcumner

[_Val_ 2 225]

Хм...Продолжим. В данном случае переход по секциям отличается только одним условием - наличием-отсутствием поршня. Гулаг в обоих случаях должен быть неактивен.

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

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

{=gulag_inactive(esc_lager) -esc_infop1} section1, {=gulag_inactive(esc_lager) +esc_infop1} section2

Ну или допустим такая..хм?

{=gulag_inactive(esc_lager) -esc_infop1} section1, {+esc_infop1} section2

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

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

Изменено 25 Августа 2015 пользователем _Val_

[abramcumner 1 157]

Совсем начальная конструкция была другой:

{=gulag_inactive(esc_lager)} section1, {!gulag_inactive(esc_lager) +esc_infop1} section2

Если неактивный гулаг, то секция1; если не неактивный(то есть активный) и есть инфопорция, то секция2

[_Val_ 2 225]

Ну и нормально всё выглядит. Всё понятно - кроме одного, чего огород городить))

[abramcumner 1 157]

@_Val_, ну вот именно это и равносильно такому:

{=gulag_inactive(esc_lager)} section1, {+esc_infop1} section2

когда во вторую часть целиком входит отрицание первого условия. Изменено 25 Августа 2015 пользователем abramcumner

[Полтергейст 37]

abramcumner

 

Я бы сделал квадратные скобки

Квадратные скобки уже заняты. Не забываем про секции ini-файлов.

[Grif_on 9]

 

 

А действительно ли нужно его удалять? Его же можно просто дизаблить

Хотел я дизаблить, да в ЗП не смог заставить работать функцию disable_level_changer. Буду копать дальше, может чего и получится.

[Dennis_Chikin 3 658]

2 Полтергейст:

 

И все-таки, почему бы сразу не писать так, как во что оно разбирается ?

Ну, да, на новом перейдем на новый синтаксис, старое - пусть работает, как работало. Какие проблемы ?

 

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

[Zander_driver 10 334]

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

А придумывать новое мракобесие ради совместимости со старым горбатым и глючным мракобесием - ну как то бессмысленно чтоли. Ведь те же грабли в итоге.

[abramcumner 1 157]

@Zander_driver,@Dennis_Chikin, предложите свой не мракобесный синтаксис. Возьмите логику Волка или Сидоровича и запишите ее в новом синтаксисе.

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

[Forser 47]

Ребят, может кто-то для примера показать скрипт, который использует LuaXML?

[Полтергейст 37]

Dennis_Chikin

 

Во-вторых, господа, вы как хотите, но палочки, скобочки и закорючки - зло. Они не человекочитаемы.

А что тогда читаемо? Нет, ну можно конечно прямо в spawn_ini вшивать Lua-код, а потом запускать через loadstring. Тоже вариант. Только чем-то надо заменять знак = и квадратные скобки, т.к. уже используются в синтаксисе ini-файлов, а также ввести дополнительные правила и ограничения. Но я просто не представляю, как всё это будет уживаться со старым вариантом.

[Nazgool 250]

@Forser, 

 

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

-- подключить библиотеку LuaXml
require 'LuaXml'

-- загрузить данные из файла "global_map.xml" в таблицу 'xfile'
local xfile = xml.load("global_map.xml") -- тут вообще-то полный путь к файлу

-- или же загрузить данные из строки 'sxml' в таблицу 'xfile'
sxml = [[<?xml version='1.0' encoding="UTF-8"?>
<!-- global map  -->	
<window x="57" y="16" width="891" height="643">
    <background>
        <texture>ui\ui_global_map_small</texture>
        <minimized_rect x1="2" y1="2" x2="130" y2="19" ></minimized_rect>
        <normal_rect x1="2" y1="2" x2="130" y2="258" ></normal_rect>
        
        <minimized_btn x="0" y="0" width="16" height="16">
            <texture>ui\ui_scb_down_arrow</texture>
        </minimized_btn>
        <maximized_btn x="17" y="0" width="16" height="16">
            <texture>ui\ui_scb_up_arrow</texture>
        </maximized_btn>
    </background>
</window>]]

local xfile = xml.eval(sxml)

-- поиск подтаблицы с именем "texture" (по имени тега)
local texture = xfile:find("texture")

-- если подтаблица найдена...
if texture ~= nil then
    -- получить значение
    local name = texture[1] --> ui\ui_global_map_small
    -- установить новый или изменить старый атрибут
    texture.width = 900 -- or texture['width'] = 900
end

-- добавить новый подтег к описанию "maximized_btn"
-- сначала получить объект "maximized_btn"
local maximized_btn = xfile:find("maximized_btn")
-- добавить поле с именем 'new_field' и значением 'test_value'
maximized_btn:append('new_field')[1] = 'test_value'
    --[[ получается :
    <maximized_btn height="16" width="16" x="17" y="0">
        <texture>ui\ui_scb_up_arrow</texture>
        <new_field>test_value</new_field>   -- ДОБАВЛЕНО НОВОЕ ПОЛЕ
    </maximized_btn>
    ]]

-- удалить поле 'texture' из описания 'maximized_btn'
table.remove(maximized_btn, 1)
    --[[ получается :
    <maximized_btn height="16" width="16" x="17" y="0">
        <new_field>test_value</new_field>
    </maximized_btn>
    ]]

-- переименовать тег 'maximized_btn' в 'max_btn'
maximized_btn:tag('max_btn')

-- создать новый XML документ с головным тегом "root"
local x = xml.new("root")
-- добавить к нему подтег с именем "child" и значением 123
x:append("child")[1] = 123
    --[[ получается :
    <root>
        <child>123</child>
    </root>
    ]]

-- сохранить XML в файл
xml.save(x, 'C:\\test.xml') 

 

 

Изменено 26 Августа 2015 пользователем Nazgool

[Zander_driver 10 334]

 

 

предложите свой не мракобесный синтаксис. Возьмите логику Волка или Сидоровича и запишите ее в новом синтаксисе.

Это же очевидно. Что есть логика? система для управления NPC (в данном значении - сталкеры или другие объекты, обладающие сложным поведением). Она описывается фундаментально - чем? набором состояний будем так говорить.

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

 

 

 

Или вообще

[section]
condition1 = 
condition2 = ... 
action1 = 
action2 = ... 

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

[abramcumner 1 157]

Это же очевидно.

Ясно. Вы просто потрепаться.

 

Все наглядно, понятно, ...

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

[section]
  on_info = ...

Она еще проще и понятней.

 

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

[_Val_ 2 225]

 

 

логику среднего размера

Эмм...Хочется посмотреть на логику караульного.

Задачи. Поспать, покараулить(вовремя сменив предыдущего постового), сменившись пожрать у костра. Ну чё - в  принципе простенько должно быть.

[Nazgool 250]

Разрешите высказать и своё мнение.

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

Это того не стоит. Точнее усилия, затраченные для достижения сомнительного

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

перестроение целой системы, более чем сомнительны.

 

Программистам (не являясь таковым, но тем не менее мне тоже) режет глаза лишняя проверка,

Тем более если перед этим уже проверялось.

{=gulag_inactive(esc_lager)} section1, {+esc_infop1} section2

Прежняя запись предельно ясна и разжевана :

{=gulag_inactive(esc_lager)} section1, {!gulag_inactive(esc_lager) +esc_infop1} section2

Но всё таки...

Тут нужно определиться для чего(точнее будет сказать - кого) пишется код.

Для железа первый вариант, конечно, предпочтительнее. Вне всяких сомнений.

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

(ну программистам об этом известно), может и задержаться на этом участке кода,

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

 

Поэтому с другой стороны, несколько инструкций, снова потраченных на эту же проверку,

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

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

 

Хотя, должен сказать, если новая система сможет выиграть хотя бы 10-15% производительности, то ...

Интересно было бы посмотреть. Не больше.Сам бы заниматься таким не стал. Слишком накладно.

Только если начиная от 30 а лучше 50 %. То может быть.

Изменено 26 Августа 2015 пользователем Nazgool

[_Val_ 2 225]

По мне - так лишняя проверка и не помешает. Сталкер же...

В связи с этим вспоминается.

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

 

[Полтергейст 37]

Zander_driver

 

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

Всё это так ровно до тех пор, пока не заполнена правая часть (после знака равенства). Как только потребуется отличить infoportion от вызова функции - появятся спецсимволы. Когда надо будет передать параметры - спецсимволов станет больше. А ещё понадобятся логические операторы and, or, not - их тоже как-то надо будет записывать, и это тоже будут спецсимволы. А если нет, то легче писать прямо lua-кодом без квадратных скобок.Nazgool, от повторных проверок можно избавиться при помощи запоминания результатов в пределах одной проверки condlist'а. И для этого не надо менять синтаксис.