BattleTechWiki talk:Project Systems

The Mapping Project, Operation Doneve, is actively seeking input and involvement from Sarna's Editors and users.

In order to promote effective communication and project progress, please determine which of the following sections are most applicable and initiate conversations in that section. If you have an idea that is rather different in scope than what is being discussed, please consider opening another independent thread to that conversation.

Conversations will be periodically (and irregularly) archived.


Audit[edit]

reference: BattleTechWiki:Project_Planets/Mapping#Audit

Corrective Services[edit]

reference: BattleTechWiki:Project_Planets/Mapping#Corrective_Services

Article Mapping[edit]

reference: BattleTechWiki:Project_Planets/Mapping#Article_Mapping

Input regarding the primary map[edit]

Gruese is seeking user input as to how the maps would best serve the system articles.

Using the Sarna system article as an example, system articles generally have a map in the right top corner, initially generated by Nicjansma when he first opened Sarna's BattleTechWiki. However, through a number of issues detailed elsewhere, these maps are often inaccurate relative to present canon. The Project: Planets team has done an incredible job in trying to ensure that accurate coordinates are presented within the article and updating this primary map image (when possible) with manually-modified images that are more accurate in the presentation of positions.

However, the Mapping Project is seeking to standardize these images across all system articles, in a way that is both accurate and easy to correct, update, and upload.

In his initial work, Gruese has created a series of test images. The below gallery allows you to compare the present image for Sarna to the test image:

One of the first things you'll notice is the difference in positions of planets: some have moved, others added. The test image is far more accurate, as it is based upon the Extrapolation Method of the SUCS. Both images depict about the same area of space, over 60 light-years out from Sarna, with 30- and 60-ly rings. The test image is far "busier" than the original, attributed to several reasons, including slightly differing scales and different fonts and font sizes.

Here's the request he making: what can he do to make the newer map images more useful to the Sarna user? Ideas he's already received from offline Mapping Project discussions include:

  • retained 30- and 60-ly jump rings
  • standardized 1000x1000 pixel size
  • directional arrow to Terra (with distance)
  • a minimap to help with positional reference (now a separate goal of the Mapping Project)
  • shaded background to match the political affiliation; in other words, instead of a white background with colored dots, the idea is to have featureless dots on a background matching the color of the realm. In this case, that background would have green for the Capellan Confederation under all of the systems shown that are controlled by them, and yellow and purple for the systems per their relevant realms (see "Example image" here, from the IS 3025 site).

For discussion purposes, what else would make this map useful (but hopefully not too cluttered)? --Revanche (talk|contribs) 14:47, 20 June 2018 (EDT)

If the intention is to shade the background of the map dependent upon the political affiliation of the worlds, then the map should include the year the map reflects; not only do borders move back and forth a lot, but there are instances where quite notable worlds change hands - New Avalon is a Draconis Combine world in 3150, for example.
The map is being auto-generated using the article names; that means a lot of claggage intended for wiki administration purposes - like the (system) suffixes - is appearing in the planet names, and cluttering the maps. I use pipes in the manually generated system tables to prevent that happening, and in the cases of worlds that change name like Runrig/Rhodos I normally go with the format Runrig (Rhodos). I'm not sure what the mechanistic way around this is, but my suggestion would be something like have whatever's generating the map reference a lookup file, matching article title against desired output - we could literally just have a file consisting of a long table with the article title in one column and the preferred output name in the other, and it wouldn't be much of a burden to update manually.
I think the jump rings would be a useful addition, and I think they're also something historically associated with the wiki, so I'd be keen to see them retained.
If we're going for the maps being shaded - which does make them more attractive - then we should find a way of linking in an obvious fashion to a key that explains the colour scheme. Even if we go with the CGL standard, there are some that are not immediately and easily deduced, and if we're going to have a range of maps through history, there are probably going to be states that aren't familiar to people.
Also, which time period is being used for the maps? Different eras are important to people at different times, and if we go with having shaded maps based on affiliation, then we've automatically time-bounded the maps, just as if we leave live worlds as hollow circles and dead worlds as filled circles. Currently, the articles I've updated include a preamble at the top that gives some detail on the status of the system, in that it states where the system was at a given date. That date is either 3145, for planets that are shown on maps in 3145; if they're not on 3145 maps, then it changes to as at 2750, for planets that are on the 2750 maps; and if neither of those is true, then it's as at the last confirmed date in which the planet was on a map. BrokenMnemonic (talk) 07:03, 28 August 2018 (EDT)
First off, thank you for your input, BrokenMnemonic.
Years: this will be done. The intention right now is to have the primary map either the latest year map on the top of the page or 3025 as default, with that indicated. There will also be a map gallery section added to the lower parts of each article, with all of the primary years (2750, each Succession War, etc.) represented and marked. This will allow users to pull up several maps in tabs and compare successively (or however they choose).
Claggage: great catch. I cannot say for certain Gruese and Volt haven't already caught that, but adding a "Map name" column to the database is something we can easily do.
Jump rings: Noted and will pass that on.
Shading legend: can you expand on the how we might represent this? (This image is a newer approximation of what the maps will look like; note the inset IS to help locate the region, if color isn't explanatory enough for some users.) I'd point out that the article itself will be rather indicative, but textually and thru the ownership table, as to whom controls the system when.
Time periods: Which map will be at the top of the sidebar and which maps will be in the Map gallery hasn't been nailed down yet, but the database does show what our choices are. That will be a Sarna consensus answer. I suggest postponing the decision for now.--Revanche (talk|contribs) 10:27, 28 August 2018 (EDT)
You got me in trouble with the cross-site team, BrokenMnemonic. Apparently my contextual understanding of claggage is not the preferred use of the term! Step forth to have your wrist slapped. However, the suffixes are not an issue any longer.
Feedback on the jumprings: Gruese feels that the second ring is misleading, because rarely can a ship completing the first jump also make it the complete distance to the 2nd ring, due to the actual destination distance (on the 2nd ring) now being over 30 lys years from the intermediary stop (which is within the the first ring, not on it). He's open to including it, though, if the consensus is there. My response is that it is more of a visual aid of relatable distance from the article system than a navigable aide.--Revanche (talk|contribs) 21:21, 28 August 2018 (EDT)
I've only ever heard claggage used as a description of the leftover, unusable scrap waste generated in a workshop after a fabrication project - and given I've been hearing it used that way by soldiers and sailors for more than 20 years now, I'm going to assume the urban dictionary is quoting some newfangled interpretation young people use Tongue.gif
For the shading key, I'd suggest that you ask Gruese to generate an image showing all of the different possible shadings and their faction affiliation as a colour chart, and that we then amend the system infobox template to include a hard-coded reference and link to a copy of that chart hosted here on Sarna - so that every infobox as standard would include it as a field that can be clicked on, in the same way that every system infobox includes the hardcoded "System information" title. Which, looking at it, should probably be System Information.
That test map has a problem, by the way. It's showing Obeedah, which is tricky; the disclosure that Sharpe was Obeedah came from a forum post outside the ATW area on the CGL forums, made by Herb Beas, in which he pointed out that was made after he stepped down as Line Developer and which was therefore not binding and could be changed. It's the same for Versailles/Taussen - until we get something published in canon, they're the dead worlds of Sharpe and Versailles. I notice that the distinction is in the article on The Five, but not the notes section for Sharpe, which is something I should tidy up...
Regarding the jump rings, they've been a part of Sarna's "look" since before I joined the wiki, and I think they're a useful visual aid. I suspect the response from one of the writers to being told that they couldn't have a JumpShip go from one planet to another in two jumps because there isn't a perfectly-positioned inhabited system would be to simply say that they use one of the many uninhabited systems to insignificant to merit being mapped as a waypoint, so my inclination is to simply handwave it - I think charting JumpShip routes and the like is more a function of something like MekHQ than a concern for us. Two jump rings make for a more striking and informative map image, IMO. BrokenMnemonic (talk) 03:11, 29 August 2018 (EDT)
Claggage: that's what I told the group; I'm a sailor of 27+ years and had never heard that definition before. However, Google was all over it. Go figure.
I like the chart idea, with the hard-coded reference. We can't build it yet, until the colors are finalized, but I'll share that idea with him.
System Information: change made.
Obeedah: would you be willing to add a note to both Sharpe and Versailles with that background info? The SUCKit does show Sharpe and Versailles as the primary names, so I'll check with Gruese to see what's up. It may just be from an older data set.
Jumprings: I'm completely onboard and I'll sell the unpopulated system perspective. In the end, he said he'd go with our consensus, and I'm not seeing any suggestion other than two rings.--Revanche (talk|contribs) 06:49, 29 August 2018 (EDT)
Claggage: I maintain that we're right, and people on the internet are wrong.
Obeedah: done. BrokenMnemonic (talk) 15:48, 29 August 2018 (EDT)

Marking Apocryphal Systems on Maps[edit]

It should be possible with relative ease to append "(apocryphal)" to the system names in any lists. The real question is if/how to put them on starmaps. If we decide to simply include them we run into the problem outlined by BrokenMnemonic above; if we either omit them completely or mark them apocryphal on the maps we may find the maps outdated if and when CGL canonize them - which may or may not happen at some point down the line. If the HBS game really pulls in troves of new players then that should be an impetus for CGL to canonize the gaming area and storyline as much as possible. Frabby (talk) 05:36, 23 August 2018 (EDT)

@Frabby: The maps will be dynamically created, whenever the SUCKit coordinates are updated, so if/when they become canonical, it'd just be a matter of removing whatever tag the mapping software uses to identify them as apocryphal. But you've highlighted a good point about identifying them in the first place; I'll bring that up with the Operation Doneve group.
If you look at the | Aurigan Reach Map that was published in the Kickstarter days it has what appear to be jump paths. This gives me the impression that a lot of the new worlds HBS have added, they did so specifically to alleviate the issue of isolated worlds. If we are to retain the 60 LY format for the tables including the apocryphal worlds will have a fringe benefit to us in that it will help cut down the number of tables that would need manual care for that region at least.--Dmon (talk) 15:41, 23 August 2018 (EDT)
Unless and until CGL canonise those worlds, and the MechWarrior worlds, and all the other apocryphal worlds, they're still something that shouldn't be showing up in a way that could mislead someone into thinking they're canon systems, though. My preference would be for them to not appear on system tables and maps in canon system articles, but I don't know how easily achievable that is. The only way they should appear in canon articles is if there's some way of making it immediately obvious and highly visible that they aren't canon systems. BrokenMnemonic (talk) 16:26, 23 Aubgust 2018 (EDT)
My gut feeling goes in the opposite direction. I'm a completionist, and I'd prefer the apocryphal systems must be added - preferrably listed as apocryphal on maps and jump links, but if that's somehow unworkable then they should still stay in. After all, the linked articles themselves will be marked as apocryphal. And there are plentiful official canon maps around to double check, and CGL even have a dedicated map guru in Øystein Tvedten. Frabby (talk) 17:24, 23 August 2018 (EDT)
I don't like any system that forces someone do to an active double-check to confirm if something's canon or not. I think that's the sort of thing that would make life complicated for people using the wiki for research purposes, and my training tells me that if you rely on someone looking something up, they won't. If apocryphal systems are going in, then they should do so in a fashion that makes them immediately visible and obvious at a glance - preferably something like having them (and their names) be in a completely different and striking colour, and a key note (akin to our current flagging up of how the X/Y coordinates relate to Terra) should be nearby spelling out that they're apocryphal/non-canon. BrokenMnemonic (talk) 06:59, 28 August 2018 (EDT)
You're absolutely right, Dmon. The dream is to make all of these tables script-updatable, and you've reminded me that we should tag the ones that are not,for such manual updating. I can't image there will be more than a handful (if any).--Revanche (talk|contribs) 16:19, 23 August 2018 (EDT)
There are a fair number - particularly since ISP3 gave us maps of the Deep Periphery for the first time, but Explorer Corps and Wars of Reaving also added a fair number. I've only worked through about 40% of the tables manually, but there were enough that by the time I'd got to systems beginning with a C, I felt it was something I needed to find a way around, so that the nearby systems section of those pages wouldn't simply be an empty table - I wanted to give readers something useful. BrokenMnemonic (talk) 16:26, 23 August 2018 (EDT)
What I meant was, following the adaption of your Phase 5 tables (as Nic refers to them), there should be few that cannot be updated by the "distance bot". In fact, that's what the cross-site collaboration team is working on now, but on system coordinates, by Nic identifying which articles are not getting updated by his coords bot, and us resolving them, so that they can. Same thing with your tables: once Nic builds the distance bot, you and I will resolve the problems keeping the remaining articles from being updated.--Revanche (talk|contribs) 19:18, 23 August 2018 (EDT)
To help frame this discussion, I'm uploading a late-stage Gruese-generated map that he provided to Operation Doneve as a status report:
We owe the Operation Doneve team a consensus:
  • Am I correct in thinking we all agree that the inclusion of apocryphal systems is acceptable, if properly marked?
  • If the answer to the above is "yes," then how should they be marked? Gruese reports it would be easy to label the VG systems with "(HBS)" or "(apocryphal)". The former reflects all of the apocryphal systems I'm aware of (Kaetetôã being canonical), but it's not immediately obvious to all users that they're apocryphal, while the "(apocryphal)" will probably be problematic for tight regions, in regards to labeling.--Revanche (talk|contribs) 07:49, 24 August 2018 (EDT)
If the majority consensus is that they should go in, then I'll abide by the majority decision, but as I mentioned above in response to Frabby, if they go in, then they should be shown in such a way that it's immediately obvious and visible that they're different; my preference would be for the worlds and the names to be in something like a different colour, which isn't used for any faction at any point in time, and with a key somewhere nearby in every article flagging up that worlds showing up on maps in that colour are apocryphal/non-canon and are included for illustrative purposes only.
Possibly the easiest way to track that from our point of view would be to add a category to the apocryphal planet articles showing them up as being apocryphal. However, I'm not sure what you do about systems that are canonical, but whose status is apocryphal - for example, those periphery worlds/rim worlds that died off in canon, but are live worlds within the HBS computer game. BrokenMnemonic (talk) 06:59, 28 August 2018 (EDT)
I'll check with Gruese to see if maybe we can color the apocryphal worlds a different color, something that would be consistent but stand out on all background shades. The default right now is to have them tagged with (HBS), though Gruese is looking at making (apocryphal) work. What he needs is a consensus from us. So, question for those reading this far (including you, BM), how should apocryphal worlds be indicated on maps, in order of choice?
  • different font color
  • tagged (apocryphal)
  • tagged (HBS)
  • other?
Respond below here, please. --Revanche (talk|contribs) 10:08, 28 August 2018 (EDT)
- Tag with (apocryphal). The reason why they're apocryphal, e.g. (HBS), doesn't belong here and has little if any value in the context of the map project.
And because the point was raised, if the existence of a given system was confirmed in canon then the system as such is canonical. Its status (affiliation, population) may be apocryphal but for the purpose of this project the only relevant question is if a system going by this name exists here in canon. Frabby (talk) 10:14, 28 August 2018 (EDT)
- (apocryphal) because there are more systems out there than just the HBS ones.--Dmon (talk) 14:58, 28 August 2018 (EDT)
- I agree with (apocryphal) as well, but I'd also like to see a different font colour being used as well - largely because it makes the distinction that much more obvious at a casual glance, which is one of those things I think is useful as an accessibility characteristic. BrokenMnemonic (talk) 03:17, 29 August 2018 (EDT)
- I vote to include the position and names of the apocryphal systems but exclude them from the Canon borders. Have a different color for the text label and the circle also aside from [a] to indicate that it is apocryphal. -Volt (talk) 08:58, 29 August 2018 (EDT)
"...exclude them from the Canon borders." Can you expand on this? What do you mean by "canon borders"?--Revanche (talk|contribs) 21:53, 29 August 2018 (EDT)
Volt is having connectivity issues; the following is his e-mailed response: "What i mean by excluding them on "canon borders" is for example in 3025, HBS made the system Balawat, belonging to MOC. since the system is apocryphal, when the borders of MOC is auto-generated, Balawat is not included in the calculation, nor will it be marked as a MOC-owned system. Instead, it would appear with a different text color and different circle color, or however else the group decides to mark apocryphal systems in the map."-Volt
This sounds good to me; it effectively makes the apocryphal worlds ghost worlds in terms of their effect on maps and borders. For internal consistency within the articles on those apocryphal worlds, we can include extracts from the source - segments of the HBS map, for example - in the gallery for the article to show their relationship to the other worlds within their own internal game universe. BrokenMnemonic (talk) 12:21, 30 August 2018 (EDT)
The only remaining apocryphal system that can be plotted on the maps is Saggina because of its unfortunate placement under the map's borders, and since it's an independent system, I guess that means there won't be any issues with drawing borders? -Volt (talk) 20:10, 9 October 2019 (EDT)

Map Errors Outside System Coordinates[edit]

Hello, the accuracy of the new maps is very good, but I have noticed a few problems with astronomical phenomena. This is probably a low priority, but I thought I would bring it to your attention. For instance, the long axis of the Caliban Nebula spans Anti-Spinward-Spinward. https://www.sarna.net/wiki/File:Circe_3151.svg https://www.sarna.net/wiki/File:CalibanNebula.png There may be other examples. I missed the probably location to report this kind of error. Thanks for your time, you guys did a great job.--01:42, 1 August 2022 (EDT)

Thanks for reporting this. I just happened to catch your response (in a timely manner, also). Generally, the #wiki-issues channel is the best place for problems discovered. --Revanche (talk|contribs) 06:09, 1 August 2022 (EDT)

Interactive Map[edit]

reference: BattleTechWiki:Project_Planets/Mapping#Interactive_Map

General Project Discussion[edit]

Nearby Systems tables[edit]

I saw Nic's bot auto-correct the planet coordinates, which is a good thing. It does leave me with a quandry though; I've been slogging through the planets articles for the last few years, updating them to the new article format as and when I have the time and can face slogging through it. I'm not quite halfway through at the moment, and I've been generating the system neighbour tables using a spreadsheet of relative distances compiled by Volt a few years ago, and a custom spreadsheet I have to generate the contents of the table with some cutting and pasting. Those will now all need to be updated, and new ones generated as needed, using the new co-ordinates - by default now, every single table is wrong; they're either very wrong, if I haven't updated the articles over the last few years, or they're wrong because they're using an older version of Volt's co-ordinates. Not only do I no longer effectively have an up to date relative distance spreadsheet, but if I'm honest, I can't face going back and updating the 1,400 articles I've already generated new tables for by hand. I'm just too damn tired. BrokenMnemonic (talk) 16:09, 17 August 2018 (EDT)

I think this may be a relatively easy fix, BM. I realize I'm speaking for Nic without authorization, but I'm fairly certain (>90%) Nic could run a bot against that portion of the articles, adding the table to articles where it does not yet exist and correcting the present ones. For this discussion, let's call this the "distance bot". As it stands right now, we're planning on running the "coordinates bot" a few times a year, as new maps are released, and the "map bot" to update multiple maps on each article. I really don't think the "distance bot" would be too much to ask.
All I think you'd need to provide is an example of the "perfect" example distance table. I'd be more than happy to consider this under Operation Doneve's umbrella. Would you like to approach Nic about this, or would you like me to? --Revanche (talk|contribs) 09:47, 18 August 2018 (EDT)
Should be possible given that the initial set of distance data was also bot-generated. Frabby (talk) 01:50, 19 August 2018 (EDT)
The most detailed system tables are generally for Capellan and former Terran Hegemony core worlds - for some reason, the centre of the map and Capellan space have the densest planet populations. Something like Genoa would be a good example. The idea behind retaining the system tables was that some users indicated they liked being able to browse around nearby systems, so for worlds that don't have any identified systems within 60 light years - like the Deep Periphery system of Fröislandis - what I've been doing is adding the table, but inserting the detail on the four closest inhabited systems, so that casual readers can locate it more easily and get an idea of just how far away it is from anything inhabited. BrokenMnemonic (talk) 03:19, 20 August 2018 (EDT)
Maybe we should change the focus from the 60 light years to simply the closest known systems (10-12 systems would be useful enough for most systems), thus allowing a bot to have a single standard to work from rather than changing as systems get too sparse to generate tables.--Dmon (talk) 03:32, 20 August 2018 (EDT)
I have no issues either way, but I think the 60 light year cut-off point was dictated by the nearest neighbour maps, which go out to a 60 light year/2-jump radius. BrokenMnemonic (talk) 04:01, 20 August 2018 (EDT)
Agree that it would be preferrable to have all systems listed that can be reached by a double-jump (given that LF batteries exist), i.e. within 60 light-years. "Closest systems" isn't helpful in densely settled areas where there are dozens of other systems within jump range. Distance is really only meaningful in terms of jump distance (30 ly intervals). Frabby (talk) 08:53, 20 August 2018 (EDT)
I'm keen to this idea as the default. We can continue to hand-build a table for those few systems/points that don't have a single neighboring planet (with a note that while distances are up-to-date at the time, they will not be updated as often as systems with neighboring systems). I'm reaching out to Nic right now.--Revanche (talk|contribs) 09:11, 20 August 2018 (EDT)
I think we may need to reach a concensus on whether or not planets from apocryphal sources with coordinates should end up in the automagically generated system tables. It doesn't feel right to me to clutter up tables of predominantly-canon planets with odd entries for planets that exist in a single video game, particularly when casual readers/researchers who aren't checking the individual entries for every single planet might just look at the table and assume they're all canon planets. I'm particularly troubled that with some of the writers occasionally using us as part of their research, and with no easy and obvious way of flagging up a planet as apocryphal in every table that mentions it, we could end up in the dicey situation of a planet from a source owned by another IP owner - like MicroSoft - ending up being accidentally mentioned in a canon short story/novel/sourcebook, even in passing, because it wasn't flagged up. It's one thing to have apocryphal articles that are clearly flagged, and sections of articles that are clearly flagged, but I don't think we should create a situation where apocryphal information can bleed into other articles without an immediate and obvious way of flagging it up as apocryphal. It feels like a recipe for something going wrong. BrokenMnemonic (talk) 17:29, 21 August 2018 (EDT)
You raise a very good and proactive point. Apocryphal should, ideally, always be marked as such, and as currently discussed, it would not be marked in those tables. Maybe there's a way to tag them (like we do extrapolated coordinates with {{e}}), maybe with {{a}} for "apocryphal" in the table, linking to an essay on the status of the HBS systems and similar articles. I'm waiting to hear from Nic, but please keep that in the forefront, when we do engage with him.--Revanche (talk|contribs) 08:10, 22 August 2018 (EDT)
@BrokenMnemonic: Nic has responded positively about including the table into the operation. So, good on ya for identifying this well before we completed the whole thing. Thank you.--Revanche (talk|contribs) 13:40, 23 August 2018 (EDT)
If you look at the | Aurigan Reach Map that was published in the Kickstarter days it has what appear to be jump paths. This gives me the impression that a lot of the new worlds HBS have added, they did so specifically to alleviate the issue of isolated worlds. If we are to retain the 60 LY format for the tables including the apocryphal worlds will have a fringe benefit to us in that it will help cut down the number of tables that would need manual care for that region at least.--Dmon (talk) 15:41, 23 August 2018 (EDT)
Unless and until CGL canonise those worlds, and the MechWarrior worlds, and all the other apocryphal worlds, they're still something that shouldn't be showing up in a way that could mislead someone into thinking they're canon systems, though. My preference would be for them to not appear on system tables and maps in canon system articles, but I don't know how easily achievable that is. The only way they should appear in canon articles is if there's some way of making it immediately obvious and highly visible that they aren't canon systems. BrokenMnemonic (talk) 16:26, 23 August 2018 (EDT)
What Sarna "says" is what Gruese will try to make happen with the maps. I wouldn't worry about the if it can be done technically, as I haven't heard anything too grandiose. However, we do need to form a consensus.
My stance is similar to Frabby's (I believe): as long as the average user doesn't follow a path that leads him to believe a system is canon when it is is not, then I'm ok in having apocryphal systems depicted alongside canon ones on tables and maps. I would not appreciate the "history" of the HBS being threaded into the history of canon systems (say, an in-game raid by pirates from HBS world Mystras onto canon world Holloway; the article on Holloway should not reference this raid in the main section). If we can find a way to clearly differentiate the apocryphal from the canon on tables and maps, then I support including them. Is this something you could support?--Revanche (talk|contribs) 08:26, 25 August 2018 (EDT)
I have more of an issue with apocryphal systems appearing in the nearest neighbour tables if we go with all worlds in a set radius - I wouldn't support including them if the decision is to simply include the top 10/12/20 closest worlds, because then canon worlds are "losing out" to apocryphal worlds, which feels wrong. If purely apocryphal systems are going to appear, then I'd suggest we either differentiate them by name or by colour or by both, so that they are clearly and visually distinct (and distinctive).
Information from computer games is already present in a number of the canon system articles, by the way; if you look at the list of worlds mentioned in the 1989 MechWarrior computer game, you'll see in the individual articles that Frabby's already added details such as climate and population figures from the computer games, flagged up as apocryphal content. Similarly, if you look at Elidere, you'll see detail in the planetary history relating to the 1989 MechWarrior game events on that world, again flagged up as apocryphal content. I suspect the reason we don't have more detail like that across the articles is that no-one cares enough to have added more so far, which may not be the case with the HBS game events. BrokenMnemonic (talk) 07:35, 28 August 2018 (EDT)
- I do not think the apocryphal stuff info not being added to various planet articles is not a case of nobody cares about the games etc and more a general lack of input across the wiki on planet articles as Planets rather than Systems. Huge amounts of effort is put into the coordinates of systems, who owns said system and what factories are there but if you look at planetary biome descriptions and names of places taken from the canon sources, things become very spotty. This information is probably more important from a story writing point of view than the coordinates ever could be. As with many things on the wiki, unless somebody sits down and makes a project of it all we have is piecemeal bits done as people read x novel. It is a titanic task to add all that info in that would require a team or another decade of slow organic growth.--Dmon (talk) 08:17, 28 August 2018 (EDT)
One of the things I want to be doing is adding more detail to the planets articles - it's one of the reasons one of my earliest personal projects on here was the work I did with Historical: Reunification War - but there never seems to be enough time. Given the amount of time and effort it's taken me to update 40% of the system articles over the last 5 years or so, I don't envy anyone trying to make updating the system article content pages a project - the H:RW detail took me a year, and that's excluding the Taurian Concordat theatre, which I didn't do much of anything on... BrokenMnemonic (talk) 03:23, 29 August 2018 (EDT)
I am in the same position myself, I would love to add it all in but my to do list already has some pretty expansive projects. Researching my Noble Houses project I have re-read almost all the novels in the last 8 months. I tend to sit reading with the sarna page open on a different tab. In doing so I feel both proud of how far the wiki has come and how much more work we have yet to even begin.--Dmon (talk) 04:30, 29 August 2018 (EDT)
I've wanted to finish off adding the detail from Historical: Reunification War and Historical: Liberation of Terra: Volume 1 for years now BrokenMnemonic (talk) 15:46, 29 August 2018 (EDT)
- Ok, so I agree with you about being inclusive (via range) rather than exclusive (via Top 10/12/20). The interior of the Inner Sphere is much more crowded than other areas and for a good reason. It makes sense (to me) that all worlds within 2 jumps (60 lys) should be in a table. So....we're progressing; does anyone have any fundamental issues with the following?
  • Nearby Systems tables of systems within 60 light-years (2 jumps) of the target system;
  • Apocryphal systems included within that range, but marked in someway to differentiate.
Please let us know here.--Revanche (talk|contribs) 09:35, 28 August 2018 (EDT)
- I agree to both, I feel the 2 Jumps system will have more utility but needs the extra worlds in avoiding the empty tables issue.--Dmon (talk) 09:46, 28 August 2018 (EDT)
- Same. BrokenMnemonic (talk) 03:23, 29 August 2018 (EDT)
I think the above two points are most likely consensus, but I'll keep an eye on it. As for the Distant Neighbors version of the same table, please indicate support/non-support for the following:
  • When no populated/mapped systems exist within 60 light-years of a target system, the chart shall include the nearest mapped neighbors ("Distant Neighbors table");
  • The Distant Neighbors table shall include the 10 nearest mapped neighbors.
Please let us know here.--Revanche (talk|contribs) 06:56, 29 August 2018 (EDT)
- I think that makes sense. I would like to add a caveat about depoppulated and unpoppulated systems though, If we are going to have the option of skipping through different time periods I would like the worlds to remain on the map, just possibly turn grey. I would be fine with them dropping off the denser "nearest neighbours tables" and but remaining on the more sparse "Distant neighbours tables". I am not a fan of ComStar style vanishing planets. Once mapped a system stays mapped.--Dmon (talk) 10:14, 29 August 2018 (EDT)
- I'd prefer the dead/vanished worlds to remain on the system tables - that's what we've been doing so far, and as various systems have shown us in canon, at least some of them are not completely dead (see: Touring the Stars: Tyrfing, touring the Stars: Inglesmond mentions of medieval-level human settlements on Haddings in one of the BattleCorps short stories, etc). In terms of number of systems to show on the Distant Neighbours table, I'd recommend a multiple of 4; from the testing I've done, the table works well when each row has four planets in it - pushing it up to five moves the table boundaries outside the screen area/easy scrolling area of a lot of monitors. BrokenMnemonic (talk) 15:46, 29 August 2018 (EDT)
I'm with you on keeping them on both maps and tables. I think Sarna's role is to track the status of items of interest, not "delete" them for the periods of time the canon does. We already do this on Ownership tables by reporting "no record" at critical years; I think ownership tables, maps, and distance tables should maintain the focus.
Good point about the multiples of four. Is there a technical reason why the columns would not be limited to four, though. For example, if we went with 20 (for the Distant Neighbors table, wouldn't we have 4 columns, 5 rows? With the Nearby Systems table, we won't have the option of limiting them to multiples of four systems listed. --Revanche (talk|contribs) 21:59, 29 August 2018 (EDT)
Sorry, I'm not sure I was clear above. The tables I've been putting together manually effectively have eight columns, with each row covering four worlds using two cells for each (name, distance). The table then has as many rows as it needs to fit all the worlds in below. When I experimented with rows containing ten columns/five worlds at a time, they were too wide for a lot of displays, particularly in instances where very long planet names cropped up (like Bob's alter-ego). Unless you can dynamically generate the table with each view, so that they resize to the size of the display on the device viewing them, then four worlds per row is probably the way to go. BrokenMnemonic (talk) 12:21, 30 August 2018 (EDT)
Yeah, I get your meaning; I wasn't thinking about the distance columns when I responded, but can see where that omission would suggest confusion on my part. So, yes, I agree, we're looking at four systems (and their distances from the target system) represented on each row. I'll pass this to Nic. Favor: when we start going live with this stuff, remind me if something get's passed over. The group isn't using a task tracker, though I'm sure each of the three principals (Volt, Gruese, and Nic) have their specific projects well-in-hand. It's on me, however, to convey the Sarna consensus. I'd appreciate someone looking over my shoulder, come press time.--Revanche (talk|contribs) 08:07, 31 August 2018 (EDT)

Archive[edit]