User talk:CPhoenix

From SotS2
Jump to: navigation, search

Template question

Hey CPhoenix, I need your help with something. I don't like how the tech links (ie what is the chance of getting Fusion Cannon from Plasma Cannon) are going to be in three different places, the Technology page, the Research Category page and eventually the tech itself. To that end, I thought that I would create a new page (formatted like "Plasma Cannon/LeadsTo Fusion Cannon" that would be the one place we would put the tech link information. I created a Template:TechRow to take the data and be able to display the tech linked from, the tech linked to or both, as well as the rest of the info. However, it's not quite what I want.

What I want is to put all of my tech link parameters on "Plasma Cannon/LeadsTo Fusion Cannon" and then instead of defining which tech link parameters I want to display in "Plasma Cannon/LeadsTo Fusion Cannon", I want to define which tech link parameters I want to display on the calling page. So I want to have Sandbox/Technology go and grab the "linksfromtechname", "researchcost" and all the Race Chance stuff, but not the "linkstotechname", from "Plasma Cannon/LeadsTo Fusion Cannon" and display it. But I want the Technology page to go and grab the "linkstotechname", "researchcost" and all the Race Chance stuff, but not the "linksfromtechname", from "Plasma Cannon/LeadsTo Fusion Cannon" and display that instead.

I'm totally stumped on how to do that. I thought that it would be as easy as just transcluding the "Plasma Cannon/LeadsTo Fusion Cannon" page to get the parameters into a specific template, but I can't get that to work. I'm out of ideas and found myself thinking in circles, so a fresh look at it would be great. --Nspace 19:22, 26 January 2012 (EST)

I think it might take a while for me to figure-out just what you want to do...I'll spend the next few hours looking at it. Before I get into it, please use camel case for variable names (e.g. "researchCost" and "linksToTechName") to help with readability. ;) Now let's see if I follow:
You want to put template parameters not in the template call on the page, but on a separate page that you can call to the template. You want to do this so that the same data isn't copied many times on different pages, so that if that data needs to be changed, you can edit one page (and then the displayed data on every page will follow suit). If I'm right, then before getting too far along, we should probably create a central index of these data pages in the SotS2 namespace, instead of subpages of various pages. It'll be easier for editors to find data pages, and ultimately less head-achy to find things when they go awry. Hopefully.
From what I gather, the problem is that the transclusion isn't happening before the template is called. {{subst:}} Solves that problem, but obviously isn't very helpful.
My suggestion would be to use a template that consists only of a switch function. You could think of it like a static object/dictionary of key-string pairs. Then we could write a template that feeds a given parameter to that switch template for whenever the called template needs particular data. If we did it this way, we'd have to be very, very good about keeping the switch table organized and well commented, with a good naming convention for keys so they won't conflict. It'd be more or less how the Rp and Fp templates I made work, but with a much longer switch function on a separate template page entirely. --CPhoenix (talk) 22:21, 26 January 2012 (EST)

Alright. The problem is that media wiki is passing all those parameters as the template's first unnamed parameter. Look at the bottom of this page and the corresponding templates. The template is transcluded, but it isn't then interpreted as if it were originally in the template call. *sigh* The way to fix this without new software involves a lot of extra work and a downright scary amount of wiki code. I'm not going there, neither should you. Because parser functions here aren't object-oriented...gods, I'm scared just thinking of it...

So, we need an extra extension. Rorschach is going to have to take care of it, but we need this to avoid headaches. (It's not installed here.) It allows you to label pieces of the page's source as sections that can then be called and transcluded by the function. This is the only way I can think of to keep multiple parameter settings on the same page. It might be possible to use the function to drill-down multiple levels, so all data could be kept on a single page, but I'm not sure about that. --CPhoenix (talk) 18:57, 27 January 2012 (EST)

  • The Labeled Section Transclusion extension is installed. Have a nice day. --Admin 19:05, 27 January 2012 (EST)
Damn. That was like, ninja speed. Go do your ninja moves with those darn images! :-p --CPhoenix (talk) 19:15, 27 January 2012 (EST)

Alrighty. Holding all the data on a single page is out, but using the section tags on separate pages for each object/dictionary for every item is doable. I suggest we use subpages of SotS2:Data for all of our data-holding needs, so we have a single place index for everything. We can index data subpages with a sortable table or something to keep it human-friendly. Then it's just a matter of calling specific pieces of those data pages with #lst from within templates.

It's best if we create a standard for how the pages will be organized first, e.g. what section names will be. The section names for #lst: should be stable across all data pages if we have any hope of building templates that use this central repository. --CPhoenix (talk) 19:46, 27 January 2012 (EST)

  • Thanks for all the work on this CPhoenix and thanks Rorschach for adding the extension. I'm going to test the TechRow template with the existing sandbox page data I've been playing with. As for standards, the only thing that I would like is that they be long enough to be easily understood. Using the tech links as an example "HC" would be too ambiguous (possibly either Hiver Chance or Human Chance) but HiCh and HuCh could work. Personally I think that making the section names the same as the parameter names of the first Template to need them would be very clear. We should also turn a thought to how much data we want to store this way. I had only planned on using the Tech links on multiple pages, though now that I look at it maybe a subset of the weapon data (not the attack stuff but the rest), the modules and a subset of the ship section data (not the armor stuff) could also work.
  • On a slightly different topic, I want to rearrange the tech and weapon page layout to look something like what I've been doing in the Sandbox page. What do you (and anyone else who wants to chime in) think? Any suggestions or ideas? --Nspace 23:39, 27 January 2012 (EST)

I don't know what you mean by "I think that making the section names the same as the parameter names of the first Template to need them would be very clear". If you mean to include a template name as part of the section names, I'd rather think that falls under the K.I.S.S. rule. ;) It also opens-up a potential issue of having two parameters that mean very different things but share similar names, like template1HiverChance and template2HiverChance.

  • Sorry, I wasn't sure what you meant by section names, so I assumed that you were talking about these sections
    <section begin=HiverChance/>Core<section end=HiverChance/>
on each subpage. What I was meaning is that the above section names should be taken from the parameters of the first template that we create that uses the data. Then all subsequent templates that need that data should have the parameters named the same as the section name that they are referencing. So for example Template:TechRow has a parameter named HiverChance. I've set up the Sandbox/LeadsTo Fusion Cannon page to have <section begin=HiverChance/>Core<section end=HiverChance/> that Template:TechRow uses to populate the HiverChance parameter. Now if we created a new template (say Template:TechBox) and we wanted to display the <section begin=HiverChance/> data from Sandbox/LeadsTo Fusion Cannon, we would create a parameter in Template:TechBox named HiverChance. Doing something like that would hopefully mean that anytime you stumbled across a Template parameter named HiverChance, it will always reference that one piece of data.
Now if you mean section names like this
==Tech Links==
on each subpage, then I don't think that we need to reference templates at all. I think in this case we should label each section functionally or by the name of the file that we get the data from. So either
==Tech Links== ==Weapon Data== ==Module Data==
or like this
==Can_Fusion.weapon== ==techtree.techtree== ==br_drone.section==
or the like. I would prefer to label each section functionally, but I don't have a strong preference. --Nspace 03:13, 29 January 2012 (EST)

I don't think length is an issue. I'd go with no spaces though, and camel case starting with lower-case (e.g. "hiverChance" and "humanChance"). No spaces makes finding them with a bot slightly less annoying. Essentially, we're creating a really f'd-up (pardon the language) version of a JSON object or Python dictionary. At least, those are the best examples I can think of right now. Just as long as the names are absolutely consistent between pages, and are never reused for some other meaning.

As for the templates, they look good. With the use of the lst function, it'll be possible to make the template grab the relevant data automatically, just as long as item data corresponds to a page name in some predictable way and never deviates. Example: parameter techName is the page name of the tech to be listed. The following code could be used for the row (going loosely by what I see in Sandbox):


If the section (data) doesn't exist, lst returns empty, meaning it's possible to set a default value to be displayed using #if :

|{{#if: {{#lst:SotS2:Data/{{{techName}}}|researchPoints}} | {{#lst:SotS2:Data/{{{techName}}}|researchPoints}} | defaultValue }}

The pipes inside #lst will probably conflict with the outside #if, in which case they'll need to be replaced with {{!}}. Note in the first example I included a percent symbol in the template code. That's for future-proofing. Who knows what we might want to do with the data later, so it's best if we leave anything in the data pages as plain as possible, and add extraneous stuff later (when the data is called). In this case, adding a percent sign in the data sections themselves would make it more difficult to use the data as an integer (it would first need to be handled as a string literal, the symbol cut-off, and then used as an integer, which might mean a lot of extra template code in future if we want to calculate anything from said data).

It dawned on me while writing this that it'd likely be a hell of a lot easier to generate these pages with a Python script, but that'd mean having access to all this data in some sort of standard format, be it XML, JSON, YAML, or something else. If I can get a handle on how pywikipediabot actually works it might be possible to automate updates...maybe. Big maybe though. :p

--CPhoenix (talk) 01:47, 29 January 2012 (EST)

  • I agree about the percent sign, which is why I did it that way in Template:TechRow. :) There is a potential issue though. In the techtree file, here are multiple techs that have the IsPermanent flag set to true (which guarantees the tech to all races) but the actual race chance fields are set to 0. In the initial data dump, all those chance fields in the techtree.techtree file set table cells on the wiki with Core instead of 100%. I have no problem changing them to 100% instead of Core, but it's something we need to decide on.
And I was thinking the same thing, except that I was looking at writing a program in C# to convert all the (nominal) XML data in each of the .weapon, .techtree, .section and .module files to a wiki formatted text document, once we settled on what we wanted the pages to look like. That would solve half the update problem, but the other half is getting the pages posted to the wiki. For that, using a bot would be great! Unfortunately, I have no idea about how to go about getting/creating, setting up or running a wikibot. So I guess we first should decide on how to store the data in the subpages of SotS2:Data and second figure out what the pages should look like. I mean we can always get it into the wiki by hand, though with 319 techs, 122 weapons and who knows how many sections, that is obviously not my first choice. :) --Nspace 03:13, 29 January 2012 (EST)

Core vs 100%: Go with 100%. "100%" is self-explanatory in the context of a column for probability values. "Core" is not.

Uploading pages: I dug around pywikipediabot for a bit and uncovered . As long as it still works as advertised, it should provide a simple way to upload all of the pages from a single UTF-8 encoded file. It might be best to export the upload file to a more convenient format like XML/JSON (gods, I just called XML and JSON convenient) first, then take that and output the file for , if only for the sake of having an intermediary format that can be used by other people or ourselves easily to do other stuff (like quickly reformat the data pages, for whatever reason).

I noticed that techtree.techtree has the human-friendly names included. Thank goodness for that. Even the icon filenames would be usable, if file upload was working here and we could decode all the images. If we could do that, it'd mean we could make templates that automate the addition of an associated icon too! Our templates could be as easy to use as typing {{ItemTemplate|ItemName}}. That'd be awesome for editors.

I need to go play with these files for a bit and see if there's an easy way to read them in Python. O.o --CPhoenix (talk) 03:50, 29 January 2012 (EST)

I tested-out and it works like a charm. pagetest.txt contained:

This is the page text.


Then this console command created Sandbox/bottest:

python -family:sots2 -file:pagetest.txt -force -notitle

Using this bot to update all of the data pages at once should be a snap. Unfortunately, it doesn't include a way to compare the text to be added to what's on the page already, so an update requires the use of the -force arg which means it overwrites every page. I'll tinker with it and see if I can patch-in this functionality. A direct comparison shouldn't be too hard. --CPhoenix (talk) 04:00, 29 January 2012 (EST)

Last thing: Perhaps we should take this discussion to SotS2_talk:Data. I've taken the liberty of copying the relevant comments there. --CPhoenix (talk) 04:10, 29 January 2012 (EST)

SotS1 stuff

Hey CPhoenix, I mentioned over on the sots 1 wiki (under your writer2 login) that Sil has already done some rewrites of the races articles there, as well as adding some new content. Thought I should give you a heads up before you got too much reworked. --Nspace 23:54, 7 February 2011 (CST)

Lol. Real redoubling of effort in commenting, but I'll say it here too, thanks. :) I've nabbed his shtuff too, and hopefully I can make everything nice and neat...before we all start lobbing more stuff on top of what's already there and making a mess again. :-p --CPhoenix 22:07, 8 February 2011 (CST)


I was reviewing how to put together the Faction articles. Was thinking of going with the Faction name as the unique ID. So Government Morrigi Federation, Government SolForce et al.

While I thought about placing the UID first, it means constant repetition of the Faction name up front and kinda screws with the sorting.

Another option would be to have some sort of short form UID, like Government MF, Government SF, but I think I would prefer longer form to ease in new comers...

Anyways, I was only asking as setting up the categories is something I can do in short order, where-as the article sorting that CPhoenix is doing is more... time consuming  :)

--Silvaril 03:08, 22 February 2011 (CST)


Don't forget that we're here to organize existing information. I'll try to see if I can get us some exclusives, but now that Paradox is treating SotS2 like a big release with a PR plan, we're not necessarily going to be able to request information like before. And even then they were pretty cagey before release. :) --Admin 20:26, 9 February 2011 (CST)

Oh, I know. But who says I can't ask the question? If they can't or don't reply for whatever reason, I'm not gonna be hurt. But I might as well ask; nothing ventured, nothing gained, as it were. :) --CPhoenix 00:06, 10 February 2011 (CST)

As long as you're polite and don't be demanding (but Mecron did mention it to me). I'd rather have a crap wiki and a great game then have them spend time catering to us instead of the game. :) --Admin 00:27, 10 February 2011 (CST)

*sigh* I always feel like something gets lost in translation between him and I on the forums. Of course I'd rather have them produce an awesome game, though I trust they all have enough sense to divide their time appropriately and ignore my questions if/when they have to to get shite done. It's the reporter blood in me...I ask lots of questions. lol

It's funny, but we're all doing the same old dance as we did five years ago. I ask lots of questions, Sil starts categorizing the wiki really early, leaving you miffed, and Mec asks you to ask me to stop being so inquisitive. (It's not like I've gotten out a heretic's fork! Sheesh. :-p ) --CPhoenix 00:38, 10 February 2011 (CST)

Well if we're doomed to repeat ourselves then maybe we'll have the same success? :) --Admin 07:23, 10 February 2011 (CST)

Let's hope so! :-D He he. I'm uploading a few of the SolForce pages now. Plus, made a few new fancy icons for the different categories under Lore. Hopefully will prove nifty...or at least kinda pwetty. --CPhoenix 07:37, 10 February 2011 (CST)

Additional info on Black Swimmers

Hey, I just added the following to the "Liirian Art of War, The"‎ page over on the SotS 1 wiki and I didn't want you to miss it. It's from this thread.

"As an example, the Liir victory screen shows some abandoned armor. The Swimmer who occupied it was relatively young – the equivalent of the 18-year-olds who populate most of Humanities armies. He was neither too old nor too far gone to heal his war wounds and go on with his life. And going on with life is very much the definition of "victory" to a Liir."

Thanks. --Nspace 16:14, 15 February 2011 (CST)

No, thank you Nspace. :) I know I haven't made any updates recently, but rest assured, I'm still plugging away. --CPhoenix 17:17, 25 February 2011 (CST)