CFG File Documentation/es

Si te gusta y/o utilizar esta información, por favor pase por la sección de Discusión y deje un comentario. Me hace sentir mejor acerca de hacer todo este trabajo, y francamente, si alguien no lo hace pronto, voy a parar y mantener esto para mí solo. Sí, puede entender todo esto por su cuenta, pero déjame decirte...En lo que a mí respecta, es un verdadero dolor en el "trasero".

NOTA Mayor: Archivos de configuración vienen en muchos tipos. El tipo más común de archivo de configuración, y por lo que la gente se interesa más a menudo, es el archivo de configuración de la pieza. También hay archivos de configuración para los recursos, aunque (también otras cosas). Voy a cubrir piezas, primero; y los recursos después.

Formato de Configuración

El formato de configuración utilizado en Kerbal Space Program NO es una clase de Unity, pero adaptada a KSP.

KSP lee archivos .cfg en nodos de configuración. Los nodos de configuración pueden contener valores (versiones en serie de toda clase de tipos de datos) u otros nodos de configuración. Ver C# class documentation en la documentación de la Comunidad API KSP para más detalles.

Module Manager

El stock de de configuración es muy simple - nodos y valores, que no son más que nodos ramificados y cuerdas. El análisis es manejado por módulos que utilizan archivos .cfg. Ver KSPField en la API.

El mod Gestor de módulos (Module Manager) añade filtrado y potentes capacidades de extensión del formato de configuración del nodo. Si ve un símbolo @, []'s, o parece programación, la configuración está usando Gestor de módulos. Está bien documentado en el hilo del foro y en Github de sarbian.

Parte fundamental de las directrices

Cada parte consta de varios archivos, incluido el archivo de configuración, un modelo y una malla de colisión. Bajo los estándares de 0,25, la malla del modelo y de la colisión ambos tiene un material asignado cuando crean en su software de modelado y previo a la exportación para su uso. No soy un modelador, por tanto dejaré esa dirección a alguien más calificado.

Al crear una nueva pieza, cada uno de estos archivos (incluyendo modelos y mallas adicionales, si es necesario) Deben incluirse en una sola carpeta que describe o nombra la pieza. A pesar de que Squad son horriblemente inconsistentes al construir piezas, Lo mejor es tener el nombre de la carpeta, y los nombres de cada una de las mallas coincidan con el nombre de la parte interior el archivo cfg (no el nombre que se ve en la construcción de las piezas! Más sobre esto más adelante).

Si creas más de unas cuantas partes, puede que desee crear una carpeta para cada tipo de pieza. Esta es sin duda una práctica aceptable y que Squad usa. Por ejemplo: /Engines/ para colocar todos sus diseños de motor dentro.

Si es un mod que hace cosas que solo proporciona un paquete de partes capaces, puede que desee unas subcarpetas más, una para las partes, una para las agencias, otro para los contratos, etc, etc.

No importa cómo profundamente aniden las carpetas de sus mods, su propio mod debe estar contenido dentro de la carpeta /GameData con un nombre que identifica de forma exclusiva a su mod. Sería conveniente poner nombre a esta carpeta del mismo modo que nombrarías tu mod (ej: GameData\Modular Kolonization System\ se anuncia como Modular Kolonization System o GameData\MechJeb se anuncia como MechJeb) (y sí, sé que estoy usando ejemplos que violan activamente este principio!)

Así, escribí un mod (llamémoslo ShadowSplat) que modifica algunos recursos, añade unas pocas agencias, y masivamente actualiza las partes que incluyen nuevos motores, tanques de combustible, contenedores de ciencias y las eléctricas. Mi estructura de carpetas podría tener este aspecto:

KSP_win\GameData\ShadowSplat\
KSP_win\GameData\ShadowSplat\Agencies
KSP_win\GameData\ShadowSplat\Resources
KSP_win\GameData\ShadowSplat\Parts
KSP_win\GameData\ShadowSplat\Parts\Engine
KSP_win\GameData\ShadowSplat\Parts\FuelTank
KSP_win\GameData\ShadowSplat\Parts\Science
KSP_win\GameData\ShadowSplat\Parts\Electrical

Archivos de configuración PARTES

A partir de al menos 0.24.2^[outdated], el orden del archivo de configuración importa muy poco. Por lo que yo puedo decir, usted puede lanzar casi cualquier cosa que desees ver ahí en cualquier orden. Sin embargo, para la compatibilidad y las razones de comprobación de errores, lo mejor es seguir la estructura general que existe dentro de las piezas de stock. Muchas de las piezas de stock contienen líneas de comentário de salida para ayudar a descifrar como deberían ir las cosas, pero, he aquí un desglose general, utilizando una parte mitológica (llamémosla "DoesItAll"). DoesItAll existirá en esta carpeta:

KSP_win\GameData\ShadowSplat\Parts\Engine\DoesItAll

y constará de los archivos:

KSP_win\GameData\ShadowSplat\Parts\Engine\DoesItAll.cfg
KSP_win\GameData\ShadowSplat\Parts\Engine\DoesItAll.mu
KSP_win\GameData\ShadowSplat\Parts\Engine\DoesItAll.mbm

Nota: esta es una explicación general. Información adicional se puede encontrar haciendo clic en los enlaces proporcionados:

Parámetros generales

Actual part	Explicación
PART	- especifica que este cfg se refiere a una parte
{
name = DoesItAll	establecer el nombre oculto de la pieza. No se permiten espacios. Guiones y otros caracteres especiales, o bien no se les permite o no recomendable. Este nombre se utiliza detrás de las escenas de referencia y de otras partes y llamadas de procedimiento, sino que también se pone de manifiesto durante cuadros de diálogo de crash/daños (F3). Es una buena práctica de programación utilizar un nombre que define, al menos parcialmente, la parte y/o creador. fuelTankSmallFlat (que ya está en uso) no es un buen nombre para usar aquí, aunque sí describe la parte efectivamente, no diferencia entre un fuelTankSmallFlat - El depósito de combustible T-100 y el tanque de combustible Rockomax X200-8, que también podría ser considerado un fuelTankSmallFlat.
module = Part	Este Convenio ya no se usa. Versiones anteriores de KSP permitieron solamente partes individuales para servir como módulos y esto fue por tanto adecuadamente colocado en ese entonces. Las versiones más recientes que las piezas tienen/sirven de múltiples módulos y las convenciones para la definición de esos módulos se han reubicado y redefinido como su propio subgrupo. Todavía se pueden encontrar en algunas partes heredadas que no se han actualizado, incluyendo el "Tail Fin" por C7 Aerospace Division. 5 partes en total son conocidas por seguir utilizando esta convención. FuelLine tiene la propiedad adicional de maxLength, presumiblemente para restringir la longitud de las líneas de combustible. Este método se utiliza en la línea de combustible Stock StrutConnector tiene las propiedades adicionales de linearStrength, angularStrength y maxLength. Este método se utiliza sobre el stock Strut Conector Winglet tiene las propiedades adicionales de dragCoeff y deflectionLiftCoeff. Al igual que el ModuleControlSurface. Este método se utiliza en las piezas de stock Aleta de cola, wingletAV-T1, sweptWing y se espera que esté en desuso en la próxima revisión de esas partes.
author	Simplemente un lugar para atribuirse el mérito por su creación / actualización. Esta línea no se hace referencia en el juego. Se recomienda que utilice el mismo crédito al autor para todas las partes que usted o su equipo crean bajo un mismo título. Por ejemplo, asignar todos los mods MKS al autor EQUIPO MKS y todos los mods OKS al autor equipo OKS, a pesar de que todos ustedes son el mismo equipo.