zoromo777 У меня русская. Если выбрать Auto, то у меня интерфейс становится английским.
Но вот вики пишет, что cvar language = "auto" выбирает подходящий язык в соответствии с языком системы:
If it is "auto" or unknown, the settings in the Regional Settings control panel will be used to determine an appropriate language.
Из GZDoom удалили автоматическое задание языка. Подробности можно найти в этой теме, а точнее:
Graf Zahl:
Undead:
I got this idea from seeing a user in the ZDoom Discord server wrestle with GZDoom after it automatically detected the system language as Russian, even though it was set to English. I’m not sure what exactly happened there, but the autodetection feature seems a bit clunky to me, and perhaps even intrusive.
The language autodetection on Windows reads the system language. I am not really sure this is a good idea with an engine that can never guarantee complete and seamless translation and I'll most likely disable this feature for the 4.0 release.
Т.е. в вышеупомянутой теме я предложил добавить возможность выбрать язык прямо в лаунчере, но от этой идеи отказались. При этом, в аналогичной теме возникло небольшое обсуждение о полезности auto-язык, а потом в итоге его отключили.
Это хорошо. А то я заливал очередной свой репак на торренты который содержал этот UDV HUD. Тестируя случайно включил русский язык и тут заметил вылеты из-за конфликта того мода и перевода. Думал надо будет править конфиг, все перезаливать и опять сидировать. А оказалось вот как.
ребята всем привет в общем наладил свой ноут, вернул вин 7 и поставил дрова на HD graphic 3000, заработала винтажка версии 3.7.2 но при завершении уровня, даже просто дум2 без модов и карт вылетает с такой ошибкой
Mostcus Как вариант, можешь в папке портом временно переименовать gzdoom-имя пользователя.ini файл, и порт сбросит все настройки создав новый. А затем из старого строку за строкой перетаскивать, либо быстро занаво настроить. У меня так было только когда я с решейдом сохранёнки делал и он захватывал превью с оверлеем, который работал криво. Но чтобы из-за настроек просто. Похоже именно на влияние пост-процессинга. Но то лишь возможно.
временно переименовать gzdoom-имя пользователя.ini файл, и порт сбросит все настройки создав новый. А затем из старого строку за строкой перетаскивать
А кстати есть какой-нибудь трик по быстрому избирательному переносу конфигов из .ини предыдущей гоззы в новую? Ключевые слова здесь "быстрому" и "избирательному", ибо копипаст настроек из старой версии в новую нифига не быстро и не удобно, а для некоторых перенастройка конфигов непосредственно в игре и вовсе окажется быстрее.
ЕМНИП, Думсдэй\Зандро давно уже умеют в экспорт конфигов.
Void Weaver Ну не знаю. Что может быть быстрее удаления/замены всего каталога изнутри кроме ini и установки порта туда же. Уже сколько версий сменил, всегда банально распаковываю пак с гозой прямо в каталог. При первом же запуске читается ini который там лежал до этого.
А так exec, но есть беда, его сначала нужно написать, а у него отличается структура от ini, так что исполнять ini файл не получится. То есть прописать все интересующие настройки + настройки модов каких то отдельно и затем либо при запуске в батнике, либо в самой консоле исполнять файл конфы (cfg, если не ошибаюсь)
Ну не знаю. Что может быть быстрее удаления/замены всего каталога изнутри кроме ini и установки порта туда же. Уже сколько версий сменил, всегда банально распаковываю пак с гозой прямо в каталог. При первом же запуске читается ini который там лежал до этого.
А так exec, но есть беда, его сначала нужно написать, а у него отличается структура от ini, так что исполнять ini файл не получится. То есть прописать все интересующие настройки + настройки модов каких то отдельно и затем либо при запуске в батнике, либо в самой консоле исполнять файл конфы (cfg, если не ошибаюсь)
Хз как у других но с 2017 у меня как минимум 5 .ини с настройками разных версий гоззы вызывали краши, баги и лаги (в частности пресловутые gl_lights_intensity\size). С некоторых пор я перестраховки ради просто стал каждый раз перенастраивать чистый конфиг. Но это маленько задалбывает.
Ну какбэ не все умеют\осилят в напейсание всех конфигов от контролсов до рендера ручками.
Всем доброго времени суток!
Решил я собрать последнюю версию порта под Linux. Поставил зависимости, запустил сборку. Всё собралось, и даже запустилось. Но.
В Brutal Doom отсутствуют звуки выстрелов. Совсем. Я глянул в консоль, а там вот такое вот:
Note: Hit end of (available) data during resync.
[src/libmpg123/parse.c:1028] error: cannot seek!
Note: Illegal Audio-MPEG-Header 0x00000000 at offset 4341.
Note: Trying to resync...
Note: Hit end of (available) data during resync.
То есть, libmpg123 пытается переваривать семплы в OGG, которые, по идее, должен переваривать libsndfile. ВОпрос - почему?
Собирал по инструкции на оф. вики.
Сначала была сборка где-то середины-конца прошлого года, потом решил снова поиграть, скачал последнюю от 02.07.2019 - и при запуске хп тупо уходила в 0 за треть секунды и надпись "player killed himself". Сначала долго копал, даже создал issue, и пробовал более ранние коммиты, чтоб потом понять, где был затык.
Но как оказалось, затык был в том, что в gzdoom.ini остались строки drpg_ от старых сборок, и что-то конфликтовало. Вычистил и всё ок
Вот кстати такие писцы тоже заглядывают в грязный ини. И как в таких случаях отлавливать косяк? Правильно, по-человечески никак, проще обнулять конфиг.
Писать там нечего. Всё берётся из ini файла, только кавычки убираются и ещё что-то. Короче, разобраться 3 минуты дело.
Полагаю это если речь только о контролсах, да? А что насчёт переброски остальных опций? Причём не забываем что придётся прописывать конфиги для каждой игры.
Кому нибудь известно в каком билде гоззы реализованы тени от нижних/верхних поверхностей? Видел скриншот ZZYZX'а, отосланный Nash'ем, где это уже реализовано
Полагаю это если речь только о контролсах, да? А что насчёт переброски остальных опций?
как я понимаю, в CFG тот же синтаксис, что и в консоли (тобишь всё что можно в консоли, можно и в CFG), а в консоли можно выставить любую опцию (не только бинды)
В общем ясно, нормального решения значит нет. А жаль.
Я не совсем понял - а какое теоретическое решение ты хотел? Если для игры без модов требуются настройки А, а для игры с модами требуются настройки Б - каким образом даже теоретически ты хотел их пихать в один единственный конфиг?
Создается несколько CFG, и дальше либо через консоль подгружаешь exec blablabla.cfg либо через батники
В чем проблема?
Причем я НЕ имею в виду, что надо копировать полные копии INI файлов. Я имею в виду следующее:
1) Твой INI будет базовый, там будет 100% настроек, 80% из которых будут одинаковы для любых модов
2) Твои CFG будут "дополнительными", в каждом из них будет по 10-20 настроек (примерно 1% из всего INI), для каждого конкретного мода. Т.е. в CFG только те настройки, которые отличаются от базового INI (полная копия INI не нужна)
Если же ты хочешь, чтобы для игры как с модами так и без, не требовались разные настройки, то это не проблема конфигов как таковых - это проблема архитектуры порта и/или модов
С другой стороны, я не вижу в этом проблемы, так как ЕСЛИ:
1) для игры "в ваниллу" на кнопку 8 у меня забиндена бензопила (стандартный ванильный бинд), а с модом "quake doom arena" на 8 будет забинден рейлган, так как в моде он есть, а в ванилле его нет
ИЛИ
2) в ванильном думе у меня маузлук, прыжки и конечная высота монстров отключены, а в моде/маппаке "cfg of sin" все это включено, так как геймплей маппака дизайнится с учетом возможности прыгать и смотреть вверх вниз, а также пробегания над/под монстрами
ТО меня такой расклад вполне устраивает, так как это вписывается в логику и здравый смысл имхо. По такой же аналогии и остальные опции звука, графики, геймплея и т д (если с опцией А в значении А1 ванилла выглядит лучше, а в значении А2 мод выглядит лучше, то для ваниллы поставлю А1, а для мода А2).
Как сделать по другому (чтобы с одинаковыми опциями было хорошо везде, и в ванили и в модах), я не знаю даже теоретически
P.S. Тут уместно вспомнить ролик ветерана https://www.youtube.com/watch?v=r6NhH840X1M про рендеры, где упоминается, что некоторые карты дизайнятся под софтвар, а некоторые под opengl (соответственно для софтварных карт делаем CFG с софтварными настройками рендера, а для опенглных с опенглными настройками). Ну или забиваем болт, и играем на всех картах на опенгл и не паримся о слишком темных комнатах и прочих результатах несовместимости задумки автора с результатом у тебя на экране
В общем ясно, нормального решения значит нет. А жаль.
Я не совсем понял - а какое теоретическое решение ты хотел? Если для игры без модов требуются настройки А, а для игры с модами требуются настройки Б - каким образом даже теоретически ты хотел их пихать в один единственный конфиг?
есть какой-нибудь трик по быстрому избирательному переносу конфигов из .ини предыдущей гоззы в новую? Ключевые слова здесь "быстрому" и "избирательному", ибо копипаст настроек из старой версии в новую нифига не быстро и не удобно
Если говорить о реквесте как об УЖЕ существующей опции порта или существующей тулзе то я видел это следующим образом:
запускаем гоззу =>
открываем опции =>
на каждой вкладке (включая низлежащие) видим 2 строки, что-то типа: "Export configs from current page to" и "Import configs for current page from" =>
каждая из команд выполняет одноимённые действия, т. е. экспортирует\импортирует соответствующие для текущей вкладки настройки в\из внешнего автоматически создаваемого\считываемого файла.
Т. е. я явно выразился что мне нужно решение "плаг энд плэй", тогда как вы с кибером рекомендуете "мэйк, зен плаг энд плэй". Т. е. те же яйца только в профиль, с пожалуй единственной разницей лишь в отсутствии регулярной необходимости каждый раз повторять процесс настройки.
Создается несколько CFG, и дальше либо через консоль подгружаешь exec blablabla.cfg либо через батники
В чем проблема?
Причем я НЕ имею в виду, что надо копировать полные копии INI файлов. Я имею в виду следующее:
1) Твой INI будет базовый, там будет 100% настроек, 80% из которых будут одинаковы для любых модов
2) Твои CFG будут "дополнительными", в каждом из них будет по 10-20 настроек (примерно 1% из всего INI), для каждого конкретного мода. Т.е. в CFG только те настройки, которые отличаются от базового INI (полная копия INI не нужна)
Это всё прекрасно но ты не понял: мне абсолютно насрать на конфиги под конкретные моды (хотя это тоже толково), мне как раз нужна возможность быстро ресать базовый .ини под СВОИ настройки, тогда как на данный момент порт в лучшем случае позволяет только возвращаться к исходным настройкам, что по сути эквивалентно физическому удалению конфиг.ини.
Дальше даже комментировать не буду, ибо ты явно не понял зачем мне это нужно. Если совсем на пальцах то это мне нужно для бэкапа собственных конфигов, и импорта оных между разными версиями порта.
Я даже ТОЛЬКО ЧТО привёл в качестве пруфа цитату _QuirK_'а как пример того каким макаром замусоренный конфиг может ломать игру, а точнее конкретный мод в данном случае. Так вот подобная фича позволила бы в любой момент кильнуть "подозрительный" .ини и быстро восстановить все ранее сохранённые настройки, без шаманства с надстройками кастомных кфг или ручной перенастройки всех конфигов из самой игры.
И повторюсь, речь не только о сэйв\лоаде контролсов но также о сэйв\лоаде любых других настроек типа формата экрана, разрешения, ЦВарок рендера, худа, и проч. Так вот если вы мне предлагаете это всё тоже перетаскивать вручную в кастомный автоэкзек или под батник "своей мечты" то я слишком ленив для подобного дерьма. :[
Насколько я понял, преобразорвать INI в CFG можно адекватным скриптом автозамены (но перед этим удалив лишние строки), и после этого у тебя будут готовые CFG для каждой версии порта
Notice:The survey has been re-enabled for this version so that we can get some information about how the state of systems being used for GZDoom has developed over the last year. We would like to ask as many users as possible to participate, so that we can make the right decisions based on the information we obtain. Like previous surveys this does not collect any private information - all it sends is basic info about the operating system, the number of CPU cores, the graphics card and supported OpenGL/Vulkan versions.
Предлагаю, во-первых, переименовать тему в "GZDoom / QZDoom / LZDoom", во-вторых, добавить на сам сайт iddqd.ru, в раздел "Новый Doom", этот самый LZDoom.
Плюсую.
Но разве QZ не мёртв? Я таки понял что отныне фичи кузи пилятся непосредственно в модерн-гоззе, а LZ квалифицируется как легаси-гозза и разрабатывается независимо от модерна.
Небольшие новости от графа по поводу планов на поддержку OpenGL и старых систем:
Скрытый текст:
Some first trend from the survey about operating system use. Linux and Mac haven't picked up yet because the downloads are either fresh or not present yet.
For Windows it looks like this:
~78% use Windows 10 64 bit
~16% use Windows 7 or 8 64 bit
-4.5% use the 32 bit build on a 64 bit system (why, oh why does this number not decrease...? )
1.75% use a real 32 bit OS.
The GZDoom 3.5 survey around the same time had ~3.5% users on a true 32 bit system, this has decreased by half!
It takes no rocket science to see that it won't take too long anymore to discontinue 32 bit support - it hasn't full feature parity anyway anymore (no Vulkan, no JIT) and it seriously blocks a feature that has been requested by some users: 64 bit integer support in the VM. While theoretically this could be done in 32 bit, it'd require a lot more work there than for 64 bit - so much more in fact that it's out of the question to implement it in a 32 bit compatible way -, so whenever this feature comes, 32 bit will be history - with the current numbers I'd say the right time will be after Christmas when a large number of older systems gets retired again.
Other numbers are less interesting, the only other important number is that the percentage of non-Vulkan compatible systems is roughly 18%, 1/10th of which only are incompatible due to old drivers. Like 32 bit above, this is half of what it was in the 3.5 survey after a comparable number of reports. This, of course, is nowhere near being discontinued, but seeing that at least AMD has been reported to begin winding down OpenGL support in their drivers it is only a matter of time until OpenGL has to be dropped. But this will most likely be decided by external factors than shrinking user base. Right now I'd give it 4 years, maybe, until OpenGL becomes a liability.