Difference between revisions of "User talk:Greys"

Revision as of 12:48, 21 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)

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)

I understand what the word's you've said and their meaning, but I don't understand... Why would it not be recommended to use the first level headers?

--Greys (talk) 01:06, 16 September 2013 (CDT)

The page title itself is a “like” (=<h1>) first level section heading. So from the style perspective your article has currently three level one headings. The English Wikipedia for example also doesn't recommend first level headings (and at least the German doesn't recommend them too so I guess most of them don't) for this reason.^Help:Section Maybe this should be split in separate articles? — xZise [talk] 03:46, 16 September 2013 (CDT)

The problem in my eyes is that 4th+ level headers serve no purpose except to add anchors in the contents tree, they're functionally worthless to the format of the page. So if I have to stop using 1st level headers, I'll have to find some way to condense everything into just two levels of headers or manually fix the gimped headers

As far as having another page, GameData is a vital topic if you want to make parts now, and aside from plugins it's not otherwise important, so if GameData was moved out of this page, I would have to preface it with "Before you read this page, read this other page, or nothing will make sense"

Basically making parts is full of completely independent "1st level" topics which do not fit inside each other, but are vital topics in making the others work. You have to understand some key things about how the code works to make the models correctly, you have to understand how GameData works to optimize your cfgs in the way that should be expected of all parts these days. Hell, you even have to understand that KSP compresses all textures into DXT1 or DXT5 format in memory depending on the presence of an alpha channel, and DXT5 is literally twice as big as DXT1, so if you have an alpha channel in your PNG textures, your textures take up twice the RAM so you need to make sure you flatten them on export. And it'd be good to understand that DXT* are bits-per-pixel compression, so having regions of uniform color will not reduce your memory cost, but you can use UV trickery to make regions that should be uniform take up fewer pixels; or that this, or that that. Right now the page contains most of the critical "stuff you absolutely need to do it at all" stuff, but there's a lot more that needs to go in on how to do it correctly and optimization tips and probably a whole section on Unity, PartTools, hierarchical structures though most of those will need to be on their own pages because covering all the stock MODULE{}s in one page is a recipe for poorly conveyed information. And that's gonna need a whole standard page format

This page won't work correctly without 1st levels, and this information won't work correctly as separate pages

--Greys (talk) 15:15, 16 September 2013 (CDT)

Okay I guess I don't know enough about that topic to determine it is possible to separate it into different pages. Maybe somebody else with a better understanding that me in that topic has a good idea. — xZise [talk] 13:49, 17 September 2013 (CDT)

After spending a while thinking about it, Game Data can make a sensible own-page if it's approached from another direction, that being the Game Database system as a whole, I'm not really qualified to speak about the Game Database so I've asked Majiir to come on and take a crack at it, and he says he'll give it a shot on the weekend. I'll still need some amount of coverage over GameData in this page, but a lot of the fine details won't need to be there, like nearly everything to do with asset formats. I'll be able to reduce the GameData section to a subsection of Config Node, and at that point I think I could make Config Node into the topic of the page, tinted towards part making, allowing me to eliminate the Config Node first level header and leave everything else the way it is. Suddenly things are coming together.

PS, this tabulation is starting to get ridiculous, and kinda the reason I was suggesting the extended community links on the main page talk page, I'd pretty much always rather use a forum or IRC over keeping track of colons. And if we could get some of the wiki crew to hang around #KSPModders, maybe we could get some of the smart people* onto the wiki and make this place a little more relevant to modern add-ons

--Greys (talk) 21:20, 18 September 2013 (CDT)

First of all: Would be nice if Majiir can add another article. I'm looking forward to it. About contacting each other: The IRC is more like instant messaging, while you can post an answer here without others need to be online at that moment and looking from your time stamps you answer while it is in the morning for me so the chances aren't that good. Also it's about this article and more about the style as I'm not really qualified for commenting on the content. Btw. another disadvantage of IRC is that you don't have a log. — xZise [talk] 07:48, 21 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)