Nazgool

Повторю ещё раз Давайте тогда уж поставим на голосование. Согласен. Я у себя в SciTE еще выставил подсветку основных функций сталкера. На скрине этого не видно, т.к. набивал в версии Lua 5.2, а в 5.1 есть ) Я вроде бы и согласен. Новогоднюю елку делать не нужно. А вот в редакторе (теоретически) может быть полезным. Возьму к примеру подсветку основных функций(ну или свойств тоже) сталкера. Набиваю db.actor --> подсветилось --> значит правильно, в db actor-а есть такое свойство далее : db.actor:give_money --> подсветилась give_money --> тоже правильно, есть такой метод. Как-то так.

+1. О да. Я совсем забыл об этом сказать. Не просто бесит. Разрывает. Это вопрос решался не нами. Так что обращайтесь в вышестоящие инстанции. Могу сказать почти то же самое - возьмите SciTE и не парьтесь. Аргументы желательно услышать. WARNING ! Хочу заметить, эти аргументы нужны не нам с вами. Каждый из нас уже давно определился как и с чем работать. Они нужны для тех, кто занимается техподдержкой сайта. Именно они, на основе наших пожеланий и предложений примут решение о том или ином стиле.

@abramcumner, Раз уж тут предполагается дискуссия, то выскажу свои претензии к подсветке Notepad. 1. Числа. Числа используются в скриптах сполошь и рядом. Их очень много. Оранжевый цвет, в силу своего спектра, воспринимается глазом достаточно сложно. Поэтому цифры должны быть подсвечены более выразительно. 2. Строки. На твоем скрине три различных способа оформления строки имеют различную подсветку. Зачем? Строка, как тип Lua значения, должен иметь и свой индивидуальный цвет. Подсветку строки в двойных кавычках лучше уж использовать для чисел. 3. Операторы. Тут моё категорическое недовольство. В глаза обязано бросаться то, какой математический знак ты поставил, закрыл ли скобку, обратился к свойству или методу... и т.д. Поэтому только красный цвет! 4. Зарезервированные ключевые слова (and, break, do, ...) Цвет одинаков в обоих редакторах. Вопросов нет, но я собственно хочу сказать не об этом. Ни один из близких к этому цветов не должен использоваться для подсветки других ключевых слов. Именно они определяют визуальное восприятие блоков кода. Из скрина видно, что в Notepad подобную посветку используют coroutine и os. 5. Ну и последнее. На скрине string, math, coroutine, os почему-то имеют подсветку базовых функций Lua. В принципе на это можно и не обращать внимания. Вроде бы таблицы библиотек тоже базовые. Но я бы не стал относить таблицы к функциям. Считаю что каждая библиотека должна иметь одинаковую цветовую гамму. Вот для сравнения набил код с твоего скрина в SciTE https://yadi.sk/i/dHXBMEoHgD83z

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

Итак, во-первых спасибо администрации сайта за проделаную работу. Теперь появилась возможность подсвечивать код Lua в наиболее распростаненном стиле. Во-вторых. Многие могут посчитать, что затронутая тема не является чем-то необходимым. Теоретически так оно и есть. Но вот практически выходит несколько иначе. Не могу и не стану говорить про всех. Скажу за себя. Разбирая вопросы пользователей касающихся скриптовой составляющей, поймал себя на том, что первое что я делаю - это копирую код с форума в редактор. Это позволяет, например, банальное отсутствие 'end'-а определить практически мгновенно. Не говоря уже о сложных скриптах, когда без без зрительного разделения блоков кода очень сложно понять принцип работы. Поэтому в-третьих. В данной теме предлагается обсудить "наиболее распростаненные стили", которые будут приняты за основу подсветки синтаксиса Lua на форуме. Ну и теперь, являясь поклонником редактора SciTE, мне остается только предложить его подсветку. Для тех кто не знаком с подсветкой этого редактора, я подготовил скриншот : https://yadi.sk/i/8p9BE4QigCaJJ

heading -- этот в движке уже делали complex_mode -- и этот light_anim la_cyclic la_text la_texture la_alpha xform_anim xform_anim_cyclic highlight_text vert_align И это только для CUIStatic. Для остальных классов писать? Как их изменять скриптово? Никак. Нет таких методов в CUIStatic. (ну по крайней мере было никак). Если кто-то сделает это всё в движке, то денег конечно не дам, но благодарность обеспечена. А раз пока ничего подобного нет, то остается только новые классы городить. Ну это я писал про "то время". Сейчас и у меня нормально переносится.

get_console():execute("unbind quit") get_console():execute("bind quit kESCAPE")

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

Интересно, уважаемый, а как в вашем мире моды устанавливаются? Не заменой ли оригинальных файлов? P.S.1 Ах, нет. У вас это видимо происходит как-то по-другому. Для вас это будет открытием, но указаные мною файлы тоже добавляются при установке. Не удивляйтесь. Это не чудо. Подобное происходит у всех. P.S.2 см. P.S.1 За сим не вижу смысла нашего дальнейшего разговора. Разрешите откланяться.

Если это о том что я говорил, то не стоит беспокоится. В bin добавляется 4 dll-ки и 1 файл lua. Т.е. 3 dll - это расширение lua, 1 dll и 1 lua - библиотека LuaXml. Ни о каком движке речи не идет.

@Serge!, Даже если способы перезаписи есть, то мазохизмом я заниматься не хочу. Тут уж нам точно не по пути. Есть нормальные способы. Моя религия не запрещает их использовать.

Да они уже сто лет известны. Сейчас поищу пост, где я уже писал про расширение Lua от RvP. Вот http://www.amk-team.ru/forum/index.php?showtopic=6185&p=928128 Про остальное потом.

@Serge!, С диалогами не работал, но со 100%-й гарантией скажу что ui xml читаются каждый! раз при обращении к ним. Я где-то уже писал, - закрыл окно -> переписал файл -> открыл уже измененное окно. Т.е. захотел изменить какой-то "xform_anim", который скриптово не доступен - не проблема. Так что их можно назвать и динамическими. Просто никто не заставлял их "динамить" )

В OGSE я кое-что начал было делать. Правда не для диалогов, а для рисования окон. Для окон предметов, над которыми я работал, у меня был один динамический xml-файл. С помощью либы LuaXML он прекрасно перезаписывался. Тоеретически я думал было избавиться от всех UI xml-ей, т.е, образно говоря, в папке config\ui у меня должен лежать один этот динамический файл.

@Arhara, Не совсем понял в каком контексте вы упомянули меня в своей последней цитате. Я, сдается, писал совсем не про логику, поэтому не расцениваю выражение относящимся к теме моего поста. Или я не прав?

Не все xml загружаются "раз и навсгда". По крайней мере те, что относятся к UI, читаются каждый раз при обращении к ним. Т.е. закрыл окно -> переписал файл с помощью io -> открыл уже измененное окно.

Эта сборка совместима со всеми официальными версиями ТЧ. Так что можно смело добавлять в каждый из 7-ми bin-ов. Главное активировать расширение вызовом RvP() в каждом из 7-ми _g.script-е.

@Simonov50, Вот я подготовил архив для расширения Lua by RvP. Инструкция внутри. https://yadi.sk/d/g7Dshghnfgzm5 Также есть возможность подключать сторонние библиотеки. Со всем этим делом очень удобно использовать "тестовый стенд". Способ нашел malandrinus. Если интересно, то могу показать как это организовать.

Этот комментарий к своему посту Вы прочитали, но если бы очень хотели решить свою проблему, то прочитали бы и мой пост чуть ниже. Либо не настолько нужно, либо не заметили, либо не читали вовсе. Если первый случай, то не стоило и задавать вопрос. Если второй, то без внимательности многое не просто делать, особенно скриптовать. Ну а третий случай ... неверное оставлю без комментариев )

Установи расширение Lua от RvP. Если будут проблемы, то распишу подробно.

Вроде люди интересуются модом. Решил установить и глянуть что тут и как. Для чего? Ну-у-у... Не буду скрывать истиных мотивов. 1. Автор - очень талантливый (и это от души) человек. Это ИМХО аксиома. Большое спасибо. 2. Также не буду скрывать - я уже имел опыт работы с идеями автора в моде OGSE. 3. Установил для того, чтобы посмотреть и (на основании предыдущего опыта - как скриптера - оценить и при необходимоти) предложить(исправить) то, что нуждается в скриптовом исправлении. Но... Вроде у всех всё нормально. А у меня не так. Я не придираюсь ни в коем случае. Всё гораздо проще. ЭТО бросается в глаза. Начну с самого начала. 1. У меня разрешение 16:9. И ПДА при загрузке растянут ну очень уж не естественно. Ерунда, это же бета. Таких разрешениий нет. Благо - это можно исправить. 2. При самой первой встрече с командиром блок-поста его логика заглючила. Пришлось сохраняться и снова загрузить, чтобы он наконец переключился в другую секцию видимо. Тоже нужно смотреть. Это вопрос без ответа! Переход из одной схемы в другую у него по методу on_info =. Он не может не работать. Я лично грешу на кривости аи-сетки или какой-то мешающий рестриктор на пути. 3. Логика солдата, что на толчке, тоже глючит не по детски. Если по "F" поймал не во время(так уж получилось видимо), то кошмар. Только перезагрузка спасает. К сожелению, это не исправишь. Дистанция инициации НПС для ГГ зашита в движке. 4. И ещё про этого солдата. Диалог у него зациклен. Так и задумано? Почему нет? 5. Спать - это нужно постараться. Очень тяжело поймать точку на матраце. Да, объект выбран слишком малого размера. 6. Ах, да. Прошу не обижаться. Но очень глупо выглядит гонка солдат за мною. Могу предложить вариант и проще и логичнее. Дело в том, что(насколько я успел понять) выходов у ГГ нет. Он все равно попадает в лапы вояк. Так что вся эта гонка просто ... ну не нужна. Не думаю, что интереснее было бы просто наступить на растяжку и очнуться в казарме. После этого даже не смею предполагать - как же же мне сбежать с блокпоста. То ли я искать не умею, то ли что-то не так работает. Скушайте Ибупрофен из аптечки и поговорите с солдатом еще раз. Ещё раз прошу извинения если что не так сказал. Я очень хотел что-то сделать, чем-то помочь, но ... молчать природа не позволяет. Все нормально, никаких проблем. Играйтесь на здоровье, пока вылеты позволяют.

Мелочь конечно и не критично, но уже не первый день мозолит глаза. Вопрос касается редактора. То, что появился выбор кода Lua - это конечно хорошо. Но подсветка синтаксиса не очень соответствует представлениям таковой для тех, кто постоянно работает в специализированных редакторах Lua. Не хочу ущемлять чувства приверженцев других редакторов, но если взять два самых распространенных - SciTE и Notepad, даже с их различиями в вопросах цветовой гаммы, все равно код читается намного быстрее и легче, чем в существующем на данный момент. А это для скриптеров не мало значит. Собственно вот и вопросы. 1 Позволяет ли движкок форума(редактора - я в этом не осведомлен) применение других подсветок? 2 Если вопрос 1 == true, то рассмотрите ли Вы вопрос по изменению подсветки синтаксиса? 3 Если вопрос 2 == true, то рассмотрите ли Вы пожелания приверженцев различных стилей подсветки, или вопрос будет решаться в единоличном (администратора) порядке? @Murarius, Спасибо за ответ и то, что поселили надежду А вот с этим и не поспоришь. Отдельная благодарность за понимание )

+1 Раз 5 перечитал, но так и не смог определить для себя круг задач. @Simonov50, Ты хочешь защититься от вылета при вызове не существующей функции в файле? Правда возникает вопрос - зачем вызывать функцию, которой нет? Распиши подробнее, что ты хочешь сделать. А если вдруг я правильно понял, то можешь сделать хотя бы так. В _g.script добавить функцию : function safe_call(script, func, ...) local module = _G[script] if module then local f = module[func] if type(f) == 'function' then return f(...) end end end И вызывать где-то в защищенном режиме : -- вызов x = safe_call('my_script','my_func', arg1, ... , argN) -- проверка if safe_call('my_script','my_func', arg1, ... , argN) then ... end

@UnLoaded, Это понятно что enable_attachable_item. Тут все проще. Батоны, гитары, водка не при чем. В sr_light.script есть функция check_light, которая стоит на апдейте из xr_motivator.script. И в самом конце : if light ~= nil and torch then torch:enable_attachable_item(light) end добавить проверку на нужного НПС : if light ~= nil and torch then if "тот_сталкер_который_нужен" then light = false end torch:enable_attachable_item(light) end Вот собственно и был вопрос, - что у этого сталкера есть такого, чтобы сказать, что это "тот_сталкер_который_нужен". Т.е. что использовать вместо "тот_сталкер_который_нужен"? stalker:section() == "секция_того_сталкера" stalker:name() == "имя_того_сталкера" stalker:story_id() == "sid_того_сталкера" stalker:profile_name() == "может_такое_имя_есть" или ещё что-то, чем его можно отличить от других

@Dennis_Chikin, С obj:name() не так всё просто, как с section или sid. Хорошо если НПС в all.spawn-е. Можно имя глянуть как с sid-ом. А если он скриптовый? В общем... Полагаю что человек ещё не очень в скриптах, поэтому сразу и исключил этот вариант из списка.