Removal of all base lists

[AboveTheChemist]

I took the liberty of grabbing the base code data for Reunion from the Google doc and turning it into a wiki table on the Reunion talk page. You can check it out here: https://homecoming.wiki/wiki/Talk:Reunion_Base_List

 

Feel free to edit/tinker with it as you please if this has any promise, its just meant for testing purposes.

 

And thunderforce raises a good point about being careful not to destroy wiki table entries that are not in the Google doc, but we can cross that bridge when/if needed. I am happy to lend whatever expertise I may offer to the effort of translating the Google doc to the wiki, if that project moves forward. All I ask is that we wait until shortly after i27p7 releases, because I am currently up to my eyeballs in getting vidiotmaps and some of the other mods I curate ready in time for the release of i27p7. Once the page releases and I release my mod updates, though, I should have more free time to devote.

 

Edited February 9 by AboveTheChemist
typo

[Easter Bunny]

This is wonderful on all counts! Thank you!

I am sure there is some fat that we can trim for the wiki variation. The Description Tags come to mind. Those are intended to be searchable buzz words if someone is looking for Architecture or Snowy landscapes.

But this really helps visualize the plan and the available space, so thank you again. I would be happy for any assistance you'd be willing to provide - and take all the time you need. This is helpful but not urgent.

We have compared our two base lists and have already added the data from the wiki to our docs - we also do not want to inadvertently delete someone's submission. We are now monitoring Wiki Changes from Michiyo's Discord for any new base submissions in the interim.

[Matsiyan]

2 hours ago, AboveTheChemist said:

I took the liberty of grabbing the base code data for Reunion from the Google doc and turning it into a wiki table on the Reunion talk page. You can check it out here: https://homecoming.wiki/wiki/Talk:Reunion_Base_List

 

Feel free to edit/tinker with it as you please if this has any promise, its just meant for testing purposes.

 

Hi, I’ve been helping with the mechanics of the spreadsheeting. We already automate the export from the master to the viewing copy. I would gladly set up an export format to facilitate updating the wiki either simplifying a manual cut/paste or scripting something.

[AboveTheChemist]

4 minutes ago, Matsiyan said:

Hi, I’ve been helping with the mechanics of the spreadsheeting. We already automate the export from the master to the viewing copy. I would gladly set up an export format to facilitate updating the wiki either simplifying a manual cut/paste or scripting something.

 

That sounds great! I basically just adapted the wiki export from another spreadsheet that I use to update another table on the wiki. To make the example table above, I just copied the data from the Reunion tab and pasted it into Excel. The data was in columns A through L (in row 2 for this example). In column M, I used the following formula:

 

="| "&A2&" || "&B2&" || "&C2&" || "&D2&" || "&E2&" || "&F2&" || "&G2&" || "&H2&" || "&I2&" || "&J2&" || "&K2&" || "&L2

 

Which basically just placed the contents of columns A through L between a series of double pipes. An example of output looked like:

 

| ATC-999123 || ATC Base || Open ||  ||  ||  ||  ||  ||  || @AboveTheChemist || Unspecified || ATC's base

 

I don't use Google sheets so I don't know if the formula would be the same, but if not then hopefully that is enough info to be able to replicate the formula in Google.

 

I copied the resulting data into a text editor and had to manually add the row separator between each row, which looks like:

 

|-

 

That wasn't a big deal for the 20 or so entries I was dealing with, but I would definitely want to automate that step for the 600+ potential entries from the Google sheet.

 

I then added the table header and footer and was more or less done. The end result would look something like this for a 2-row table:

 

{| class="wikitable sortable"
! Base Code !! Base Name !! Availability !! Purpose !! Type !! Setting !! Location !! Description Tag !! Description Tag !! Owner !! Builder(s) !! Brief Description
|-
| ATC-999123 || ATC Base || Open ||  ||  ||  ||  ||  ||  || @AboveTheChemist || Unspecified || ATC's base
|-
| ATC-999124 || ATC Base II || Open ||  ||  ||  ||  ||  ||  || @AboveTheChemist || Unspecified || ATC's other base
|-
|}

 

I am by no means a wiki table guru so there may be more stuff that could be done to improve the looks of the table. But it should just be a matter of formatting the Google sheet rows properly, adding the row separators, and pasting that in between the header and footer.

[Dacy]

I was editing some tables last night, and noticed that they also typically have a space modifier at the top; the ones I worked on had been set to 80% of  width; I resized them to 40% (because I eliminated information that was no longer applicable).

 

I would also like to apologize for my outburst last night; that is the most heated response I have ever sent, and usually I take a bit of time to think it through.  But I also had to see if there was a path forward, because it truly felt like there was no way forward at that point. That is not to excuse myself, though; I am sorry for expressing my frustration the way I did.

 

Above the Chemist, I really appreciate all your input and help! Thank you!

 

I have a question. As noted, I've been trying to update some of the base information, which is terribly outdated. I'm looking at entire sections that no longer apply, and they need to be modified not only in the applicable sections, but in the table of  contents. Here is what I mean:

Item origin: that entire section no longer applies.

Base Rooms: the only difference in base rooms is between the entry and the others, in terms of function, and then there are various sizes. So none of the categories listed after base rooms apply.

Could we move these items to "Legacy Concepts" and redo the table of contents? Do I need to have a discussion for approval before doing something that major? (Or "attempting" as I'm not yet confident in my ability).

 

-Dacy

[AboveTheChemist]

The box in your screenshot is called a navbox, and it's a template which means that it is applied to any page where it is invoked. In other words, if you see that navbox on a page, and go into edit mode on that page and scroll to the bottom, you should see:

 

{{Navbox SG Bases}}

 

Which is the code to place that navbox there. If you edit that template, it will propagate those edits to all the pages where that navbox is used (which should be any page dealing with base stuff). Here is the template page itself: https://homecoming.wiki/wiki/Template:Navbox_SG_Bases

 

I am not a navbox guru either, but looking at the code for it, it looks fairly straightforward.

 

As far as consolidating and/or moving pages that no longer conform to how base building works on Homecoming, I think your ideas are perfectly reasonable.

[Dacy]

Thank you! So, I've found so many pages and so many interrelated pages that simply completely do not apply and there is nothing to salvage from them, and I use that word intentionally, as it relates to the salvage aspect of bases. There is all kinds of info on what items needed salvage, what kinds, how much, and what the prestige costs were, among other long dead things. How to get rid of the entire page and weed the network of superfluous items? I assume I follow the links, delete the pages linked until I'm back at the root, and then follow another link branch.

 

-Dacy

 

[Lunar Ronin]

28 minutes ago, Dacy said:

Thank you! So, I've found so many pages and so many interrelated pages that simply completely do not apply and there is nothing to salvage from them, and I use that word intentionally, as it relates to the salvage aspect of bases. There is all kinds of info on what items needed salvage, what kinds, how much, and what the prestige costs were, among other long dead things. How to get rid of the entire page and weed the network of superfluous items? I assume I follow the links, delete the pages linked until I'm back at the root, and then follow another link branch.

 

-Dacy

 

 

I wouldn't delete them, I'd just mark them as historical and unlink them, like other outdated pages.

[Dacy]

6 hours ago, Lunar Ronin said:

I wouldn't delete them, I'd just mark them as historical and unlink them, like other outdated pages.

Right! So...how to mark them historical and unlink, please? Is there an established way to do that?

 

So...returning for an edit...on second thoughts...in the interest of memory, storage, neatness, and relevance...why would we make certain inapplicable pages historical when there's an entire wiki that shows the game as it was? I mean, perhaps such a page is insignificant in memory and storage costs by itself, but, surely, such pages add up over time to become a drag on resources? As they are redundant, I am not sure I see the  point? I am not trying to be combative, I understand you have a certain way you prefer to have things done, but is this even a consideration?

 

-Dacy

Edited February 10 by Dacy

[AboveTheChemist]

7 hours ago, Dacy said:

why would we make certain inapplicable pages historical when there's an entire wiki that shows the game as it was?

 

Therein lies a great philosophical debate that probably all the wiki editors have had at one point or another. Early on, I felt it was more important to mark things as historical, but now I lean towards just deleting it, because as you point out, ParagonWiki is essentially our historical archive.

 

I think however you feel is most appropriate to handle it, is how you should handle it. If you find pages where there is absolutely nothing remaining that is relevant to Homecoming, I have no problem with them being marked for deletion (more about that in a sec). If you find info that may be of significant historical/contextual value, then you could either mark the page as historical, or move those interesting bits to a more relevant page as a historical footnote and delete the rest. Those are just some ideas and one man's opinion on the matter.

 

One wiki page I find handy is the editor's tags templates page. It has links to, among other things, the deletion tag which is used to put pages in the deletion queue (an admin has to actually push the delete button, which may take a few days) as well as the historical tag which is used to mark historical items. There should be usage directions on each page but we're here if you need help. One tip I would add is that if you do use the deletion tag, definitely add a sentence or two to explain the reason.

[UltraAlt]

On 2/8/2024 at 10:07 PM, Easter Bunny said:

CR Dacy and I have been wondering who has more or less taken the responsibility of maintaining the base lists on the wiki? They are not accurate. And unfortunately grow more inaccurate each day. The information listed on the HC Wiki was/is fed from a separate Google Doc that has become pretty severely corrupted and compromised by player misuse. Player bases have been deleted and base codes and owners have been removed or changed. 

 

Okay.

I'm not sure where all this information is coming from.

The responsibility of maintaining the wiki is on all of us. 

 

My personal base listings on the Wiki were entered manually by me and not by anyone else or from any spreadsheet.

Last I checked, ALL my base information on the wiki is correct.

 

I don't know who moved information from some spreadsheet to the wiki. I have got to go to sleep and I don't have time to dig through all of this because it mostly seems to be an unnecessary conflict. 

 

I can't talk for anyone else's bases, but I can say that one of my bases was moved around from one category to another by someone.

I moved it back.

I may have even been the one that added "Please do not remove or recategorize other people's base postings." at the top of each of the Shard base pages after that happened. I haven't seen any drastic changes since that was posted and that was a good while back.

 

On 2/8/2024 at 6:56 PM, thunderforce said:

https://homecoming.wiki/wiki/Special:Contributions/The_Easter_Bunny removed every base list to redirect stuff to a Google spreadsheet. I think this is obviously bad (and reverted it immediately) but (especially since they are a CR) I fear there may be some pushback.

 

I agree.

There is no reason that the existing information needs to be axed and replaced.

 

The two can coincide on the same page and people can pick which one they want to access.

 

Honestly, I can't edit the google one and I certainly wouldn't do it by accessing it with my google account.

I do my utmost to keep my mask on here.

 

Can't we make it a co-op zone?

 

What I have read of this is really not necessary.

If people want to use the wiki listing system, fine. If it needs corrections, I already said that I would help with that part.

If people want to access the google spreadsheet through a link on the wiki, fine. I would put that on the main base page and on each shard base page if the link on shard base page will access a google sheet that just shows bases for that shard.

 

That would be my suggestion.

 

I must have talked in the forums to Dacy about the wiki pages over a year ago. So I'm a bit confused about the "only recently" comment.

 

 

And, I found this, from even earlier:

 

 

This is not to needle or start a conflict, but this has been an ongoing situation it seems.

 

If it comes down to who is "right" about the situation, then it is what it is.

I do think the situation should be resolved in a co-operative manner.

 

I have already indicated through PMs that if the base lists needed to be fixed in the wiki as it is, that I would put time in  to update it, with the caveat that the people that own the bases are okay with me doing so.

 

Honestly, I don't feel that the google spreadsheet will resolve the issue of stale/changed base codes or who is currently the @ for a base if someone goes dormant as the sg leader and the base moves to another @. That is just something that will occur if players don't update when the change codes or when players go dormant.

 

I appreciate the work that was done on the spreadsheet, and I know a person/people put time into doing it. 

People have also put time into posting on the wiki.

I guess my point is, we shouldn't be wasting anyone's time if the simple solution is finding a way to cooperate instead of trying to replace one another in some show of dominance.

Edited February 10 by UltraAlt

[Easter Bunny]

On 2/9/2024 at 7:19 AM, AboveTheChemist said:

In terms of duplication of effort, it is possible to script a tool to translate a Google doc into a wiki table, if that route is of interest.

I think this is the way forward. 

I wholeheartedly believe that two separate base directories is a waste of effort, space and resources. And I also completely agree that there is a solution that doesn't abandon one of these directories in favor of the other.

We have a tentative plan in place that I feel really good about and would like to see what you all think of it. It hinges on us being able to automate some form of feed from our directory into the wiki; which thanks to AboveTheChemist's help earlier we feel hopeful that we can accomplish.

The Plan:

We create a wiki page with some very clear prominent disclaimers that the information is fed from an outside source (our directory) and that direct wiki edits to this page are endanger of being overwritten by the next update that we push. 
Now, as a reminder, we have already compared the two lists and have added any bases that previously only existed on the wiki to our Google directory.
We then create a wiki page and process for new base entries to be added into the wiki. We are now monitoring all wiki changes via Michiyo's discord, so when we see an addition is made we will capture that data in our directory and then push another update that will feed into the Wiki Base Data page.

How does everyone feel about that? Please share your thoughts and concerns.

 I also want to be clear that our directory is new. It is not the old yellow pages directory that anyone could tamper with. If you have not yet seen it, by all means, please give us a visit 🙂 https://docs.google.com/spreadsheets/d/14DqavAx6ov60d92rhvwy2sNEW_909MCHp421GM4q-Yk/edit#gid=0

- EB 

[Dacy]

4 hours ago, UltraAlt said:

I must have talked in the forums to Dacy about the wiki pages over a year ago. So I'm a bit confused about the "only recently" comment.

Yeah, didn't follow that link at that time, forgot about it, was more focused on my frustration with being told that "bases are irrelevant".

 

4 hours ago, UltraAlt said:

Honestly, I can't edit the google one and I certainly wouldn't do it by accessing it with my google account.

I do my utmost to keep my mask on here.

Are you aware that you can log out of your google account and access the sheet anonymously? All I see when others are in it are "anonymous (some silly animal avatar)". And they aren't even logged out.

 

4 hours ago, UltraAlt said:

There is no reason that the existing information needs to be axed and replaced.

 

The two can coincide on the same page and people can pick which one they want to access.

 

Okay, let's back up a moment. We have discussed updating the wiki with the updated, accurate, checked, and calibrated information. Yes, this will be a different format, because we are adding information.  We will link the doc, yes, and we will encourage people to submit entries to the doc, but, and this part we haven't said  yet, we think offering a table for submission of new information in the wiki will give those such as yourself who want nothing to do with Google, a place to make entries. So currently what we'd like to do is reformat the information, clean up the inaccuracies (which we have done on our end), and let people know that this information is sourced from a protected document, and we'd appreciate it if they would submit changes to us, and if that is not something they wish to do, they may enter their  information into the "new submissions" chart on the wiki.

There is absolutely no point in maintaining two base listings.  Especially not when one is demonstrably inaccurate, your own bases notwithstanding. Yes, there are indeed other bases as well that have accurate information. There are also bases that have inaccurate information. We've checked all of our information. Surely you would also wish to have the wiki be accurate in what information it offers.

 

-Dacy

Edited February 10 by Dacy

[Matsiyan]

On 2/9/2024 at 1:25 PM, AboveTheChemist said:

 

That sounds great! I basically just adapted the wiki export from another spreadsheet that I use to update another table on the wiki. To make the example table above, I just copied the data from the Reunion tab and pasted it.

Many thanks, ATC! I’m not sure how soon I can test that out, but it should be possible to generate the whole thing as a single sheet in google to make a single copy/paste. I came from Excel too. They are remarkably similar.

[Dacy]

7 hours ago, UltraAlt said:

Honestly, I don't feel that the google spreadsheet will resolve the issue of stale/changed base codes or who is currently the @ for a base if someone goes dormant as the sg leader and the base moves to another @. That is just something that will occur if players don't update when the change codes or when players go dormant.

Perhaps we have not been transparent about how we are doing this. We are getting people to update their entries.  They enter the information as they want it to appear, we preserve that and keep it from being tampered with. We have checked all of the base codes we have access to, from all listings published anywhere, to see if they work, or if the base is still there, etc.  So any bases that are not updated by the owner or builder is at least accurate to the best of our knowledge, and listed as it has been previously published. No, it does not fix the issue going forward, we still need to rely on players updating, but this is an effort TO GET PLAYERS TO UPDATE and to correct existing inaccuracies. This is not us unilaterally deciding how to list a base and whether or not a code should be public. This is us attempting to increase base visibility and accessibility for those that want to find bases for whatever reason. We want to de-clutter while providing accurate and reliable information.

 

Also, the wiki will have an external link or two to the spreadsheet, but the information will be transferred to the wiki, not simply linked.

 

-Dacy

[thunderforce]

On 2/9/2024 at 5:31 PM, AboveTheChemist said:

I took the liberty of grabbing the base code data for Reunion from the Google doc and turning it into a wiki table on the Reunion talk page. You can check it out here: https://homecoming.wiki/wiki/Talk:Reunion_Base_List

I propose to do a bit of scripting (not really necessary for Reunion's half-dozen bases) to compare it with the wiki list and see which bases are missing, then (if any) to check if they are defunct. If there are any non-defunct bases not in the spreadsheet (and I propose to create one for that test case) I think they might, if the spreadsheet upload process otherwise works, be at the bottom of the table on the wiki so they don't constantly get stomped by spreadsheet uploads.

[Easter Bunny]

On 2/8/2024 at 7:44 PM, thunderforce said:

Having reviewed the edit history on https://homecoming.wiki/w/index.php?title=Excelsior_Base_List&action=history I can see little reason to believe there's been a bulk upload of any kind, although I could be wrong.

I believe the bulk upload occurred in Dec. 2020. Looks like GM Kal brought them in. 


Looking through their contributions, it seems they created all of the shard base lists that month.

And, I know the Google Docs were implemented on June 18th, 2019. 



Just FWIW. This is where the Google Doc format and bulk listings were brought into the wiki.

- EB

Edited February 11 by Easter Bunny

[Dacy]

19 hours ago, thunderforce said:

On 2/9/2024 at 11:31 AM, AboveTheChemist said:

I took the liberty of grabbing the base code data for Reunion from the Google doc and turning it into a wiki table on the Reunion talk page. You can check it out here: https://homecoming.wiki/wiki/Talk:Reunion_Base_List

I propose to do a bit of scripting (not really necessary for Reunion's half-dozen bases) to compare it with the wiki list and see which bases are missing, then (if any) to check if they are defunct. If there are any non-defunct bases not in the spreadsheet (and I propose to create one for that test case) I think they might, if the spreadsheet upload process otherwise works, be at the bottom of the table on the wiki so they don't constantly get stomped by spreadsheet uploads.

 

AtChemist, nice transfer, really surprising that all the descriptors fit! Now, either you got to it before we'd cleaned up the duplicate entry for Olympus, or, it picked up some info somehow. The info has been correctly displayed now, could you perhaps reload that table from the current document and see if it's picking up extra info somehow, or if it corrects the duplicate? That would also show us how well it deals with different data. I should think it wouldn't be a bother, as it should just overwrite it with the correct, current version. Otherwise....looks great! We think the mistake was on our end as in, the table wasn't cleared of the extra information yet when you ran the script. And obviously, we're hoping to get more base owners to update. It's a process!

 

thunderforce, there should be no bases on the wiki that are not on our docs. Easter Bunny already collected and added all the bases we could find. We don't yet have all the updating done, as we are hoping the owners will do that, but the codes and bases and owners, if listed anywhere, should be listed in our document. And all of the codes have been checked.

 

As to information getting "stomped"; there really should be minimal changes for each update, but of course that depends on how many bases were made, and how many are entered. Reunion being the smallest shard, of course means that it is the least likely to see significant changes. Existing data will only change if the base's status changes, and we get updated as to that change.

 

Thanks!

 

-Dacy

[thunderforce]

14 hours ago, Dacy said:

thunderforce, there should be no bases on the wiki that are not on our docs. Easter Bunny already collected and added all the bases we could find. We don't yet have all the updating done, as we are hoping the owners will do that, but the codes and bases and owners, if listed anywhere, should be listed in our document. And all of the codes have been checked.

On reflection it seems like this would work fine. It's not like the wiki base lists get edited so frequently that it will be hard to check for recent edits before doing a fresh upload from the document. I sha'n't do what I proposed above, since I think you're right that it's unnecessary.

[AboveTheChemist]

15 hours ago, Dacy said:

you got to it before we'd cleaned up the duplicate entry for Olympus

 

This is indeed what happened. I just checked the spreadsheet I copied the data to and there are two entries for the Olympus base. I can't get to Google docs at the moment but I'll run a quick update with the updated Reunion data when I am back home.

 

It shouldn't be too much trouble to write a script to compare the Google doc to the wiki to look for missing bases, and potentially for other duplicates. Maybe an hour or two of work at most. It would probably be most useful right before we do the big Google to wiki transfer, but it might come in handy later down the road as well. It's something I was planning on doing even before thunderforce mentioned it so I don't mind taking care of it.

[Matsiyan]

6 hours ago, AboveTheChemist said:

It shouldn't be too much trouble to write a script to compare the Google doc to the wiki to look for missing bases, and potentially for other duplicates.

I wouldn’t call it a script but that’s how we did the recent check. I cut and pasted the wiki tables into a spreadsheet and threw formulas in to highlight differences and missing rows either way. That’s what EB used to reconcile the two. The consistency between the shard lists on the wiki was a big help.
 

A scripted extract and diff would be smoother.

[Dacy]

AboveTheChemist, we appreciate SO MUCH your willingness to put in the time and effort on these scripts!!

 

I just wanted to say that, and also, I note the other bases were formatted into different tables based on the type of base it was. That format would be fine, if that's not a lot of work (although I'd probably recommend that they be sorted according to "purpose", which is similar in many cases); if that's a headache at all, then just one table is fine, and we'll call attention to the sorting feature at the top of each column. 🙂  But assuming a similar format would make the least obvious changes for people to deal with. As I said, either way is fine, whatever works. We certainly are not going to be demanding of your time and talents when you've so generously volunteered them. ❤️

 

Say, I was noticing that it's a bit of a several page hunt or having to search to actually find the base list, do you think the link could be either on the "Supergroup" page, or have its own link on the table of contents? I was a bit surprised that it wasn't there already. And I have *no* idea how to program that; Thunderforce had to go edit a link I put in already, because I'd got it wrong. 😞 I thought I followed what they had done, but clearly I had not. (thank you for that, thunderforce!). Besides, I always feel like nav boxes aren't things I should casually change.

 

Thank you again!

 

-Dacy

[BlackSpectre]

On 2/8/2024 at 9:22 PM, Aalya said:

In addition, lots of people have been victims of malicious deletion and editing of listings. I personally have had all of my bases specifically deleted from the Yellow Pages more than once in a targeted attack. The yellow pages are so vulnerable that anyone could go in there right now and delete the entire document.

 

In my view, this is the real problem. I saw this on the Excelsior page, and since I pretty much live on Excelsior, I edited the page, reorganized it, and fixed all of the malicious code. There were several where someone had replaced the base access code with a different base access code... presumably to get more traffic compared to other bases listed. Some SG base codes were simply deleted. There were bases listed that were no longer accessible to the public (account closed down or permissions revoked). I removed those.  This was all about a year ago I did this, and only on the Excelsior page.

 

The wiki is a public endeavor. Anyone can edit and change wiki pages, and that's fundamental to wikis. It's why comments are asked for when changing pages and why discussion pages exist for every page. 

 

The problem of people coming into the wiki and maliciously altering wiki pages is an ongoing problem with every wiki. One that is policed only by the people actively editing the wiki. Most every page I edit, I also follow and note when someone else has changed it (I get sent an email). There is also a Watchlist page in your wiki account that can help you monitor pages.  Policing the wiki is a group effort. Openly editable spreadsheets stored off the wiki can not be monitored at all. It side-steps the small amount of oversight that the wiki has. It's an issue. I don't think such resources should be publicly editable, and should only be linked at the wiki as a resource.

 

But I have to say, the base listing pages are the ONLY wiki pages I've run across that have been maliciously targeted.  They might require some special handling, It would be worth checking into how other wikis handle these things. @Michiyo, any ideas?

 

So @Easter Bunny and @Dacy, I appreciate all of your hard work over the years and am glad you are now taking note of the wiki! Glad to have you on board as wiki editors. I don't have any problem with either of you updating the wiki pages (I don't think any of us do)... even completely reorganizing them would be fine. Just stay with the spirit and intent of the pages and I think you'd be golden.  There are some apps that will take a spreadsheet and instantly format it into wiki code to make wiki tables. Might be worth looking into. There are several web page tools that will do that too such as this one https://sciwiki.smith.edu/converter/.  Some are better than others. 

 

If I can be of any further assistance, please let me know. 

[BlackSpectre]

58 minutes ago, Dacy said:

Do you think the link could be either on the "Supergroup" page, or have its own link on the table of contents? 

 

 

Done. I added a link to the Supergroup page at the bottom under "See Also", and added links to the other SG related navbox. Good enough?

 

Looking over the supergroup related pages, they could use a little love.  🙂

 

Edited February 12 by BlackSpectre

[Dacy]

Yes, they could use a lot of love. Slowly working on it (my "to do" list atm is rather extensive!).

 

Would it be presumptuous to ask for a link on the main page? I mean, just looking over the topics, there's quite a lot listed there; it seems to me that "bases", both information about building and the lists of the bases, are of at least of equal importance to things such as "battle terminals" and "titles', etc.  For many people, bases ARE the game for them. For others, it is a huge enhancement they do not wish to play without.  See, right now they are just under "supergroup", but I will tell you that there are a good number of bases that are created, not as part of a supergroup, but as a part of the game and the community. For many players, bases are truly a thing only connected to supergroups by the fact that you have to create a sg in order to make a base. Many bases are named something other than the name of the sg that ownns them. So I believe that that separation needs to be recognized.

 

But yes, the base pages need to be updated asap, perhaps organized in such a way as to easily link to in a way that makes sense as a whole topic. Which means I need to do some research on editing.

 

-Dacy

Edited February 13 by Dacy