cfg file will be addressed in depth-first alphabetical order based on it's position within /GameData/, relative to other. sfs, these files are simply disk-storable containers for Config Nodes and as such their names and locations are almost entirely insignificant. cfg is used for every configuration file in KSP except persistence files, which are stored in.
Parts will be displayed in the order they are loaded in.īecause of this parts located in /GameData/Squad/Parts/Utility/ will always be listed before those in /GameData/Squad/Parts/Wheel/, even if the wheel part's name is before the utility part's name alphabetically.Īside from load order, the directory structure of /GameData/YourFolder/ only serves as an organizational tool for the developer.įile type. (This is just the way Squad does it, you can do it any way you want)Īll assets will be loaded in a depth first alphabetic order, in sets based on file type. Resources/ - This folder contains the file that declares all of the stock resources Props/ - Props are the functional little elements in IVAs Parts/Utility/ - Parts that do things and don't contain resources (except some of them do) Parts/Structural/ - Parts that don't do anything, and don't contain resources Parts/Electrical/ - Parts that create and store electricity Parts/Command/ - Command pods, probe cores, and reaction wheels Flags/ - Flags must go here or they won't be loaded as flags, Capitalization Matters Inside the dedicated folder, the directory structure is largely unimportant.Īll of the stock parts are contained within GameData as well, and Squad uses this structure: Everything related to a given Add-on should be contained within a folder created specifically for that Add-on. Please discuss on the talk page if you have concerns or things to addĪll add-on files should be placed in the GameData folder, located in the root KSP folder alongside the KSP executable. Tentatively complete: I believe this section to be complete aside from inconsistent terminology and refining the exact text.
#Ksp crossfeed rules code
Reflecting the organization of the code helps to a degree, but a perfect replication is neither the goal or particularly useful. In code this information gets placed into, where partInfo is an instance of AvailablePart, so really cost is found at st. It is also important to note that the way things are organized in the cfg does not strictly reflect how they are organized into code. This has been fixed now, but previously giving it a bad value would cause an exception that immediately ended the loading process, causing KSP to skip over all following values in that part, but also all parts following, and go straight to the landing screen with the Kerbal floating around. One example is st, cost is an int or integer, in past versions of KSP cost would fail if given a value that is not an int, such as a float such as 4.7 or a string such as 4,000 (the comma makes it a string or text value). Predominantly you will see string, int, and float, and if the data does not match the necessary type it will likely cause some kind of crash. In the code, the allowable contents of a Field are quite specifically defined based on C# Types. Keep in mind that the shorthand is technically incorrect For the purposes of this article we will be referring to the organization of things in code in a format similar to the code, Node.Field=value, in example: ="ModuleWheel", though it can be easier to shorten that to, the value of which is "ModuleWheel". Node names and Field names are Case Sensitive, if they are spelled wrong or in the wrong case they will not exist as far as the code cares. As well, Nodes must be asked for by the code, they don't do anything without a code counterpart. From there Fields hold Values, but those values have to be asked for by the code or they never get loaded. PART does not work inside another PART and MODULE does not work outside of PART. More specifically Nodes, such as PART, RESOURCE_DEFINITION, and MODULE, only exist in certain contexts.
Nodes can be in other nodes but fields must be in a node. In it's most basic form the structure of a cfg file is as followsĪll cfg structures can be represented as this. KSP's cfg format can be difficult to converse about without getting into how the code works because the format is a direct reflection of the code, but also because it's not very regular and a lot of labels get used repeatedly for different meanings while a lot of meanings get labeled differently in various places all the while there are misnomers abound and piles of deprecated things that may or may not still work.
0 kommentar(er)
