Создание CFG файла для простой детали 


Мы поможем в написании ваших работ!



ЗНАЕТЕ ЛИ ВЫ?

Создание CFG файла для простой детали

Создание IVA

alexustas

 

Выдалась свободная "минутка" (т.е. часа полтора-два) и я решил опять написать тутор по созданию IVA
В качестве наглядного пособия я буду использовать свою капсулу A.L.C.O.R.

Итак,
Intra-Vehicular Activity
aka
Внутрикорабельная деятельность

В контексте игры, этот термин подразумевает пребывания игрока внутри командного (или просто, обитаемого) модуля, и, до недавнего времени, никакого толка от этого пребывания, по сути, не было. но мы сейчас не об этом...
КЭП всегда рад помочь, и подсказать, что для того, чтобы в чем-то где-то пребывать, нужно сначала "Это/где-то" создать. Вот об этом мы сейчас и поговорим.

Давай разберемся, "что" тут "где" и "когда".
В КСП, Обитаемый (а как правило он же и Командный, но это не обязательно) модуль состоит из ТРЕХ независимых компонентов:
1. Внешняя (external) модель - это то, что мы видим в ВАБе и с внешней камеры в процессе игры, существует и виден всегда
2. Внутренняя (internal) модель - это интерьер кабины, может жить в двух слоях "реальности", один из которых существует только когда мы находимся внутри кабины, второй существует всегда, как и External
3. Реквизит (Props) - отдельные элементы, созданные для наполнения Интерьера (приборы, индикаторы, кнопки и т.д.), прописываются и живут там же, где и Internal
Отсюда и первое наблюдение:
пункт №1 (External) может вполне себе существовать без пунктов 2 и 3, пункт №2 может существовать без №3, но №3 не может существовать без №2, а №2 не может существовать без №1.
Вот такая "Санта Барбара" получается.

А теперь, давайте выясним, что же такое интерьер (Internal) с точки зрения КСП и Юнити:
МодельInternal - это по сути, такой же Парт (Part) как и любой другой, но с некоторыми заморочками характерными отличиями:
Первое, что нужно понять - на интерьер мы смотрим находясь в нем, то бишь изнутри модели.
Юнити (Unity) все поверхности считает ОДНОСТОРОННИМИ, т.е. полигоны видны, если мы смотрим на них с "лицевой" стороны и НЕ видны, если мы смотрим на них с обратной стороны. А в случае с Интерьером, как я у же писал чуть выше, мы как раз таки его видим с обратной стороны. Что это значит? Правильно! Это значит, что:
Наблюдение второе
нормали полигонов модели Internal должны быть ИНВЕРТИРОВАНЫ!

Теперь время пояснить, что я имел ввиду под термином
"Слои реальности".
В КСП, различные элементы сцены живут в разных Слоях (Layer). игровой движок комбинирует эти слои в нужной для данной ситуации последовательности и, в итоге, формирует для игрока игровую сцену, т.е. то, что мы в итоге видим на экране.
Чтобы КСП правильно сформировала для нас эту сцену, нам надо правильно распределить элементы (на этапе подготовки моделей в Юнити) по Слоям (Layer).
Для Интерьера в КСП зарезервированы ДВА слоя (Layer):
1. Internal Space
2. Kerbals
Печалька в том, что (по умолчанию) этих слоев в Юнити нет. хорошая новость - мы их можем легко создать!


Для этого, тыкаем в меню "Layer" и в самом низу списка выбираем "Add Layer..."


В открывшемся окне в строке "User layer 16" мы пишем "Kerbals", в строке "User layer 21" - "Interna Space"


Заодно, можете сразу создать и Part Triggers, прямо сейчас оно нам не надо. Но раз уж мы в этом меню, то пусть сразу уж будет. потом пригодится.

Наверняка, у вас уже возник логичный вопрос - "А нафига нам столько почему мы сделали ДВА слоя и в чем разница?".
А вот почему.
Помните, в игре, в правом нижнем углу, есть маленькие такие экранчики с мордами наши отважных Кербонавтов?


Чтобы нам их показать, игра создает специальные камеры напротив каждого кресла в кабине и картинка с этой камеры помещается в тот самый экранчик. Но, может получится так, что вы построите такой интерьер, что между Кербалом, сидящим в кресле, и камерой, которая его снимает, окажется какой-то предмет (или вообще стенка капсулы) и картинка получится "не айс" (с)... Чтобы уладить эту досадную неприятность мы и воспользуемся РАЗНЫМИ слоями (Layer). А именно:
- все, что должно быть на экранчике с мордой мы поместим, т.е. для выделенной детальки выберем из списка слоев, Слой (Layer) "Kerbals" (потому-то он так и называется)
- все, что должно быть в Интерьере, но НЕ должно отображаться на экранчиках, мы назначаем в Слой (Layer) "Internal Space"
Вот такое колдунство. Но это еще ерунда, ща будет еще веселее ибо...

"ОРИЕНТАЦИЯ"

Что можно о ней сказать? Она, как и практически все в КСП, не совсем традиционная. Сквад, в бесконечной своей мудрости, нагородил аццкий огород с координатными системами для разных элементов сцены и теперь нам с этим надо как-то жить.

Наблюдение третье:
Создатели КСП - весьма неординарные личности и простому обывателю никогда не понять всю глубину и масштаб ....

В момент, когда мы решим заняться той самой "внутрикорабельной деятельностью", то бишь зайдем вI.V.A., мы со всего маху столкнемся лицом к лицу ажно с ТРЕМЯ РАЗНЫМИ системами координат:

1. Внешняя модель (External)
Ось Z - верх, ось Y - перед

2. Интерьер (Internal)
Ось Z - задЪ, ось Y - верх

3. Кербонавты (Kerbals)
Ось Z - перед, ось Y - верх

Круто, правда?
Как это выглядит на практике? Да ужасно это выглядит на практике, и очень неудобно это на практике и, на практике, это дико бесит. Но деваться некуда. я решил эту проблему следующим образом.
В "трехмерке" (я крутой работаю в Maya), я ничего никуда не разворачиваю и работаю с одной, общей ориентацией. ибо так гораздо удобнее


синий цвет - External | зеленый - Internal.
И прямо вот так же и экспортирую обе модели в Юнити
А дальше, у же в Юнити, я привязал все, что относится к Интерьеру, к GameObject'у (не забудьте сначала обязательно обнулить его координаты) и уже его развернул по оси X на 90 градусов и по оси Y на 180. Получилось вот так:

 

черный - это Internal.

Чуть не забыл. чтобы былаI.V.A. нужно же поселить в кабину Кербонавтов! Иначе же кто эту деятельность там будет разводить?!


Для этого надо создать, что бы вы думали? Пралльна! Наши любимые Gameobject'ы, а куда ж без них-то в нашем деле.
Итак, делаем GameObject -> Create Empty. Называем его "Seat1", то бишь "кресло1". и размещаем его там, где у нас должен сидеть Кербал, не забывая о том, что у него верх - это Y, а смотрит он вдоль Z повторяем процедуру столько раз, сколько у нас по паспорту вмещает кабина. Имена соответственно будут "Seat2", "Seat3" и т.д.

 

Теперь, как было описано выше, все, что у нас будет интерьером, раскладываем по слоям "Internal Space" и "Kerbals". Создаем еще один GameObject (обнуляем его координаты!). Вешаем на него компонент PartTools и экспортируем обычным порядком, как любую другую деталь (Part)


настройки материалов и прочего я тут пропускаю, ибо ничего особенного в данном случае с ними делать не надо.
Структура файлов (в геймдате) для Командного модуля обычно выглядит так:
Gamedata / Ваше название компании или никнейм / название мода/ название детали/, а в ней:
->Part - тут лежит External модель с текстурами и конфигом
->Spaces - сюда мы экспортируем модель Интерьера (Internal) с текстурами и создаем ее конфиг
->Props - это реквизит, созданный для нашего Интерьера. отдельная история, об этом в другой раз
->Sounds (опционально) - это ваши кастомные звуки

И так. У нас есть mu-файл и текстуры, но это еще не Интерьер, чтоб эти груды байтов стали Интерьером, нам нужно прикрутить к ним конфиг
В самом простом случае, конфиг для интернала будет выглядеть так:

INTERNAL
{
name = ALCORInternals3
MODULE
{
name = InternalSeat
seatTransformName = Seat1
allowCrewHelmet = false
}
MODULE
{
name = InternalSeat
seatTransformName = Seat2
allowCrewHelmet = false
}
MODULE
{
name = InternalSeat
seatTransformName = Seat3
allowCrewHelmet = false
}
}

name = ALCORInternals3 - официальное название вашего Интерьера
name = InternalSeat - название модуля, добавляющего Кербала
seatTransformName = Seat1 - название Геймобжекта, указывающего где этот Кербал должен сидеть
allowCrewHelmet = false - указывает, в шлеме или без него должен сидеть кербал в этом кресле

Вот, собственно, и все с конфигом Интерьера.
Помните, я писал в самом начале, что Интереьер не может существовать БЕЗ Внешней модели? Молодцы!
А это значит, что нам надо связать наш новенький, уютненький, сверкающий свежей краской, Интерьерчик с внешней моделью Командного модуля.
Делается путем прописывания ссылки на модель Internalв кофиге Командного модуля (т.еPart'а.).

Открываем конфиг капсулы и вписываем аккуратным, каллиграфическим почерком:

INTERNAL
{
name = ALCORInternals3
}

Все! теперь КСП, в момент воссоздания вашего корабля, дойдя до командного модуля, увидит, что с ним ассоциирован Интерьер (Internal) с именем "ALCORInternals3" и, зайдя в I.V.A., вы окажетесь в том самом Интерьере, который только что построили.

You Win!


П.С.
И да! Не вздумайте на модель Internal вешать коллайдер, а то капецЪ

 

Создание стыковочных портов

manhak

 

Для создания стыковочного порта понадобится провести некоторые действия в Unity.
Сперва создается пустой объект, которому придется название dockingNode.
Далее он ориентируется локальной осью Z в направлении от порта (проще говоря наружу).

Это можно увидеть на картинке взятой с официального форума:

 

После этого в файл настроек добавляется следующий модуль:

MODULE
{
name = ModuleDockingNode
deployAnimationController = 1
nodeType = size1
}


Где параметр nodeType отвечает за то, к каким портам будет стыковаться ваша деталь. size1 - порт средних размеров, 0 - маленький, соответственно 2 - большой.

 

Создание двигателя

[Авторalexustas, правка KiRiK]

 

Необходимо объяснить КСП где у твоего двигателя центр тяги ("thrust") и какой у неё вектор. КСП сама, глядя на твой двигатель, к сожалению этого делать не умеет .

 

для этого в Unity создаешь очередной пустой игровой объект, тобишь делаешь GameObject ->Create Empty.

помещаешь его ТОЧНО в ту точку, где по твоему замыслу, должен находиться этот самый Центр, и разворачиваешь так, чтоб синяя стрелка смотрела ТОЧНО в нужном тебе направлении. Обычно вертикально вниз, но мало ли, может у тебя есть хитрый план. И переименовываешь этот игровой объект в" thrustTransform", причем ИМЕННО такое имя должно быть, с большой буквой "Т" в середине. Иначе кирдык.

 

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

Пишешь соответствующий модуль в конфиге, он стандартный, только свою "atmosphereCurve" сочиняешь и фсё.

И да! На этот же thrustTransform в конфиге можно повесить и модуль Gimbal, дабы рулить можно было.

П.С.
Еще как-то можно сделать чтоб сопло (Nozzle) калбасилось в такт Gimbal'у, но щас не скажу как.. это надо dataminig'ом заниматься долго

 

 

в модуле двигателя строчка fxOffset Это параметр смещения спецэффектов движка относительно GameObject'a, символизирующего его Центр тяги.

Я на шару вбил левые значения

fxOffset = 3.0, 3.0, 2.4

и вот что получилось

 

и еще по движкам, для полной ясности.
Британские Ученые в своих Докладах какбэ намекают нам, что GameObject, созданный для обозначения Тяги, необязательно должен называться "thrustTransform". Главное - название этого GameObject'a должно ПОЛНОСТЬЮ совпадать со значением параметра "thrustVectorTransformName = " в конфиге к двигателю.

надо тупо назвать кожух "fairing" в Юнити и дальше оно само заработает. надо было просто попробовать и не ломать мозх

 

РЕЦЕПТ ПРИГОТОВЛЕНИЯ ДВИГАТЕЛЯ
-Возьмите модель вашего вечного двигателя и поместите его в Юнити
-Создайте пустой игровой объект (GameObject -> Create Empty)
-Переименуйте этот объект в "thrustTransform"
-Поместите его так, чтоб его центр находился строго в Центре Тяги вашего будущего двигателя.
-Разверните объект "thrustTransform" таким образом, чтобы ось Z была обращена строго по направлению истечения газов (или как это называется),в общем, в сторону, противоположную движению вашего корабля
должно получиться примерно вот так^

 

-Если вы планируете завоевать весь Мир использовать модуль Gimbal (отклонение вектора тяги) и хотите, чтобы эффект работы этого модуля был виден в игре, т.е. сопло (nozzle) двигателя откланялось, согласно изменению вектора тяги, то необходимо в окне Hierarchy Юнити
перетащить все элементы модели, символизирующие Сопло вашего супер-двигателя, на созданный вами ранее объект "thrustTransform". т.е. привязать все элементы Сопла к вектору тяги. получится вот так:


Далее, все как обычно, сделайте еще один игровой объект, повесьте на него PartTools и бла-бла-бла....

Далее, в конфиге прописываем необходимые модули:

эффекты, на ваше усмотрение


пиротехника

// --- FX definitions ---
fx_exhaustFlame_blue_small = 1.0, -5.8, 0.0, 1.0, 1.0, 0.0, running
fx_exhaustLight_blue = -5.0, -5.8, 0.0, 0.0, 1.0, 1.0, running
fx_smokeTrail_light = 0.0, 1.3, 0.0, 0.0, 1.0, 0.0, running

 

звуки

 

// --- Sound FX definition ---
sound_vent_medium = engage
sound_rocket_hard = running
sound_vent_soft = disengage
sound_explosion_low = flameout

 

модуль, собственно, самого двигателя:

MODULE
{
name = ModuleEngines
thrustVectorTransformName =thrustTransform //внимание! имя должно строго совпадать, не исключая и регистр
exhaustDamage = True
ignitionThreshold = 0.1
minThrust = 0
maxThrust = 220
heatProduction = 800
fxOffset = 0, 0, 2.4
PROPELLANT
{
name = LiquidFuel
ratio = 0.9
DrawGauge = True
}
PROPELLANT
{
name = Oxidizer
ratio = 1.1
}
atmosphereCurve
{
key = 0 390
key = 1 270
}
}


модуль отклонения вектора тяги:

 

MODULE
{
name = ModuleGimbal
gimbalTransformName = thrustTransform //указываем то же имя, что и для Тяги
gimbalRange = 2.5
}

 

модуль ракетного двигателя в конфиге

MODULE
{
name = ModuleEngines - название модуля KSP

thrustVectorTransformName = thrustTransform - имя элемента модели (как правило специально созданного пустого игрового объекта Юнити), который будет Центром тяги вашего двигателя. именно к нему прикладывается реактивная сила и он задает направление истечения струи газов.
внимание!имя должно строго совпадать с именем игрового объекта созданного в Юнити, в том числе и регистр.
Есть так же информация, что не обязательно, объект должен называться именно "thrustTransform", но главное условие - имена в юнити и в конфиге должны полностью совпадать.

exhaustDamage = True - наносит ли реактивная струя повреждения другим объектам в игре. True = Да, False = Нет.

ignitionThreshold = 0.1 - не понял смысл этого параметра. по идее, это порог воспламенения (зажигания) топливной смеси... не знаю в общем..

minThrust =0 - минимальная тяга вашего двигателя

maxThrust =220 - максимальная тяга, чем выше значение, тем мощнее двигатель

heatProduction =800 - нагрев работающего двигателя, чем выше значение, тем быстрее двигатель перегревается

fxOffset =0, 0, 2.4 - смещение (в метрах) по осям X, Y, Z визуальных эффектов (дыма, пламени) относительно Центра тяги двигателя

PROPELLANT - объявляется потребляемый ресурс
{
name = LiquidFuel - название ресурса, в данном случае - жидкое топливо

ratio =0.9 - пропорция потребления данного компонента

DrawGauge =True - отображать ли шкалу остатка топлива возле иконки двигателя, когда активируется соответствующая ступень (да/нет)

}

PROPELLANT- объявляется еще один потребляемый ресурс

{

name =Oxidizer - еще один ресурс требуемый для работы двигателя, в данном случае - окислитель

ratio = 1.1 - пропорция потребления данного компонента. окислителя расходуется обычно больше, чем топлива. т.е. получается на одну единицу топлива уходит ~1.22 единицы окислителя

}

atmosphereCurve - объявляется кривая, описывающая эффективность работы двигателя (что-то вроде КПД).
характеризует силу, которую выдает двигатель к потраченному за единицу времени топливу. ну или что-то в этом роде ))
для ракетных и реактивных авиационных двигателей этот показатель называется "Isp" , чем выше параметр, тем эффективнее и экономичнее двигатель. подробнее читаем тут

{

key =0 390 - Isp в вакууме (на орбите). первая цифра "0", как раз намекает нам, что атмосфера уже вроде как отсутствует

key =1 270 - Isp на уровне моря. цифра "1" указывает, что атмосферы вокруг ну просто завались

}

}

опционально, двигатель можно наделить умением рулить. для этого прописываем в конфиге модуль "Gimbal", т.е. отклонение вектора тяги:

MODULE
{
name =ModuleGimbal - название модуля KSP

gimbalTransformName =thrustTransform - имя элемента модели (как правило пустого игрового объекта Юнити), который будет Центром вращения вектора тяги (сопла) вашего двигателя. Как правило, используется объект "thrustTransform", созданный для обозначения Центра тяги двигателя, хотя были замечены случаи, когда для Тяги и для руления использовались разные объекты.... зачем, лично я не понял.

gimbalRange =0.5 - величина отклонения вектора тяги. чем больше значение, тем "маневреннее" ваш двигатель
}

 

Создание разъединителей

[Авторalexustas, правка KiRiK]

 

С декуплерами все просто, вроде бы. Прописываешь в конфиге модуль:

MODULE
{
name = ModuleDecouple     //объявление модуля
ejectionForce = 20   //сила "отстрела", значения over 9000 дают весьма занимательный результат
explosiveNodeID = top     //какой нод "выстерливает" (верхний или нижний)
}

Это самый простой вариант декуплера. Также, можно добавить параметры:

В стандартных параметрах конфига:

 

stagingIcon = DECOUPLER_HOR        //тип иконки в панели ступеней, в данном случае "горизонтальное разделение", актуально для радиальных декуплеров

 

stageOffset = 1                           //будет создана отдельная ступень, после текущей

childStageOffset = 1

 

В параметрах модуля декуплера:

 

staged = false                             //не будет автоматически создаваться дополнительная ступень, отстрел можно будет сдалть только в ручную через контекстное меню

isOmniDecoupler = true       //декуплер полностью отрывается от всех деталей, т.е. подрываются заряды сверху и снизу одновременно

а так же для разделяющихся радиальных декуплеров, можно указать деталь, которая останется на крафте после отстрела, но там и модуль другой надо объявлять.

 

Теги в юнити

[Авторalexustas, правка KiRiK]

 

приготовьте свои тетрадки и записывайте:

в инспекторе под названием объекта есть параметр Tag. У тебя там щас скорее всего выбрано "Untagged"

 

тыкаешь в это меню, в самом низу выбираешь "Add tag..." и видишщь примерно вот это

 

в поле Size ставишь 4 (можно другое число, но тебе еще пригодятся свободные ячейки)


заполняешь появившиеся поля "Element X" как-то вот так:

 

чуешь, к чему дело идет?

да-да. Теперь у тебя есть полезные и питательные Тэги и не только для "жеттисонов".

Тыкаешь в свой fairing объект и выбираешь из списка Тэгов "Icon_Hidden".

Дальше - по обычному плану...

Создание CFG файла

[автор KiRiK]

 

Для создания cfg файла под вашу деталь проще всего подобрать готовый cfg файл из папки Squad

Допустим, вы создали некую простую деталь вроде бака с топливом.

Соответственно лезем в \GameData\Squad\Parts\FuelTank\fuelTank\, хотя можно любой другой бак.

Копируем файл part.cfg в папку с вашей деталью.

Открываем его любым текстовым редактором (например Notepad++, в нем можно поставить синтаксис С# который будет удобно подсвечивать вам текст).

В этом файле видим следующий текст:

PART

{

// Kerbal Space Program - Part Config

// FL-T500 Fuel Tank

//

 

// --- general parameters ---

name = fuelTank

module = Part

author = NovaSilisko

 

// --- asset parameters ---

mesh = model.mu

scale = 0.1

 

 

// --- node definitions ---

node_stack_top = 0.0, 7.72552, 0.0, 0.0, 1.0, 0.0

node_stack_bottom = 0.0, -7.3, 0.0, 0.0, 1.0, 0.0

node_attach = 5.01, 0.0, 0.0, 1.0, 0.0, 0.0, 1

 

 

// --- editor parameters ---

TechRequired = basicRocketry

entryCost = 1600

cost = 850

category = Propulsion

subcategory = 0

title = FL-T400 Fuel Tank

manufacturer = Jebediah Kerman's Junkyard and Spaceship Parts Co.

description = The FL series was received as a substantial upgrade over previous fuel containers used in the Space Program, generally due to its ability to keep the fuel unexploded more often than not. Fuel tanks are useless if there isn't a Liquid Engine attached under it. They can also be stacked with other fuel tanks to increase the amount of fuel for the engine below.

 

// attachment rules: stack, srfAttach, allowStack, allowSrfAttach, allowCollision

attachRules = 1,1,1,1,0

 

// --- standard part parameters ---

mass = 0.25

dragModelType = default

maximum_drag = 0.2

minimum_drag = 0.3

angularDrag = 2

crashTolerance = 6

breakingForce = 50

breakingTorque = 50

maxTemp = 2900

 

RESOURCE

{

 name = LiquidFuel

 amount = 180

 maxAmount = 180

}

 

RESOURCE

{

 name = Oxidizer

 amount = 220

 maxAmount = 220

}

}

 

Убираем все не нужное:

PART

{

// --- general parameters ---

name =

module = Part

author =

// --- asset parameters ---

mesh =

scale =

// --- node definitions ---

node_stack_top = 0.0, 7.72552, 0.0, 0.0, 1.0, 0.0

node_stack_bottom = 0.0, -7.3, 0.0, 0.0, 1.0, 0.0

node_attach = 5.01, 0.0, 0.0, 1.0, 0.0, 0.0, 1

// --- editor parameters ---

TechRequired = basicRocketry

entryCost = 1600

cost = 850

category = Propulsion

subcategory = 0

title =

manufacturer =

description =

// attachment rules: stack, srfAttach, allowStack, allowSrfAttach, allowCollision

attachRules = 1,1,1,1,0

// --- standard part parameters ---

mass = 0.25

dragModelType = default

maximum_drag = 0.2

minimum_drag = 0.3

angularDrag = 2

crashTolerance = 6

breakingForce = 50

breakingTorque = 50

maxTemp = 2900

 

RESOURCE

{

 name = LiquidFuel

 amount = 180

 maxAmount = 180

}

 

RESOURCE

{

 name = Oxidizer

 amount = 220

 maxAmount = 220

}

}

 

Далее изменяем параметры под свою деталь:

// --- general parameters ---

name = BTR90             имя вашей детали для игры(не должно совпадать с любым другим)

author = KiRiK              автор, здесь можно писать любую информацию.

 

// --- asset parameters ---

mesh = btr90.mu       название файла с 3D моделью (обычно model.mu, хотя никто не запрещает переименовывать свою модель)

scale = 1                         масштаб, если вы напутали с размерами или хотите создать несколько деталей разных размеров. Значение больше единицы увеличивает модель, меньше – уменьшает.

 

// --- node definitions ---                                                      здесь вам нужно проставить координаты точек крепления. Измерить координаты можно в 3D редакторе

node_stack_top = 0.0, 0.5, 0.0, 0.0, 1.0, 0.0                   верхняя точка крепления, в формате x, y, z, angx, angy, angz, size

node_stack_bottom = 0.0, 0.5, 0.0, 0.0, 1.0, 0.0                          нижняя точка крепления, в формате x, y, z, angx, angy, angz, size

node_attach = 0.5, 0.0, 0.0, 1.0, 0.0, 0.0, 1

 

// --- editor parameters ---

TechRequired = basicRocketry            здесь можно указать в каком месте будет расположена ваша деталь в дереве науки

entryCost = 1600                                           

cost = 850                                                         

category = Structural                               здесь указывается категория в которой можно найти деталь в ангаре

subcategory = 0

title = Платформа БТР                            название детали которое будет отображаться в игре

manufacturer = KiRiK                               здесь указывается компания производитель

description = Корпус от БТР-90.         описание вашей детали которое отображается в ангаре

 

// attachment rules: stack, srfAttach, allowStack, allowSrfAttach, allowCollision

attachRules = 1,1,1,1,0

 

// --- standard part parameters ---

mass = 1                                                        масса вашей детали

dragModelType = default

maximum_drag = 0.2

minimum_drag = 0.3

angularDrag = 2

crashTolerance = 6

breakingForce = 50

breakingTorque = 50

maxTemp = 2900

 

RESOURCE                                    модуль который добавляет вашей детали ресурсы

{

 name = LiquidFuel                    название ресурса

 amount = 180                             количество

 maxAmount = 180                    максимальное количество

}

 

Сохраните ваш cfg файл.

На этом все. Вы можете протестировать вашу деталь в игре, и сделать необходимые поправки.

 



Поделиться:


Последнее изменение этой страницы: 2024-07-06; просмотров: 32; Нарушение авторского права страницы; Мы поможем в написании вашей работы!

infopedia.su Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав. Обратная связь - 216.73.217.176 (0.01 с.)