User talk:Greys
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)
- Although you first want to fix the text: The use of the first level headers (= GameData =) is not recommended. Before you make the article official they should be removed. — xZise [talk] 02:58, 13 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.
--Greys (talk) 00:00, 13 September 2013 (CDT)
- I don't know if I understand you correctly, but maybe there should be separate documentations (maybe even in different files)? A general documentation about the ConfigNode system and then separate documentations about the structures (PART{}, RESOURCE{},…). — xZise [talk] 02:58, 13 September 2013 (CDT)
