ACCEPTED STEP Patches

[EssArrBee]

Well, CORE is far from 128, around ~60, but Extended is at ~140, I believe. CORE could have more than one patch, but it would be from leaving out WATER for people that go with RWT or Pure Waters. It would be really easy to do though.

 

For extended, I would like to do one patch just for wearable lanterns and one patch just for all three SoS mods. then do a patch that groups together the other extended mods plus the CORE patch since there would only be minimal amount of masters added and easy directions to remove those edits could be given. Right click "this" -> Remove.

[Nearox]

z, I think EssArrBee was referring to https://forum.step-project.com/showthread.php?tid=3699 and

https://forums.bethsoft.com/topic/1462394-relz-skyui/?p=23032032

  

 

(Going a little off-topic) I haven't read through the entire bethesda thread but has there been any conclusive evidence that going over 128 does indeed cause those issues? Some of the names in the bethesda thread that discuss it are USKP & SkyUI authors I think, so that's credible enough, but I'm not sure if the issues extends further than hotkeys and max mcm menus... 

---

As for Waterbreathing Breathless Emerge' date=' not sure if it is still necessary. Not good with Dialogue records. Is it like FNV, or is Skyrim a bit different?[/quote']

 

Some time ago I looked into WBE. I believe the USKP 1.3.3c fixes the waterbreathing for argonians only while WBE does it for all, or something like that.  Not sure about 2.0

 

Edit: Also, would like to stress this again, the individual patches would not necessarily have to be made available to the STEP:Core public. They just make our life easier in the long run. 

 

For example EssArrBee, let's say that I will know make changes to the big extended patch, one week later some mods get updated and z makes some changes. Another week more mods get updated and techangel85 makes the changes. A few days later rootsrat. The big  patch probably already has over 100 patched formid's, if not many more. I am of the opinion that, unless we maintain a list for mod version numbers and a long changelog, there is a significant probability that we're going to lose track at some point. This may or may not cause game-breaking issues, but why run the risk? Individual patches wíth version numbers would be easiest to maintain. Don't really need a changelog for that imo as we could simply save and keep any patches made with previous versions to check the difference later, if need be.

 

The methodical approach I proposed before (or something similar to your liking) would really help to keep the patching project organized. We could for instance assign everyone involved to do the patching only of a certain collection of mods, so that the burden of patching can be divided amongst the group. E.g. EssArrBee does Wearable Lanterns/SoS while I am assigned to maintaining WATER/BOYD/Skyfalls (just giving examples here). E.g #2: People could be divided by their are of expertise, or what they enjoy more (e.g. someone does mods which need patching for worldspace/cell edits, another person does dialogue topics & npcs|). In the end, any of us could roll out the single patch by simply combining the work that everyone did. Using something like Dropbox as rootsrat proposed would be really handy (or a similar functionality from the forum/wiki if it exists). 

 

Anyways, this is all of course just IMO :)

[EssArrBee]

The problem we would end up with is that if the patches change the same things. then the one that loads last wins. We can't force people to use certain mods, but if we don't then we have to make a bunch of patches. Man, why can't Bashed Patch get cell and graphics imports, that would make everything so easy.

 

We would end up with a wearable lanterns patch and a sos patch and a wearable lanterns/sos patch. That would be easy to make, but would mean that someone like Will would have more work placing all the patches in the right order. The more I think about it the more I like the idea of a Patch that complements CORE and then one for each pack. We are already doing all the work to put together and test STEP and we also maintain an excellent wiki that is one of greatest sources of modding any game period. Not to be a stick in the mud, but we get excited about doing these things early on, but they become burdensome to maintain as time goes on if we try to make it to big a project. As mods get updated most updates will not affect the big patch and if they do we just forward the updates and it is minimal work.

[TechAngel85]

snip...

 

The issue I have about the big patch for extended is that it would completely remove the modular concept from STEP. At the moment, users have a choice which extended mods to include or exclude. When we are making 1 big patch for extended, we are basically telling users that step is no longer modular and that they now must install all the mods affected by the patch. The only way they could resolve this is to manually remove masters from the patch, which kind of defeates the purpose of keeping it as simple as possible for end-users.

 

What I'm asking is, if that is the intention or not? I'm still relatively new to the STEP scene so I may not be 100% aware of all the plans. 

 

Not true. The patch will not be a "required" component of STEP:Extended. Just optional like all the mods, but recommended to increase stability if all mods that are patched are installed. STEP will remain modular as ever. This is also where adding the TES5Edit instructions to the mod pages will help. It will allow those that can't use the patch to still patch the mods that they do use (albeit, on their own).

snip...

---

I'm for the single big patch. It's less time consuming for the users' date=' a hell of a lot less downloading and takes up less ESP slots which we've already figured out should be kept less than 128. Individual patches will quickly clutter up the Nexus page. I'm not against individual patches for the more popular mods; however, the larger single patch I think is the way to go. We have never do it and simply can not cater to ever single situation. Having one patch for Core and one patch for Extended is the better solution, imo, for those that are following those guides. Then if users add in additional mods, then it's up to them to patch.

 

I middle ground solution would be to add the TES5Edit instructions to the mod pages, which I'm 100% for; however, Z doesn't seem to want to do it for some reason. I think he thinks it'll add into much complications for the users that aren't advanced enough; however, we can simply put a "For Advanced Users Only:" header in to solve that.

 

I missed this ... and Core approaches if not exceeds this. the max plugins should be much higher. What is your source?

 

I like TESEdit instructions for mod pages, but we will need to build that functionality as a modular component to Semantically store the info. Needs dev time.

 

snip...

 

I was being discussed here on the forums. Neo brought it up and it seems creditable. Thread is here: https://forum.step-project.com/showthread.php?tid=3699

snip...

 

(Going a little off-topic) I haven't read through the entire bethesda thread but has there been any conclusive evidence that going over 128 does indeed cause those issues? Some of the names in the bethesda thread that discuss it are USKP & SkyUI authors I think, so that's credible enough, but I'm not sure if the issues extends further than hotkeys and max mcm menus... 

---

snip...

 

The point is that is new limitation is new enough that we don't know the extent that it reaches.

The problem we would end up with is that if the patches change the same things. then the one that loads last wins. We can't force people to use certain mods, but if we don't then we have to make a bunch of patches. Man, why can't Bashed Patch get cell and graphics imports, that would make everything so easy.

 

We would end up with a wearable lanterns patch and a sos patch and a wearable lanterns/sos patch. That would be easy to make, but would mean that someone like Will would have more work placing all the patches in the right order. The more I think about it the more I like the idea of a Patch that complements CORE and then one for each pack. We are already doing all the work to put together and test STEP and we also maintain an excellent wiki that is one of greatest sources of modding any game period. Not to be a stick in the mud, but we get excited about doing these things early on, but they become burdensome to maintain as time goes on if we try to make it to big a project. As mods get updated most updates will not affect the big patch and if they do we just forward the updates and it is minimal work.

 

And that is because several start out doing the work as a team, but the team eventually fails and it's left for one or two people to do the work; usually the Admin/Senior Staff.

[z929669]

Well' date=' CORE is far from 128, around ~60, but Extended is at ~140, I believe. CORE could have more than one patch, but it would be from leaving out WATER for people that go with RWT or Pure Waters. It would be really easy to do though.

 

For extended, I would like to do one patch just for wearable lanterns and one patch just for all three SoS mods. then do a patch that groups together the other extended mods plus the CORE patch since there would only be minimal amount of masters added and easy directions to remove those edits could be given. Right click "this" -> Remove.[/quote']

OK, we have close to 160 mods, but apparently only about 25% have plugins.

z' date=' I think EssArrBee was referring to [url']https://forum.step-project.com/showthread.php?tid=3699[/url] and

https://forums.bethsoft.com/topic/1462394-relz-skyui/?p=23032032

This refers to scripts and MCM, not plugins ... besides, I don't take assertions by anyone as "golden", regardless of their status as TES modders. Only assertions made by consensus across many experienced modders over a period of time ... with consistent evidence ... after I see for myself ... is golden. According to the testimony thus far, plugins do not need to be kept below 128 (that includes BSAs, BTW), only Papyrus dependencies do.

(Going a little off-topic) I haven't read through the entire bethesda thread but has there been any conclusive evidence that going over 128 does indeed cause those issues? Some of the names in the bethesda thread that discuss it are USKP & SkyUI authors I think' date=' so that's credible enough, but I'm not sure if the issues extends further than hotkeys and max mcm menus... [hr']

As for Waterbreathing Breathless Emerge' date=' not sure if it is still necessary. Not good with Dialogue records. Is it like FNV, or is Skyrim a bit different?[/quote']

 

Some time ago I looked into WBE. I believe the USKP 1.3.3c fixes the waterbreathing for argonians only while WBE does it for all, or something like that.  Not sure about 2.0

 

Edit: Also, would like to stress this again, the individual patches would not necessarily have to be made available to the STEP:Core public. They just make our life easier in the long run. 

 

For example EssArrBee, let's say that I will know make changes to the big extended patch, one week later some mods get updated and z makes some changes. Another week more mods get updated and techangel85 makes the changes. A few days later rootsrat. The big  patch probably already has over 100 patched formid's, if not many more. I am of the opinion that, unless we maintain a list for mod version numbers and a long changelog, there is a significant probability that we're going to lose track at some point. This may or may not cause game-breaking issues, but why run the risk? Individual patches wíth version numbers would be easiest to maintain. Don't really need a changelog for that imo as we could simply save and keep any patches made with previous versions to check the difference later, if need be.

 

The methodical approach I proposed before (or something similar to your liking) would really help to keep the patching project organized. We could for instance assign everyone involved to do the patching only of a certain collection of mods, so that the burden of patching can be divided amongst the group. E.g. EssArrBee does Wearable Lanterns/SoS while I am assigned to maintaining WATER/BOYD/Skyfalls (just giving examples here). E.g #2: People could be divided by their are of expertise, or what they enjoy more (e.g. someone does mods which need patching for worldspace/cell edits, another person does dialogue topics & npcs|). In the end, any of us could roll out the single patch by simply combining the work that everyone did. Using something like Dropbox as rootsrat proposed would be really handy (or a similar functionality from the forum/wiki if it exists). 

 

Anyways, this is all of course just IMO :)

This is why we should use a DMS to manage said document ... or SVN (whi8ch may be more appropriate) if a single plugin is where we end up.

 

Lastly, I think the patch should be built for 2.2.8 and not 2.2.7 (i.e., not for Water but for RWT2, for example).

[EssArrBee]

Are we using the wiki for a working 2.2.8 list? I haven't kept up with it, but I think trying things out amongst ourselves for 2.2.7 will give us an idea of what to do for the next release. I kinda figured out that making a bunch of patches individually might make sense for the people making patches and then what is released to the STEP users is a combined patch. The merge mod scripts available work okay, but a bit of manual editing is still necessary.

 

Here's a couple for Wearable Lanterns and SoS just to see if this is preferable for extended, they are good for anyone using those mods not just STEP users. Every time I open up TES5Edit I get a different idea of how it should be done, so that probably means we should play around with different methods for distribution. Maybe give a poll about a few options that we are willing take on, (not ask for suggestions that will just be a thousand different opinions) and see what people will actually use. When creating something for the community, we should always gage their interest so we know if something will get wide enough adoption to match our efforts.

 

EDIT: Sorry I just realized I messed up one of those patches, will update it later.

 

EDIT 2: Okay here they are fixed this time. Man, I'm hurting this morning. 

[z929669]

Just develop for 2.2.7 keeping in mind mods under testing and what gets accepted. RWT2 is accepted, although it is not showing that in the MT forum yet.

[Nearox]

With regards to STEP 2.2.8 wiki developments/changes, where would I write down suggestions? I suppose in this thread or alternatively in the 2.2.7 bugs one?

[EssArrBee]

Here for 2.2.8 development, keep 2.2.7 to bugs or mods that change/update and would affect 2.2.7 specifically.

[z929669]

OK. Rather than using a DMS, we should use SVN over Github or SourceForge for managing patch versions and contributions. Sound good?

[EssArrBee]

Just point the way, and we can get started now, so it doesn't turn in to even more work down the road. Better to bring this along as 2.2.8 develops instead of doing it all right before a version launch.

[z929669]

Whomever has the first big patch ready, register it with your favorite free SVN server and point the way. I would suggest Github or SourceForge, but whatever works. I have never set one up myself, but I subscribe t several.

[Nearox]

The 2.2.7 release brings us one step closer to the 2.3.0 goal by locking down STEP:Core into its much more final state. With this release' date=' many STEP:Extended mods were also added and several mods were removed from STEP; reasons can be found on the changelog for 2.2.7. The next few release will bring us even closer to the 2.3.0 goal by focusing on refining the non-Core mods in the current guide even more. These non-Core mods will ultimately formulate the basis for STEP:Extended, and this means that we can begin testing mods for 2.2.8 and 2.2.9 according to the STEP:Extended Mandate, which opens up the door to new possibilities.

 

This is now the "2.2.8 interim-2.3.0 release". The "rules" are somewhat relaxed, so we are open to more suggestions.

 

Please post here though if you have suggestions or comments on the existing guide and mod list.

---

For replacers, the test case should be a high-quality screenshot compare. We don't need a lot, just two or three sets of compares on the thread in Mod Testing (MT) marked [ TESTING ].

 

For non-replacers, please head over to MS and read the Announcement. Then go into the testing thread and contribute some test ideas or some of your own test results.

 

The idea is that testing --and logging of that activity on the threads-- will be touch & go for a lot of mods, and it should be pretty clear by anyone stumbling upon any mod thread what the end result is.

Hey, since it is the first time I would attempt to make a contribution to STEP development, can you be a little more concrete what the development goals are? What is the intended outcome of 2.2.8 and 2.2.9? Why these interim versions when work could already be put in place for  2.3? Once again I';m fairly new to this but I am wondering why there are small versions with small improvements running up till 2.3 when the latter - especially now that USKP 2.0 is out - is the major overhaul that is been looked forward too. 

[Kelmych]

I expect the idea is that for 2.3 the goal is to have all the decisions made on alternative mods, while for the intermediate releases we will get as much decided as possible while aiming at fairly regular updates. Sometimes the alternative mod discussions take a fairly long time.

[Nearox]

Alright. Is there any date or deadline by which 2.3 is supposed to be ready? 

 

I'm asking because I don't want to develop another pack around 2.2.7 or 2.2.8 if 2.3 is going to be the definitive version for a long time.