Difference between revisions of "Template talk:Infobox/Part"

Revision as of 22:47, 8 June 2013

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|}}}|
  {{#ifexist: 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)

Could cause conflicts and it wouldn't allow a user to see where the file is on the local copy. — xZise [talk] 11:33, 30 May 2013 (CDT)

If there are no objections or further suggestions, here's what I would implement as part.cfg path: GameData/{{{plugin}}} or Squad/{{{parent}}}/{{{part}}}/part.cfg. This is obviously not valid wiki syntax. The actual line will be a lot longer, because it will include support for the old formats and missing params. --dgelessus ^{(talk, contribs)} 16:48, 31 May 2013 (CDT)

Actually my code should work (if you replace category with parent). I'll add it then with both error categories. — xZise [talk] 05:20, 1 June 2013 (CDT)

Okay I added the parameter. Now we only need to set the parent parameter for the subtemplates. I also had to change the code slightly (in its logic): The old code linked to the old folder structure even when the old file doesn't exists. So it now only links to the old folder structure when the new one doesn't exists and the old one does exists. In all other cases (except parent isn't set) it links to the new one and may create a red link like Mk1 Lander Can. This added a new #ifexist, but as those should be removed anyway, it shoudl be okay. — xZise [talk] 08:19, 1 June 2013 (CDT)

Rename to “Template:Infobox part”

At the moment we have only two infobox templates (apart from the many many {{Partbox}} subtemplates) but maybe it would be better, when we follow the Wikipedia naming for infoboxes and name them “Template:Infobox <described object>“ like Template:Infobox planet. Of course I would recommend to create redirects, so not all part pages break. But for example when there is already the need to update all templates like with the new parameters for {{Partbox/CommandPod}} (added linPower and rotPower) also the name could be updated. And for example {{Planetbox}} should be renamed to Template:Infobox planet and there are already two parameters which were added but rarely added to the template using pages. — xZise [talk] 17:05, 8 June 2013 (CDT)

Maybe this would be useful: something like Template:Infobox is just a basic infobox and for example the partbox (which I'd rather put under Template:Infobox/Part) is based on that. That would eliminate some formatting in the specific infoboxes. --dgelessus ^{(talk · logs)} 17:47, 8 June 2013 (CDT)