Конфигурационный файл - это просто XML-файл с соответствующим именем, со-
держащий набор необходимых тегов. Имя конфигурационного файла приложения
должно иметь следующий вид:
конфигурационный файл приложения myApplication.exe назван myApplication.
exe.coring. Конфигурационный файл должен располагаться в одном каталоге со
сборкой приложения, для настройки которого он предназначен.
Содержимое конфигурационных файлов определяется общей для этих файлов
схемой. Базовая структура конфигурационного файла выглядит так:
Обязателен только первый тэг, в котором указаны версия XML, используемая
кодировка и элемент
зательны и добавляются или удаляются по мере необходимости.
Чтобы создать конфигурационный файл для сборки, написанной на Visual Basic
.NET, выберите в меню File пункт Add New Item\Application Configuration File -
к проекту будет добавлен новый конфигурационный файл, в который можно вруч-
ную добавить необходимые элементы. При компиляции приложения файлу назна-
чается соответствующее имя.
При использовании Visual C# конфигурационный файл придется создавать и за-
полнять вручную при помощи текстового редактора (например, Блокнота). Гото-
вый конфигурационный файл следует сохранить с именем app.config и добавить к
проекту приложения.
Схема конфигурационного файла
Полностью обсудить схему конфигурационного файла в этом разделе на представ-
ляется возможным, но ее элементы верхнего уровня мы все же рассмотрим. Более
подробно об этом рассказано в документации по Visual Studio .NET. Элементы вер-
хнего уровня схемы конфигурационного файла описаны в таблице 9-1.
Таблица 9-1. Элементы верхнего уровня схемы конфигурационного файла
Элемент Что содержит
требуемую версию CLR
мусора
приложение использует криптографические технологии
> Создание конфигурационного файла для приложения на Visual Basic .NET
1. В меню Project выберите nyHKTAdd New Item - откроется одноименное окно.
2. В окне Add New Stem выберите шаблон Application Configuration File - к проек-
ту будет добавлен конфигурационный файл.
3. Внутри элемента < configuration > поместите элементы схемы для настройки не-
обходимых параметров. Более подробно о доступных элементах схемы - в доку-
ментации на Visual Studio .NET.
4. Сохраните созданный файл и скомпонуйте приложение.
> Создание конфигурационного файла для приложения на Visual C#
1. В меню Project выберите Add New Item.
2. В окне Add New Item выберите Text File - новый текстовый файл добавляется к
проекту и открывается в текстовом редакторе.
3. В окне Solution Explorer щелкните правой кнопкой новый текстовый файл и вы-
берите команду Rename, чтобы переименовать файл в App.config. В текстовом
редакторе добавьте к файлу следующий XML-код:
В окне Solution Explorer дважды щелкните файл App.config. Ответьте согласием
на вопрос о закрытии файла - среда разработки переключится в редактор с
XML-текстом файла App.config.
Файлы конфигурации используются для задания параметров настройки операционной системы. Они имеют несложную структуру и могут редактироваться вручную с помощью обычного приложения «Блокнот». Файлы конфигурации имеют расширение ini и могут содержать комментарии, пустые строки и различные параметры. Часто данный тип файлов используется для задания параметров загрузки.
Вам понадобится
- - права администратора.
Инструкция
; for 16-bit app support
CMCDLLNAME32=mapi32.dll
CMCDLLNAME=mapi.dll
MAPIXVER=1.0.0.1
Задание профиля с помощью командной строки – метод далеко не всегда удобный. Даже при работе с самой командной строкой используется окружение для сохранения настроек, чтобы не задавать их всякий раз и для всякой команды. Что уж говорить о сложных системных службах, свойства которых должны сохраняться не от сеанса к сеансу, а постоянно (в том числе при перезагрузке системы). Вывод прост: профиль необходимо держать в файле, вроде того, что создается по команде "сохранить настройки".
Однако сам подход к хранению профиля в файле, при котором пользователь не может изменять этот файл напрямую, а пользуется "умными" конфигураторами, удобен только в случаях, когда настроек много, а цена ошибки невелика (например, при настройке внешнего вида рабочего стола). В общем случае довольно сложно задать поведение системы на основании описания (часто неявного) свойств того, что эта система должна получать в результате . Иными словами, из описания того, что должно получиться, далеко не всегда можно автоматически сделать вывод, как оно должно получаться.
Конфигурационный файл . Текстовый файл, содержащий настройки какой-нибудь части системы (утилиты, демона и т. п.). Как правило, считывается ею при запуске. Типичный для Linux способ организации профиля .
Одним словом, если есть конфигурационный файл , то должны быть и средства редактирования этого файла. Учитывая, что в Linux реализована высокоразвитая система хранения и переработки (как ручной, так и автоматической) данных в текстовом виде, изобретать какой-то новый формат – все равно что изобретать велосипед. Тем более, что именно текст, разделенный на строки и слова, лучше всего подходит тогда, когда есть четкое деление профиля на объекты управления и их свойства (например, настройки какого-нибудь демона и значения этих настроек). Вдобавок, именно со структурированными текстами отменно управляются текстовые редакторы Linux: Vi, Emacs и др:
Methody@localhost:~ $ cat .vimrc so $VIMRUNTIME/vimrc_example.vim " Some mappings map:wall!^M map! ^O:wall!^M " Tune up set shiftwidth=2 tabstop=8 history=200 viminfo="50 set showmode showmatch showcmd ruler modeline set autoindent ignorecase smartcase set nohlsearch noincsearch set dir=/var/tmp set wildmode=list:longest,full set wildmenu " Colouring syntax on colorscheme desert Пример 12.2. Настройки редактора vim
Вот как выглядит конфигурационный файл для Vim , написанный Мефодием на основе файла, взятого у Гуревича. Легко заметить, что файл состоит из команд режима командной строки Vi с комментариями (в отличие от большинства утилит Linux, в Vi комментарии начинаются на """). Символы " ^O " и " ^M " – это именно соответствующие управляющие символы (вставленные в текстовый файл с помощью " ^V ", см. лекцию 9). Такой конфигурационный файл легко понимать и изменять.
Как уже было замечено, набор переменных окружения составляет особенный профиль , к которому чувствительны все запускаемые программы – в этом его достоинство. Задаются переменные окружения обычно в командном сценарии, который тоже можно рассматривать как конфигурационный файл ). Например, во многих дистрибутивах используется конфигурационный файл .i18n для настройки языковых особенностей клавиатуры, языка вывода сообщений и т. п. 2Обозначение "i18n" происходит от слова " internationalization ", в котором 20 букв, т. е. "i", "n" и 18 букв между ними. :
Methody@localhost:~ $ cat .i18n LANG=ru_RU.KOI8-R LANGUAGE=ru_RU.KOI8-R SYSFONTACM=koi8-r SYSFONT=UniCyr_8x16 DICTIONARY=russian MPAGE="-CKOI8-R" export DICTIONARY MPAGE Пример 12.3. Файл настройки языковых особенностей
Однако хранить настройки специфической программы (не нужные всем остальным) в окружении – не самое удачное решение: синтаксис, задающий переменную окружения , слишком прост (имя_переменной=значение ), а самих переменных становится слишком много, поэтому при просмотре трудно выделить, какая из них к какой группе настроек относится. Если пытаться упаковать все настройки в значение одной переменной, это значение окажется трудночитаемым, и все преимущество текстового формата сойдет на нет. Например, стандартный конфигурационный файл утилиты ls (точнее, только ее цветовых предпочтений) – /etc/DIR_COLORS (его можно подменить личным файлом ~/.dir_colors ) занимает около ста строк вместе с комментариями. Команда ls использует не этот файл, а создаваемую утилитой dircolors переменную LS_COLORS , значение которой – 600-символьная строка без всяких комментариев.
Если профиль слишком велик, держать его в одном конфигурационном файле – значит, доставлять пользователю сомнительное удовольствие разбирать этот файл целиком даже при необходимости внести минимальное изменение. Методов борьбы с неудобочитаемостью несколько. В частности, уже известный по лекции 10 механизм " .d ": файл разделяется на несколько независимых друг от друга файлов так, что редактировать приходится только один из файлов, а программа во время самонастройки считывает все.
Другой способ опирается на то, что изменения , которые пользователь вносит в профиль , как правило, существенно меньше объема всего профиля . Поэтому может быть выгодно хранить все настройки по умолчанию в каком-нибудь файле, менять который вообще не надо, а файл пользовательских настроек использовать как бы "поверх", изменяя профиль в соответствии с ними после того, как выставлен профиль по умолчанию. Дополнительное преимущество такого способа – в том, что пользователь всегда может подглядеть в "большой" файл, чтобы узнать, как оформляется та или иная настройка. Например, утилита updfstab, которая изменяет содержимое /etc/fstab при появлении или удалении съемного дискового носителя (например, лазерного диска), считывает данные из конфигурационного файла /etc/updfstab.conf . Сам этот файл состоит из единственной строки: include /etc/updfstab.conf.default , что приводит к чтению файла с настройками по умолчанию, где задан способ работы со многими съемными устройствами системы. Если администратору нужно как-то изменить поведение updfstab в отношении определенного устройства, он копирует соответствующую группу настроек из updfstab.conf.default в updfstab.conf после строчки include.. . и исправляет их. То, что эти группы настроек читаются дважды, не играет особой роли: чтение коротких файлов выполняется быстро.
Наконец, третий способ сделать конфигурационный файл удобочитаемым - секционирование профиля , когда все настройки разбиваются на группы, каждой группе дается собственное имя, и синтаксис конфигурационного файла проектируется так, чтобы границы групп хорошо различались при просмотре. В сущности, этот способ – предок схемы " .d ", где группе соответствует отдельный файл, однако нередки ситуации, когда разбивать на файлы неудобно (например, если группы не полностью независимы, поэтому может понадобиться редактировать их сразу несколько). Конфигурационный файл утилиты дозвона wvdial , например, секционируется по адресату (провайдеру) плюс отдельная секция "по умолчанию". Сами секции отделяются друг от друга заголовками, заключенными в квадратные скобки:
Root@localhost:~> cat .wvdialrc Modem = /dev/modem Baud = 115200 Init1 = ATZ Init2 = ATQ0 L0 M4 V1 E1 S0=0 &C1 &D2 +FCLASS=0 Auto DNS = on Modem Type = Analog Modem Phone = 0123456 Username = fireman Password = Fire!Fire! TOnline = true Phone = 0246813 Username = cop-120 Password = gimmethegun Force Address=10.0.0.120 Пример 12.4. Секционированный конфигурационный файл
Утилита wvdial обладает высокоразвитым искусственным интеллектом: она самостоятельно догадывается, какой именно тип идентификации используется на сервере. Например, "с той стороны" может оказаться терминал Linux, которому требуется сначала ввести обыкновенное входное имя и пароль, затем надо получить командную строку, запустить на сервере сетевой демон pppd , и только после этого запустить pppd на собственной машине. Другой вариант: pppd на сервере уже запущен, а настройки "Username" и "Password" означают идентификационную информацию протокола CHAP , используемого pppd . Обо всем этом и о многом другом wvdial способна догадаться,так же как wvdialconf умел определять, какое же из устройств является модемом.
Однако на любой искусственный интеллект найдется непостижимая ему жизненная ситуация. На одном из серверов (секция "Dialer hotspace") тоже стоит программа с зачатками искусственного интеллекта, которая тоже пытается определить, каким способом хочет идентифицироваться позвонивший. Оттого эти два кудесника, созвонившись, все ждут, пока кто-нибудь не проявит себя... Помогает настройка TOnline , которая заставляет wvdial немедленно задействовать протокол ppp , на что сервер, подумавши "ах, ppp!", с облегчением запускает pppd . Остается вопрос: почему эта полезная настройка никак не отражена в документации (ее нашел в исходных текстах программы Гуревич)? Не потому ли, что пара wvdialconf-wvdial не по-Linux-овски стремится все делать за пользователя, а стало быть, пользовательская документация для разработчиков этой программы – не главное?
Идею чтения настроек по умолчанию можно развить. Оказывается, бывает удобно, когда описание настройки помещено не в руководство, а непосредственно в конфигурационный файл в виде комментариев. Тогда при изменении этой настройки пользователь сразу видит, что она собой представляет, при этом отпадает необходимость сначала находить строчку в файле, а потом искать ее же в руководстве. Такой распространенный способ оформления называется самодокументированием профиля . Например, файл /etc/man.conf , управляющий работой команды man , оформлен в самодокументированном стиле:
Methody@localhost:~ $ cat /etc/man.conf . . . # NOCACHE keeps man from creating cache pages ("cat pages") # (generally one enables/disable cat page creation by # creating/deleting the directory they would live in – man # never does mkdir) # # NOCACHE # The command "man -a xyzzy" will show all man pages for xyzzy. # When CMP is defined man will try to avoid showing the same # text twice. (But compressed pages compare unequal.) # CMP /usr/bin/cmp -s . . . Пример 12.5. Самодокументированный конфигурационный файл
Мефодий, может быть, и не понял бы сразу, зачем команде man использовать утилиту cmp, однако в поясняющем комментарии написано: когда нужно показать несколько руководств разом, они предварительно сравниваются, и показываются только несовпадающие.
Если пойти еще дальше, то можно создать несколько различных файлов с примерами настроек, чтобы пользователь мог взять один из них и довести до нужного ему состояния. Именно такую – демонстрационную – настройку Мефодий и включил в качестве настройки по умолчанию в свой .vimrc (в первой строке). Кстати, на самом деле профиль Vim весьма сложен, но большинство его настроек по умолчанию находятся в различных файлах дерева каталогов /usr/share/ vim – эдакая "схема .d/.d ", где файлы профиля , соответствующие подгруппам настроек, лежат в подкаталогах, соответствующих группам. Включение определенного настроечного файла может происходить неявно: например, строчка colorscheme desert из .vimrc приводит к чтению /usr/share/ vim /colors/desert. vim .
Конфигурационные файлы могут иметь довольно замысловатый синтаксис, если соответствуют сложным структурам данных (таковы, например, настройка irc-клиента irssi ) или содержать в себе дополнительные средства самодокументирования (например, файл настройки текстового www-броузера lynx не просто хорошо документирован, но и размечен теми же средствами, какие используются в самом броузере для представления HTML).
etconfig.cfg - основной конфигурационный файл.etconfig.cfg - это главный конфигурационный файл, в котором находятся все настройки игры.
Он создается вместе с профилем (profile ) игрока и по умолчанию находится в папке etmain/profiles , либо в папке того мода, из-под которого Вы играете, например: etpro/profiles . См скриншот:
Самый простой и быстрый способ изменить значения переменных - это изменить их прямо в нем с помощью любого текстового редактора.
Но это неудобный и ненадежный способ, т.к. настройки будут постоянно "слетать".
Самый удобный способ - это создать свой конфигурационный файл с помощью файла autoexec.cfg .
autoexec.cfg - самый удобный способ создать свой Конфиг.
autoexec.cfg
- это файл, который автоматически выполняется, когда Вы заходите в игру.
Соответственно, все команды, указанные в нем будут выполнены при подключении к серверу.
Создается он очень просто: с помощью Блокнота , WordPad"a , Word"a или другого текстового редактора необходимо создать Текстовый документ , а затем просто переименовать его в файл autoexec.cfg .
Тут следует сказать, что максимальный размер конфигурационного файла не должен превышать 16 кб
, и вряд ли все Ваши настройки переменных, скрипты и бинды поместятся в один файл.
Поэтому удобнее всего создать несколько конфигов и прописать их выполнение в autoexec.cfg
.
Т.е., например, можно создать файлы settings.cfg, scripts.cfg и binds.cfg и прописать в них свои настройки. Выглядит это примерно так:
Затем прописать в autoexec.cfg их выполнение, например, так:
Файл autoexec.cfg должен быть помещен в папку etmain , только тогда он будет выполняться игрой во всех модах.
Если Вы поместите его, например, в папку etpro , то он будет выполняться только на серверах, использующих этот мод. Но, поскольку большинство серверов используют именно этот мод, то это не критично...
Файлы settings.cfg , scripts.cfg , binds.cfg могут быть помещены в папку etmain , либо в любую подпапку в папке etmain , но путь к этой подпапке необходимо прописать в файле autoexec.cfg .
Т.е., например, Вы можете создать в папке etmain подпапку config , поместить туда файлы settings.cfg , scripts.cfg , binds.cfg , а в файле autoexec.cfg прописать путь к этой подпапке, например, так:
В итоге получаются 4 файла, которые и являются Вашим "Конфигом ":
Примечание: Удобнее всего создавать свой конфиг, используя готовые примеры, скачать которые Вы можете, например, отсюда .
autoexec_side.cfg - конфигурационный файл для каждой стороны.
Вы можете также создать конфигурационные файлы для allies , axis или spectator , которые будут выполняться, когды Вы зашли за команду allies или axis , либо вышли в spectator , соответственно.
Выглядят они следующим образом:
autoexec_allies.cfg
autoexec_axis.cfg
autoexec_spectator.cfg
autoexec_map name.cfg - конфигурационный файл для каждой карты.
Вы можете также создать конфигурационный файл для каждой карты, который будет выполнен, когда загружена соответствующая карта.
Создаются такие файлы так же как файл autoexec.cfg , и таким же образом помещаются в папку etmain .
Такие конфигурационные файлы позволяют прописать для каждой карты свои настройки, например:
уровень яркости - r_gamma
,
уровень освещенности - r_mapoverbrightbits
,
уровень интенсивности освещения - r_intensity
и т.д.
Также с их помощью можно создать скрипты для выбора SpawnPoint"а (Места респавна) для каждой карты и другие полезные вещи.
autoexec_battery.cfg
autoexec_braundorf_b4.cfg
autoexec_et_beach.cfg
autoexec_et_ice.cfg
autoexec_goldrush.cfg
autoexec_fueldump.cfg
autoexec_oasis.cfg
autoexec_supplydepot2.cfg
autoexec_sw_goldrush.cfg
autoexec_sw_goldrush_te.cfg
autoexec_sw_oasis_b3.cfg
и т.д., в зависимости от названия карты.
Если для карты не существует конфигурационного файла, то ею автоматически используется файл autoexec_default.cfg , поэтому Вам необходимо создать такой файл и прописать в нем настройки по умолчанию, чтобы они использовались на тех картах, для которых Вы не сделали отдельный autoexec_map_name.cfg .
autoexec_class.cfg - конфигурационный файл для каждого класса игрока.
Вы можете также создать конфигурационный файл для каждого класса игрока, который будет выполнен, когда Вы вступите в игру соответствующим классом.
Создаются такие файлы также как файл autoexec.cfg , и таким же образом помещаются в папку etmain .
Такие конфигурационные файлы позволяют прописать различные настройки для каждого класса игрока.
Например, Вы можете назначить различные бинды для разных классов, что является очень удобной возможностью.
Выглядят эти файлы следующим образом:
autoexec_covertops.cfg
autoexec_engineer.cfg
autoexec_fieldops.cfg
autoexec_medic.cfg
autoexec_soldier.cfg
