Template talk:InfoboxShip

From Traveller Wiki - Science-Fiction Adventure in the Far future
Jump to: navigation, search
Wiki Navy.png

Notes (2019)[edit]

Two templates now exist:

- Maksim-Smelchak (talk) 12:33, 31 May 2019 (EDT)

Create comparison of the two templates with a transition phase plan.

- Maksim-Smelchak (talk) 13:08, 31 May 2019 (EDT)

Infoboxes 1 to 3 (2019)[edit]

Infoboxes 1 to 3
Row IBS-1 IBS-2 IBS-3 Remarks
X X X X None
- Maksim-Smelchak (talk) 05:44, 25 June 2019 (EDT)

Notes (2018)[edit]

Ship 1 Stock Template (Alphabetized):

{{InfoboxShip
|name     = 
|alsosee  = 
|architect= TBD
|caption  = 
|cargo    = 
|crew     = 
|cost     = 
|IOC      = TBD
|enlisted = TBD
|footnote = TBD
|g        = 
|hp       = 
|hpass    = 
|image    = Imperial Sunburst-Sun-IISS-Traveller.gif
|jump     = 
|lpass    = 
|marines  = TBD
|model    = TBD
|officers = TBD
|origin   = Third Imperium
|QSP      = TBD
|size     = 
|tdes     = 
|TL       = 
|type     = 
|usp      = TBD
|manufacturer= Various
}}

Experimental Ship 2 Stock Template (Alphabetized w/definitions):

{{InfoboxShip
│Name     =
│agility  = TBD
│armor    = (Armor type in tons)
│bridge   = TBD
│caption  = TBD
│cargo    = (in tons)
│compTL   = TBD
│cost     = TBD MCr
│crew     = TBD
│dateIOC  = (Initial Operational Capacity)
│defense  = (major defensive systems)
│footnote = TBD
│fuel     = TBD
│fuelproc = TBD
│G        = Maneuver / Sublight Drive (Sublight)
│Hp       =
│Hpass    = (HiPass)
│Hullcnfig= [per architect guides] 
│image    = [[file: Imperial Sunburst-sun-IISS-Traveller.gif]]
│jump     = Jump Drive (JumpDriv)
│Lpass    = (LoPass)
│Maneuver = Will replace G in InfoBoxShip2
│Mpass    = (MedPass)
│size     = [in tons]
│smallcrft= TBD
│stealth  = TBD
│streamlne= TBD 
│Tdes     = Type
│TL       = Tech
│type     = Military
│weaponry = Offensive systems.
│manufacturer= TBD
}}

Experimental Ship 2 Stock Template (Alphabetized):

{{InfoboxShip
│Name     = TBD
│agility  = TBD
│armor    = TBD
│bridge   = TBD
│caption  = TBD
│cargo    = TBD
│compTL   = TBD
│cost     = TBD
│crew     = TBD
│dateIOC  = TBD
│defense  = TBD
│footnote = TBD
│fuel     = TBD
│fuelproc = TBD
│G        = TBD
│Hp       = TBD
│Hpass    = TBD
│Hullcnfig= TBD
│image    = [[file: Imperial Sunburst-sun-IISS-Traveller.gif]]
│jump     = TBD
│Lpass    = TBD
│Maneuver = TBD
│Mpass    = TBD
│size     = TBD
│smallcrft= TBD
│stealth  = TBD
│streamlne= TBD 
│Tdes     = Type
│TL       = TBD
│type     = TBD
│weaponry = TBD
│manufacturer= TBD
}}

Edits and additions to the Template (2019)[edit]

Maksim, you asked me to add a few things to both the template and the underlying cargo tables. In reading through the existing template I have found a number of changes that could be made. I'm putting the list here for discussion:

  • Aerodynam: Since every rule set refers to this as Streamline, I think that make a better parameter name than the truncated Aerodynam.
  • Architect: In the original this was the Architect fee, part of the cost of creating a ship. Not all ship design system include this as a calculation. I am re-asserting this parameter as the fee (in MCr).
  • Canon: In all the other templates this is a simple Yes/No flag. I'm going to assume this is true here too.
  • Cost: Pedantically, this should be price, but every system uses Cost. There are three parts to the cost of a ship: Architect fees, price singly, and price in quantity. I've seen several ships trying to put both into this field. Cost will be assumed to be for singly, and add a costQuantity field. And architect parameter will hold the Architect fee.
  • Designer: The designer is a new parameter, holding the name of the person who created the design (if known). e.g. Ronald Klein. The ref parameter is for book references.
  • Design System: The designSystem is a new parameter. This holds the name of the design system used for the original design. e.g. Book 2, High Guard, MT, GT: Starships, T5, FF&S1, FF&S2, etc. The different design systems can produce different results.
  • Hpass / Lpass: These are assumed to be Staterooms and Low Berths (respectively). Some designs include barracks between these two. And small-craft may have seats (think airplane).
  • Illustration: Like Canon and Blueprint this will be a simple Yes/No flag
  • IOC : I wish the linked page would explain the IOC refers to year of starting operation. This will be only a year. Is there a corresponding term for when the ship leaves service?
- Tjoneslo (talk) 23:23, 23 May 2019 (EDT)

Thank you for all of your hard work and brainstorming.

  • I will respond back later.
  • Great ideas!
- Maksim-Smelchak (talk) 13:51, 24 May 2019 (EDT)

Modest Update Proposals (2019)[edit]

Thomas, feedback: Why don't we proceed with two new updates:

  1. InfoboxShip2: A gradual update of the older template along very modest lines.
  2. InfoboxShip3: A more differentiated update of the template with the ideas you have presented which are quite excellent.

FYI, a discussion like this is why the wiki style of comments works better. We can create a thread of discussion about each topic.
I dislike the idea of creating two new templates. There should be at any one time one infobox template to be used for a type of article. In the case, like this one, where we're making major changes we should have an old template, and a new template. The editors should be instructed to use the new template on new articles, and if possible update existing article to the new template as needed. With too many templates it becomes confusing as to which should be used.
- Tjoneslo (talk) 21:38, 25 May 2019 (EDT)

InfoboxShip3:
All of the ideas should be implemented exactly as you have proposed.

  • Aerodynam: Since every rule set refers to this as Streamline, I think that make a better parameter name than the truncated Aerodynam.
  • Architect: In the original this was the Architect fee, part of the cost of creating a ship. Not all ship design system include this as a calculation. I am re-asserting this parameter as the fee (in MCr).
  • Canon: In all the other templates this is a simple Yes/No flag. I'm going to assume this is true here too.
  • Cost: Pedantically, this should be price, but every system uses Cost. There are three parts to the cost of a ship: Architect fees, price singly, and price in quantity. I've seen several ships trying to put both into this field. Cost will be assumed to be for singly, and add a costQuantity field. And architect parameter will hold the Architect fee.
  • Designer: The designer is a new parameter, holding the name of the person who created the design (if known). e.g. Ronald Klein. The ref parameter is for book references.
  • Design System: The designSystem is a new parameter. This holds the name of the design system used for the original design. e.g. Book 2, High Guard, MT, GT: Starships, T5, FF&S1, FF&S2, etc. The different design systems can produce different results.
  • Hpass / Lpass: These are assumed to be Staterooms and Low Berths (respectively). Some designs include barracks between these two. And small-craft may have seats (think airplane).
  • Illustration: Like Canon and Blueprint this will be a simple Yes/No flag
  • IOC : I wish the linked page would explain the IOC refers to year of starting operation. This will be only a year. Is there a corresponding term for when the ship leaves service?

InfoboxShip2 (IBS2):
This would ideally be a more modest update:

  • Aerodynam: Since every rule set refers to this as Streamline, I think that make a better parameter name than the truncated Aerodynam.
    • IBS2 would leave this alone without changes.
  • Architect: .Architect fee...
    • This will become the designer in IBS2, I have been laboriously interviewing Marc to find these as in the Type S and am hesitant to update all of the templates. Other users have asked to convert this to fees. So, let's do it overriding my preferences.
  • Canon: In all the other templates this is a simple Yes/No flag. I'm going to assume this is true here too.
    • I would like to leave this as a text box rather than a boolian integer. Many of the entries have responses more complicated than y/n.
Specifically what are the considerations for Canon beyond yes/no. This field as a Boolean make for a useful search/sort field. And several other infoboxes also have the canon as a boolean flag. So if we need additional information around qualifying the canon state we should make sure it is added to all the places. And I would probably like to add a second ``canonDescription`` parameter to capture that. Though there would be only one field in the infobox for it. Tjoneslo (talk) 07:49, 26 May 2019 (EDT)
  • Cost: There are three parts to the cost of a ship: Architect fees, price singly, and price in quantity...
    • I am good with changes anyway you do it. It does makes sense as a three-part venture.
  • Designer: The designer is a new parameter, holding the name of the person who created the design (if known). e.g. Ronald Klein. The ref parameter is for book references.
    • I quite agree with you. Ref is for published sources... ideally. But, we still have homebrews to deal with. Dsigner can become the designer... sigh. ;-)
  • Design System: The designSystem is a new parameter. This holds the name of the design system used for the original design. e.g. Book 2, High Guard, MT, GT: Starships, T5, FF&S1, FF&S2, etc. The different design systems can produce different results.
    • Brilliant.
  • Hpass / Lpass: These are assumed to be Staterooms and Low Berths (respectively). Some designs include barracks between these two. And small-craft may have seats (think airplane).
    • What do you think? I think we need to expand to this:
      • PassLP: Low Passage
      • PassMP: Middle Passage or Working Passage
      • PassHP: High Passage
      • PassFW: Frozen Watch
I realized there are three sets of items here for consideration
There are accommodations used by both crew and passengers: ``staterooms``, ``bunks``, ``seats``, and ``lowBerths``. For the crew these are occupied by ``officers`` and ``enlisted``, ``marines``, no one, and ``frozenWatch``. For passengers these are occupied by ``mid/high passage``, ``steerage``, ``seatedPassengers``, and ``lowPassage`` respectively. In theory we should have these three sets of parameters and entries in the infobox. Tjoneslo (talk) 07:49, 26 May 2019 (EDT)
  • Illustration: Like Canon and Blueprint this will be a simple Yes/No flag
    • Ok.
  • IOC : I wish the linked page would explain the IOC refers to year of starting operation. This will be only a year. Is there a corresponding term for when the ship leaves service?
    • I updated the article awhile back. Added the other end of the equation:

Thanks!

- Maksim-Smelchak (talk) 21:06, 24 May 2019 (EDT)

Two New Templates (2019)[edit]

FYI, a discussion like this is why the wiki style of comments works better. We can create a thread of discussion about each topic.
I dislike the idea of creating two new templates.
  • There should be at any one time one infobox template to be used for a type of article. In the case, like this one, where we're making major changes we should have an old template, and a new template.
  • The editors should be instructed to use the new template on new articles, and if possible update existing article to the new template as needed. With too many templates it becomes confusing as to which should be used.
- Tjoneslo (talk) 21:38, 25 May 2019 (EDT)

I am going to agree to disagree with you here.

  • I think that this technique works if one is not willing to use newer communications techniques.
  • Otherwise, much more can be done much more quickly with a cooperate and collaborative technique.
  • This system creates bottlenecks and was pretty advanced for the 1990s. It's old school and often not in a good way in the late 2010s.
For a system that was developed and is used by hundreds of thousand of people across thousands of wikis can hardly be considered out of date or unusable. The copy / paste messaging system you insist on, also used by Facebook, was pretty advanced for 1970s technology. Tjoneslo (talk) 07:40, 26 May 2019 (EDT)

RESPONSES:

  • Ok. Fine with one template: InfoboxShip2 it is.
  • I get that rationale.
  • However the counterpoint is that we can't affect many types of updates quickly, even with automation.
  • We have a volunteer workforce and we can't get too demanding or we lose folks like Ron. Blame whatever we like, but the pace of change was primary factor in that stress.
  • Your rationale and strategy is decent with the idea of working one template to another, bu the idea of a third is for there to be a sandbox templat eto experiment and play with.
For sandboxing templates I recommend the process used in Forum:SophontData infobox update. Tjoneslo (talk) 07:40, 26 May 2019 (EDT)
  • And in that notion and by that rationale, we have to go with bracketed hyperlinks. Volunteer users don't need the extra complication.
  • Otherwise we lose functionality.
Correct. So the simpler we make the process for the volunteers the better. Tjoneslo (talk) 07:40, 26 May 2019 (EDT)
  • I suggest that we implement the image category as a hyperlinked bracket item for large items such as ship and vehicles for now.
  • We can hold off for periodicals and lesser items like robots for the time being. Eventually smallarms will go that way as well.
Well, the Template:InfoboxBook2 uses the bare file and that seem to work for everyone, and looks reasonably for all of the hundreds of book. So there is that Tjoneslo (talk) 07:40, 26 May 2019 (EDT)
  • I realize that that creates more complication with cargo tables, but ease of user utilization is more important.
- Maksim-Smelchak (talk) 06:28, 26 May 2019 (EDT)

Thomas, Please expand on this:

  • Hpass / Lpass: These are assumed to be Staterooms and Low Berths (respectively). Some designs include barracks between these two. And small-craft may have seats (think airplane).
  • What do you think? I think we need to expand to this:
    • PassLP: Low Passage
    • PassMP: Middle Passage or Working Passage
    • PassHP: High Passage
    • PassFW: Frozen Watch
I realized there are three sets of items here for consideration
  1. There are accommodations used by both crew and passengers: staterooms, bunks, seats, and lowBerths.
  2. For the crew these are occupied by officers and enlisted, marines, no one, and frozenWatch respectively.
  3. For passengers these are occupied by mid/high passage, steerage, seated, and lowPassage respectively. In theory we should have these three sets of parameters and entries in the infobox. Tjoneslo (talk) 07:49, 26 May 2019 (EDT)

TJonesLo Oldness (2019)[edit]

Just because software is old does not make it bad. Just because software is new does not make it good. Software engineers and UI designers are known for their overlooking, or ignorance of, the innovations of their own fields. So the 1980's development I'm advocating and using is the idea of threads. Having an in-depth conversation about a topic, especially when trying to resolve differences, requires context. And the design of many modern software packages (Facebook, Instagram, Disquis) have forgotten this important innovation. Or have deliberately ignored it in favor of more important functionality like ad count.
Having an in-depth conversation about a topic, especially when trying to resolve differences, requires context. So having the context of a discussion scattered across a news feed disrupts that context. Or in this case, spammed all over the page. And you seem to grasp that in the sense that when you cut/paste your questions you include some parts of the discussion. So all I'm asking is you take the next step. Learn that you can keep the thread all in one place.
- Tjoneslo (talk) 11:07, 27 May 2019 (EDT)

Ok. Thanks.

  • Q1. (Query) May we please add frames or lines to the infobox as well?
  • Q2. Just build it out as InfoboxShip2 and leave the old InfoboxShip active, please.
    • We now have nearly 2,000 entries and it will take Adie and I sometime to update them.
    • Having both concurrently active is a good idea.
  • Q3. Added the EOS that you wanted. IS that adequate to what you envisioned?
  • P4. (Point) I am really more of a doer than a chatty Cathy. The wiki already had a decade of lots of analysis paralysis and committee crud.
    • I will participate in your chats as you like. But, I think we need to push forward. We now have momentum and increasing community support.
  • P5. We have also been centralizing Referral Trees to standardize that material and still retain accessibility.
- Maksim-Smelchak (talk) 12:00, 27 May 2019 (EDT)

Agility (2019)[edit]

I did a quick check through the various starship construction and combat systems. Agility is specific to the CT High Guard rules. And because it's only use is in the combat system this puts it firmly into the game mechanic category.

- Tjoneslo (talk) 06:48, 7 June 2019 (EDT)

There is overlap between game mechanic and storyline setting for almost all CT and Highguard characteristics. I have discussed it with our major stakeholders. I am also in discussion regarding MGT Specifications with trusted stakeholders.

- Maksim-Smelchak (talk) 11:27, 7 June 2019 (EDT)