TechAngel85

See: https://stepmodifications.org/wiki/User:TechAngel85/Sandbox3 If you're okay with broken things, fine. I'll yield. Regardless if you have never had an issue...the bug is there and the potential is there. {{{text|{{{2}}}}}} would still have to be defined as "text=" since named parameters have to be called. You can try it, but I don't think that'll work. EDIT: I did this in Dev and the issue remains, but it does work without "text="...isn't just still broken: https://stepmodifications.org/wikidev/User:TechAngel85/Sandbox3

So does the syntax not transclude? <syntaxhighlight lang="ini"> markup </syntaxhighlight> Just thinking there is no need to reinvent the wheel if we already have something that works for such. EDIT: No, we have this, which is inferior imo, if only because of the number of supported languages: https://www.mediawiki.org/wiki/Extension:Highlightjs_Integration

So not really a pre tag, but a faked one using a paragraph and custom styling. Works. Just be sure we're updating the Wiki User Guide so there are references for it. That's likely what I'll use to refresh myself when doing tasks, so as long as it's documented. Is there a reason we don't have SyntaxHighlight installed? Seems it would be useful for such things...not sure how it transcludes, but also works with VisualEditor if we are ever able to make the switch to it.

Sure, I'll just say if you want me to do anything, just let me know. I would like to keep the files separated out, like they are now, though. The mod is just too complex to toss it all into a FOMOD....been there done that, no not recommend with EVT. Also, you probably get the installation process, but it's setup up to install in the order of 1. 2. 3. (see file names). One of the main files (#1) must be installed. The others are optional and #2 can be skipped without issue. However if all files are used, to get the proper file overwrites, it must be 1. 2. 3. Pretty easy for the users to install this way, and makes it easier for authors to maintain. There are just are ton of options to deal with... Btw, the included 2D Billboards are provided for convenience so those should stay. They should be from Indistinguishable Billboards...unless you're planning on redoing those too. IDK if DynDOLOD 3.0 will build 2D Billboards or not. I tried the manual way and it's a LOT of work to get it to look good. It was far easier in the end to just include Indistinguishable Billboards.

@DoubleYou, @Greg, @z929669 Numbers must be assigned in the order they are given, else the template breaks. I'm not a fan of this simply because I don't always remember the right order the parameters are in. Thus, I prefer named. Also, unless you dive into the code and know what the numbers represent and which order to put them in, the templates come out broken. Forget a parameter...broken. It doesn't help that 50% or more of our templates are not documented or the documentation is old, which I've been trying to update as I go. You guys are in the bad habit of updating templates without updating the documentation. I say "you guys" because I don't know who (over the years), but I always update it, as needed. Examples too...I've found several examples left in that don't actually work due to changes in the template. (Seems no one followed and read the linked document or didn't understand it...) Numbered parameters aren't appropriate for anything used for unknown text...meaning the user can put whatever text they want for the parameter. Specially, "=" characters will mess up the templates when only using numbered parameters for this. This is because the first "=" character is processed as part of the template, thus, again breaking the template. Naming the parameters prevents the majority of these issues. That is why the Alert, Alert Small, PageTile, and other templates have the named parameter "text" or something else where the user is able to enter any text. As advanced users, we often forget the everyday user's , who is not likely fluent in "wiki", prospective. All most user are going to care about is that the templates are easy to use. It may be more to type, but in most cases named parameters are simply easier to remember vs the arbitrariness that inherently comes with using numbered parameters. It's easier to remember a name (especially when they're consistent across templates) vs numbers, how many numbers, what the order of the numbers represent, etc. for a single template...and we have dozens. Imo, named parameters are more user-friendly by nature. With all that said, I'm not wanting to change all the templates. Just keeping a consistent standard where it applies, regardless of convenience; else why have the standard if we're going to bend and break it where it pleases us. In this case, it just so happens to be a bug fix too. Yes, this template will use a combination of numbered and named. The color is the numbered {{{1}}}. The displayed text will be "text" to stay will the other templates' format. This is also to prevent the bug with the "=" character. Since there are only two parameters and one is named, it will not matter the order these are listed by the user. This makes it user-friendly: {{fc|color|text=blah}} ...works! {{fc|text=blah|color}} ...this works too! But is not recommended, because it makes it harder for maintenance purposes. {{fc|text=blah}} ...we could make this work too, if we wanted to make the default...highlight? However, having one standard (the first example) makes it much easier for maintenance (like using Replace Text). Replace Text makes this a five min task.

@Greg, @z929669 If we're okay with those changes, I will go ahead and make them and replace without causing any issues. Several that I checked already aren't even being used. The syntax of the template will be updating too, though, which is just adding "text=". This is still the documented way to prevent issues when transcluding certain characters: {fc|keyword|text=BlahBlahBlah}}

Just ignore it. All forms were converted in latest patches using xEdit.

Discussion topic: Site Color Palette by Step Modifications Colors and classes by theme for use on the Step platform. This is our color standardization in use across our official content and features. This is implemented so there aren't multiple staff/curators assigning colors palettes to elements arbitrary, thus, keeping the theme consistent across our official content. Highlight and dimmer are just that and shouldn't need any special standards. They are simply used to provide dimmer or highlighted text. Current Color Palette red salmon orange yellow chartreuse green blue purple magenta highlight dimmer Color Standards ROYGBIV Red, Orange, Yellow, Green, Blue, Indigo, Violet Step's Color Palette in ROYGBIV order: red, salmon, orange, yellow, chartreuse, green, blue, purple, magenta Multi-Use Colors Any time a color must be picked for a feature that will use multiple colors. This includes two versions: Left to Right The simplest solution is to use the colors in the ROYGBIV order listed above. Left to Right - Skip Used when there is little to no space between the colors used, and more distinguished colors are required for readability: Standard: red, yellow, blue, salmon, chartreuse, purple, orange, magenta, green The colors sitting in the half way points (salmon, chartreuse, magenta) are ignored during first pass due to them being too similar to the colors before and after. From there, simply select every other color, left to right, until all colors are listed. A good example of this would be the flags in the mod tables. "Left to Right - Skip" Logic Pass 1: red, salmonignored, orangeskipped, yellow, chartreuseignored, greenskipped, blue, purpleskipped, magentaignored = red, yellow, blue Pass 2: salmon, orangeskipped, chartreuse, greenskipped, purple, magentaskipped = red, yellow, blue, salmon, chartreuse, purple, Pass 3: orange, greenskipped, magenta = red, yellow, blue, salmon, chartreuse, purple, orange, magenta, Pass 4: green = red, yellow, blue, salmon, chartreuse, purple, orange, magenta, green

I updated this template to fix the behavior of using incorrect keywords. Using a wrong keyword should have resulted in default text color (according the example), however, it was being highlighted, instead. This is corrected. I would like to challenge the need for each of the keywords used, though. The reason being is I sometime find it confusing and some of them just don't make any sense to me. Ultimately, I think it should be reduced to 3 keywords (max) for each color; less is better though. Here are the current keywords for each color supported: magenta purple addition, enhancement, confirmation, blue fix, functional, relevant, green, added chartreuse issue, unknown, yellow instruction, ilheading1, salmon, notice change, modification, orange, updated removal, non-functional, irrelevant, warning, red, dropped important, highlight dimmer Here is what I recommend (using ROYGBIV as standard): red, warning, drop "non-functional" I doubt is used irrelevant seems...irrelevant, ironically. removal and dropped are the same thing, lets just make it "drop" salmon, instruction, ilheading1 Is ilheading still in use??? Why is "notice" here? Our notices are blue...moved that. orange, update "change", modification, and "updated" are the same thing, let just make it "update" yellow, issue I doubt "unknown" is used. chartreuse, bug green, add "functional". "fix" and "relevant" do not seem relevant "addition" makes more sense to be green rather than blue, also since "added" is the same thing we just use the shortest version "add" blue, notice "addition" didn't make sense here. Move it to green Our notices are blue so I moved "notice" to here "confirmation" and "enhancement" don't seem relevant purple, development magenta important, highlight dimmer, dim Assuming "ilheading" is still in use, that is a reduction of 9 keywords, which should help to optimize this template even further...considering its heavy use.

Discussion topic: Realistic Boat Bobbing Patch Hub by jjensen6823 Wiki Link Accepted for v2.0

Exactly what you circled. This is the fixed colors: z929669 EDIT: @R0AST3DN3WT you will want to load the LW patch with LoS and modify the patch data to match the screen. Not sure why adding blue would work, but it probably is because R/G values are also decreased.

There have been minor grammar revisions to a few of our Privacy Policy headings. No content changes.

Honestly, Bethesda players should expect buggy releases by now...and expect the modding community to fix most of the bugs never addressed during the short period patches are released. Another thing that is trending, though, is longer term support for games with patches being coupled with free content releases. It's closer to a 50/50 split now than it ever has been between these two sides of "new content is free" vs "paid DLCs", where paid DLCs dominated the market not too long ago. Users are starting to expect more content from a $60 game than a 10hr storyline filled with a bunch of grind in between story scenes and after the story ends. In turn, developers are trending towards longer term support and continued development rather than just the "one and done" approach of the past. Bethesda is already doing that with Fallout and The Elder Scrolls with their MMOs (and the unfortunate Creation Club). It wouldn't be unreasonable to assume these next few single-player Bethesda games (Starfield, ES6, FO?) to be supported in the long term with patches, CC content, and full-sized DLC for the next decade after their releases. I am still very excited about the quality of the visuals. They are stunning for a Bethesda game and I can't wait to get my hands on that CK. I'm also curious the approach the modding community may take. The majority of the mods released are mesh/texture mods and I'm fully expecting many of these assets to be fairly high quality from vanilla. The in-game preview we got pretty much show this. But is it going to be mod-able at all? That question has yet to be answered, but I don't see any reason it wouldn't be.

I'm good with this as long as the Changelog is updated so that we can review changes. If anything needs to be reversed before release from a review of the changelog, then it should be fairly easy. Obviously, if the change isn't trivial it should be discussed.

Starfield E3 Trailer Watching Bethesda's Starfield E3 video confirms three things: Starfield release date: 11-11-22 (they like that date...) Xbox exclusive (likely for the PC too, but possibly only via Game Pass; unconfirmed) "Creation Engine 2" is confirmed (new CK) The video is "in-game" footage so if you didn't pay attention go watch it again and look closer at everything! They're giving us a look at what their Creation Engine 2 can do (likely maxed out). Starfield will be the first release on their truly next-gen engine, and that detail is amazing! Now take all that and imagine ES6! The thing about the "Xbox exclusive" detail (and all the optimized for Xbox Series S/X talk in their showcase kind of support this) is what the Xbox Series S (digital version) has for a graphics card roughly compares to a GTX 1060. So if these games are optimized for this, then that is impressive. I would have at least expected to need at 2000 series card for that level of detail. Of course, much of that could be marketing and you only get that level of detail on the Series X, which is closer to a GTX 3060. (...is it just me, or does the launch command voice in the beginning before the video starts and towards the end sound like Todd? His will be the first voice you hear starting the game...haha!)

It's a level list for all clothes and the chef stuff is clothing, so I would say it should have upper and lower parts. All of it.

That would have been an add from a mod someone that the file isn't actually being included in the Guide because it's in the Patch. Obviously this one needs some addressing as you point out. It's not forwarding everything as it should.

One thing to note is that there are several edits to the Patch that aren't covered by any obvious mods because those things were incorporated into to the Patch by incorporating either 3rd-party patches or mod. These are only included if permissions allow or we specifically sought permissions from the author. Other things may have come from the result of dropping WB, so all leveled lists and such are handled by hand. Also keep in mind we only incorporate mods that are plugin-only. If the mod contains assets (textures/meshes/extra) they belong in the Guide. I would have to see this to know what it's from. It could be a leftover from something or from an incorporated mod. If there is a mod that does the same but is better, feel free to change to it. Full version was removed on purpose. We desire the Lite version for the Guide (see comment below about user choices). Fine with this too, as long as we get those permissions to incorporate and it's plugin-only. Leveled list stuff come from various mods and not all options will be within the Guide or installed by the user to see those conflicts (because it was incorporated). I'd have to see it to know what it is. It's sounds like you're making a ton of CR patches for "choices". There aren't "choices" in the Step Guides anymore. They are meant to be installed "as-is". Gone are the days where we catered to various setups. Now it's all or nothing. Which is why there are only two Step Patches and no more. If users want to deviate, they're on their own. If they want the "Step experience", they can install the Guide as is. Keep this in mind because we don't want 15 patches for various user setups...which sounds like what you're doing?

Guide is designed for mouse and keyboard (pure PC). Gamepads are never tested in an official compacity. We used to call this out, but it hasn't been an issue in a very long time. Perhaps it should be mentioned, again, though I think it would be obvious with all the mods added that have key binding options since you're not going to be able to do that with a controller. I only use a controller for certain games, Skyrim is not one of them.

I have removed that argument from both Guides since it seems to be a point of controversy. The gamemode arguments are included because we don't know if users are installing fresh or coming from another game. So if a user already has xEdit installed from FO4, they don't need to install it again. They can just launch it using -SSE or -TES5 (not -TESV), then xEdit will load for that game regardless if the EXE is named for FO3Edit, FNVEdit, SSEEdit, etc.

You may not have completed the elements for the quest, or if you have Not So Fast - Mage's Guild installed, then that will slow things down and stop them from happening. If so, go sleep in your bed in the college for a night to see if anything progresses.

Lets set a few facts on the table: Most of the work is not "new", it's new to the game Older games now support DX11 Devs confirmed a lot was "backported" from existing ME3 All single player DLC from the series is included All games include ME3's character creation We know the devs, more or less, "imported" the old games into the updated engine used by ME3. Doing this automatically gave them access to all of DX11 features, as well as, allowed them to easily recycle ME3 assets and effects into the older games. Evidence of this is in some of the textures and enhancements throughout the series. However, whether the changes are new, recycled from ME3, or a result from the old games ported to a newer engine, all are very welcomed! Mass Effect 1 Mass Effect 2

Well, that was my plan for the LE Guide since it didn't make sense to try to stretch our small staff over two of the same games right now. If Darklocq wants to continue with LE development and desires that to be the SkyrimLE Guide, then I'm all for its continued development. The easiest thing to do would be to mirror the SE Guide, as much as possible, and fork from it where required (like the LW/ENB/LOD sections). However, if the desire is to go outside our Mandates, then that would be appropriate for an unofficial guide using our framework. I'm cool either way.

I'm fine with this, but Editors don't have permissions for the Guide stuff, unless you changed that. Only staff-level of "Step Staff" (now call Step Admin) and higher have only ever been those with Guide-level editing permissions; not even the Super Mods had these permissions. I think the name we naturally went with for those staff doing the Guide stuff was "Curator" or "Guide Curator". I don't think any of it was set up on the Forums or wiki, though. Just need to create that member group. "Editor" was left over from the CMS. I like curator better than editor. As for the LE Guide maintenance, I wasn't planning on there being any more versions of it, no. The only maintenance I was going to do was what is being done by Darklocq, it seems, which was "routine maintenance" for instruction updates (for new versions of mods/tools), patch updates, no new mods would be added, old mods only dropped if they were no longer available....those sorts of things.

The game doesn't allow random deviations. Just straight settings for all NPCs. There is a height setting for each race and separately between male and females for each of those. So if Nord males are set to 1.05, then all male nords in the game will be 1.05. No issues with clothing. We were testing Lore-Friendly Heights, but the male Bosmers where just too small. The differences become forgettable after the initial noticing of the changes. But that is sort of the goal with a mod like this. If it's changes feel natural enough that they are passed over, then the mod is successful, imo. In that respect Lore Friendly Height was successful on most accounts besides that Bosmer issue.