Purpose of this assembly loader. about bepinex

[bbepis]

If you want to know why I didn't initially use IPA, it's simply because I didn't know it could be used for koikatsu. I've mainly been involved with AA2 development, and such had never run into IPA, reipatcher, etc. before. When I did encounter IPA as I was looking into how to run a plugin system however, I had found a repo dating several months back, and I had assumed it was abandoned, as from what I've heard is not uncommon for other patchers.

If you're asking why I'm not using it now, there's several reasons:

From a subjective point of view, I've already invested a lot of time into my patcher, and I don't want to migrate my plugins to a patcher that's trying to compete. I don't really want to throw away all that work, especially when I've had people who have been experienced in creating unity patchers before give me pointers about how they would've done things right from the start. Moving over to another patcher would've invalidated all that and it would've just made all that time they helped wasted.

From an objective point of view, there's several things I disagree with how the framework architecture is implemented:

• The plugin interfaces and handling. Arguably, IEnhancedPlugin.Filter is something that IPA plugins use and that I don't have support for, but everything else in the IPlugin family is redundant. It's just proxying unity events to all IPlugin derivatives, regardless of whether or not there's actually code there. In comparison, my plugin loader initializes all the plugins directly as MonoBehaviours and then attaches them to the game, and then is never heard from again. It's a much more direct approach.
  • And in terms of functionality, if I wanted to use something like say OnGUI(), which isn't exposed by IPlugin, I'd have to make a completely seperate MonoBehaviour to be able to even do that, and still have to deal with the overhead of being relayed events from CompositePlugin.
• The patcher itself. From what I understand, the IPA patcher does some extremely heavy modification. It virtualizes everything inside Assembly-Csharp.dll, regardless of whether or not it's overridden or not. Why does it do this, when you can just easily patch methods at runtime? If you want a comparison, my patcher EXE is about 110 lines of code. Of those 110 lines, only 14 is related to patching. That's all I need to match the performance and flexibility of IPA. I cannot imagine how the patcher is easily maintained when it reaches 500+ lines of code.

It's not a good idea to encourage users to adopt every new idea that's put out there, and people have been perfectly happy with IPA.

Apparently not. From what I know of, the only community that actively encourages the use of IPA for koikatsu is the Honey Select userbase. 4chan has been very vocal about how they dislike IPA, and hongfire seems to have no idea that IPA exists in terms of koikatsu.

Even if you find that subjective and don't believe it, a lot of people have downloaded it. If IPA was the superior option in the users eyes, why aren't they using IPA instead?

There have also been user reports of IPA consuming more processor and GPU resources than BepInEx, although I'm not able to verify these claims. There have been none in the reverse, though.

Thanks for taking the time to ask me about it though. I have heard things about the IPA devs repurposing my plugins for their framework, and I was completely unaware of it, so it's good to have some communication as to what's going on.

[bbepis]

Sorry, pressed the wrong button

I'm open to discuss it further

[exdownloader]

Thanks for reopening the issue.
I'll try to address as many of my concerns as possible. To clarify, these concerns are not held by just me, but a good number (about 4 haha) others but I imagine that the philosophy holds up in general, I'll let you be the judge of that.

If you want to know why I didn't initially use IPA, it's simply because I didn't know it could be used for koikatsu.

IPA isn't particularly glamorous but it gets the job done. I feel that research before taking any large strides is very important to building a piece of software as crucial as a framework. I don't expect everybody to have a full working knowledge of a "modding scene" before stepping into it, but I'd also expect those same people not to try establish a standard before trying out what already exists.

I had found a repo dating several months back, and I had assumed it was abandoned

I'd say that this is a sign of good design. Updates can break installs, they can add new features that force users to upgrade. It's not always necessary to be updating a piece of software all the time, in fact people like to install a patcher and forget it about it. Updating all the time would be a downside if anything.

I've already invested a lot of time into my patcher, and I don't want to migrate my plugins to a patcher that's trying to compete.

Time spent in development is valuable, but not to the end user. To provide a better example: You've recently added in the the equivalent of IPA's modprefs. It's currently a little less featured, but it's still a step down. So while your version of modprefs is a valuable feature, it might eventually see the addition of a proper .ini file structure, invalidating the current format and requiring users to set things up again. While this is a more valuable format, the users see that development as tedious. But this is hypothetical.

From an objective point of view, there's several things I disagree with how the framework architecture is implemented.

Certainly. I have a lot of disagreements with how IPA is designed. That being said, the quest for efficiency will eventually result in poor design decisions for this framework, which would justify the release of yet another framework. I would love to strip out half the fluff in IPA, convert interfaces to abstract classes and adjust the assembly loader to work with bytes instead of locking file handles. However this brings nothing to the end user.
Everything boils down to the value offered to users. While developers can have lofty goals of achieving O(n) runtime or whatever, what people really want is new features, and I'm sure we can spare a few clock cycles to that end.

The patcher itself. From what I understand, the IPA patcher does some extremely heavy modification. It virtualizes everything inside Assembly-Csharp.dll

I hate this. Just wanted to share your disgust.

Apparently not. From what I know of, the only community that actively encourages the use of IPA for koikatsu is the Honey Select userbase. 4chan has been very vocal about how they dislike IPA, and hongfire seems to have no idea that IPA exists in terms of koikatsu.

You're looking at this incorrectly. Allow me to reiterate my earlier point: people want features. I wrote ports of your mods that work with IPA and got a great deal of interest for them. People don't care about the framework and it shouldn't be used as a measure for interest. It's the plugins that they want and those can be written for any framework. Your project is the only real development going on for Koikatsu. I've discussed ideas at length with others as to how to proceed with modding and the general consensus is to wait for release. The interest generated for your work is in no small part due to the fact that everyone else is holding off.
If you're worried about having your time wasted, is it not irresponsible to dive into a system which is subject to change? Would you not be able to put this stuff together in an hour or two after the title is actually released? It seems almost opportunistic to enter into modding during the window between trial and release, when modding really has no space to provide cool features. This is evident in the creation of a mod to... toggle components and take screenshots.

There have also been user reports of IPA consuming more processor and GPU resources than BepInEx, although I'm not able to verify these claims. There have been none in the reverse, though.

No idea. But your implementation is certainly a lot more lean. It's not something that would cause a massive difference I feel, but I cannot dispute the truth in the statement.

Thanks for taking the time to ask me about it though. I have heard things about the IPA devs repurposing my plugins for their framework, and I was completely unaware of it, so it's good to have some communication as to what's going on.

Thanks for your level-headed response and taking the time to work through the misinformation.
Allow me to reiterate: I am not associated with the IPA project in any way.
I did copy code directly from your repo and port it to IPA as a proof of concept, proving full attribution to you.

I have no intention to stop what you're doing but I do ask that you reconsider the purpose of all of this work. Yes, time has been invested but this could be time invested into new features instead of pursuing ideals that don't help the user.

[bbepis]

I would love to strip out half the fluff in IPA, convert interfaces to abstract classes and adjust the assembly loader to work with bytes instead of locking file handles. However this brings nothing to the end user.

...the users see that development as tedious.

I've discussed ideas at length with others as to how to proceed with modding and the general consensus is: wait for release.

Personally this is where I see an issue. If you are unhappy with your current framework, then this is the best possible time to fix it / use / make a new one. There are very little plugins available to be able to break, and users know that they'll be updating very frequently since everything is still under heavy development. If you wait for things to be set in stone, you'll lose that opportunity to have some freedom as to what you want to do.

That being said, the quest for efficiency will eventually result in poor design decisions for this framework, which would justify the release of yet another framework.

My intention isn't to try and be as efficient as possible, I just want to keep the code base as small as I can. I want this to be easy to maintain with redundancy removed, efficiency is only a result of it being very lean.

It seems almost opportunist to enter into modding during the window between trial and release, when modding really has no space to provide cool features.

I disagree with this as well. It's important to poke around and see what you can do even if it might not be a representation of the final product, because at least you have already got an idea of how the game works beforehand. We already know the file format for save files, which might be useful down the line when we need to save arbitrary information into the save file. Hell, we've even managed to load the buggy male editor.

I have no intention to stop what you're doing but I do ask that you reconsider the purpose of all of this work. Yes, time has been invested, but this could be time invested into new features instead of pursuing ideals that don't help the user.

As far as I understand it, the patcher is (core) feature complete. Everything from v1.0 onwards has been mainly focused on the plugins themselves. Stuff like the config class is just a little extra on top, since it just saves me from having to deal with doing individual implementations in each plugin. While it wasn't needed, it was useful.

Thanks for your level headed response and taking the time to work through the misinformation.

It's always an us vs them issue. It's always been that way for god knows how long, but I've seen it quite a bit with AA2 of 4chan vs hongfire. Honestly, I don't think we're ever going to reach a middle ground in terms of a common patcher.

I've seen the way how on your side prefers to use IPA because they've used it for a long time and don't want to change. I've seen what people have said about BepInEx and how they don't like it. However, I've seen on my side how people want to use what I've made simply because they know me. I've also seen the things they've said about IPA and how they don't like it.

I'm very sure none of us are going to drop the topic of which patcher we want to use. However, I'm not completely opposed to the idea of making my plugins work for both frameworks. I just didn't want to port them to IPA and abandoning my one completely.

I'll consider it, if adding the appropriate interfaces doesn't add too much bulk to the plugins.

[exdownloader]

Your consideration is good enough for me, honestly.
I believe I've stated, albeit not in a particularly public place, that I don't much mind for which framework ends up succeeding. I'd be totally fine with using your work if it ends up being the most popular option.
My concern is the possibility that both frameworks will be in use, which would suck, since they're the same thing.
You're aware of this now and you've thoroughly explained your reasoning behind your decisions. Thank you for taking the time to have this discussion.
While we do have diehard fans that will fight on the IPA hill, once your framework has more going on I'm sure that attitude will drop quickly.
Good luck with developing this further, I look forward to seeing what you do with it.

Cheers.

[bbepis]

Closed by request