Кстати, в архиве language не распознается по типу файла - потому я могу его открыть и редактировать, только если открыть весь пк3 слэйдом, что не очень удобно.
На сколько я помню, можно приписать LANGUAGE.txt и все норм работало.
Shadowman Это всё же GZDoom, а не типографская система для вёрстки, о переносах он не знает (а их правила в каждом языке свои), поэтому выбран наиболее простой и надёжный путь --- по пробелам.
Если шрифт не моноширинный, то длина строки не равна количеству символов в строке, т.к. одни символы занимают больше места (типа букв Щ, Щ), а другие - меньше (i, точки и запятые). Это вечная проблема при определении переносов в гздум-текстах, потому каждый раз она решается на глазок, ориентируясь на примерную длину "стандартной" для данной области строки.
Всё правильно! Об этом я и говорю. BreakLines складывает длину строки из длин отдельных символов (см. строку №123 из исходника), и поэтому проблем в случае их неравенства не возникает. Метод специально реализован для решения этой проблемы, а три с половиной года назад его включили в ZScript.
Вот, пожалуйста, иллюстрация с первого уровня всё той же Blade of Agony. Там реализованы листы бумаги с текстом, к которым можно подойти, нажать на них и прочитать, что же там написано. Класс листа сделан на ZScript, а в методе отображения текста используется BreakLines (собственно, оттуда я и знаю про этот метод). Шрифты пока плохого качества (кое-где ещё нет некоторых символов для тире), да и текст, возможно, корявый (не уверен, что на текущий момент качество моего перевода хоть кто-нибудь тестировал, кроме меня самого), но представление он дать должен.
Вот ещё пример с немоноширинным шрифтом:
А все же интересно - какой же прогой ты создаешь LANGUAGe, что он корректно работает?
Прогу и батник я тебе кинул в pk3шнике выше. Она из LANG_ANSI создает корректный LANGUAGE. Сам же файл LANG_ANSI я создаю в проге Far Manager https://www.farmanager.com/download.php?l=ru кнопками shift+F4 (по умолчанию FAR юзает кодировку 1251, но если вдруг стоит 866, то жму F8 чтобы сменить на 1251)
Таким образом, алгоритм такой:
1) В FAR-е жму shift+F4, вбиваю имя LANG_ANSI, жму ENTER
2) Убеждаюсь, что кодировка выбрана 1251 (обычно это так)
3) Если выбрана не 1251 (например 866), то жму F8
4) Набираю текст и сохраняю файл кнопкой F2
5) Запускаю батник UTF8_LANGUAGE (он мне делает файл LANGUAGE)
6) можно играть/тестить
Но этот алгоритм я юзаю только для первого раза. Сейчас же, когда файлы у меня уже в руках, я просто копипащу аналогичные файлы из других моих модов, и редактирую их
BreakLines складывает длину строки из длин отдельных символов (см. строку №123 из исходника), и поэтому проблем в случае их неравенства не возникает.
Хорошо, но можно конкретнее - в чем измеряется wrapwidth?
void SetHudWrapWidth (int wrapwidth);
Например, установлен SetHudSize(1024,768); SetFont("MyFont");HudMessage(s:"text"...) или HudMessage(l:"Identifier"...)
Перед HudMessage я прописываю SetHudWrapWidth (число);
Длина строки будет в пикселях относительно SetHudSize? Например, максимальная длина строки не должна превышать 800 пикселей из доступных 1024 в SetHudSize, т.к. иначе уедет за рамки для текста - за картинку страницы в случае примера из БОА?
Т.е. мне надо взять стандартную строку, которая помещается в рамки текста, определить каким-то образом показатель wrapwidth для нее, и тогда все остальные строки будут подгоняться под этот показатель (и если слово выходит за рамки строки, то будет перенесено на след. строку, а строка закончится на пробеле перед этим словом)?
Shadowman Так это не "конкретнее", а другой вопрос. Перед этим мы говорили про ZScript-овый метод.
Да, судя по всему, именно так. Не могу найти часть исходника GZDoom, это подтверждающую, но вроде должно быть так. Вот пример кода (он библиотечный) и скриншот:
Нужно будет просто писать нормальный текст, как в Word или любом другом текстовом редакторе, и разбивать его не на строки, а на абзацы.
---
А всё-таки через ZScript эти вещи контролировать куда удобнее. Можно и из центра текст сместить, и несколько колонок сделать.
Да, текстовый файл работает и нормально правится - проблем нет. А вот все попытки пересохранить его в csv и открыть экселем показывают кракозябры вместо русских букв. Так что эксель юзать не получится, похоже...
Как бы в таком случае сделать удобные колонки для отдельного текста - русс, англ? Например, я записал достаточно длинную фразу (пример диалоговых скриптов) и в блокноте language это выглядит так:\
default,Identifier,ru
Picked up a crystal vial for health.,STRING_TEXT1,"Теперь, когда ты получил оружие и освоил азы магического искусства, ты можешь безбоязненно покинуть Зал Сотворения, и выполнить свою миссию, в чем бы она ни заключалась. Не спрашивай меня больше ни о чем, странник, ибо твое будущее мне неведомо. Могу лишь пожелать тебе успехов на твоем поприще!"
Для удобства восприятия выставил Перенос по словам в блокноте.
Но попытки сделать так, чтобы англ. и русский текст начинались с новых абзацов вызвали краш гздума. Т.е. вот такой вариант записи language не работает:
default,Identifier,ru
Picked up a crystal vial for health.,
STRING_TEXT1,
"Теперь, когда ты получил оружие и освоил азы магического искусства, ты можешь безбоязненно покинуть Зал Сотворения, и выполнить свою миссию, в чем бы она ни заключалась. Не спрашивай меня больше ни о чем, странник, ибо твое будущее мне неведомо. Могу лишь пожелать тебе успехов на твоем поприще!"
Но попытки сделать так, чтобы англ. и русский текст начинались с новых абзацов вызвали краш гздума. Т.е. вот такой вариант записи language не работает:
возможно стоит графу багрепорт сделать или suggestion, и обсудить с ним его мнение по поводу решения данной проблемы
Поэкспериментировал еще немного с Language. Кстати, файл в ANSI-кодировке работает, если используемый шрифт тоже в ANSI. Это как раз мой случай, судя по всему - т.к. когда я писал language в юникоде, то скрипты не показывали русский текст. Пересохранил language в ANSI - русский текст в скриптах стал нормально отображаться.
Но зато сразу же возникла проблема с декорэйтными сообщениями Консольный шрифт в юникоде, потому там стали показываться кракозябры вместо русских надписей.
Теперь даже не знаю, что делать. Шрифт, используемый в скриптах, меня устраивает полностью, я уже знаю его параметры и очень не хотелось бы его менять (тем более не ясно до сих пор, создает ли прога Нила шрифты в ANSI по умолчанию или там можно настроить кодировку). А вот для декорэйтных надписей нужен юникод.
Нельзя же держать 2 language - файла - один для юникода, другой для ANSI.
Кстати, language в отличие от других лумпов не понимает комменты, если вставить строчки типа:
здум вылетает. А жаль, можно было бы визуально немного структурировать тексты, разнести их по картам или по рубрикам.
Кстати, на зумвики другой пример структуры Language-лумпа:
https://zdoom.org/wiki/LANGUAGE И там допустимы и комментарии, и более удобное расположение строк.
Из описания здум вики:
there are two varieties of LANGUAGE lump: A .csv spreadsheet exported from Google Docs containing strings for multiple languages, or the old-style plaintext format, which typically holds only one language at a time with multiple LANGUAGE lumps present. LANGUAGE lumps, like all other text lumps, are cumulative and allow both types of C-style comments.
следует, что можно делать несколько кумулятивных лумпов. Но синтаксис неясен. Во всяком случае попытка сделать по аналогии с декорэйтом через инклюд:
Тогда что имелось в виду под кумулятивностью лумпов - не понятно.
Добавлено спустя 1 час 31 минуту 8 секунд:
Хотя позднее выяснилось. что я неверно понял описание - в вики сказано, что разные лумпы должны иметь разное разрешение (но тогда они только для одного языка - rus, eng и т.д.). Что в данном случае не подходит, т.к. нужны мультиязыковые лумпы для разных типов сообщений (консольные, скриптовые и т.п.).
Еще поэкспериментировал с SetHudWrapWidth. Как у любого автоматизированного решения недостатки все же нашлись. Например, если в конце строки оказалась фраза с тире - то есть вероятность, что тире перенесется на следующую строчку, что не соответствует правилам русского языка. Т.е. будет как то так:
"бла бла бла... Демон Чеогш "
"- это владыка преисподней"
В общем после нескольких попыток удалось сделать 2 файла language - один оставить в виде txt, а второму присвоить расширение csv. Причем оба файла структурированы как указал theleo_ua, но один я оставил в юникоде, и туда записал консольные сообщения, а второй - в ANSI - и там тексты из скриптов, использующие шрифт, который корректно работает в ANSI.
Хорошо что csv-файл тоже открывается блокнотом, так что эксель не нужен.
Таким образом можно работать и с имеющимся шрифтом, и с консольным шрифтом, который требует юникода.
Кстати, language в отличие от других лумпов не понимает комменты, если вставить строчки типа:
решение:
Скрытый текст:
default,Identifier,ru
HEXEN W4 UI MOD,,
REQUIRED,,
HANDLE (FIRST SEGMENT OF QUIETUS) IS REQUIRED,HEXEN__W4MOD__QUIETUS_1_HANDLE_REQUIRED,ТРЕБУЕСЯ РУКОЯТЬ (ПЕРВЫЙ СЕГМЕНТ ПОСЛЕДНЕГО ДОВОДА)
PICKUP,,
HANDLE (FIRST SEGMENT OF QUIETUS),HEXEN__W4MOD__QUIETUS_1_HANDLE_PICKUP,РУКОЯТЬ (ПЕРВЫЙ СЕГМЕНТ ПОСЛЕДНЕГО ДОВОДА)
ALREADY,,
YOU ALREADY HAVE A QUIETUS,HEXEN__W4MOD__QUIETUS_ALREADY,ПОСЛЕДНИЙ ДОВОД УЖЕ СОБРАН
HEXEN W4 UI MOD, REQUIRED, PICKUP и ALREADY - это комментарии
в данном случае не подходит, т.к. нужны мультиязыковые лумпы для разных типов сообщений (консольные, скриптовые и т.п.).
пока кроме идеи "каждый тип language кинуть в свой pk3 (или свою подпапку), которые при тестинге подрубать через gameinfo, а в релизе просто кинуть все pk3 внутрь основного pk3" у меня нет других вариантов. Лучше думаю графа напрямую спрашивать
В общем после нескольких попыток удалось сделать 2 файла language - один оставить в виде txt, а второму присвоить расширение csv. Причем оба файла структурированы как указал theleo_ua, но один я оставил в юникоде, и туда записал консольные сообщения, а второй - в ANSI - и там тексты из скриптов, использующие шрифт, который корректно работает в ANSI.
Хорошо что csv-файл тоже открывается блокнотом, так что эксель не нужен.
Таким образом можно работать и с имеющимся шрифтом, и с консольным шрифтом, который требует юникода.
А причем здесь консоль? Тексты из скриптов, которые через свой шрифт и HudMessage пишутся, в консоли не отображаются никак. Да это и не нужно. Потому если ANSI-шрифт работает с ANSI-language, то на консоль можно забить (ну разве что тебе понадобится выводить сообщение именно для консоли, но не понимаю, зачем это делать?)
Т.е. оставлять пустые позиции для идентификатора и русского текста?
Возможно, хотя не самый наглядный вариант. Вообще заметил, что language - очень капризный лумп, пару раз у меня гздум отказывался запускаться из-за какой-то ошибки, после чего я смотрел в language, чтобы не было лишних пробелов, в том числе после записанных сообщений. Один раз ошибка вылезла после того, как я скопировал нижнюю строку language наверх, чтобы она шла первой по списку (все операции проводил в блокноте).
Может-то может, но и там непонятки, как его готовить. Мои попытки написать в блокноте что-то подобное примеру из здум-вики оканчивались тем, что гздум ругался на 2 строчку, утверждая, что там должен быть знак "=", вместо "-". Хотя на второй строке стояла запись по образцу, типа MY_TEXT = "бла бла бла";
а в релизе просто кинуть все pk3 внутрь основного pk3" у меня нет других вариантов.
возможно, сойдет. Пока остановился на варианте из 2 файлов - с расширением txt и csv. Главное, чтобы при очередном обновлении гздум не отказался бы считывать оба language - тогда вся проделанная работа пойдет насмарку...
А причем здесь консоль? Тексты из скриптов, которые через свой шрифт и HudMessage пишутся, в консоли не отображаются никак. Да это и не нужно. Потому если ANSI-шрифт работает с ANSI-language, то на консоль можно забить (ну разве что тебе понадобится выводить сообщение именно для консоли, но не понимаю, зачем это делать?)
Слушай ты можешь наконец перестать задавать вопросы и просто сделать то что просят? Вот просто взять и вывести. И скриншот. Это нужно для отладки и понимания проблемы...
Т.е. оставлять пустые позиции для идентификатора и русского текста?
Возможно, хотя не самый наглядный вариант
да. Для наглядности можешь:
1) комментарии писать только большими буквами
2) в начале каждого комментария добавлять что-нибудь такое: или пара символов __ -- ++ ** на выбор, или целую строку вот так:
--------------------------------------------------,,
ТЕКСТ КОММЕНТАРИЯ СТРОКА 1,,
ТЕКСТ КОММЕНТАРИЯ СТРОКА 1,,
ТЕКСТ КОММЕНТАРИЯ СТРОКА 2,,
--------------------------------------------------,,
подозреваю что какие-то символы гздум не захочет обрабатывать в таком стиле (т.е. может и крашнуться), но для начала надо понять, какие символы заранее работают, а дальше сделать например так:
__--------------------------------------------------,,
ТЕКСТ КОММЕНТАРИЯ СТРОКА 1,,
ТЕКСТ КОММЕНТАРИЯ СТРОКА 1,,
ТЕКСТ КОММЕНТАРИЯ СТРОКА 2,,
__--------------------------------------------------,,
в примере выше мы опытным путем определили, что прочерк _ в начале строки гарантированно сделает, чтобы гздум не крашился
Вообще заметил, что language - очень капризный лумп, пару раз у меня гздум отказывался запускаться из-за какой-то ошибки, после чего я смотрел в language, чтобы не было лишних пробелов, в том числе после записанных сообщений. Один раз ошибка вылезла после того, как я скопировал нижнюю строку language наверх, чтобы она шла первой по списку (все операции проводил в блокноте).
Да, у меня были подобные вещи (кстати, когда я себе подбирал формат комментариев, чтобы гздум не крашился и не игнорировал весь мой ламп language вообще, мне тоже пришлось попотеть)
Может-то может, но и там непонятки, как его готовить. Мои попытки написать в блокноте что-то подобное примеру из здум-вики оканчивались тем, что гздум ругался на 2 строчку, утверждая, что там должен быть знак "=", вместо "-". Хотя на второй строке стояла запись по образцу, типа MY_TEXT = "бла бла бла";
если второй формат не работает, надо просить графа обновить вики (или его разрешения чтобы обновить там текст самому), чтобы не дезинформировало
возможно, сойдет. Пока остановился на варианте из 2 файлов - с расширением txt и csv. Главное, чтобы при очередном обновлении гздум не отказался бы считывать оба language - тогда вся проделанная работа пойдет насмарку...
Я хз можно ли сделать так, чтобы он загружал файлы именно из твоего pk3 (тобишь внутри pk3 есть gameinfo, который заставит гздум загрузить дополнительные файлы language из этого же pk3), но с незаархивированными папками точно работает (я так делаю у себя)
Проверил для консоли. Как и следовало ожидать - англ. текст норм выводится, вместо русского - кракозябры. Использовался шрифт в fon2, сгенерированный прогой Нила.
Сам скрипт:
Нельзя же держать 2 language - файла - один для юникода, другой для ANSI.
Я вот кстати как раз и использую 2 файла . Для zdoom\lzdoom\zandronum использую language.txt с кодировкой (ACSII / windows 1251) и в нем примерно так написано:
[rus]
TEXT_TEST = "какой то заранее написанный текст";
Русские буквы взял из гздума и переминовал в STCFN*** как в первом посте и вроде работает (консольный шрифт брал у прошлой русификации гздума до 4.x.x версий).
Файл language.csv тоже правлю в блокноте (Notepad++) и нем меняю кодировку на UTF. Там к примеру следующее пишу:
Identifier,ru
TEXT_TEST,какой то заранее написанный текст
в самой карте пишу скрипт:
script 1 open
{
PrintBold(l:"TEXT_TEST");
}
И затем запаковываю в архив зип (pk3): уровень с language.txt, language.csv, русскими буквами в папке graphics и confont.lmp. В итоге и в гоззе и зандронуме\лздуме\здуме все норм отображается. Как то так.
Будет странно слышать, но это вирусняк... 1: на virus total'е трое антивирей тригернулось, 2: со вчерашнего дня у меня антивирь уже пахает в полную силу, уже 10+ угроз нашло. Не качайте! (+К тому же PID запуска меньше некоторых системных программ)
Пока остановился на варианте из 2 файлов - с расширением txt и csv. Главное, чтобы при очередном обновлении гздум не отказался бы считывать оба language - тогда вся проделанная работа пойдет насмарку
Либо я что-то делаю не так, либо гздум таки перестал считывать оба файла и, к сожалению, приоритет отдаёт старому формату в ANSI-кодировке, полностью игнорируя "csv". Как-то можно заставить гз считывать оба файла из одного архива или теперь только с помощью доп. патча придётся делать локализацию для разных портов?
Кто-то пробовал поговорить на эту тему с Графом?
Сам спросил, сам отвечаю.
Вот что сказал мне Graf Zahl: "There is no priority here- things will be read in directory order. If you have two LANGUAGE lumps in the same container file you have to ensure the intended ordering - in Zips you have to use another extension that sorts in later alphabetically."
Переименование расширения с .csv на .zzz действительно решило проблему. И не верьте Slade, двигать в нём файлы для изменения порядка загрузки в pk3 - бессмысленно, гзд их всё равно в алфавитном порядке прочтёт.
Правила 
Поиск
Консольный шрифт в юникоде, потому там стали показываться кракозябры вместо русских надписей.
