Template talk:Infobox/Part

Rework

I'm working on a new version based on the {{Planetbox}} which you can find here: User:XZise/Partbox If you have any suggestions/feedback please let me know. — XZise (talk) 07:14, 23 February 2013 (CST)

Okay I now added it into this template;

Class/Role Parameter

What exactly are the class and role parameter? It looks like the role parameter is nothing specific and is simply the type of part. But class seems like a internal definition. But I can't see where the it is defined. — xZise [talk] 10:21, 16 April 2013 (CDT)

Where is the API name set? Some parts have class and role set, but the API name won't appear, while others don't have them set, but have an API. --Dgelessus (talk) 08:26, 6 May 2013 (CDT)

When you use {{Partbox}} directly it class/role aren't set by default. While the class is optional (it will show Unknown API if not set) role isn't. Now all subtemplates are now choosing role and class for you, to make it easier to add new articles and to be consistent. So {{Partbox}} should only be used, if there aren't many parts of this type and this part doesn't have any additional values (like I_sp etc.). Now the class is the API so you have to set the class to change the API but this works only for {{Partbox}}. Mind if I ask you why you want to change the class/role of a part? OR do you mean where the role/class are defined in the part.cfg? — xZise [talk] 09:53, 6 May 2013 (CDT)

{{Partbox/Decoupler}} has no class/API set per default, but can't be overwritten either, so all decouplers have "Unknown API". --Dgelessus (talk) 10:45, 6 May 2013 (CDT)

Do you know what API decouplers and separators have? Then I can add it. Or you do it on your own by editing {{Partbox/Decoupler}}. — xZise [talk] 13:08, 6 May 2013 (CDT)

If "module=(something)" in the part.cfg is the API, then all decouplers and separators have Part as API. I'll try adding it to {{Partbox/Decoupler}}... --Dgelessus (talk) 13:15, 6 May 2013 (CDT)

Done. Seems to work. --Dgelessus (talk) 13:18, 6 May 2013 (CDT)

New folder structure for parts and part.cfgs

The location of the part folders and thus of the part.cfg files has changed a lot in version 0.20. Would it make sense to reflect that in the "part" parameter and maybe add a new one for the parent folder (Aero, Command, Electrical, ...)? If so, I see a lot of moving of part.cfgs coming up... --dgelessus ^{(talk, contribs)} 11:17, 28 May 2013 (CDT)

I'm thinking about this problem too. At the moment it doesn't affect us, but in the future it may come to collisions between those Names. Now there are some possibilites:

1. Leave at it is (I won't suggest that)
2. Updating all current part.cfg (could be many … maybe a bot can help us out)
3. New articles use the new structure

Now I thought that this template get a new parameter (e.g. “category”) and the subtemplates fill the parameter (so {{Partbox/CommandPod}} would set it to Command). With {{#ifexists:}} we could check if the part.cfg was moved and if not link to old path (without the category directory). Then add two or one Categories (Category:Partbox with unmoved part.cfg and optional Category:Partbox without category) so we know what articles we have to update. When all articles are up to date remove the #ifexists check (#ifexists is expensive) and both categories.

So something like:

{{#if: {{{category|}}}|
  {{#ifexists: Parts/{{{category}}}/{{{part}}}/part.cfg|
    [[Parts/{{{category}}}/{{{part}}}/part.cfg|part.cfg]]|
    [[Parts/{{{part}}}/part.cfg|part.cfg]][[Category:Partbox with unmoved part.cfg]]
  }}|
  [[Parts/{{{part}}}/part.cfg|part.cfg]][[Category:Partbox without category]]
}}

— xZise [talk] 13:39, 28 May 2013 (CDT)

My understanding of complicated templates is not too great, but what you wrote there looks quite good and is pretty much what I thought of. As for what to do with the existing files, I'd say that we use the category approach and just move everything... there's no good way around that. RoboJeb would be quite helpful for that though. We'd still have to enter the category param manually though, but that can be done by non-sysops, so it should get done quicker. --dgelessus ^{(talk, contribs)} 14:58, 28 May 2013 (CDT)

Coming to think of it, "category" can be quite misleading and could be mistaken for the editor tab. Maybe something like "topdir" or "supdir" (dir as in directory/folder) would be more useful. Also, should "GameData/Squad/Parts/" be included? After all, "Parts/" is in the old path as well. --dgelessus ^{(talk, contribs)} 15:03, 28 May 2013 (CDT)

Okay “category” may not be the best choice. And I would drop the first two directories. If we add plugin parts, there should be a plugin parameter which is is then by default Squad. (Afaik a mod/plugin part would go to GameData/<pluginname>/Parts/). Now I'm not sure if, but sometimes or always RoboJeb has to analyse the “category” parameter to determine the new directory. But I have no idea how the bot works, so maybe it is piece of cake. — xZise [talk] 16:16, 28 May 2013 (CDT)

I'd say that it would be better if we included the GameData/Squad/Parts/ in the part.cfg names, just to prevent having to do the whole moving all over again once those dirs might become important (maybe once DLCs get released they will get their own dir, along the lines of GameData/Squad_Colonization/. Or I'm just looking too far into the future ;) The param in the template can be added later, that's not an issue. --dgelessus ^{(talk, contribs)} 16:38, 28 May 2013 (CDT)

Another idea: how about having the part.cfgs as subpages similar to the partboxes? (e. g. Structural Fuselage/part.cfg) --dgelessus ^{(talk, contribs)} 10:58, 30 May 2013 (CDT)