z929669

OK, first the index ... but I wanted to understand the other pieces to see if anything can be consolidated. For example, you proposed "Entity" as the 'thing' common to all of the 'Index' names. Are all headings in the Index really 'entities' or are they just names listing many different concepts that warrant their own 'chapters' or 'topics'? If they are all game eitities, then I would propose Property:Entity If they are all 'topics', I would go with Property:WhateverTheyAre Looks like they are all really just 'topics' listed in what we are calling an 'index'. If true, It may be best to go with Property:NMS_Topic. Once we have this down, you can create that Property in DEV and add the "Allows Values" table just as we have for Property:Game, adding any other info to the table you want. The only specs that matter on this page are the [[Allows value::]] strings and [[Has type::Text]] declaration. EDIT: Actually, forget all of that. I am now thinking that Property may not be the best way to do this. Let me mock something up in DEV that we can work on. I may not be making all the right assumptions.

So let's work out what you are calling "GameFile". According to Game Structure, the game directory path has the following folder structure: Game Files root AUDIO BANKS_INTERMEDIATE FONTS INPUT LANGUAGE MATERIALS METADATA MODELS MUSIC PIPELINES PLAYTOGETHER PROMO SCENES SHADERS TEXTURES TPFSDICT UI Is this the content of ..\Steam\steamapps\common\No Man's Sky\ ? Configuration Files Where are the config files located? That page says here: ../Binaries/SETTINGS ../Binaries/SETTINGS/HDR ... but I don't see a Binaries folder above Save Files What is a 'recluded' folder? Saves appear to be included under: %LOCALAPPDATA%\Roaming\HelloGames\NMS\ with related data under: ..\Steam\steamapps\common\No Man's Sky\Binaries\SETTINGS\ ... so this is same dir as Config files? Game File SubCats Biome Global Texture XML How do these fit into the above?

OK, just nevermind all that^ ... I already know the answer. All I ask is that we STOP creating hundreds of Cats in our live wiki. Let's do all such work in DEV going forward as I explained previously. Each one of those pages just adds data that will never go away, increasing the size and complexity of our live wiki DB. Let me think about how we can do this stuff in the simplest way possible and using as much of the existing org as possible. If we need to create a few added NMS-specific cats, then so be it, but I'd like to see how best to use what we have and apply the NMS stuff to that. Index is definitely a property. GameFile seems more like a Category. As I mentioned, Tutorial = Guide and Reference = Reference unless I am missing something.

Ok, so the 'Index' really just looks like a way to organize (Categorize) information. This seems unnecessary, since MW already lets you do this in any number of ways via Categories and Category Tree extension ... see: https://stepmodifications.org/wiki/Category:Games. So they want a nav method it seems like, because they don't like the options available on the wiki. The same goes for the top nav bar. Why are we reinventing the wheel? This is a novel website design just for them and that game. The wiki provides the means to navigate, and we can expose that a bit more for that namespace, I think. Seems like a ton of unnecessary maintenance being created. So Index, NMSPage, and the NPS navbar are all unnecessary overhead that we are now committed to maintaining. It would be sooooo much simpler if they used the wiki natively so that we can dispense with all the extra work maintaining a completely unique paradigm for a single game. I have mentioned all of this before, so probably won't make a diff. Now, the GameFiles, Reference, and Tutorial stuff are all data org, so that's valid for providing the game info needed for modding that game; however, I think we should use our existing cat structure for this game as we do all others ... drilling down from Games: https://stepmodifications.org/wiki/Category:SkyrimSE All of our games have this exact structure, and so can NMS. The following don't fit in the general structure and most of these could go under "NonMansSky General Guides" ... or we can use Properties. We already have a Reference Category. Tutorials are Guides ... we have a Category for that too. I do really hate the idea of maintaining the NMS website if they are not going to adopt standard Step wiki practice within our org structure. The direction we are going adds both maintenance and performance overheads unnecessarily. It was one thing if they were going to maintain it, but now it seems to be on us ... so it should be OUR way (which will give them all the info they have now but in standard Step and wiki formats). If you insist that we MUST continue doing it the way THEY want it, then we at least need to make it work within the structure we have, which means continuing this conversation but not by creating an entirely unique Category structure that stands apart from all other games and a SMW structure solely to support the concept of their unique navigation preference. Very frustrating ...

Yes, the gallery link works

Your image links seem to be 'yours', so when we open them, we get this error: You should have a gallery for each of the files you upload to ImageBox. Hovering on them, you will see a 'share' link. From there, you can click "full size" to get the code for the sharable links. Here is a "Gallery link" I have: https://imgbox.com/g/va2ay91xP1 You can also use links for each image: https://imgbox.com/nFbtL9Q8 https://imgbox.com/Ujqv2rHC https://imgbox.com/53zsEeMZ https://imgbox.com/stEinY75 https://imgbox.com/3gugbBFb https://imgbox.com/ydUBzAqe https://imgbox.com/3WK74EYC https://imgbox.com/rav6jniC ... or BB code for posting on many forums. NOTE: You will still want to save as jpg format so that they don't take forever to load from the service.

No ... not exactly. Let's work via the page you created. I will leave some comments there and we can come up with a strategy. Nevermind, let's discuss here: GameFiles seem to be folder names that house NMS game assets? Please define the Index ... it seems like an arbitrary categorization of information (like at the end of a book)? What are GameFile subcats you are proposing? How do they relate to GameFiles? Could you define all proposed NMS Cats (GameFile, Index, Reference, Tutorial)? They each seem unrelated to one another (which is fine), but if there are relationships, we should identify them ... example: Are GameFiles, References, or Tutorials listed under Index? Do GameFiles have Tutorials? Are Tutorials a form of Reference? Just want to conceptualize the bigger picture.

There is an image format called a 'jpeg' or 'jpg' ... you are uploading 'bmp', which is much larger (as is 'png') use any image program to convert to jpg and watch the size dwindle. You can also possibly set your screen capture software to save in jpg format. If you have several images, you can use a free service like ImageBox (or a plethora of others). Why on Earth would you expect a ad-free website hosting free services to allow transient posters the ability to upload > 1 Mb? Disk space costs $. If you meet the posting threshold, you will get up to 2 Mb per post. Most forums (e.g., Nexus) have very limited post-upload capacity or don't allow uploads to posts at all. Use More Informative Console to discover what plugin is providing the missing textures/models on that building.

A property can hold any value of data type 'whatever', so numbers, text, page, etc. You simply assign the Property value like [[Entity::Textures]] on the page. There is also another way to assign the property silently using this format or using {{#set:Entity|Textures}} I think. Then that property and its value are associated with the page. You can examine our existing Properties and how they are used: https://stepmodifications.org/wiki/Special:Properties

No prob

Yeah, but our settings work nicely for Cathedral Landscapes. See sheson's post about grass textures/models in addition to modifying the RGB values for your needs (more red/green and less blue possibly to get a better match to the brown grasses). Looks like you have dark green grass in foreground, brown in short distance (LOD4?) and then light green farther out (LOD8?). Play with your LOD level distance settings to help determine what's what. You can do this without regenerating LOD. Seems like you have some strange contrasts and possibly some conflicting grasses that are defined in parts of the same area. You can also regen LOD using red 0.5 and blue/green = 0 to get an idea of the affected areas (LOD grass). Also, if grass model object bounds are not set, you will not get LOD for those grasses. Check the grass plugins you are using. Possibly simplify your grass setup.

Yes, essentially the same principle as Cats, but Properties allow values and also allow you to share Property values across cats, subcats and sub-subcats. Also, don't forget that you can use combinations of Properties, Cats, and other Concepts in Concepts (dynamic cats) ... or a Concept can be based upon any single of these. I can't think of a use case offhand, but maybe you will see the value. Read up on when to use Cats. Properties and Concepts to get ideas. It could be useful to set up Cats or Concepts for Reference and Tutorials, but you would know better with your understanding of how it all works together. EDIT: The Properties you have listed are actually "Allowed Values" for the property, which I assume is NMS_Entity? That's fine, but I would drop the 'NMS_' prefix from each, since it's redundant and throttles them to NMS alone. Properties should be treated like Facts as in they are generic to anything (like a number). The specificity of the context is understood by how the data are used ... in your case, for NMS_Entity (which could also just be 'Entity' and used for any game).

Sounds good ... still should consider using at least one NMS Property though. We may find use for more as we go (as I work with the data and understand more about what it means and how it's used)

Actually, it may be that NMSPage Template could be used for all of this along with Form:NMSPage maybe. or possibly something entirely new, but hopefully you see where I am going. There should be a way to largely automate everything you want to accomplish with a GUI form that ultimately does all of the work (create pages, assign cats and properties). This is definitely stuff that we should be mocking up and testing in DEV, since it can get messy and may need major revisions possibly from the ground up over several iterations. No caching out there or users, so rebuilding data is not disruptive, and cleanup is a matter of restoring a DB backup if necessary. In SMW, I think of Properties as 'Facts' in a relational DB star schema ... Categories are more like 'Dimensions' ... Concepts are dynamic cats defined by queries against Facts and/or Dimensions

OK, so after examining the OP and some of the markup: The potential overlapping cats like "Textures" should probably fall under a new Property called something like "NMS_Components" ... you name it ... some term that apples to all of those headings irrespective or whether or not they are Indexes, GameFiles, or References. So Property:NMS_Components will have page content analogous to Property:Game, where it is of type=Text and has strictly "allowed values". This allows us to circumvent the reused cats problem by calling the property value on the relevant pages. These pages could also have multiple cats corresponding to each parent cat, but we still would have the issue of 'shared' cats with different parents and a sort of cat loop or redundancy. Property resolves this nicely. On these same pages, you can have Category:Index (or one of the other two). No need for "Textures" to be a subcat of Index, GameFile, or Reference cats. It is a property associated with a page and that page's cat. Use a Template to generate pages that fall under Indexes, GameFiles, or References ... this makes assignment of Properties and Categories automatic based on criteria included in the Template (which can also use a Form so that users don't need to worry about calling the Template correctly ... same as ANY of our Templates, BTW ... see Form:GuideVersion, which uses a few Templates to build the ModList pages ... this is a very complex example, but you can see that any ModList page is just a bunch of Template calls built by the form ... same is true of Form:Mod mediated by Template:Mod) Use Categories sparingly and avoid creating cats that will only have a single page. If you have 40 cats, each with a single page, then find the commonalities among the 40 and associate the 40 pages using < 40 cats ... probably < 10 or 40/3 (number of 'master' Index, GameFile, or Reference pages) This is the 'index' page ... are there analogous 'GameFile' and 'Reference' pages? You could simplify if your framework houses all three using a similar structure or heirarchy. Then one Template/Form could be used to build out all of this for each 'new' "NMS Component". Listing the components in pages like the NMS Index page linked in the OP can be achieved using queries just like you are doing now. Concepts can also be incorporated, depending on other stuff you may want to do (allow users do download lists in CSV or XLSX, or tabulate results ... all kinds of stuff (see Result Formats on SMW).

This almost always comes down to a mod not playing nicely due to invalid options/version OR due to plugin sorting issues. Try disabling Alternate Start and re-sorting with LOOT (if applicable for FO3). Then test. If you don't crash, you know Alt Start isn't plaing nicely with something. Try disabling mods in batches (leaving Alt Start enabled). I would disable the last half of mods and then first half with Alt Start enabled. Note that you should run LOOT each time mod list changes (note all LOOT messages), checking that all plugins are activated beforehand. Whichever half contains the faulty mod, split that list in half, and so on.

If you look closely at each log file and the timestamps inside, you will see that they consist of multiple logs from multiple runs. You only need to post the relevant run logs. Alternatively, delete all logs and run again, but that obviously isn't necessary. I generally delete/move my logs between runs to avoid having to parse them. Also see sheson's previous post.

Try following our WIP instructions for Grass LODGen settings. You need to modify RGB values in DynDOLOD_SSE.ini (see screens). All WIP LODGen settings are also out there: https://stepmodifications.org/wiki/SkyrimSE:2.0.0#Grass_LOD_Configuration

OK, then we should simply copy over the changes to DEV so that I can fiddle with the site CSS there first to avoid issues. There is also no CSS caching on DEV, so changes can be seen in real time.

@TechAngel85 Are you making these RD changes to DEV or live? Best to do all of this on DEV so that I can tackle all of the behind the scenes stuff relating to the potentially-conflicting site CSS. Then I can make same changes to all on live once varified in DEV. If you did this in live, please mimic all changes in DEV so that we are in sync. Then I will get it all cleaned up. Since I have been away for several days, I'm a bit behind on changes and to-dos for RD stuff, so it might be helpful to post about all such changes on the Admin RD topic so that I have a checklist and don't miss anything.

@sheson May have some recommendations for this. Mine is customized, and I don't have the original settings on hand. Many of them come from Skyrim.ini anyway. Others may come from the DynDOLOD_SSE.ini, but I don't recall. @TechAngel85, @DoubleYou, @Greg ... I had planned on getting screens showing DynDOLOD 3+ MCM defaults to add to our dev guide MCM settings section, so this may be an opportune time to do that once we know what they are. I assume that one could easily revert to defaults via the MCM scripting config, but I am not familiar enough offhand and don't want to get sidetracked chasing down the best way to do this with all the other 'ducks' I am aligning.

@TechAngel85 can confirm, but this should not be a problem. The patches will also be updated for the next release, so it may be a moot point then.

That is not the intention. I updated the instructions again for clarity: https://stepmodifications.org/wiki/SkyrimSE:Kryptopyrs_Patch_Hub

But this also affects all object LOD4 like trees. I personally think LOD trees look much better at a min of fBlockLevel0Distance=50000 (or as high as your system can handle it). I also personally think tree object LOD is much more important and noticeable than grass object LOD, so 'dumbing' down tree LOD to accommodate the relatively unimportant grass LOD performance is an undesirable trade-off, IMO. In other words, I don't think grass LOD is important enough unless the system can handle it without throttling fBlockLevel0Distance (so "optimal, no grass" DynDOLOD settings are what I recommend for most systems).

It goes into SKSE folder only because NGIO precaching is mediated by SKSE64. If our instructions are followed for SKSE64, then this should just happen, but I have heard that some people get it elsewhere or in overwrite, so those persons are not setting up SKSE64 via MO as we recommend probably/ NGIO output can go into ANY /Data/grass folder in ANY mod.