Решил я тут поглядеть на Disciples 3. Игра красивая, занятная. Ставится вообще без бубна и идёт лучше пятых героев (правда, с nodvd от triviuma, который для hotfix 8, игра не запускается вообще, и юзать надо что-то предыдущее, например, nodvd для 5-го хотфикса; однако, сейвы работать не будут; c 7-м - вылетает при заходе в режим строительства). Вообще, насколько я понял, игру допилят только к выходу европейской версии. По причине того, что без сейвов играть скучно (и спустя часа эдак 3 пропали текстуры земли в главном режиме) я решил глянуть вторую часть. О чём и пойдёт речь в данной заметке.
Итак, последняя часть у нас именуется "Восстание эльфов" (Rise of the elves). Аддон этот не требует наличия ничего кроме свободного места на диске. Перед установкой я, дабы не наступить лишний раз на грабли, примонтировал оба образа (образы от Руссобит-М) и скопировал содержимое в отдельную папку, из которой уже и производил установку. Ставится оно без шуму и пыли.
Вообще говоря, по поводу установок виндовых игр/приложений. Если игра требует каких - либо вендовых либ: будть то директиксовые либы, или что-нибудь типа msvbvm60.dll; или же требует наложения патчей на какие-либо элементы самого вайна, то для такого приложения лучше завести отдельное окружение:
env WINEPREFIX="/home/username/.wine_appname" winecfg
Соответственно, для запуска бинарника, например, установочного нужно писать следующее:
env WINEPREFIX="/home/username/.wine_appname" wine setup.exe
Ну ты понел.
Для всех программ, использующих MS .NET Framework лучше завести окружение типа ~/.wine_dotnet и все эти программы ставить в него.
Софт же, который не требует никаких лишних телодвижений, изменений реестра и прочего прочего, лучше ставить в окружение по умолчанию (~/.wine). Так и установщики пускать проще (простым двойным тычком) и свободного места на диске больше.
Для игры, являющейся предметом разговора, нужно завести отдельное окружение (напр. ~/.wine_disciples2). Для тех кому надо только команды посмотреть:
env WINEPREFIX="$HOME/.wine_disciples2" winecfg
$HOME - это переменная окружения, которая содержит полный путь до домашней директории текущего пользователя. Интерпретатор автоматически заменяет её на соответствующее ей значение. То есть, фактически, вышеуказанная команда "введётся" так: env WINEPREFIX="/home/username/.wine_disciples2" winecfg, где username - имя вашей учётной записи.
Создавать отдельное окружение для disciples 2 необходимо, так как данное приложение не работает без эмуляции виртуального рабочего стола. Поэтому, в winecfg переходим во вкладку "графика" и включаем эмуляцию рабочего стола, например, 1024х768.
Если не включить эмуляцию рабочего стола, то при попытке запустить Disciples 2 вы скорее всего услышите музыку заставки, но не увидите никакой картинки (на экране будет изображено последнне, что было на нём до запуска игры).
После успешной установки игры необходимо сначала её настроить. Для этого запускаем соответствующий бинарник:
env WINEPREFIX="$HOME/.wine_disciples2" wine "C:\путь_до_папки_с_игрой\ConfigEditor.exe"
Если вы создали ярлык на рабочем столе, то всю команду можно скопировать из него, заменив, конечно, Discipl2.exe на ConfigEditor.exe. В настройках игры необходимо включить поддержку Direct3D (иначе ролики, главное меню будут не на весь экран, и в игре будет тормозить мышка). Выставляем также соответствующее рабочему столу разрешение. Например, 1024х768. Да, и игра у нас должна быть на полный экран, а не в окне. Иначе вы встретите сообщение "Can't initialize Disciples 2".
За сим всё. Игра запускается и играется без нареканий.
Теперь пара слов об издании Disciples 2 Gold от Акеллы. Установщик игры не производит копирования целой кучи весьма важных файлов (на данной стадии даблтык по ярлыку на рабочем столе не приводит вообще ни к чему). Поэтому, после окончания установки игры необходимо скопировать по соответствующим местам файлы из папки data на диске с игрой. После того, как скопируете, нужно перейти файловым менеджером в папку с игрой, и внимательно посмотреть, что же там скопировалось (ибо теперь при попытке запустить игру вылетает сообщение "Can't initialize Disciples 2"). Поскольку никсы система регистрозависимая, вы там увидите такие папки как Globals и globals, Interf и interf и так далее. Собственно говоря, переносим файлы из папки с маленькой буквы в соответствующую папку с большой и удаляем пустую. У меня ещё папка Video была с маленькой буквы. Я это дело поправил. После чего игру можно запускать.
Да, конечно, nocd/nodvd наше всё.
Живи и процветай!
четверг, 11 марта 2010 г.
воскресенье, 7 марта 2010 г.
Прыгающий нод lirc'а
Вечно забываю поститься тут. Буду навёрстывать.
Данная заметка всецело пригодиться пользователям пультов дистанционного управления для своих электронно-вычислительных машин (напр. продукция фирмы avermedia). Пользователи, активно использующие данные девайсы, наверняка сталкивались с внезапно не реагирующим на манипуляции курсором мыши прямо сразу после загрузки иксов и, всё так же внезапно, своей машиной, напрочь не реагирующей на команды, посылаемые с, собственно, ПДУ.
Вышеописанную проблему можно решить двумя способами:
1. Перетыкнуть (отсоединить-подсоединить) манипулятор типа "мышь". Мышка сразу заработает. Делать cat на всяческие /dev/input/event* и смотреть, реагирует ли оно на нажатия клавиш на ПДУ. Найденный прописать в /etc/conf.d/lircd и перезапустить lircd. Не забыть запустить офигевший от не того девайса irexec. Пульт работает. Повторять по мере необходимости и надеятся, что когда-нибудь оно само рассосётся.
2. Первый способ, конечно, действенный, но от него, почему-то, очень быстро устаёшь. :) Поэтому, легче всего немножко разобраться во всём этом.
Вообще говоря, раньше была очень удобоваримая нода типа pci-blablabla-blabla-event-ir, лежала она по адресу /dev/input/by-path/ и никуда она оттуда не девалась. Поэтому проблемы не существовало. Однако, после очередного когда-то произведённого emerge -DNu world данная проблема себя проявила: статическая нода исчезла и файлик конфигурации lirc'а пришлось исправить на event4 (например 4, у вас может быть, и скорее всего, будет по-другому). Собственно, работало оно очень долго, до очередного апдейта, после которого уже индекс ноды генерился как Бог на душу пошлёт (в порядке, в котором девайсы появляются в системе).
К чему я это? Да к тому, что если снова сделать статический нод и прописать его в соответствующем месте в /etc/conf.d/lircd то о проблеме можно будет забыть (хотя бы до следующего апдейта xD). Сделать такое можно при помощи udev'a (почитать о нём можно на сайтах и в манах).
Итак, в кратце, удев у нас строго следует определённым правилам. Правила эти лежат в каталоге /etc/udev/rules.d/. Если там уже есть файл 10-local.rules, то писать новое правило можно в него. В противном случае создаём указанный файл самодержавно. Что же в него писать? Для начала нужно найти правильный event* в каталоге /dev/input/. Делаем cat /dev/input/event4 (тыкайте табом и смотрите, какие там есть, перебирайте), тыкаем кнопки на пульте. Если в консоле появляется вывод - вы нашли верный файл устройства.
Для удобства изложения, положим, event4 - файл верный. Вы же, далее по тексту, вместо event4 представляйте свой вариант верного имени.
Затем выполняем следующую команду (фактически - две команды): udevadm info -a -p `udevadm info -q path -n /dev/input/event4` (это не одинарная кавычка, а штрих, который находится на одной кнопке с тильдой и буквой "Ё"; набирается в английской раскладке; текст, обрамлённый данными знаками интерпретируется интерпретатором как отдельная команда; можно подставлять в иные команды; детально об этом можно почитать в книжках по интерпретатору Борна, например). В выводе данной команды нас интересуют параметры первого parent (родительского) девайса (в случае использования пульта ДУ через/от tv-тюнер(а)). Нужна нам строчка ATTRS{name} (у меня оно выглядит так: ATTRS{name}=="bttv IR (card=41)"). Копируем данную строчку в буфер обмена. Далее возвращаемся к нашим баранам. То есть, открываем/создаём файл /etc/udev/rules.d/10-local.rules и пишем в него следующее:
KERNEL=="event*", ATTRS{name}=="bttv IR (card=41)", SYMLINK+="irremctrl"
Обратите внимание: никаких переносов, ибо удев расценит перенесённую на другую строку часть как отдельное правило, и получится ноое знает что. Вместо ATTRS{name}=="bttv IR (card=41)" вставляем из буфера ту самую строчку, что скопировали в него ранее. По-русски данное правило звучит следующим образом: когда (если) в системе появится устройство, проименованное ядром как event*, у которого атрибут "имя" соответствует bttv IR (card=41) - создать дополнительный (прирастить) симлинк irremctrl (в каталоге /dev). Теперь остаётся только перезапустить удев (/etc/init.d/udev restart). После перезапуска удева появится новая нода: /dev/irremctrl. Открываем /etc/conf.d/lircd и в соответствующем месте, вместо чего-то типа
LIRCD_OPTS="--driver=dev/input -d /dev/input/event4 /etc/lircd.conf"
Прописываем что-то типа
LIRCD_OPTS="--driver=dev/input -d /dev/irremctrl /etc/lircd.conf"
То есть меняем /dev/input/event4 на /dev/irremctrl.
Перезапускаем lircd и запускаем irexec, конечно.
Вот и всё.
Живи и процветай!
Данная заметка всецело пригодиться пользователям пультов дистанционного управления для своих электронно-вычислительных машин (напр. продукция фирмы avermedia). Пользователи, активно использующие данные девайсы, наверняка сталкивались с внезапно не реагирующим на манипуляции курсором мыши прямо сразу после загрузки иксов и, всё так же внезапно, своей машиной, напрочь не реагирующей на команды, посылаемые с, собственно, ПДУ.
Вышеописанную проблему можно решить двумя способами:
1. Перетыкнуть (отсоединить-подсоединить) манипулятор типа "мышь". Мышка сразу заработает. Делать cat на всяческие /dev/input/event* и смотреть, реагирует ли оно на нажатия клавиш на ПДУ. Найденный прописать в /etc/conf.d/lircd и перезапустить lircd. Не забыть запустить офигевший от не того девайса irexec. Пульт работает. Повторять по мере необходимости и надеятся, что когда-нибудь оно само рассосётся.
2. Первый способ, конечно, действенный, но от него, почему-то, очень быстро устаёшь. :) Поэтому, легче всего немножко разобраться во всём этом.
Вообще говоря, раньше была очень удобоваримая нода типа pci-blablabla-blabla-event-ir, лежала она по адресу /dev/input/by-path/ и никуда она оттуда не девалась. Поэтому проблемы не существовало. Однако, после очередного когда-то произведённого emerge -DNu world данная проблема себя проявила: статическая нода исчезла и файлик конфигурации lirc'а пришлось исправить на event4 (например 4, у вас может быть, и скорее всего, будет по-другому). Собственно, работало оно очень долго, до очередного апдейта, после которого уже индекс ноды генерился как Бог на душу пошлёт (в порядке, в котором девайсы появляются в системе).
К чему я это? Да к тому, что если снова сделать статический нод и прописать его в соответствующем месте в /etc/conf.d/lircd то о проблеме можно будет забыть (хотя бы до следующего апдейта xD). Сделать такое можно при помощи udev'a (почитать о нём можно на сайтах и в манах).
Итак, в кратце, удев у нас строго следует определённым правилам. Правила эти лежат в каталоге /etc/udev/rules.d/. Если там уже есть файл 10-local.rules, то писать новое правило можно в него. В противном случае создаём указанный файл самодержавно. Что же в него писать? Для начала нужно найти правильный event* в каталоге /dev/input/. Делаем cat /dev/input/event4 (тыкайте табом и смотрите, какие там есть, перебирайте), тыкаем кнопки на пульте. Если в консоле появляется вывод - вы нашли верный файл устройства.
Для удобства изложения, положим, event4 - файл верный. Вы же, далее по тексту, вместо event4 представляйте свой вариант верного имени.
Затем выполняем следующую команду (фактически - две команды): udevadm info -a -p `udevadm info -q path -n /dev/input/event4` (это не одинарная кавычка, а штрих, который находится на одной кнопке с тильдой и буквой "Ё"; набирается в английской раскладке; текст, обрамлённый данными знаками интерпретируется интерпретатором как отдельная команда; можно подставлять в иные команды; детально об этом можно почитать в книжках по интерпретатору Борна, например). В выводе данной команды нас интересуют параметры первого parent (родительского) девайса (в случае использования пульта ДУ через/от tv-тюнер(а)). Нужна нам строчка ATTRS{name} (у меня оно выглядит так: ATTRS{name}=="bttv IR (card=41)"). Копируем данную строчку в буфер обмена. Далее возвращаемся к нашим баранам. То есть, открываем/создаём файл /etc/udev/rules.d/10-local.rules и пишем в него следующее:
KERNEL=="event*", ATTRS{name}=="bttv IR (card=41)", SYMLINK+="irremctrl"
Обратите внимание: никаких переносов, ибо удев расценит перенесённую на другую строку часть как отдельное правило, и получится ноое знает что. Вместо ATTRS{name}=="bttv IR (card=41)" вставляем из буфера ту самую строчку, что скопировали в него ранее. По-русски данное правило звучит следующим образом: когда (если) в системе появится устройство, проименованное ядром как event*, у которого атрибут "имя" соответствует bttv IR (card=41) - создать дополнительный (прирастить) симлинк irremctrl (в каталоге /dev). Теперь остаётся только перезапустить удев (/etc/init.d/udev restart). После перезапуска удева появится новая нода: /dev/irremctrl. Открываем /etc/conf.d/lircd и в соответствующем месте, вместо чего-то типа
LIRCD_OPTS="--driver=dev/input -d /dev/input/event4 /etc/lircd.conf"
Прописываем что-то типа
LIRCD_OPTS="--driver=dev/input -d /dev/irremctrl /etc/lircd.conf"
То есть меняем /dev/input/event4 на /dev/irremctrl.
Перезапускаем lircd и запускаем irexec, конечно.
Вот и всё.
Живи и процветай!
Подписаться на:
Сообщения (Atom)