Load Through Instead of Patch

[mpstark]

CptMoore posted on ModTek's issues:

Create BattleTechLoader.exe as a substitute for starting BattleTech.exe and that automatically patches any un-patched assemblies before starting BattleTech.exe automatically. Bascially a nice wrapper around BTML for users. Thats why Skyrim is doing.

[mpstark]

This is a straight improvement to the current patch-in-place behavior.

[Tyler-IN]

Do you actually want to do this?

I don't think you should make a BattleTech.exe substitute or loader, but you could merge in a module initializer and pre-empt and delay the Unity startup, display your own GUI, and ultimately do the same thing... You could patch everything but UnityEngine.dll (or whatever framework assembly we pick, e.g. mscorlib, System, etc.) at startup before it gets loaded that way.

I think the patch-in-place behavior can be more flexible and simpler in some ways than pre-runtime patching. Having both facilities available would be great though. Similar to "core mods" that have to modify the jar vs regular "mods" that are loaded by the mod loader in Minecraft.

[CptMoore]

I think the patch-in-place behavior can be more flexible and simpler in some ways than pre-runtime patching.

What do you mean, what exactly would be simpler?

[CptMoore]

I would propose moving the injector.exe out to the battletech.exe directory and allowing it to just start battletech.exe if it detects an injected assembly or has successfully injected an assembly. A /noautostart command line option would prevent starting battletech.exe automatically.

I also can see some additional features that can see being useful:

• instantiate and load special mod dlls outside of the game, so one can run prechecks for certain things
  • ModTek could have a small lib that runs and checks loadorder and does some other verification and then could interact with user
  • my compilation mod for dynamic compilation could start compiling already at this point and get everything ready for BTML and the ModTek. if one keeps the injector at a higher .NET level, I could introduce a more modern Mono.CSharp compiler with less bugs and modern language features.
• make a remote version check, see if BTML and associated mods are at their latest version
  • I think in combination with the previous feature, one can keep BTML core rather sleek

@Mpstark thoughts? I'll start with a this kind of exe asap, but I'd like some feedback for the feature points I mentioned.

[mpstark]

If the the launcher still patches the files on the hard disk, there is zero reason to change the fundamental nature of BTML. The only reason to change the fundamental nature of BTML is to change how the game is injected and I believe that injection through a launch-through process that doesn't touch the game files is basically the only way to improve the current behavior. That way the user can run the game without BTML-launchthrough and get the vanilla game.

As to adding in wizbang features like checking versions -- straight no from me. Things that are complicated break and foundational parts of how mods work should not break, therefor BTML should not be complicated.

BTML also shouldn't be moved from the \managed\ folder because it uses the games libraries to perform the patch, excepting Mono.Cecil which is included in the injector assembly. Since the game is the only part a users setup that we can rely on, this makes sense to me. Using the same libraries as the game reduces friction and therefor reduces complication.

Ultimately, I very much like the core choices that I've made so far for both ModTek and BTML. I want this project to stay working for as long as people are still playing the game -- surely you can understand the thought process of keeping everything simple at the foundational level.

[CptMoore]

If the the launcher still patches the files on the hard disk, there is zero reason to change the fundamental nature of BTML.

That was not what had in mind for the launcher, the launcher is for automating patching after game updates, so improving the user experience by just clicking an exe called BTMLLauncher .

But you ask for additional features, like the ability to start the native experience without mods. That can be achieved by making the launcher communicate with BTMLoader and telling it to actually load mods. Patching is done regardless.

Making it patch only in memory would be another neat feature, but thats yet outside of my experiences with C#/C++ and unity.

Please tell me if you are still against a BTMLLauncher that just automates patches, because that is what I was about to implement.

surely you can understand the thought process of keeping everything simple at the foundational level.

In what is simple I always have to defer to your judgement since you are obviously the one who has to maintain this and coordinate all effort. My suggestions are often from myself needing a feature and seeing features available in other modded projects. Sometimes its from the view of a modder and sometimes from a gamers point of view. I'm sorry if I overload you with questions and demand answers all the time, but from my point whats simple for you is hard for me to guess.

[mpstark]

There is a difference between building a tool over BTML and changing how it works. If you want to build a tool that depends on BTML or a tool that installs it, that's fine by me -- ultimately it's your time. It'd just be it's own thing, not be part of BTML if that makes any sense.

I don't personally believe that I would use it, but then again, since I've written this, I sorta know when I need to reinject.

[CptMoore]

An installer is also needed. Would you mind if I create separate projects within the BTML sln and add those to this repo for the launcher and installer?

The installer might take some time, my knowledge about this is kinda old (~10 years ago with NSIS).

Why put the launcher and installer in the same sln? Well release packaging, it should be one click to create the btml loader, btml launcher and the btml installer.

Or dont you want any code of such in this repo? You know my stance, if it is smaller than the linux kernel put everything related in the same repo. Different artifacts are managed using different projects under one single sln.

[CptMoore]

see https://github.com/Qwiso/QModManager , they dont have a loader but and installer, they ask just to reinstall the installer to setup everything again

they seem to have the loader and the dependency management (modtek) as the same app

[mpstark]

Look, I'm going to be real with you -- I like the way that it is. Small and self-contained. And I feel that I have clearly stated this and tried to be clear about what improvements that I think would be valuable. The constant barrage of insinuations that I'm wrong about choices I made is starting to wear on me as well -- I understand that you would make different choices then me. Hell, I might have made different decisions three years ago and almost certainly will make different ones in the future.

I do not feel as if a launcher that still patches game files or an installer bring any real benefit to the project as it is now, in the very early days. Perhaps when BattleTech modding is significantly more mature and the codebase has been tested over some amount of time, then it might be good to have an installer/launcher. Perhaps when HBS is not patching the game every week.

Ultimately, I cannot prevent you from spending your time doing these things, even if I think that they are not well spent. I can tell you that I probably won't be accepting a pull request that adds them at least for some time.

[CptMoore]

The constant barrage of insinuations that I'm wrong about choices I made is starting to wear on me as well

Since you feel that way, then I will cease doing that.

[mpstark]

You've made lots of suggestions that I've followed through on, and I don't think you've made any bad or incorrect suggestions. It's just that when it's the same suggestion made multiple times after I've tried to explain my reasoning behind making it.

I don't know, I could just be sensitive or hard to work with and just need to get over it. Or maybe I need to say 'no' or 'not right now' better, I don't know. I'm a work-in-progress just as much as the project is.

[CptMoore]

maybe I need to say 'no' or 'not right now' better

You did that in your previous post and I then understood, it was not a "no" it was a "not yet" with a weight on "not yet since I want resources spent elsewhere". Resources also include thinking time about the issue.

That's correct for you to decide as maintainer.

When you say you don't see a benefit, I hope to sway you with arguments on topics with differences in opinion. Now its clear that the core of the topic is often not what you meant to argue against, and a resource constraint doesn't go away with more arguments.

You've made lots of suggestions that I've followed through on

I'm impressed on the amount of things you were able to absorb and make decisions over, since I know that I've been bombarding you with bad suggestions too.

Sorry if I overloaded you. Just release a ModTek version asap, everything else can follow.

Launcher / Installer

I'm working on a launcher (finished for steam/gog) and installer (qmods copy/steam easy, gog still ongoing), but I wont put them out as a PR as to not bother you. I will also not put them on nexus unless you have no objections. Note that the installer will include BTML and ModTek.

I have to upload a patch for BTML though, as I'm unable to set Environment.UserInteractive to false , that seems to be a check to know that a program is running as a windows service.