Since version 4.0.20000, the mod loads extremely slowly (presumably due to the newly added research browser). The loading times when I start the game double because of this one mod alone (and I'm playing with a total of 129 mods!).
(4.0.20002 dont fix this, btw.)

To be honest, I don't understand why this research browser was added in the first place. It would be much better suited to a separate mod.

Thanks for the feedback
Ive had a lot of trouble getting this mod to support 200+ running mods without conflicting with any single one of them...

im sure theres a better way of doing this, but right now at startup it runs checks to make sure all of the technologies it tries to add dont break some new mod or specific combination of mods that i havent tested.

Without these checks, if i add a technology or support for a requested mod, it could break a dozen combinations of mods that were previously stable. The thread before you was troubleshooting exactly this in v4.2.1 funnily enough...

I have a library of 60GB of mods and run 48+ hours of load/save/migrate tests across 1000+ combinations of em, but I ran out of RAM and one of the combos I never tested and didnt catch at startup caused nearly all technologies to be blocked, which was diagnosable in the research browser... Not sure how many people that affected.

So the browser shows what the research compiler did during loading because I needed to be able to see what technologies were being rejected when certain mods were loaded, and which techs were not showing up at all, or conflicting with other mods, and etc...

At the end of the day the performance and coverage of this mod needs a lot of work.
Hopefully by next weekend I will have the loading and startup issues fixed and we can start going back to adding more mod support.
thanks again, ill keep you posted

I completely understand you. The loading bar is stuck for a good 20 seconds while your mod is loading, so I almost think it's going to crash any minute.

I'll just wait for your update. It's not like it's unplayable. ;)

The loading bar is stuck for a good 20 seconds while your mod is loading, so I almost think it's going to crash any minute.

20 seconds is pretty good. For me, it adds 1–2 minutes to the load time.

However, it still takes twice as long as without the mod. ;)

I do a lot of testing and write mods myself, which is why I often have to restart the game dozens of times, so it's particularly annoying.

To add to this, i think something is going to need to change. because while i do admittedly have a lot of mods (313 in my mods folder) i gave up trying to use the new version of this after it about two hours of loading.

Actually, after further testing it seems there might be an incompatibility with Vanilla Galore/Space Age Galore? At least when i remove those two it loads a lot quicker... well at all really.

Might be something with mods that add a lot of alternate recipes and/or research nodes? i should note that i am trying to go from 4.1.20000 → 4.2.20002.

From looking at task manager while it's stuck on loading this mod it does seem to be doing something, i can see the ram usage jumping around and, at least when i removed Vanilla/Space Age Galore it would actually make progress and write debug info to the log. But with those and probably a few others it just stops.

If it is the research browser i would say to have it as a optional start up setting that's disabled by default, because this is a little ridiculous for it to add this much load time.

Yeah this is DEFCON 1, it should not be this bad.
In v4.2 I added support for a lot of new mods, big overhauls. I thought I was slick and would upgrade the research compiler (runs at startup and figures out what technologies to load AKA the thing that's causing all the lag) to handle not just the mods and technologies requested now, but any future request.
Eventually I plan to "derestrict" the compiler and allow it to generate missing technologies for any mod or combination thereof, even without programming it in... Basically pattern matching on roids.

Unfortunately and obviously I blundered. While each stage of the process is pretty much optimal (algorithms and such), the whole loop doesn't just check if it can load a technology safely, it checks if this is the BEST technology it can load (basically)...
This was added to make sure that ingredients like K2 science cards and mods that remove technologies would not be clobbered or incorrectly consumed.

I think we might be on track for a fix...
I've got a few ideas, I think I can eliminate checks by sieving them beforehand, and then for whatever valid competing possible technologies remain, rank them without sorting them.

Side note, the research browser library whatever I called it adds no loading time, and is designed to consume minimal resources (that being said I found a bug that causes it to cache some copies of factoriopedia recipes, but that's on the order of a megabyte or so, and will be gone in the next update)

Thanks again for all the feedback, it's good to know that people are actually playing through with the mod, or at least an older version of it!
I'll keep y'all posted, if I can pull this off v4.3 should be out by the weekend. If not, I might have to gut the compiler and switch to an extension based support model.
If anyone has any logs or reports or ideas too, I'm all ears. Cheers

Alright lets see how messy this gets, 4.3 out now

Alright, gave it a shot again loading with Vanilla/Space Age Galore, and like last time it took ages to load and/or just couldn't. Waited 4 hours this time. Removing those two and trying again it loaded in a fairly reasonable amount of time.

After that i changed the startup setting to the "Classic" compiler and added the Galore mods back, and again it loaded in a reasonable time. Though loading a save showed that (almost?) all the productivity research that this mod made on the older version had been removed.

After that i thought i should load my save without Vanilla/Space Age Galore just to make sure nothing changed. Turns out things did. Again for whatever reason the productivity research was gone.

Thought i would try and remove Dark Matter Replicators because it adds it's own lab with exclusive science packs and i thought maybe that was confusing this mod. No luck, log still said this mod skipped creating most if not all of the technologies because of "no_lab_compatible_science".
Trying again but changing the startup setting from "configured packs" to "all lab science packs" yielded the same result.

So my original issue might be different from the original of this thread. And i wonder if it may be related to the latter issue of all science packs being marked as invalid. Probably something with my specific combination of mods and/or startup settings so i can proved the list if needed. It is quite the semiotic mess of mods so i wouldn't be surprised if this near exclusive to me.

Even if the loading bar still gets "stuck" when loading this mod, it's still 60-70% faster now with the new update. At least, for me.

[EDIT]
The game loads much faster now, but it's no longer playable in multiplayer. My friend, who wants to join (I'm the host), gets the following error message:

"Cannot join. The following mod event scripts do not match the server's. This indicates that these mods could cause problems in multiplayer mode (during saving/loading). (Further details in the log file):
mod-more-infinite-research"

Excerpt from the log file:

"442.147 Error ClientMultiplayerManager.cpp:1079: mod-more-infinite-research was not registered for the following events when the map was saved but has registered them as a result of loading: on_tick (ID 0)
442.148 Error ClientMultiplayerManager.cpp:86: MultiplayerManager failed: "" + multiplayer.script-event-mismatch + "
" + "
mod-more-infinite-research"
442.148 Info ClientMultiplayerManager.cpp:608: UpdateTick(61816235) changing state from(ConnectedLoadingMap) to(Failed)
468.528 Info ClientMultiplayerManager.cpp:199: Quitting multiplayer connection.
468.529 Info ClientMultiplayerManager.cpp:608: UpdateTick(61816235) changing state from(Failed) to(Disconnected)
468.529 Info ClientMultiplayerManager.cpp:217: Deleting active scenario (global = true).
470.889 Info UDPSocket.cpp:238: Closing socket
470.889 Info UDPSocket.cpp:268: Socket closed"

We switched back to the previous version. Takes longer to load, but is stable in Multiplayer.

Well shit. On it, give me an hour

Okay 4.4.1 is out, hopefully better now.
Still working on performance improvements too

hmm, welp progress! loaded... till it crashed with this error. looking it over it does seem dark matter replicators is causing this issue (and maybe the previous?) with the "dmrsa-dark-matter-scoop" at the top there. I'm using Dark Matter Replicators Reborn version 3.7.1 if that helps with debugging. If i had to guess Dark Matter Replicators is probably the culprit for a lot of the issues i'm experiencing, given that it adds it's own labs, science packs and research.

86.218 Error ModManager.cpp:1767: Failed to load mod "more-infinite-research": more-infinite-research/data-final-fixes.lua:2: ...infinite-research__/prototypes/mir/pipeline/commands.lua:251: ...infinite-research__/prototypes/mir/pipeline/commands.lua:74: .../pipeline/compiler_orchestrator/context_construction.lua:81: ...s/mir/capabilities/science_integration/science_packs.lua:35: MIR approved science binding is unresolved: dmrsa-dark-matter-scoop (unresolved-approved-pack-dependencies:dmrsa-dark-matter-scoop). No research was removed and the former solver will not be invoked.
stack traceback:
[C]: in function 'error'
...s/mir/capabilities/science_integration/science_packs.lua:27: in function 'source_for'
...s/mir/capabilities/science_integration/science_packs.lua:35: in function <...s/mir/capabilities/science_integration/science_packs.lua:33>
(...tail calls...)
...r/capabilities/science_integration/lab_compatibility.lua:14: in function 'pack_is_admitted'
...r/capabilities/science_integration/lab_compatibility.lua:171: in function <...r/capabilities/science_integration/lab_compatibility.lua:139>
(...tail calls...)
...e-infinite-research__/prototypes/mir/planner/science.lua:7: in function <...e-infinite-research__/prototypes/mir/planner/science.lua:6>
(...tail calls...)
...rch__/prototypes/mir/planner/stream_compiler/qualify.lua:112: in function <...rch__/prototypes/mir/planner/stream_compiler/qualify.lua:32>
(...tail calls...)
...rch__/prototypes/mir/planner/stream_compiler/compile.lua:43: in function <...rch__/prototypes/mir/planner/stream_compiler/compile.lua:22>
(...tail calls...)
[C]: in function 'xpcall'
...-research__/prototypes/mir/pipeline/compiler_context.lua:45: in function <...-research__/prototypes/mir/pipeline/compiler_context.lua:37>
(...tail calls...)
...
...infinite-research__/prototypes/mir/pipeline/commands.lua:74: in function <...infinite-research__/prototypes/mir/pipeline/commands.lua:74>
[C]: in function 'pcall'
...infinite-research__/prototypes/mir/pipeline/commands.lua:238: in function <...infinite-research__/prototypes/mir/pipeline/commands.lua:226>
(...tail calls...)
[C]: in function 'xpcall'
...-research__/prototypes/mir/pipeline/compiler_context.lua:45: in function <...-research__/prototypes/mir/pipeline/compiler_context.lua:37>
(...tail calls...)
...infinite-research__/prototypes/mir/pipeline/commands.lua:251: in function <...infinite-research__/prototypes/mir/pipeline/commands.lua:250>
(...tail calls...)
[C]: in function 'xpcall'
...-research__/prototypes/mir/pipeline/compiler_context.lua:45: in function <...-research__/prototypes/mir/pipeline/compiler_context.lua:37>
[C]: in function 'pcall'
...infinite-research__/prototypes/mir/pipeline/commands.lua:250: in function <...infinite-research__/prototypes/mir/pipeline/commands.lua:247>
(...tail calls...)
more-infinite-research/data-final-fixes.lua:2: in main chunk
stack traceback:
[C]: in function 'error'
...-research__/prototypes/mir/pipeline/compiler_context.lua:49: in function <...-research__/prototypes/mir/pipeline/compiler_context.lua:37>
(...tail calls...)
.../pipeline/compiler_orchestrator/context_construction.lua:81: in function <.../pipeline/compiler_orchestrator/context_construction.lua:76>
(...tail calls...)
[C]: in function 'xpcall'
...-research__/prototypes/mir/pipeline/compiler_context.lua:45: in function <...-research__/prototypes/mir/pipeline/compiler_context.lua:37>
(...tail calls...)
...infinite-research__/prototypes/mir/pipeline/commands.lua:74: in function <...infinite-research__/prototypes/mir/pipeline/commands.lua:74>
[C]: in function 'pcall'
...infinite-research__/prototypes/mir/pipeline/commands.lua:238: in function <...infinite-research__/prototypes/mir/pipeline/commands.lua:226>
(...tail calls...)
[C]: in function 'xpcall'
...-research__/prototypes/mir/pipeline/compiler_context.lua:45: in function <...-research__/prototypes/mir/pipeline/compiler_context.lua:37>
(...tail calls...)
...infinite-research__/prototypes/mir/pipeline/commands.lua:251: in function <...infinite-research__/prototypes/mir/pipeline/commands.lua:250>
(...tail calls...)
[C]: in function 'xpcall'
...-research__/prototypes/mir/pipeline/compiler_context.lua:45: in function <...-research__/prototypes/mir/pipeline/compiler_context.lua:37>
[C]: in function 'pcall'
...infinite-research__/prototypes/mir/pipeline/commands.lua:250: in function <...infinite-research__/prototypes/mir/pipeline/commands.lua:247>
(...tail calls...)
more-infinite-research/data-final-fixes.lua:2: in main chunk
stack traceback:
[C]: in function 'error'
...infinite-research__/prototypes/mir/pipeline/commands.lua:241: in function <...infinite-research__/prototypes/mir/pipeline/commands.lua:226>
(...tail calls...)
[C]: in function 'xpcall'
...-research__/prototypes/mir/pipeline/compiler_context.lua:45: in function <...-research__/prototypes/mir/pipeline/compiler_context.lua:37>
(...tail calls...)
...infinite-research__/prototypes/mir/pipeline/commands.lua:251: in function <...infinite-research__/prototypes/mir/pipeline/commands.lua:250>
(...tail calls...)
[C]: in function 'xpcall'
...-research__/prototypes/mir/pipeline/compiler_context.lua:45: in function <...-research__/prototypes/mir/pipeline/compiler_context.lua:37>
[C]: in function 'pcall'
...infinite-research__/prototypes/mir/pipeline/commands.lua:250: in function <...infinite-research__/prototypes/mir/pipeline/commands.lua:247>
(...tail calls...)
more-infinite-research/data-final-fixes.lua:2: in main chunk
stack traceback:
[C]: in function 'error'
...-research__/prototypes/mir/pipeline/compiler_context.lua:49: in function <...-research__/prototypes/mir/pipeline/compiler_context.lua:37>
(...tail calls...)
...infinite-research__/prototypes/mir/pipeline/commands.lua:251: in function <...infinite-research__/prototypes/mir/pipeline/commands.lua:250>
(...tail calls...)
[C]: in function 'xpcall'
...-research__/prototypes/mir/pipeline/compiler_context.lua:45: in function <...-research__/prototypes/mir/pipeline/compiler_context.lua:37>
[C]: in function 'pcall'
...infinite-research__/prototypes/mir/pipeline/commands.lua:250: in function <...infinite-research__/prototypes/mir/pipeline/commands.lua:247>
(...tail calls...)
more-infinite-research/data-final-fixes.lua:2: in main chunk
stack traceback:
[C]: in function 'error'
...infinite-research__/prototypes/mir/pipeline/commands.lua:255: in function <...infinite-research__/prototypes/mir/pipeline/commands.lua:247>
(...tail calls...)
more-infinite-research/data-final-fixes.lua:2: in main chunk
86.272 Loading mod core 0.0.0 (data.lua)
88.296 Checksum for core: 1551277403
88.367 Error ModManager.cpp:1767: Error in assignID: recipe-category with name 'recycling' does not exist.

Works for me (Multiplayer). Thanks.
Found another bug:
If I limit the "Working Robot Speed" research to level 10, I can still research level 11.

Welp. looks like its working for me, even got all the proper research, thanks!
Though one thing thought, is there meant to be compatibility with bobs mods? bobs plates specifically in this case, as i look though the log and see at the top end that it tried to do something with them but didn't for various reasons.