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)

Having a lot of time on my hands and seeing the move from subtemplates I began the work of adding the new part.cfg where they are missing. Using Category:Infobox/Part_with_unmoved_part.cfg as a reference the job seemed reasonable, adding new part.cfgs would remove them from that category and add them to Category:Infobox/Part_with_leftover_part.cfg where they later could be found and marked for deletion. (While the category has more than 300 pages they are usually grouped by 2 pages listing to 1, which makes the total pages around 100 which is far more doable). However I quickly realized this rose a couple issues:

Firstly, it seems like the categories aren't refreshed when the pages are added through a template. 2HOT Thermometer for instance seems to be a part of Category:Infobox/Part_with_leftover_part.cfg if you go to its page, but is not listed under the category. Are these automatically refreshed on an interval or do they have to be manually refreshed somehow to appear? Also, is it supposed to still be a part of Category:Infobox/Part_with_unmoved_part.cfg even if the new part.cfg is in place?

Secondly, the ingame category doesn't always match with the directory of a part.cfg file. BZ-52 Radial Attachment Point for instance is listed under Structural ingame but the part stackPoint1 is installed under Utility on the hard drive. Adding a parent parameter to the box template won't do any good as Template:Infobox/Part/Strut adds Structural directly with no option to overwrite on individual part box pages. Adding a simple parameter check to Template:Infobox/Part/Strut would be a easy fix in the meantime but I wondered if all subtemplates are supposed to eventually be replaced with a direct usage of Template:Infobox/Part like the sensors were.

Thirdly, I wanted to know if editing and updating the existing part.cfg to 0.23 and adding a move request is preferable to creating new pages for each part.cfg. I've already created 6 pages but realized in the long run I may be creating more work for sysops if an automated solution is planned.

I'll continue adding/updating the part.cfgs if needed when these questions have been answered. Artorp (talk) 02:28, 24 January 2014 (CST)

Hi Artorp. First of all, it is odd that the category don't update. Usually it takes some time but only in a matter of minutes. Now it's almost two hours ago. About your second question, I'm adding the possibility to overwrite the parent parameter. Because it will take some time to update to the new system and it will only be a minority of subtemplates which need this option added. Also I would recommend to only update the existing part.cfg, because a move request is not really necessary. I'll usually check once a day and then move those which were updated. Unfortunately there isn't really a bot available (User:RoboJeb doesn't run) so I guess moving will be a manual job. Maybe I'm able to get a bot running which checks sometimes if there are pages to move.

You may add a move request when also the directory in which the part.cfg is changes. For example the Mystery Goo Containment Unit got renamed. — xZise [talk] 04:21, 24 January 2014 (CST)

It was a little slow to update, purging various pages refreshed them though. The edited pages are removed from Category:Infobox/Part_with_unmoved_part.cfg and added to Category:Infobox/Part_with_leftover_part.cfg.

I will update the existing part.cfg pages to 0.23 and leave moving/renaming to you and others who have permission to do so. Artorp (talk) 06:33, 24 January 2014 (CST)

All part.cfgs have now been updated to 0.23. Quite a few still needs renaming/moving, my estimate is 100 pages. Getting a bot online would considerably speed up the process. Artorp (talk) 09:47, 24 January 2014 (CST)

Yeah I noticed that large sweep of updates. First of all thanks (!), I've been working on a bot which should automatically detect the parent parameter (if you used {{Part config}}). So the remaining problems are:

• Getting my bot the bot flag status (Though I'm an admin I can't change anyone's user rights). I'll contact the authorities to get User:BobBot to bot status (and sysop if bots can't move pages).
• Completing the list of subtemplates which set parent automatically (what you were noting above).
• Finish testing and programming (apart from the list the bot also really needs to move pages, but I'll run a dry test first).

So it's looking relatively good. If you are interested this is the script: https://gist.github.com/xZise/8602652 It is running with pywikibot and poorly documentated. — xZise [talk] 12:03, 24 January 2014 (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)

Impressive stuff xZise. If you want to keep both sets of infoboxes, could you save the new templates with a new name? eg Infobox/MODULAR/Part/Engine/Liquid ---Dogface (talk)

I actually don't think we should maintain the current sub templates, as they would be obsolete then. I've added {{Infobox/Part/Drymass}} which calculates the total mass with the given dry mass and fuels. It wouldn't be as good as the current version but would make the maintenance of the infoboxes for the tanks (and now also command modules) with the new system easier, because the dry mass is given in the part configuration. So it isn't necessary to calculate the total mass for the template but instead something like |mass = {{Infobox/Part/Drymass|0.025|lf=10|ox=12.2}} (=0.136) for the ROUND-8 Toroidal Fuel Tank. — xZise [talk] 05:39, 22 December 2013 (CST)

Okay I changed {{Infobox/Part/FuelTank/Xenon}} to the modular system (as there were only two parts and it uses dry mass). I added to the main template also the dry mass calculation directly (so {{Infobox/Part/Drymass}} isn't required anymore) utilizing the “two row” feature of {{Infobox/Line}} (like with specific impulse). Along with that I updated PB-X150 Xenon Container and PB-X50R Xenon Container to the modular system. There are some things which need to be addressed. The role and class parameters are not set. The role(s) is/are given with the module (so they are basically a bit lower). And as I don't know what this class parameter does I don't know what exactly to do with it. The parent parameter also needs to be set manually so depending on what we do with role and class this main template should have a type parameter which determine all three other parameters. But now I want to know what you guys are thinking. — xZise [talk] 16:21, 25 December 2013 (CST)