Difference between revisions of "User talk:Greys"

Revision as of 07:58, 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:

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)