Difference between revisions of "User talk:Greys"
(→Your userpage) |
(→The Color of the Game: CFG File Documentation: new section) |
||
Line 29: | Line 29: | ||
I don't want to use a table for that information because it's depicting a structure, not a set; but at this point I'm far more concerned with getting rid of outdated or incorrect things, and getting good useful information back in, rather than formatting. | I don't want to use a table for that information because it's depicting a structure, not a set; but at this point I'm far more concerned with getting rid of outdated or incorrect things, and getting good useful information back in, rather than formatting. | ||
--[[User:Greys|Greys]] ([[User talk:Greys|talk]]) 12:30, 1 September 2013 (CDT) | --[[User:Greys|Greys]] ([[User talk:Greys|talk]]) 12:30, 1 September 2013 (CDT) | ||
+ | |||
+ | == The Color of the Game: CFG File Documentation == | ||
+ | |||
+ | One of the issues I've been considering since the start of this revision is that the name is not really relevant anymore. | ||
+ | |||
+ | :'''.CFG files no longer pertain to parts exclusively''' | ||
+ | .CFG files contain config nodes that are a means of passing data to code. | ||
+ | |||
+ | :'''It's increasingly less viable to make a part without understanding of systems beyond the .cfg file''' | ||
+ | Whether it's /GameData/ or the hierarchy of a .MU file, making a part with any complexity cannot be done without knowing how to set up and abuse these systems. | ||
+ | |||
+ | --[[User:Greys|Greys]] ([[User talk:Greys|talk]]) 00:00, 13 September 2013 (CDT) |
Revision as of 05:00, 13 September 2013
Your userpage
Hi, I guess you rewrite CFG File Documentation and test it on your userpage. In theory a great concept, although I would recommend (when you want to do something like this again) to use a page in your namespace. For example User:Greys/CFG File Documentation. Now I got another question: What do those ø mean? A reminder for you to check them later again?
Also how do you want to handle suggestions? For example that list in the first section:
-
/Flags/
: Flags must go here or they won't be loaded as flags, Capitalization Matters -
/Parts/Aero/
: Aerodynamic parts - […]
Or when you really want to have that the note to each directory is indented to the same depth:
Directory | Description |
---|---|
/Flags/
|
Flags must go here or they won't be loaded as flags, Capitalization Matters |
/Parts/Aero/
|
Aerodynamic parts |
[…] |
Main reason I suggest this here, is to avoid normal text to be in <pre> tags. — xZise [talk] 06:22, 1 September 2013 (CDT)
Yo
I'll keep the namespace in mind
the ø are inline comments about specific things that are inaccurate or inadequate, where the Outdated tags are general section wide concerns. If you look at the page history, I did most of the notation in the first version of the page, and then started deleting stuff over the next few; well more than half of the original page is so outdated as to be worthless, or entirely and originally wrong that it could be considered harmful.
I don't want to use a table for that information because it's depicting a structure, not a set; but at this point I'm far more concerned with getting rid of outdated or incorrect things, and getting good useful information back in, rather than formatting. --Greys (talk) 12:30, 1 September 2013 (CDT)
The Color of the Game: CFG File Documentation
One of the issues I've been considering since the start of this revision is that the name is not really relevant anymore.
- .CFG files no longer pertain to parts exclusively
.CFG files contain config nodes that are a means of passing data to code.
- It's increasingly less viable to make a part without understanding of systems beyond the .cfg file
Whether it's /GameData/ or the hierarchy of a .MU file, making a part with any complexity cannot be done without knowing how to set up and abuse these systems.