• I'd like to start this thread to gather some ideas on what to do with Infobox_shop. Clearly, the current one is not cutting it, and I think the format used for the locomotives and wagons won't work quite as well for buildings and decorations.

    Starter topics for discussion:

    Should we change the name of the template to something that makes more sense? Infobox_StationItem?

    What is the full list of information that needs to be incorporated for a building/decoration?

    What should the layout look like? Should we restrict the image size in a similar manner to locomotives and wagons?

      Loading editor
    • I have tried to gather the information I see needed in the infobox for station items. Most stuff is grouped as in the infobox for trains. I am not sure if the contractor shop information can be incorporated into the infobox or should remain as separate boxes like now. Regarding the general layout you are probably right that the layout of train infobox will not work entirely, although information to display are almost the same. The big issue is probably the image that will not fit into the dimensions available in the train infobox.


      • type (Decoration or building)
      • pass /hr (left out for decorations and special buildings)
      • size (left out for decorations)
      • Ratio (pass / hr) / size (calculated) (left out for decorations and special buildings)
      • Theme (Theme based on the look of building/decoration)
      • ThemeRequired (yes or no if the above theme is required to build)

      Purchasing Information

      • Shop Info: Gold
        • Cost
        • Build XP
        • Level
        • Limit
      • Shop Info: Gems
        • Cost
        • Buy XP
        • Level
        • Limit

      Award Information

      • Award From
      • Limit (shown in buyback shop)
      • Buyback Cost
      • Buyback Level (might not be needed, so far I have only seen items with Level 1 requirement in buyback shop)

      Offer Information (zero or more)

      • Offer type (special, vintage, ??)
      • Offer date
      • Cost
      • Build XP
      • Level
      • Restrictions (Limit, theme?)

      Other Information (for required by contracts and bonus for special buildings)

      Contractor Shop (zero or more)

      • Contractor name
      • Pass / hr
      • Size
      • Ratio
      • Cost
      • Build XP
        Loading editor
    • Concerning Lumbye's list:

      • Size is NOT left out for Special Buildings.
      • Ratio should be calculated, of course, instead of input. I recommend using Template:Decimals with decimals set to 2 to give everything a consistent look. The template will accept an expression, so that can save some coding. If you also want to use formatnum on the output, you can use Template:Formdec as a shortcut.
      • Theme should be included (possibly even required in TemplateData) for all buildings and decorations. They all have one.
      • We should include an additional parameter for 'ThemeRequired', or something to that effect. Input could be "yes" if the theme is required to purchase the item, and it could default to "no" if left blank.
      • Offer Information could easily be duplicated from Template:OfferLoco. I've already included references to Template:OfferShop on several pages, even though {{OfferShop}} doesn't exist yet.

      My opinion on images is that we should make them fit our infobox. We resize the locomotives, and some of the buildings images are just too big, anyway.

      I like the idea of contractors being part of the infobox instead of separate infobox. I have no ideas on how to implement that, though.

        Loading editor
      • Size is of course required for special buildings as well, I have fixed the mistake in my list.
      • I have incorporated your suggestion for theme in the list.
        Loading editor
    • I have created a first draft for Template:Infobox_stationItem duplicating the layout from Template:Infobox_train and Template:Infobox_wagon. A few things are however still not working properly.

      • Cost amount and icon is not split into two columns so that they align properly with the buy xp amount and icon. It is rather tricky to do that when using the current cost template. One possibility would be to create an additional cost template that could handle putting the amount and icons in two different cells. It however seems a bit messy having two different cost templates.
      • Contractor shop info is still not integrated into the infobox.
      • Image size might still need a bit of adjustment.
      • No separate offer template. Currently I have tested using Template:OfferLoco which seems to work fine. Is there a need for offer templates for each different infobox? Currently Template:OfferLoco and Template:OfferWagon looks identical.
      • Documentation page is not completely done. There are still many leftovers from Template:Infobox_train/doc that was used as basis.
        Loading editor
    • Please create a test page with some examples, using your template, so we can see what you are talking about. Sometimes text doesn't quite do it justice.

      We should create a separate Offer___ template for the items. I know it doesn't make sense, because they are currently all the exact same, but the naming scheme helps make it clear, and it gives us leverage for improvements in the future. I'd rather do it now, and have everything cleaned up nicely, than have to go back and change everything over later..again..

        Loading editor
    • Infobox StationItem? OfferStationItem? I sincerely hope that those are working names only. "Shop" is much shorter, easier to type, and easier to remember than "StationItem".

      I noticed that Gold Depository (which is using Template:Infobox stationItem) belongs both to Category:Under Level 90 Special Offer and Category:Under Level 90 Special Offer 14 Mar 2014. I have no idea why, even after looking at the source code for Template:Infobox stationItem. In my opinion, having separate categories for each date would get very messy very quickly, and it is completely unnecessary.  Just my input.

        Loading editor
    • TheRealPella
      TheRealPella removed this reply because:
      Quoted by mistake. Intended to edit.
      02:36, March 17, 2014
      This reply has been removed
    • That was me testing a way to more easily find old offers to complete the tables on Category:Special Offer and Category:Vintage Offer. I admit it does look messy and have therefore removed it from Template:OfferStationItem.

        Loading editor
    • It's been a while since any progress or discussion happened on this topic. Anyway, something just occurred to me, so I thought I'd mention it.

      What about including Discounted Cost as part of the infobox? This isn't an issue with the locomotive or wagon infoboxes, so we've never considered it before. With Shop items, it's a consideration for buildings but not decorations. (One hundred percent of everything we buy in this game, we buy in the Shop. I have no idea how the term "Shop items" came to refer to buildings and decorations and nothing else. At any rate, that's how I'm using it here.)

      So, should we include Discounted Cost in {{t:Infobox shop}}? If so, how would we format it? Would we format cost differently for buildings and decorations, since buildings use it and decorations don't?

        Loading editor
    • I have some time, so I'm picking this up. Let's change it to Infobox_Item. Makes more sense anyway. It will allow us to search for pages using the other templates and convert them over. I'll be doing tests over the upcoming week.

      Having said that, props to Lumbye for having done most of the work to get this project started. I'm going to tweak the format a bit. Added flags in, we have some work to do on those now that they can be purchased.

        Loading editor
    • Should we maybe make a seperate template for the flags? Certainlly based on the Item template but their properties are different than buildings and I could see them changing again in the future rather than the builders or decorations. Just a thought to "future proof" the templates. However being the template novice that I am, I'll defer to the experts on that one.

        Loading editor
    • I think it's easy to combine the two. I'll throw out some examples when I'm ready.

        Loading editor
    • As long as we're adding items that Infobox_Item can handle, how about adding themes to the mix? Unlike the flags, they don't have any "extra" or "different" properties from buildings or decorations. In fact, they have fewer properties, which should make them even easier to handle.

      Also, I think Infobox_Item needs to show Discounted Cost. It's easy to calculate, especially with templates doing the dirty work for us. Below is a random list of my opinions on the subject. As always, they are open for discussion and negotiation with the community.

      • Reminder: The below are Pella's opinions, not statements of fact.
      • Only items that get discounts, such as buildings and themes, should display a Discounted Cost section. Decorations and other non-discounted items should skip it entirely. This is easy, since it's how most of our major templates work already.
      • Example cost sections
        The infobox should list Cost, then Discounted Cost, then Buy XP. If you need a visual, please consult the screenshot.
      • The template should use the correct discount (duh!), based on the type of item.
      • The "Discounted Cost" header should be a link to Sam's page for buildings or the Stock Exchange page for themes. Alternatively, we can create an article page discussing Discounted Cost in general and link to that instead. (If we did that, we could consider changing other D.C. links on the site. But I digress.)
      • Infobox_Item should have a way to accept cost information in whatever form the user/editor wants to enter it. This is the most critical part of the whole idea. If this doesn't work, or if it works poorly, or if it's difficult to use, then we could lose a bunch of good editors. Or a bunch of good information. Or both.
      • Reminder: The above are Pella's opinions, not statements of fact.

      I'm guessing that the best way to implement that last item is simply to have multiple optional parameters for cost (regular full-price cost, already-discounted-by-Sam cost, already-discounted-by-Stock-Exchange cost). The template would check the parameters until it found some cost data, then do whatever it needed with whatever it had (calculate the discount or reverse the discount). I handle templates more easily than Mhommer does, but I'm not the expert that Katat0nyx is, either, so I'll definitely listen to other ideas. The goal, as always, is to do whatever is best for the community as a whole.

        Loading editor
    • Holy crap, has it been 4 months since I've worked on this? I blame Pella for not reminding me sooner.

        Loading editor
    • hehehe ... Yeah, well, Pella has had a few other things on his plate, too. Life moves pretty quickly. If you're not careful, you could miss it.

        Loading editor
    • I worked on this a bit today. To refresh everyone:

      Template: Template:Infobox_item

      Test page: User:Katat0nyx/KataExample2

      Reminder: Please do not edit these pages, make suggestions and I will take care of it. I've locked the template page down to registered users. As usual, once we are satisfied with the final product, the template will be locked down to administrator only access. This is nothing personal, but our wiki is very dependent on templates, and we can't risk vandalism on our primary templates.

      I disagree with adding themes to Infobox_item. If we want to template themes, they should be separate, because they are fundamentally different. They don't have stats. They have cost, and on top of that, a cost that is discounted in a different way than buildings (Stock Exchange instead of Sam, 20% instead of 10%). If we start considering templates for themes, I would think about templating extensions with them.

      The first thing you are going to notice on the example page is the lack of cost data. That is intentional, because Mhommer and I were trying to figure out how to handle items with a tall image. I finally settled on adding an 'image_pad' parameter, which can be specified to pad out the statistics section to match the image height when item images are very tall. Otherwise, the template tries to stretch each statistic row to match the image height and it looks weird.

      The cost section has been started, and it will most likely look very similar to the loco and wagon templates, so it should be relatively fast to finish. It's currently absent from the template. I'll get working on that.

      I took a different approach to this template, because I figure there will be some time in the future when someone else may wish to view or edit the template. I've added comments. Yes, that's right, comments. I know that's a first for us, but it should help to explain why/how things are done inside our templates.

        Loading editor
    • Added theme content: The following abbreviations were used..

      <!-- wes = Western Theme -->
      <!-- mea = Meadow Theme -->
      <!-- har = Harbour Theme -->
      <!-- ori = Orient Theme -->
      <!-- rio = Rio Theme -->
      <!-- met = Metropolis Theme -->
      <!-- nip = Nippon Theme -->
      <!-- lan = Land Down Under Theme -->
      <!-- bra = Bratislava Theme -->
      <!-- ven = Venice Theme -->
      <!-- lon = London Theme -->
      <!-- ber = Berlin Theme -->
      <!-- san = San Francisco Theme -->
      <!-- tra = Transylvania Theme -->
      <!-- ste = Steamtopia Theme -->
      <!-- pol = Polar Theme -->
      <!-- cha = Character Sign -->
      <!-- cou = Country Sign -->

      Note: I removed Black Hills Theme from the list, it is unused.

        Loading editor
    • Looks good, clean and consistant throughout the examples. Little thing, the decoration icon in the upper right looks smaller than the flag and building icons. Is that actually or just an optical illusion or are the icons really different in size and the size deltas are magnified when enlarged?

      Just a thought, do we want to break out flags into a seperate template? Just because their stats are significantly different from decorations and buildings and the images themselves are far more consistant in dimentions. I'm not the template guru at all so if it really isn't a big deal to leave them combined fine but if it makes things easier it would be a sensable seperation point. Also may lend a little more flexability if Pixel changes how flags work or attributes in the future.

        Loading editor
    • Fixed the Decoration template to increase the size of the icon.

      It's easy to unify flags, and I don't feel like there is any more danger to PF changing the flags again than there is changing anything else. Our entire wiki is based on assumptions that the in-game items won't change drastically.

        Loading editor
    • [Themes] have cost, and on top of that, a cost that is discounted in a different way than buildings (Stock Exchange instead of Sam, 20% instead of 10%).

      As suggested in my post on the subject, I don't think this is a roadblock. Infobox_Item already needs to check for the item type when displaying "Discounted Cost", because decorations don't have them and shouldn't display the field. If the template already checks for the item type to decide whether or not to show a discount, then how hard is it to have it apply the correct discount for the type?

      Even so, you raised more than just this one objection. If you think that themes are so fundamentally different that they should have their own template, then that's the way we'll do it. My thought process was simply that we could save time and effort by creating one template that does many things (like Infobox_Wagon does) instead of duplicating effort by creating multiple templates--which, in turn, could create confusion among editors. But hey, you're the template superguru, and you're the one who'll probably be creating the templates, anyway, and you're an admin besides, so ultimately, my opinion really doesn't matter.

      Hmm. Ya know, if I hadn't spent 10 minutes typing this, that last statement would convince me not to post it.

        Loading editor
    • Never mind. Just ignore me.

        Loading editor
    • I think the reason we decided not to do templates at all for extensions and themes, was that they didn't have enough information to warrant generating separate pages for them. If that has changed, I can work on it.

        Loading editor
    • You're correct about the lack of information being insufficient to warrant article pages. Most themes are also categories, though, which means they automatically get pages whether there's any information to put on them or not.

      I, for one, really dislike empty category pages. Apparently, I'm not alone, because someone (or multiple someones) manually created infoboxes on most of those pages. A few, like Western and Black Hills, contain descriptive information--again, probably just so the page wouldn't be empty.

      In addition, we recently edited the Themes page to remove dates of availability from the seasonal themes; those now reside on each theme's category page. I edited a few of the theme category pages to use the current Infobox_Shop instead of the manual infobox. See Transylvania for an example.

      SUMMARY: Separate pages for themes exist, whether we want them or not. Most, if not all, of the theme pages already contain a tiny bit of content, just so they won't be empty--including an infobox. In my opinion, adding themes to the new Infobox_Item will give the theme category pages simplicity and consistency, neither of which they currently possess.

      Of course, opinions differ. I apologize for my previous post, in which I became personally attached to my idea instead of remembering that ideas are things to be discussed, analyzed, and then either accepted or rejected, according to the needs of the community. If you think there's a better way to handle the theme category pages--even if it's to leave them as they are--I'll accept your judgment and move on. :-)

        Loading editor
    • BTW, just curious about something.

      As we all know, the Buyback Shop is gone. Therefore, there's no reason to display Buyback Shop information in our new Infobox_Item.

      Are we going to make any effort to preserve historical data about the prices of items in the former Buyback Shop? Is that too much work? Do we simply not care about that information anymore? Just because I can't think of a reason why anyone would want to look up that information doesn't mean no one will want it. :-/

        Loading editor
    • Something else I just remembered. The current Infobox_Shop uses the namespace prefix Image:. (For that matter, all of our important infobox templates use Image:.) Although this works, Mediawiki states:

      Images that are stored on a MediaWiki server are usually rendered by using the File: namespace prefix (but the legacy Image: namespace prefix is still supported as a synonym) as the target of a MediaWiki link.
      In my brain, the word "legacy" is almost equivalent to "deprecated". Their choice of words suggests that Image: may not work forever. Just a thought you may wish to keep in mind while designing the new template.
        Loading editor
    • A seperate little page for each theme i think if fine and even a dedicated little template (Infobox_Theme?????) if it makes ilfe easier and consistant. Might be overkill since new themes are not introduced all that often.

      I would like to preserve the buback shop as well. Not sure the best way to do that however. Maybe as a note in the notes field?

      I kinda hear the same thing with the comment of legacy. Definitely something we should watch for with the existing templates and keep it in mind as we make future template (or others do since I am such the template master . . . not)

        Loading editor
    • FYI: Changing from image: to file: is a few seconds fix, however it will take time to propagate through all the pages without doing a null edit on each and every page.

      Leaving the Buyback information is not problematic. I feel it's better to retain than to discard information, as long as it doesn't get in the way. There are things on our Wiki that the developers may not even remember any more, and I like the idea of that. :-P

        Loading editor
    • A thought/suggestion/recommendation/whatever you want to call it:

      The section of {{Infobox item}} that calculates a building's passenger-to-spaces ratio currently reads:

      {{#if: {{{pass|}}}|
      {{!}} style="background:{{#var:IB_STAT_SUB}}; height:15px;" {{!}} Ratio
      {{!}} style="text-align:right;" colspan="1" {{!}} {{formdec|{{{pass|}}}/{{{size|}}}|2}}
      {{!}} style="text-align:left;" colspan="1" {{!}} {{Passenger}}/{{Space}}

      In this state, if an editor included a number for the "pass" parameter and failed/neglected/refused/whatever to include a number for the "size" parameter, the template will choke when it attempts to divide by zero. I ran a little test, and the ratio field filled with 13 copies of an error message in bold, red text. Yeah, thirteen.

      To prevent the errors, we could add a second check to the first line:

      {{#if: {{{pass|}}}| {{#if: {{{size|}}}|

      Of course, we'd also need to close the second #if statement, making the end of the section look similar to:

      | }} |

      The second-to-last line could be expanded to three lines for consistency, if desired.

      Finally, to make it easier to read, plus make its format consistent with the format of the other #if statements in the template, I recommended this slight modification to the {{formdec}} call:

      {{formdec| {{{pass}}}/{{{size}}}| 2}}

      Have a nice day. ;-)

        Loading editor
    • I'll work on a Template:Infobox_theme, just to make things a bit easier on you guys.

      If we don't do null edits on every page, how much time will it take for sitewide propagation of "File:" vs. "Image:"? Is that something the server does during its spare time, or must a page be edited before it will update?

        Loading editor
    • I will impart what I know of the magic of page propagation. When you make an edit to a content page, it immediately forces the regeneration of the content displayed on that page. When you edit an image, it uploads the new image data to the wikia database, and at some point, when the upload has finished and verified, the new image will displayed when a user requests the image to be displayed (i.e. their browser doesn't just use a cached image already stored on their machine). Editing templates queues a wikia site for a background updating task which will determine which pages are affected, and queues those pages for idle updating, in which the content for those pages will be regenerated based on the current state of the template/templates and other content.

      When the Wikia servers are "idle", they undertake the task of updating any wikia sites which have been queued for background updates. The order in which a wikia site is handled, and even the order in which the pages of a wikia site are handled is in indeterminate order, if at all. Yes, there is a possibility that you will be put in the queue and never handled. Ever. The only way to circumvent this is to do a null edit and force the database to immediately regenerate all page data.

      What does this mean for template makers? It means that you better have your template 99.99% done when you release it and start using it, because if you make changes, it may take a long time for those changes to appear on their own. If ever.

        Loading editor
    • I fixed the divide by zero. I don't want you to feel bad, because I appreciate you testing the template, but I totally ignored your fix because it seemed like too much typing and I'm lazy. I wrapped the call in a #iferror. No, seriously, don't feel bad. Please? It's just that, as a designer, I often feel like being a jerk to endear myself to the public.

        Loading editor
    • LOL ... Do I feel bad? No, of course not. I learned a little something about Wikitext today. I haven't used #iferror before. Although I knew it was there, I didn't think about it at the time. My only comment on using #iferror here is that it probably would benefit any editor (including us) who produced an error to have the function return some sort of "Hey, you screwed up" indicator in the field instead of a black hole.

      Am I confused? Uhh, yeah. My fix "seemed like too much typing" to you? I did all the typing, precisely for that reason. You haven't heard of copy-and-paste? :P

        Loading editor
    • Old business
      Concerning sitewide propagation of file: vs. image:, my opinion is that it's probably enough just to change the templates and let things propagate naturally. Some propagation will occur as we edit pages over the normal course of activity, anyway. If, at some point in the future, Wikia stops supporting the image: namespace, we can track down and fix any unpropagated pages then. I still believe that changing all templates that use image: to use file: instead is a good idea.

      New business
      Since we're cleaning up several issues with themes already, how about this? Most of our themes article pages are category pages. That's fine for themes that have Shop items within them. For themes that are purely aesthetic, though, it amounts to clutter. We have several category pages that never will have anything categorized into them.
      If I provide a list to you guys, can you/will you convert the pretty-station-only themes into pages in the main namespace instead of categories? Or is that something I can handle even though I don't know (yet) how to un-category a category? Or is this whole idea something I should forget?

        Loading editor
    • Award section is up and working. I need people to start testing to see what they can find. Parameters are:

      award: the contract or achievement that gives you the item

      limit: # you are awarded

      award_required_by: if the award is required by another contract/achievement

      cost_buyback and/or level_buyback: Old fields

      Let me know if there are issues.

      Next on the agenda are the regular Shop section, which requires modifications for buildings, and the Offer section.

        Loading editor
    • I see something right off the top, without even doing any testing.

      The parameter "limit" is confusing.

      • Some items are awarded more than once. For example, see *Gresley LNER*. It would show separate "limits" of 4 and 3, instead of the true limit of 7.
      • Some items are awarded and are available in the Shop. For example, see *Gresley Composite*. It would show a "limit" of the 1 awarded instead of the true limit of 5.
      • Some items present both of the above issues. For example, see Gresley Composite. It would show two separate "limits" of 1 each, when in fact it has no limit at all.

      I recommend using a different term for the number of an item rewarded. To make things a little easier for editors, the template could test for a separate {{{limit}}} parameter, and, if not present, use the number rewarded as the limit. After all, that's usually the case, which I'm sure is why you built the template that way in the first place. ;-)

      Edited to add: I just realised that items like Gresley Composite will be especially tricky. If you do build the template to use the number rewarded as the limit in the absence of a separate limit parameter, and since the current method for indicating the lack of a limit is to leave the limit parameter empty, how do we indicate that such an item has no limit?


      • Editors could input limit = 0. The template would test for this and, if present, not display the limit section.
      • Editors could input limit = none. The template would test and not display as above. This option has the advantage of being more intuitive to editors.
      • If the designer/programmer has a different idea he thinks is better, go for it. I got you thinking about it; you decide what is best.

      In addition, if some overzealous editors decide to insert limit = 0 or limit = none or whatever into every {{Infobox item}} they create, it won't hurt anything, even if it's technically incorrect.

        Loading editor
    • Concerning your next tasks of the Shop and Offer sections--specifically accepting and displaying cost data--I've devoted many hours of thought to the subject of how to get two sets of output from one set of input. With the old res1= and amt1= pairings, it would be child's play. Now that everyone are used to using {{Cost}} and its new variants, it's not so easy anymore.

      One option, of course, is to require editors to give the same cost data twice, using different parameters. I dislike this option for two reasons. First, I'd rather we design a slightly more complex template that processes the input twice than ask every editor to input the same data twice in every template. Second, this option would require that the template allow for four different parameters for cost data: Full, Full-to-convert-to-discounted, Discounted-to-convert-to-full, and Discounted-to-display-as-is. If any of that confuses you, just think about how many potential new editors will be even more confused, give up, and never contribute. If you then consider that many items have Shop and Offer data, Shop and Award data, or data from multiple Offers, and that every set of data would require two sets of cost input, even we "old-timers" could start burning out.

      The biggest problem with accepting one set of cost data is that all of us are accustomed to assigning a template call as an argument for a parameter. For example, |cost = {{cost|gold=3|wood=5}}. We've been giving double data in tables, using {{Cost}} or {{CostNoSam}} for one column and {{CostSam}} or {{Cost}} for the next column, but we've never done that for infoboxes. If we send a cost parameter using {{Cost}}, there's no easy way for {{Infobox item}} to take that same input and send it to {{CostSam}}--if it's even possible at all.

      I've been working, testing, and researching. I've made a bit of progress, though I still don't have a working solution. I'll accept ideas, assistance, or even a slap on the back of the head and a "Yeah, I already figured it out." In the meantime, I'll keep looking for an answer that doesn't involve any of those three things, just in case. ;-)

        Loading editor
    • Okay, I found the answer I was seeking. Unfortunately, it's not the answer I wanted.

      I found a way to allow a user to input a cost with any chosen delimiter, such as a slash, and for the template to create a properly formatted string. The template then passes this string both to {{Cost}} and {{CostSam}}, or whatever other templates are appropriate. Pretty cool.

      Here's the catch.
      Meta Wikimedia states: "Braces, pipes, and equals signs which are produced by expansion are taken as just characters, not parts of structures". In plain English, this means that the string my template created--which includes | and = characters (because that's the way we write a {{Cost}} call)--never gets processed by {{Cost}}. Bummer.

      At this point, the only options I see are:

      • reverting to the old res1= and amt1= system, or a variant thereof.
      • asking the editor to input cost data twice for each infobox.

      Anyone else see another alternative?

        Loading editor
    • Of course, as soon as I go to bed, my brain comes up with a brilliant idea for a solution. Well, my brain and I think it's brilliant. We'll type it up quickly, and you guys can tell us whether we're brilliant or daft. ;-)

      {{Infobox item}} would be set up with three cost parameters. Each editor would use two. They would appear in the blank template in this order:

      | Scost= 
      | Fcost= 
      | Dcost= 

      The parameter names are short for "Sam cost", "Full cost", and "Discounted cost", respectively.

      • If Sam is complete, the editor enters:
      1. | Scost= {{Cost|<cost seen on screen>}}
      2. | Fcost= {{CostNoSam|<cost seen on screen>}}
      • If Sam is not complete, the editor enters:
      1. | Fcost= {{Cost|<cost seen on screen>}}
      2. | Dcost= {{CostSam|<cost seen on screen>}}

      Whether an editor has completed Sam's contracts or not, every editor will use {{Cost}} first, then use a different template on the line immediately below it. Every editor will have an entry for Fcost, which always is the full cost of a building. The template does a quick test:

      • If it received parameter Scost,
        • then the infobox "Cost" field displays Fcost and the "Discounted Cost" field displays Scost.
        • else, if it received parameter Dcost,
          • then the infobox "Cost" field displays Fcost and the "Discounted Cost" field displays Dcost.
          • else, display an error message.

      So, whaddaya think?

        Loading editor
    • Am I a nitpicker? Hell yes! That's what I do. And believe me, the detail geek isn't always popular, but he's always necessary.

      The times, they are a-changin', and we here at TrainStation Wiki ought to change with them. I've noticed that two of the terms we use here appear to be outdated, and it could be a good idea to do something about it.

      • Throughout the TS Wiki, items we purchase in the game carry a "Gems Cost", a "Regular Cost", or both. In many places, the word "Purchase" is used in place of "Cost".
        • The word "regular" indicates that any other option is irregular, strange, or abnormal. Especially considering how many items in the Shop are available for gems only, I think we're doing ourselves and our users a disservice by giving that impression.
        • I propose changing the concept of a "Regular Purchase" to a "Materials Purchase". Yes, I realize that the term "materials" technically doesn't include gold, but it was the most accurate term I could find while keeping it short. If you have a better idea, let's hear it.
      • The game no longer uses the term "award". The new term is "reward", and it has been for a long while now. We've started using the new term in several places, but the old term persists in our infoboxes and categories.

      Will changing these two things be easy? No way. Changing "award" will be an enormous project that really will require a group effort.

      Will changing these two things be worth it? I believe so. It will bring huge portions of our site up to date with the new look of TS, which translates into new users trusting that our site has current information.


        Loading editor
    • Jeezh, I didn't mean to take over this thread. Really...

      The template should accept and display separate input for materials limit and gems limit. A few of the 5th Av. buildings have different limits for materials and gems. They create a unique case where players may purchase up to both limits, essentially adding the two together.

      For example, see 5th Av. Helios. The gems limit is 3, and the materials limit is 2, for a total limit of 5. However, {{Infobox shop}} isn't designed to give this information. Instead, it shows only a limit of 3.

      Since almost all items have matching, non-adding gems and materials limits, I don't think it's necessary to make the template flip over itself to show the total limit of 5 in these extremely few cases. The Notes section can take care of that. All we need the template to do is show both limits.

        Loading editor
    • Katat0nyx wrote:
      Award section is up and working. I need people to start testing to see what they can find. Parameters are:

      award: the contract or achievement that gives you the item

      limit: # you are awarded

      award_required_by: if the award is required by another contract/achievement

      I have noticed that there are some items that are awarded multiple time from different contracts. Can the limit field or award handle multiple entries? Likewise some items are used in multiple contracts so we will need to be able to put multiple entries in the required by field as well. Now had I bothered to read the entire thread before commenting I would have noticed that Pella already covered this topic.

      That seems to be a more challangeing obstical. I agree with the basic idea that nobody is going to want to enter the cost multiple times. Give that this is going to be a new template we certainlly can creat a new cost entry struture. My quick thought would be a sturucture similar to the original one "amt1 = , etc." and an additional field of "SamComplete = Yes or No". Given those parameters would the information be clean enough to allow the template to do all the math?

      Nitpicking :)
      I like the idea of maintaining consistancy with the game. Again since it is a new template using Reward inplace of Award is a good idea. I don't think we immediately need to go back and revert the entire site, we can handle that at a later time.

      As for purchases, I would lean more toward Gem and Material or even Gem, Material and Gold since that will make it very obvious the parameters we are looking for. Again, we can establish the standard in this template and worry about converting the rest of the site at a later date. Not ideal but makes it a more bite size managable task.

        Loading editor
    • Mhommer wrote:
      Given those parameters would the information be clean enough to allow the template to do all the math?

      Yes. Super clean and super easy. The template would put it all together essentially like this:
      Cost: {{Cost|{{{res1}}}={{{amt1}}}|{{{res2}}}={{{amt2}}}

      Discounted Cost: {{CostSam|<do it all again>}}
      If | SamComplete= y, then it would use {{CostNoSam}} and {{Cost}}, respectively, instead. Also, the final code probably won't look exactly like the above because the template needs to test for the number of res# parameters present. But you get the idea. As I wrote in one of my posts on the subject, splitting the input into six lines makes this task child's play. The biggest drawback, again, is lack of consistency with something used everywhere on the site except in this new template--that something also generally considered much cleaner and easier to use than six lines of input.

      One side note about cost input, though. I didn't make a special announcement about it because it didn't change the existing functionality, and I haven't made casual mention before now because there wasn't a truly appropriate moment. Now there is.
      I modified {{Cost}} and all four of its offspring to accept the same four-letter abbreviations that {{Infobox wagon}} accepts for type of cargo carried, in addition to the input they already accepted. Any user, anywhere, at any time, may use "bric", "marb", or "sili", for example, within any {{Cost...}} template. You're welcome. ;-)

      Mhommer wrote:

      Nitpicking :)
      I don't think we immediately need to go back and revert the entire site, we can handle that at a later time.

      Again, we can establish the standard in this template and worry about converting the rest of the site at a later date. Not ideal but makes it a more bite size managable task.

      Agreed, and pretty much what I meant. It all needs to be done, it all should be done as quickly as we can get to it, we need to bring the community together to work on it as a group, AND attempting to do everything within a week of releasing {{Infobox item}} is stupid. We need to plan each segment of the overall project similarly to how we're planning this. That way, we can find the issues and deal with them before we actually start diving in, making it quicker and easier to complete each segment. RL and other considerations mean that we should give ourselves well-deserved breaks between segments, too.

      Mhommer wrote:
      As for purchases, I would lean more toward Gem and Material or even Gem, Material and Gold since that will make it very obvious the parameters we are looking for.

      I see your point. So then, headers within the infobox of "Gems Purchase" and "Gold & Materials Purchase"? And what about the parameters within the template itself?

      • | cost_gems=
      • | cost_gold_mats_res1=
      • | cost_gold_mats_amt1=
      • | cost_gold_mats_res2=
      • etc

      Is that what you meant?

        Loading editor
    • A FANDOM user
        Loading editor
Give Kudos to this message
You've given this message Kudos!
See who gave Kudos to this message
Community content is available under CC-BY-SA unless otherwise noted.