[Potatoider]

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

Функции папируса:

На английском

На русском (не все, но базис)


 

[mr Jyggalag]

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

Код скрипта

Scriptname DSMaddspellmenu extends Quest Conditional

SPELL Property DSMspellmenu Auto
Message Property DSMopeningMSG00 Auto
Message Property DSMopeningMSG01 Auto
Message Property DSMopeningMSG02 Auto
Message Property DSMopeningMSG03 Auto
Quest Property DSMasmquest Auto
Actor Property PlayerREF Auto

Function DSM()
    if DSMasmquest.GetStage() == 0
        Utility.Wait(3.0)
        DSMopeningMSG00.Show()
        Utility.Wait(2.9)
        DSMopeningMSG01.Show()
        Utility.Wait(1.9)
        DSMopeningMSG02.Show()
        Utility.Wait(1.9)
        PlayerREF.AddSpell(DSMspellmenu, false)
        DSMopeningMSG03.Show()
        DSMasmquest.SetStage(10)

    elseif DSMasmquest.GetStage() == 20
        PlayerREF.AddSpell(DSMspellmenu)
        DSMopeningMSG03.Show()
        DSMasmquest.SetStage(10)
    endif
EndFunction

Всё работает прекрасно, но вот в чём незадача - почему то, по непонятным мне причинам, DSMopeningMSG03 сразу выводится на экран после месседжа DSMopeningMSG02, а не ждёт 1.9 секунды. Если я убираю строки

Utility.Wait(1.9)
DSMopeningMSG02.Show()

всё работает правильно (т.е после DSMopeningMSG01 проходит 1.9 секунды и появляется DSMopeningMSG03). Почему я убираю именно эти строки? Потому что ранее я их и добавил, модифицировав скрипт (чтобы вместо 3-х месседжей показывалось 4).

P.s:

1. все проперти верно настроены, проверка именно в тайминге.
2. DSMopeningMSG01-DSMopeningMSG03 это простые месседжи (не месседжбоксы), имеют Display Time 2 (поэтому после них идёт задержка 1.9 секунды). DSMopeningMSG00 также "простой месседж", имеет Display Time равный 3 (следовательно, задержка после этого месседжа 2.9 секунды). Изначально идёт скрипт ждёт три секунды, чтобы сразу не вываливать все месседжи (это Utility.Wait(3.0))
3. в принципе, я могу и удалить "проблемный" месседж, объединив его с другим, но мне чисто из принципа интересно, какого чёрта не работает

Сообщение отредактировал mr Jyggalag: 17 апреля 2018 - 22:27

[YourBunnyWrote]

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

К чему конкретно есть претензии?

[Karandra]

К чему конкретно есть претензии?

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

function foo()
    
endFunction

while (true)

endWhile

Что мешало сделать окончание блоков через просто end?
 
3. Мне не нравится синтаксис оператора приведения типов.

PonyScript Pony1Script = Pony1 as PonyScript;

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

using Utility;

Utility.MyGlobal();

5. Наследование вообще треш. Пример с той же статьи в Wiki.

ScriptName Script1 extends ObjectReference
function foo()
    debug.trace("Calling foo on Script1")
    parent.foo()
endFunction

; The following intermediary scripts don't define foo().
ScriptName Script2 extends Script1
ScriptName Script3 extends Script2
ScriptName Script4 extends Script3
ScriptName Script5 extends Script4
ScriptName Script6 extends Script5
ScriptName Script7 extends Script6
ScriptName Script8 extends Script7
ScriptName Script9 extends Script8
 
ScriptName Script10 extends Script9
function foo()
    debug.trace("Calling foo on Script10")
    parent.foo()
endFunction

И нам пишут что "...foo() would be called 10 times; Script10's version once, and Script1's version 9 times." то есть что версия функции foo из Script10 будет вызвана один раз и девять раз функция foo будет вызвана из Script1. Хотя по нормальному должен быть один вызов foo из Script10 и один вызов из Script1.
 
6. Определение классов. Сама по себе запись

ScriptName Script1 extends ObjectReference

Определяет новый класс с именем Script1 как наследника от ObjectReference. Где все переменные, отъявленные на уровне файла будут приватными (или защищёнными, не помню можно ли к ним добраться из наследников) членами этого класса. А Properties (свойства) публичные функции-аккссесоры с семантикой переменных. По хорошему тут нужно было сделать явное описание классов. Это было бы намного удобнее. Например вот так (используя немного модифицированный синтаксис C#):

using Debug;

class ScriptA: ObjectReference
{
	public void foo()
	{
		Debug.Trace("Calling foo on ScriptA");
	}
};

class ScriptB: ScriptA
{
	public void foo() override
	{
		Debug.Trace("Calling foo on ScriptB");
	}
};

class ScriptC: ScriptB
{

};

class ScriptD: ScriptC
{
	public void foo() override
	{
		Debug.Trace("Calling foo on ScriptD");
		parent::foo();
	}
};

7. Описания на Wiki. Раз уж папирус объектно-ориентированный, то почему у него нет нормального представления структуры классов и их зависимостей?
Типа этого:

 
8. В папирусе нет цикла for. Конечно его можно сделать через while, но почему Бетесда сама его не сделала?
 
В общем, единственное глобальное дополнение в скриптовой системе после Обливиона было добавление Properties, что позволили не писать кучу одинаковых скриптов для разных объектов. А больше и нет ничего особенного. Возможно я забыл ещё что-то.

[Potatoider]

Ты просто зануда. Нормальный язык.

Сделала же Bethesda конкретно на нем 2 игры, сделает и еще 10
 

Он не объектно ориентированный, но юсер-ориентированный.

Я вот это дерьмо терпеть не могу например. (Я даже не знаю обязательно ли его всюду лепить):
 

 

{
}

[Karandra]

Сделала же Bethesda конкретно на нем 2 игры, сделает и еще 10

Естественно сделают, оно же работает как никак.

 

 

Он не объектно ориентированный, но юсер-ориентированный.

Он именно что объектно-ориентированный хочешь ты этого или нет.

 

Я вот это дерьмо терпеть не могу например. (Я даже не знаю обязательно ли его всюду лепить):

Да надо. Просто ты похоже никогда не писал на языках из семейства C вот и не понимаешь всего удобства этого синтаксиса.

[Potatoider]

Да надо. Просто ты похоже никогда не писал на языках из семейства C вот и не понимаешь всего удобства этого синтаксиса.

Писал простой скрипт в Юнити неделю назад. Плевался и  блевал от необходимости лепить еще и такие скобочки.
 

 

Он именно что объектно-ориентированный хочешь ты этого или нет.

Ты не понял чо я сказал. Я сказал что папирус прост в обращении и изучении. Бесезде на нем нормально работается и народу. (хотя они и его освоить не могут)

[Karandra]

Писал простой скрипт в Юнити неделю назад. Плевался и  блевал от необходимости лепить еще и такие скобочки.

Писал бы больше чем неделю перестал бы блевать. 

 

Ты не понял чо я сказал. Я сказал что папирус прост в обращении и изучении. Бесезде на нем нормально работается и народу. (хотя они и его освоить не могут)

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

[Potatoider]

Писал бы больше чем неделю перестал бы блевать. 

 

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

Зануда.

Большим дядям с большими денюжками виднее чо у них в играх должно или не должно. Логично же.

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

[Karandra]

Большим дядям с большими денюжками виднее чо у них в играх должно или не должно. Логично же.

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

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

Тот пример школьной программы осваивается за 15 минут если у человека есть мозги. Тем более если человек знает один язык программирования, то освоить другой ему будет проще. Я ведь не предлагаю сделать из папируса новый C++, а только добавить в него то, что там должно быть изначально. А именно нормальный синтаксис с поддержкой циклов, однозначность (через регистрозависимость), нормальную реализацию наследования, более организованную документацию. Ну это если бы я мог исправить папирус конечно.

[Potatoider]

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

Вот! It just works! Пришел дизайнер, ну не знает он языков, он уровни ворочал туда сюда, умеет в 3д максе работать и музыку писать. Не умеет он в эти буковки. Ему дают редактор и документацию к нему и обучают простенькому внутреннему языку. И он готов.

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

[Karandra]

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

На изучение модификации папируса с моими дополнениями у него уйдёт максимум на полчаса больше.

[Potatoider]

На изучение модификации папируса с моими дополнениями у него уйдёт максимум на полчаса больше.

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

[YourBunnyWrote]

4. Неплохо было бы иметь директиву using

Излишне. Имело бы смысл, если бы были пространства имён.

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

В вики на страницах методов есть ссылки на их скрипты (классы), на страницах скриптов (классов) есть ссылки на базовые скрипты (классы), если они есть, так что выяснить для себя зависимости не представляет труда. Если тебе не нравится формат, то для себя ты можешь сделать, как больше нравится тебе. Можешь и с народом этим потом поделиться.

...

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

Да надо. Просто ты похоже никогда не писал на языках из семейства C вот и не понимаешь всего удобства этого синтаксиса.

Я писал и не могу понять, в чём заключается удобство или неудобство. Просто особенность синтаксиса, как по мне. Можешь раскрыть свою мысль более подробно?

[Karandra]

Излишне. Имело бы смысл, если бы были пространства имён.

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

 

В вики на страницах методов есть ссылки на их скрипты (классы), на страницах скриптов (классов) есть ссылки на базовые скрипты (классы), если они есть, так что выяснить для себя зависимости не представляет труда. Если тебе не нравится формат, то для себя ты можешь сделать, как больше нравится тебе. Можешь и с народом этим потом поделиться.

У меня была такая идея. Может быть сделаю если смогу заставить Doxygen сгенерировать всё это.

 

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

Честно, я не смог бы смириться с такой хренью в наследовании. Я сам писал поиск функций-членов в случае множественного наследования для реализации OOP для Lua. Это не так сложно, тем более что папирус компилируемый и в рантайме этого поиска уже не будет (наверное, хз как работает их компилятор).

 

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

 

Я писал и не могу понять, в чём заключается удобство или неудобство. Просто особенность синтаксиса, как по мне. Можешь раскрыть свою мысль более подробно?

Меньше писать, блоки явно видны сразу, унификация в конце-концов.

[YourBunnyWrote]

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

Это и так ясно: раз нет переменных и свойств с таким именем в коде, значит это обращение к другому скрипту.

Отсутствие цикла for ещё.

ИМХО, это не критично, особенно учитывая весьма скудные возможности массивов (только одномерные, статической величины, которую можно определить только через константу, могут содержать максимум 255 элементов). Тем более, что нет ничего такого в for, что нельзя бы было сделать через while.

Меньше писать, блоки явно видны сразу, унификация в конце-концов.

1. Есть языки, в которых ещё меньше (привет, Python).
2. Только при хорошем форматировании кода и относительно небольшой величине блока. Довольно часто встречается, что программисты добавляют комментарий после закрывающей скобки, чтобы было видно, что здесь заканчивается.
3. Привет switch-case и модификаторы доступа в C++.

Но разве был бы папирус хуже с такими изменениями?

Не могу знать. Совершенствовать можно бесконечно, но угодить всем всё равно никогда не получится. ИМХО, говорить об изменениях следует тогда, когда инструмент не позволяет реализовать желаемое, остальное - перфекционизм.

[Karandra]

Это и так ясно: раз нет переменных и свойств с таким именем в коде, значит это обращение к другому скрипту.

Логично конечно, но чтобы найти эти ссылки тебе придётся просмотреть код.

 

ИМХО, это не критично, особенно учитывая весьма скудные возможности массивов (только одномерные, статической величины, которую можно определить только через константу, могут содержать максимум 255 элементов). Тем более, что нет ничего такого в for, что нельзя бы было сделать через while.

Естественно нет, но крайне не удобно постоянно использовать while для которого нет даже break.

 

1. Есть языки, в которых ещё меньше (привет, Python).

Многие его за это и не любят.

 

2. Только при хорошем форматировании кода и относительно небольшой величине блока. Довольно часто встречается, что программисты добавляют комментарий после закрывающей скобки, чтобы было видно, что здесь заканчивается.

Хорошо. Тут добавление идентификатора структуры будет помогать.

 

3. Привет switch-case и модификаторы доступа в C++.

Хорошо, модификаторы доступа с C++ особенные. В случае switch-case я всегда пишу скобки даже если там одна строка.

switch (column)
{
	case ColumnID::Name:
	{
		...
		break;
	}
	case ColumnID::Source:
	{
		...
		break;
	}
};

Не могу знать. Совершенствовать можно бесконечно, но угодить всем всё равно никогда не получится. ИМХО, говорить об изменениях следует тогда, когда инструмент не позволяет реализовать желаемое, остальное - перфекционизм.

Этот инструмент не позволяет нормально реализовывать желаемое. Только через борьбу с синтаксисом и языком в целом. Чем не причина?

[Azazellz]

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

Вот чего уж точно не надо.

Что мешало сделать окончание блоков через просто end?

Через просто end - менее наглядно. Базовый интерфейс в редакторе по типу обычного виндовского блокнота, в нем где какая функция кончается было бы тупо не видно.

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

От такое есть. Мало чтоль?

 

Остальное (почти все) для меня какое-то программисткое вуду.

 

И да, Папирус - очень доступный язык.

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

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

[Karandra]

Вот чего уж точно не надо.

Надо. Очень надо. А то все пишут кто во что горазд. Один EndFunction, другой endFunction, третий endfunction, а кто-нибудь вообще напишет ENDFUNCTION или EnDfUnCtIoN.

Через просто end - менее наглядно. Базовый интерфейс в редакторе по типу обычного виндовского блокнота, в нем где какая функция кончается было бы тупо не видно.

Кто пишет код в блокноте то? Пусть берут Notepad++ (на CK Wiki даже написано про настройку его для папируса), Atom, VS Code да что угодно.
 

От такое есть. Мало чтоль?

Я не видел эту страницу. Что же, это уже хорошо.
 
Папирусу всего лишь нужно обновление, этакая версия 1.1 чтобы исправить все косяки которые Бетесда допустила то ли по не знанию как будет лучше то ли потому что им было абсолютно похрен на всё.

[Potatoider]

Надо. Очень надо. А то все пишут кто во что горазд. Один EndFunction, другой endFunction, третий endfunction, а кто-нибудь вообще напишет ENDFUNCTION или EnDfUnCtIoN.

Ну и нормально. Чем плохо?

Я выработал привычку писать EndEvent. Каждое слово с заглавной. Удобно. Кто-то капсом прописывает. Важно что это работает. Не хватало еще чтобы скрипты не компилировались из-за большой I (i) вместо l (L) (например)

[Karandra]

Ну и нормально. Чем плохо?

Ты прикалываешься, да?

 

Я выработал привычку писать EndEvent. Каждое слово с заглавной. Удобно.

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

 

Не хватало еще чтобы скрипты не компилировались из-за большой I (i) вместо l (L) (например)

И поэтому важно чтобы такой косо написанный код не компилировался. Чтобы не было потом идиотизма с поразному написанными идентификаторами которые делают одинаковые вещи.