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 {{Infobox/Part/CommandModule}} 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 should be okay. — xZise [talk] 08:19, 1 June 2013 (CDT)

A few days ago I changed it a bit: It now always link to the new place (if parent is set) and only optional to the old place (if there is still a file) with a little note why there are two. — xZise [talk] 17:12, 14 December 2013 (CST)

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)

I'm not sure what exactly the Template:Infobox could provide, but I won't use the directory structure, as Template:Infobox planet and Template:Infobox part are very different (apart from Template:Infobox part/Command Module). But of course maybe other could comment on this. — xZise [talk] 19:07, 8 June 2013 (CDT)

Oh, the partbox and planetbox aren't that similar afer all, just had to look at the two side by side. However the few common characteristics of the boxes are the grey title bar, then the image with subtitle, then lots of rows with statistics and then a "footnote" line. Maybe I'll manage to create a mockup Template:Infobox in my userspace, that might help you understand what I mean. --dgelessus ^{(talk · logs)} 07:37, 9 June 2013 (CDT)

There. I have to admit that it is quite useless for the existing boxes, but if there should be the need for new ones (scenarios?) it would definetely help. --dgelessus ^{(talk · logs)} 08:57, 9 June 2013 (CDT)

Nice, and it looks like it will work good with the part box, but the planet box (btw. this should be named Infobox celestial body) would need an update (as a row has there only two columns). I may move it into the official Template namespace. — xZise [talk] 10:08, 9 June 2013 (CDT)

Okay, I now created User:Dgelessus/Infobox/Line. Similar to Partbox/Line, but without the fancy atm and vacuum stuff. It just generates one to three table columns. Also removed the subtitle and footer from the infobox, as they can now easily be generated using the line template. --dgelessus ^{(talk · logs)} 12:50, 9 June 2013 (CDT)

The infobox line is now completely dynamic. Here's what it does:

• 1 param: all three cells occupied by the first param.
• 2 params: cells 1 and 2 are used by param 1, cell 3 is used by param 2. Looks as if there were only two columns.
• 3 params: each param has its own cell.

This should now also work with the celestial box. Please tell me if wouldn't. --dgelessus ^{(talk · logs)} 16:27, 13 June 2013 (CDT)

"additional" parameter?

Is it used anywhere? I haven't seen it anywhere yet and don't think it is that useful either. Why would you need to separate a part of the stats from the rest? --dgelessus ^{(talk · logs)} 14:54, 28 June 2013 (CDT)

Yup I added it when I migrated the Small Hardpoint. — xZise [talk] 15:32, 28 June 2013 (CDT)

Wouldn't a "crossfeed" param be more appropriate? It doesn't really appear to be working anymore either. --dgelessus ^{(talk · logs)} 15:46, 28 June 2013 (CDT)

When I added it I wasn't sure if this will be the only usage. So if another part also “supports unicorns” it is easily possible. And I fixed it btw the same way I fixed the more parameter. — xZise [talk] 16:09, 28 June 2013 (CDT)

Ah look what I've found: Template:Infobox/Part/Strut — xZise [talk] 18:13, 28 June 2013 (CDT)

tech tree

I think, the tech tree should be added to this box somehow. And the tech tree level and the name of the research node should be given (and linked). --Simplimus (talk) 03:11, 4 December 2013 (CST)

Might be possible, but the current layout does make it harder (every subtemplate has to support this). If somebody has a good suggestion how to fix this, I'm happy to hear it. — xZise [talk] 10:30, 4 December 2013 (CST)

Okay before we add anything we should maybe determine what there should be added to minimize the edits required. I would simply add the research node's name. I mean the tech tree level doesn't really tell you how hard it is to get there, and the it is either in the technology tree article or the research node article itself (as the research node would be linked). — xZise [talk] 06:39, 6 December 2013 (CST)

Rework the template?

Hi, currently I think there might be a better way to handle these part infobox templates. For example the two research parameters needs to be added to all those subtemplates. And as soon as a new property for all parts arises, this needs to be done again. My primary objective with all those different subtemplates was to have a similar look: All liquid fuel engine would have the same infobox with the same parameters (obviously different values). But now with the R.A.P.I.E.R. Engine there is another problem: What if a part is a combination of two.

I suggest that there is only one Infobox/Part template in which you can add multiple (but usually only one) boxes. One box for example would be all liquid fuel engine specific properties like specific impulse, fuel consumption and thrust. Now with the RAPIER Engine you would simply add two of those boxes: One for the LFE and one for the jet engine. And to be clear: I don't mean like I temporarily added it with two actual infoboxes but similar; all redundant information (research etc.) is only added once.

If somebody has any (or a better) suggestion please let us now so maybe we can avoid another “failure”. — xZise [talk] 10:56, 17 December 2013 (CST)

Okay I created an example on User:XZise/Part which uses this template and as the boxes User:XZise/Part/LFE and User:XZise/Part/JE. The current problems with this system are:

• Most of the names are already used. For example User:XZise/Part/LFE should be in {{Infobox/Part/Engine/Liquid}}. But there might be a workaround: Use the same name for both templates, but if the mass parameter is determined it treats it as the old version. As long as not all templates are updated this might be a solution.
• There might be multiple properties with the same name (e.g. maximum thrust). Maybe there could be headers added like in {{Infobox/Body}}. I added those manually, in the final version, those headers should be integrated in the subtemplates. Maybe rearrange them, that Research and Since version are not below the specific ones (or separate them with another header).
• Also some parameters are superfluous (e.g. vectoring). This might be only the case here, but maybe future other hybrid engines have different vectoring values?

— xZise [talk] 14:55, 18 December 2013 (CST)

As I submitted this: The tank templates might be a problem. Unfortunately in the part configuration the mass is actually the dry mass. Currently the template is calculating the wet mass using the dry mass and the mass of the resources aboard. As those boxed subtemplates can't change the mass this needs another solution. As command pods appear to have RCS as well it makes things worse (I guess the mass given in the cfg is again the dry mass). — xZise [talk] 14:58, 18 December 2013 (CST)