Proton

I removed the DLC indicators because with 2.3.0 the expectation is that users have all of the DLCs. I took a more aggressive culling stance instead of gradually phasing out. When it comes to instructions, you should never set the expectation that it's fine to skip a few sentences. I feel it is better for every sentence to be important and brief, so that users skip instructions as little as possible. I didn't inherently dislike the system requirements class, but I wanted to start with a consistent appearance first and tweak from there.

Whoops, missed one of the edits (I had to change all the {{PAGENAME}} magic words into {{SUBPAGENAME}} so it'd automatically grab 2.3.0 instead of Proton/2.3.0). It's fixed now.

You mean the large gap in content right after the system requirements? It's because the TOC is so long.

I took the 2.2.9.2 and removed all the Extended mods, changed the mod tables to remove the DLC column, implemented non-image versions of the LQ and HQ indicators, and hit the introduction with a heavy Occam's razor. https://wiki.step-project.com/User:Proton/2.3.0 Just for kicks.

Should be able to change the frequency of shooting stars in the MCM, as I recall.

As a fan of the Rainbows and Shooting Stars mods, I must address a concern with the switch to Wonders of Weather. Even though it's made by the same person, the shooting stars in WoW went from quick motes of light to fat crumbling meteors. I was disappointed, because these annihilated the immersion offered by the original. As such, I have personally uninstalled WoW and returned to the original separate mods, even though isoku no longer supports them. Looking through the posts on WoW's Nexus page, it seems some modders experience high thread counts when outside, noticeable especially during rain. I propose, in light of both of these, that Wonders of Weather be removed from STEP:Extended. I don't feel that STEP can appropriately recommend it, or its unsupported predecessor.

Is there any kind of milestone checklist for 2.3? Somewhere that we can see what exactly is left to do, even if we can't specifically help. For example, I'm completely prepared to pre-emptively make a copy of the 2.2.9.1 guide with all non-Core bits removed.

I figured it was that style guide, but I wasn't sure if you perhaps had a separate draft being worked on in secret or something.

This response satisfies me. Thank you for taking the time to explain :).

Okay. Where could one find the most current draft of a STEP style guide? The aesthetic should be developed first, and then an implementation developed to associate it with the desired semantics. This ought to help make sure all relevant templates are designed in parallel and ring with a sense of unity. That came out a little more poetic than I intended.

As long as the team is consciously developing the aesthetic and not just running with random ideas, I don't think there's a way to really mess it up. It just needs to be written down and then applied. I think the core reason there's so much article inconsistency is because people will mimic what they've seen before they go looking for a style guide, and no one really went through and made the current set of pages consistent. I mean, background color, accent background color, body text color, and a handful of semantically-associated accent text colors (like the blue/green/red/etc. we're already using) are really all you need, and we already have that much. What remains to be designed exactly? I think a dev wiki is a little overkill for these purposes.

All right, but my point of not knowing whether you're out of date or not still stands. If STEP had an automatic updater then being informed of new changes wouldn't be necessary, but currently it requires more than a glance at the main page to find out, and I reckon a glance is all it ought to take.

I see—so effectively the intent behind the “hotfix†restriction I described? In that case, I suppose, I still feel it would be ideal if each batch of such post-release changes came under the (small) banner of a hotfix letter, for the same reason mentioned above: it should always be readily apparent if the current guide has changed since a user last followed it.

You mean a limit to the number of templates a page can contain? I wasn't aware such a thing existed. Can you refer me to where I can find more information on it?

It’s taken me some time looking through patch notes to try to figure out exactly how the process of updating the STEP guide works. As I understand it, the workflow is something like this: Official release of version 1. Incremental changes made over time to version 1, but remaining the same “version.†Official release of version 2, leaving version 1 stable(?) with the last set of incremental changes it had. Incremental changes made over time to version 2, but remaining the same “version.†Official release of version 3, leaving version 2 stable(?) with the last set of incremental changes it had. Et cetera.This seems messy to me. It involves constant revision of patch notes with “post-release†sections, and users not knowing whether anything has actually changed since they installed the most recent version. I feel that a paradigm similar to software code development would be cleaner and easier to track, along the following lines: Official release of version 1. It is modified (“hotfixedâ€) only to amend unforeseen game-breaking issues or unexpected unavailability of a mod. Hotfixes append to the version number in the form of 1a, 1b, 1c, or 1.1, 1.2, 1.3, etc. Incremental changes made over time to “STEP Forward,†an in-development, possibly unstable live branch of version 1 (automatically updated with hotfixes applied to version 1). When stable, STEP Forward is released as version 2. As with version 1, it is only modified with hotfixes. Version 1 is officially unsupported and will no longer receive hotfixes. Incremental changes made over time to STEP Forward (automatically updated with hotfixes applied to version 2). When stable, STEP Forward is released as version 3. As with version 2, it is only modified with hotfixes. Version 2 is officially unsupported and will no longer receive hotfixes. Et cetera.This paradigm makes it so users have a clear indicator that the version they are running is not the most recent, and also makes patch notes easier to maintain, as they should only ever change upon addition of a hotfix. ...I also think “STEP Forward†is the coolest name for a live branch but that’s kind of a personal point.