Difference between revisions of "User talk:Greys"

Revision as of 19:27, 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)

I guess this is a little more cryptic looking than I intended, it was a late night after a long day. I don't thing "CFG File Documentation" can fit within a reasonably organize page given how wide it is, hell, GAME{}, which I've chosen to exclude from this, would probably take three times as much text to explain and it would only be useful to people who want to edit their saves. Explaining partModules has more to do with coding plugins than making parts and the only aspect of it that fits in this page is what it does, the context it operates under during gameplay because when you make a plugin you do things certain ways to have things work certain ways and most of the ways you can do things are not partModules but beyond that I'm not a programmer anymore, I don't know anything about Unity's engine except the things I soak up in the IRC channel. But then, something between half and a third of the page right now is about things not in the cfg file that you have to understand to in order to set up a cfg with say, proper asset synonymy or a gimbling engine or, the greatest horror, a wheel.

This page as I'm writing it is about making parts, I don't currently plan on talking about modelling, coding plugins, and only very limited coverage of Unity's hierarchy, transforms, colliders, etc, but it's by no means limited to to .cfg file documentation, and .cfg file documentation in a vacuum would be nearly worthless

--Greys (talk)