z929669

https://www.mediawiki.org/wiki/Help:Images https://stepmodifications.org/wiki/STEP:Game_Guide_Framework

open DynDOLOD app and look for Ko-Fi

@i25Island you should consider posting in our general SE topic to resolve your modding issues rather than piling onto sheson's plate for LOD support. It's clear to me that you need some help with mod compatibility and general setup stuff, and there you will get more support. Once you have resolved all of that, you can rerun LODGen processes and post back here for that support.

I'm guessing 'modules' are > 1 mod either 1) packaged together (as a mod) or 2) associated for end-user installation ... together. #1 wors fine with our framework, but #2 is problematic ... this could be done if all 'modules' have the same ModGroup. Otherwise, no: module = Guide. I would advise against this "guides within guide" format if that's the case, but feel free if that's what you are set on doing. In that case, you can just continue doing your own thing on your User page. That's what the wiki if for ultimately. If you do care to work within the more traditional mod-build guide structure, I can point you to the relevant wiki doc to get you started. Once your guide is complete, I have a means to articulate it with the Fallout3 Home page so the URL shows up there for other users to find it easily without a specific link.

After reading through the above discussion a bit more, I now understand that mod permissions are an issue in some cases ... and for relatively trivial mods. If we can't get explicit permissions for a mod without waiting for who-knows-how-long, then I say we forget about incorporating said mod and use it "as is" or drop it. Either way, that's a mod change and a version increment. I'd say this all will end up being 3.1.0 version, so that metadata is reflected in SMW for LE DEV guide. It the mod is trivial, then you am "seconded" by me for any decision you make about dropping/adding. So you can move forward as you choose for this stuff if you like, unless @TechAngel85 objects in the next few hours. If 3.0.0 still 'works' as it is, then it makes sense to change any relevant mod Recommendations to bring it up to date. If such changes also apply to 3.1.0, then nothing to do for 3.0.0 mod-wise. It'll just get the updates. Go ahead and make any relevant guide text changes relating to phraseology or clarification (but not procedural changes, as that's 3.1.0 stuff). Also remember to update the relevant Changelogs. Lastly, I have a guide-framework how-to started on the wiki that you can use as a reference. Feel free to make any crucial edits if you deep necessary as you use it.

Nexus file updated to account for TexGen bug that will be fixed once sheson releases his next update to DynDOLOD 3. Please re-download.

@sheson Strange situation here. I suspect user error of some kind, but just in case, I want to confirm that it is NOT possible for TexGen output to place rendered trunk billboards into: ..\Textures\DynDOLOD\render\billboards\dyndolod\lod\trees\ Rather than ..\textures\dyndolod\lod\trees\ If possible, I need to convey how to prevent. Thanks EDIT: ... it just occurred to me that I am running some of your dev EXEs, including one for TexGenx64.exe ... This may be why. I recall you may have corrected this for me but unsure if it is in the latest DynDOLOD alpha package in the OP CRC (my version): 1B08A497 CRC in OP Mega download: 25439778 I just included the trunk billboards to the 3D trees file in a small update, so should be good until next version is ready.

I see. If the 3.0.0 CR patch needs fixing for continued use in 3.0.0 due to the issues, then I'd just make that correction without incrementing a version. One of us can post it once @TechAngel85 is satisfied with it. Either way you can continue on with the next version without the holdup. The guide-version-specific mod Recommendations can be used for the next-version CR patch, and the existing 'base' recommendations can be updated if necessary without affecting versioning (two different files on our Nexus page). The guide framework was designed such that any components of any guide version can be maintained independently, including mods.

In the future, rather than compressing the image(s) into a file archive, simply open up the image in your default image editor, and "Save as" to jpeg/jpg format and/or use said editor to change the image size (resolution) width to 1024 (ticking "maintain aspect ratio"). Alternatively, you can keep the size and adjust the jpeg compression ratio to something like 90%. Then you can copy/paste directly into the post rather than as a file.

I responded on Nexus (sheson may have additional advice)

@boycad Let's discuss your guide work here. It looks like you want to create an unofficial guide based on your own personal vision. This is totally fine, and you can do that using the Step guide infrastructure. Again, this benefits you and other curators (like us) in the long term. In response to your reply on the wiki: "badges" that I mention have nothing to do with the wiki or Wikipedia. It's just a forum group you would belong to "Fallout4 Curator" that would give you and others that curate FO4 guides permissions to do certain things on the forum and wiki to support that. It is also a label that all members can see so they know that you are an 'authority' on such matters. First step is to create your wiki mod pages as described on all the threads I linked on your wiki Talk page. I am also in the process of creating a guide for curators, but that will take a week or two.

Once you update mod instructions and changelog for 3.0.0 wo that this guide still 'works', then you are ready to propagate the guide and changelog to the next version (requires update to some SMW metadata), depending on what is changing (as described in STEP:Versioning). This is done on the SE Portal page, and I can do it myself or show you how to do it once you confirm where you are in the process. After that, it's a matter of ... Adding any new mods not present and adding guide-version-specific instructions to existing mods if applicable (this is rare) Adding forum threads for new mods Revising the ModList Revising the Guide doc itself Rebuilding Step patches as applicable Finalizing the new changelog Release (we will take care of some of this stuff) Create new guide forum thread Update Nexus Update guide redirect

Discussion topic: Aspens Ablaze by mindflux Wiki Link See mod page for screen compares for all versions. Those screens were created under Step WIP 2.0.0. I think "Autumnal" is the most vanilla-friendly option, and I think it is also the most realistic.

Discussion topic: Aspens Ablaze Add-On - DynDOLOD 3 by z929669 Wiki Link Adds 3D hbrid trees to all versions of Aspens Ablaze Consider adding a DynDOLOD mesh rule for these aspens to be loaded with CR patch

Try following the guides I linked and advice posted previously. If you do, you will succeed and likely figure some stuff out.

If you are trying to follow our DynDOLOD 2.xx instructions for DynDOLOD 3.00, then they are different. Use the WIP instructions instead. DynDOLOD 3 is better in so many ways. If you are using MO, then I suggest that you create a vanilla (default) profile and disable all mods. Run through the LODGen process on the base game. It's faster and does not suffer from all of the mod-specific issues. Once you get everything working and looking right in vanilla, you can rule out any process issues and focus on the problematic mod issues. If the tools, configs, and directory locations are not set up properly, things don't work. You will benefit by validating your environment and tools setup

Agree with Tech on Step patches. We want to maintain only one for CR and one for L&W. Any more is just more work for all of us. Guide users that want to deviate should also be OK with learning this stuff themselves ... give'em and inch, and they will take a mile. That said, in unofficial guides, you can do whatever you like. Lastly, if you are going to swap out "Masque of Argonian Vile" for something else, you will need to create that mod page on the forums (TIP: Edit an existing well-formatted mod OP and copy/paste the source, minding that you need a blank line after the <hr> to preserve that) and apply the "testing" prefix. Once it is approved by at least one other staff person, the prefix should be changed to "accepted". Also always link to the mod page on the wiki, even if it doesn't yet exist (use same string as mod name on post). The link will become valid later when you create the mod page. Also note that forum mod pages should also get the proper modgroup category tag (like '03-Resources', fe)

Yes, That's what I mean. I use one of them, too. The one I'm using allows mapping of multiple hotkeys/favorites breakouts that give my controller almost as many options as the KB, but I haven't configured it yet. You need to temporarily disable the controller option and possibly SKSE to set some of them I think. Anyway, lots of those controller-key-mapping mods out there for all games.

Thanks for the update. You should be able to edit mod pages now, but please hold off on making any changes other than updates to instructions due to mod updates (e.g., FOMOD options, etc.) until @TechAngel85 is able to address your findings with the CR patch. These changes can be made directly to the existing base Recommendations for 3.0.0 and corresponding updates to that changelog. Note the guide-version-specific mod recommendations as well (there are hover notes on the little icons on mod pages). Based on your post, this definitely constitutes at least a hotfix version increment (3.0.1) ore more likely a minor increment (3.1.0). Either way, you should still be able to add new mods to the wiki per the instructions on the LE Portal page. If you do this, they cannot be used in the guide until each has a forum post and has been 'accepted' for inclusion (at least one upvote by one of the staff). We can discuss next steps for updating the guide, regardless of any mod additions/removals. For example, the changelog should be updated to reflect any changes, but not the 3.0.0 changelog, since this looks like a version iteration. In this case, both 3.0.0 guide and changelog will be propagated to the next version pages and edited at those new locations ... more on that once we get there. Of course, it would be best to make mod-recommendations changes applicable to 3.0.0 (and changelog) prior to propagation into the new version.

Posts split off to new FalloutNV guide topic:

TIP: These mods can be found easily using the MO right "Data" pane

Absolutely necessary to keep these args for all xEdit apps in all guides. This is how we reuse tool instructions across Bethesda games and is not up for debate for that reason.

I do use a controller and haven't run into any issues yet, but I really don't play. I do stuff relating to testing is all. Past XP tells me that using a controller always presents some challenges, but they are all resolvable by the user. I do not advocate supporting them or even mentioning them outside of linking to a guide for that specifically. I think it should be up to the user to figure it out. Ultimately, we should have a guide on this, so anyone that dives into the controller options and workarounds should probably start such a guide on the wiki. then we can just point to that.

@Darklocq I created new game-specific wiki roles and changed you to the skyrimle role. You shouldn't notice any difference in your ability to edit pages in that 'game'space, but do let me know if otherwise. We will have the forum roles defined soon.

OK, then we are on the same page. Previous post edited to clarify for Darklocq