z929669

I'll try to check this out this weekend ;)

Not changing really, but it could use some fleshing out and augmentation. RE Nexus methods: they have to support the least common denominator, since they are for-profit. We do not, and as long as we abide by our author's wishes with regard to their products, we are good to go here (since we don't really host any files, just content). Parlor philosophy is the majority and most restrictive, unfortunately.

Thanks for noticing ... fixed!

I just started this guide after reading through the SRO thread and seeing Uhuru's mention of Wrye's notes on the topic. I had read this years ago, and my own modding philosophy is same as Wrye's (my life philosophy, too with regard to "digital art" in general). https://wiki.step-project.com/Guide:Open_Modding This is such an important topic and philosophy, that I have stated as much and referenced this guide within the STEP Citizenship guide ... ... and have copied over Wrye's own official notes onto our wiki, because the original is not editable by the public at that location. We are opening up this document to the "cathedral" philosophy so that the modding community can elaborate and hone the document in hopes of garnering more cathedral-minded support and adoption by more of the modding community at large. The STEP Community is an "open modding" community.

And just to note: SRO does not require ANY optimization via DDSopt or any other compression-format change or mipmap adjustment, etc. It is already optimized in these ways. The only 'optimization' required is with regard to using the best texture sizes for the optimal performance-quality tradeoff. Read the torrent description. That pretty much says what needs to be done. Use max quality with no changes on all indoor-only textures and reduce any outdoor textures that are used frequently to 1k. It is tricky to isolate all the textures that can exist outdoors (e.g., some clutter can kill performance), so that is why we recommend the 'optimal' version. If anyone wants to improve upon that, go ahead, however, you are not welcome to post it from this forum. We have an agreement with Starac that must be honored, and I have made that plain on this and other threads. The torrent is fine, since it is anonymous and Starac has deferred users to that. Any updates are only available through Starac directly and may not be shared on this site. Informal warnings will be issued momentarily. @ moderators Please help me to eliminate all links to private SRO sources. The only valid links we support on STEP are to the torrents that Starac himself pointed us to (i.e., linked in the guide ... there is also a link to a 2K torrent that we can provide if anyone has it. Any subsequent violations (i.e., linking publicly to private SRO sources other than the public torrents) should draw formal warnings

Attached BAT will remove the redundancies. Delete Redundancies.7z

Not if you use the optimized version ... the redundancies are all removed ... nobody should be using the 2k version for this reason and for performance reasons. Follow the guide, that is why we recommend it (so does SR:LE BTW)

See link in my sig to get an idea of the VRAM hit of the 2k versus optimized. (Definitely use the latter!)

Looks good to me.

I like this one.

Yep, I did not want to go into the server source to add a new class. Quick fix :P

This should be fixed now, please confirm ;)

You can use whatever means you want to establish a functional MW dev install. Just go out to Tools > Special Pages > Versions to get the list of components/plugins and the versions we are using, then you need to set up a connection to your MW and begin developing in SMW. You don't really need an exact copy of ours, but it would be helpful to configure the same SMW classes that we have configured here. If you PM me and invite s4n to that, then I will defer to him as to how to set up a dev env (or if we can set one up for anyone that is interested on our server)

Will look into that.

De-maked form testing

We need some advanced STEP users to 'step' forward and be willing to learn SMW well enough to understand how to revise the system. The only way to do that is to install a VM with effectively a snapshot of our wiki. We may be able to construct a server side instance for dev purposes that uses several sandbox namespaces for independent dev envs to exist, since SMW integrates with the entire wiki (i.e., it is not possible to do sandbox dev on the standard wiki namespaces without disrupting the entire prod system)

I agree to some extent, but what must be made perfectly clear to all users (experienced and inexperienced) is that MO uses a system that inherently merges install order and load order ... installation is just setup of the virtual directories that are references with regard to load order ... install order ~= load order. Specifically, mods in MO do have a "priority order", and their plugins have a "load order". These are still decoupled. the difference with MO is that everything is an override and there are no overwrites. The overwrite folder and its benefits/uses (and all of the above) will best serve experienced mod users more familiar with other mod managers. It is critical to address the benefits of the VD and the overwrite 'mod' thoroughly and mark that as "vital info" for experienced modders in order to promote use of MO by experienced modders. One issue that very experienced modders have with MO is that it uses a unique paradigm that does not follow the traditional overwrite rules of manual installation and other mod managers.

Both 'Forms' usue unique template sets, and all is constructed using Semantic Mediawiki.The way data needs to integrate precludes the use of user-created templates (unless you know SMW and out SMW config, which only s4n knows really well). I even only mess with the system as little as possible due to the complexity and ease of breaking things, so please just submit these requests and we can eventually address. Project:Data Dictionary describes much of this, but it is a bit outdated (and it also uses its own SMW classes). Pretty complex stuff really. In order to construct the ideal Pack Guide system, we will likely need to rebuild our config under a dev environment and test thoroughly prior to implementing on the production server.

I think these look good at night, but pretty saturated and unnatural in daylight (screens above, vanilla lighting); however, this is too lighting dependent, I think, and requires that any raters judge by look in-game under vanilla lighting. I abstain from rating this for inclusion into STEP.

OK, I guess I thought it was higher res. Seems like 1k 565 is a great downsample then.

I vote this one should not be included in STEP.

Good tip ... I'll try it out

Me too, but this was already mentioned previously.

They certainly won't without a poll in the OP (which is why I asked for that, but who knows if the OP-er is even alive at this point!). Anyway, if they suddenly see an influx of posting and constant posting, it will bubble the thread up from the depths and draw more attention.