Mod lists appear broken in latest build(new issue)?

this whole thing was originally meant to be a steam comment on the mod itself, until I realized they had length restrictions(which I was exceeding at least 3 times over), and also that you wanted bug reports posted to your git... so I hope you'll excuse the format and language/writing style. ...and general wall of text, sorry, this is my first time on git.

Hey there Fluffy, I love your mod(and frankly, I wouldn't be able to play the game without it, not with ~300 mods). But as of your last update, the mod list functionality is more or less completely broken for me. I even tried deleting(well, moving out of the rimworld directory :p ) the mod manager config file along with the mod lists folder. Up until now, I've been getting by with a locally saved copy of the previous version of mod manager(ironically, made by mod manager, talk about convenience), but that version as you know has the broken preview images...

So, clean slate, testing. I load the bare minimum mods I need to be able to prove my point/see if it was something in my old config just breaking things during the version upgrade. I've only got Core, HugsLib, and Mod Manager active(and what do you know, the game no longer takes 5 minutes to launch :p ). If I make a mod list using the "Save current list" command(normally I would manually create empty, correctly formatted list files, so that I could add my mods into them one at a time, then colorize them as a group, but that's a bit beyond the scope of this test here... though it does do a good job of outlining my personal use case for mod lists, beyond backing up entire load orders), and open it up in notepad++ just to double check, it has in fact added everything in my active mods list like it should have. However nothing except for Core actually reflects that fact. They all still offer the "Add mod to a mod list" context menu option, which should be absent given that there's only a single mod list, and they're all members of it. If I hit that, it does indeed "add" the mod to the mod list... again, in the config file, as many times as you hit the button, but those changes are never reflected in the GUI. As I mentioned earlier, Core seems to be the only mod that is functional in regards to mod lists at the moment, as it does correctly recognize its membership in the mod list I created, and respects any changes in color I make at the list level as well, along with offering me the context menu option to remove it from the list. As an addendum here, the individual mod coloring system does appear to still be functional.

I also tried unsubscribing from all inactive mods, so that I only had the test mods present in my mods folder(as I know inactive mods can still throw errors), in case that was causing some oddball issue to occur. Either way, in both situations, there was NOTHING in the log; they're identical in both cases. This log was taken on the latest version of Mod manager, with only the above mentioned mods active, however I did re-subscribed to my full mod list before doing this: output_log.txt

I'm just wondering if this is an issue you are aware of and are working on, or if I'm some strange edge case and this is some new thing. Either way, any input on this would be greatly appreciated, as for now I'm trapped on the previous version with no thumbnails like I mentioned earlier.

Sorry about the wall of text, thanks for (hopefully) reading it. :p -craze

PS: Your UI control element for the window resize grab handle in the corner on the mod manager window doesn't seem to capture the "mouse button up" event if your cursor leaves the bounding rect for the grab handle element, which its possible to accomplish if you drag the cursor all the way to the bottom of the screen, as it appears to be 1 pixel too short on that side(with the amount of mods I have, the first thing I do every time I open the mod manager is make the window as big as it can go, and getting it stuck in drag mode until I re-click the handle element is a minor annoyance). Hopefully you can take a look at that if you have the time, I'm running rimworld at 2560x1440, in case it matters.

PPS: Hopes and dreams here, but if you could add the ability to drag the entire window around(by, say, clicking and dragging the very top portion of it, even though there is no distinct 'title bar' to hint at 'grabability'), it would help dramatically with window real estate potential(even at 2k res, 300 mods still take up a LOT of room when you lay them all out).

PPPS: This one is just a personal complaint mostly, but there seems to be some kind of issue with the local copy generation feature, where it will randomly decide that the steam version has updated, even though it hasn't(in extreme examples, some of these haven't updated in the past 8 months). Having an option in the mod options menu to disable the 'local copy out of date' warning dialogs for power users would certainly be handy(even as a general feature, if/after this bug gets fixed). On a side note, under certain circumstances that I cant seem to nail down(and of course, don't throw any warnings or errors), the warning dialog you get upon closing the mod manager window sometimes pops up a second time after you hit confirm. No info on that other than the fact that it happens rarely when you have outdated mods, legitimate or not.

I have this problem as well, and unlike OP i got a nice stacktrace ^^ :

Rebuilding mods list
Adding mods from mods folder:
  Adding Color Coded Mood Bar(D:\RimWorld\Mods\Color Coded Mood Bar)
  Adding Core(D:\RimWorld\Mods\Core)
  Adding MedicalTab(D:\RimWorld\Mods\MedicalTab)
  Adding ModManager(D:\RimWorld\Mods\ModManager)
  Adding PickUpAndHaul(D:\RimWorld\Mods\PickUpAndHaul)
  Adding Recipe icons(D:\RimWorld\Mods\Recipe icons)
  Adding RelationsTab(D:\RimWorld\Mods\RelationsTab)
  Adding Replace Stuff(D:\RimWorld\Mods\Replace Stuff)
  Adding ResearchTree(D:\RimWorld\Mods\ResearchTree)
  Adding RimHUD(D:\RimWorld\Mods\RimHUD)
Adding mods from Steam:
Deactivating not-installed mods:
Verse.Log:Message(String, Boolean)
Verse.ModLister:RebuildModList()
RimWorld.Page_ModsConfig:PreOpen()
ModManager.Page_BetterModConfig:PreOpen()
Verse.WindowStack:Add(Window)
ModManager.Patch_Replace_Page_ModsConfig:OpenModsConfig()
Verse.ListableOption:DrawOption(Vector2, Single)
Verse.OptionListingUtility:DrawOptionListing(Rect, List`1)
RimWorld.MainMenuDrawer:DoMainMenuControls_Patch0(Rect, Boolean)
RimWorld.MainMenuDrawer:MainMenuOnGUI()
Verse.UIRoot_Entry:DoMainMenu()
Verse.UIRoot_Entry:UIRootOnGUI()
Verse.Root:OnGUI()

Exception filling window for ModManager.Page_BetterModConfig: System.MissingMethodException: Method not found: 'Verse.ModMetaData.get_PreviewImage'.
  at ModManager.Page_BetterModConfig.DoDetails (Rect canvas) [0x00000] in <filename unknown>:0 
  at ModManager.Page_BetterModConfig.DoWindowContents (Rect canvas) [0x00000] in <filename unknown>:0 
  at Verse.Window+<WindowOnGUI>c__AnonStorey0.<>m__0 (Int32 x) [0x00000] in <filename unknown>:0 
Verse.Log:Error(String, Boolean)
Verse.<WindowOnGUI>c__AnonStorey0:<>m__0(Int32)
UnityEngine.GUI:CallWindowDelegate(WindowFunction, Int32, Int32, GUISkin, Int32, Single, Single, GUIStyle)

Reached max messages limit. Stopping logging to avoid spam.
Verse.Log:Warning(String, Boolean)
Verse.Log:PostMessage()
Verse.Log:Error(String, Boolean)
Verse.<WindowOnGUI>c__AnonStorey0:<>m__0(Int32)
UnityEngine.GUI:CallWindowDelegate(WindowFunction, Int32, Int32, GUISkin, Int32, Single, Single, GUIStyle)

I traced this back to 634e11970b54e82b6ad574ba0c269eb53474e485 (specifically, the changes made to ModManager.cs) which capitalized the call to previewImage. According to ILSpy, that is supposed to be lowercase even on v1.0.2282.

The solution for now is to downgrade to ModManager v1.19.

Thanks for the intel! I wonder why my stack traces never gave me errors like that... This does, however, give me the ability to nab the 634e119 codebase, fix the incorrect references in ModButton_Installed.cs, and build my own copy of the assembly as a stopgap solution(so that I can retain whatever other fixes were introduced in that version and have working mod previews). Its worth a shot at least...

Now that Fluffy knows what needs to be fixed, I'm mostly holding out hope for the extra bits that I tacked on to the bottom of my bug report. In all honestly they probably deserve their own separate reports(barring the request to be able to move the window around, as that one is just that; a feature request), but nevertheless it would be nice to see them if Fluffy had the time.

I'll report back on if building a custom assembly fixed the issue on v1.19.

EDIT: I should have prefaced this. I'm a C programmer, not a C# programmer. Yes, I'm familiar with OOP concepts as I've dabbled in C++ before, but C# kind of makes me want to gouge my own eyes out, nothing personal. Up until taking up rimworld modding about a month ago, me and C# hadn't spoken for nearly 15 years.

Right now what I'm taking away from this now that I've got the project loaded in visual studio(this is a bit of me thinking out loud here) is that the .19 codebase used camel case, had functional mod lists, yet had broken preview images. the subsequent up through present codebases use pascal case, have functional preview images, yet broken mod lists, and for some reason throw errors for people not me, making it quite amusing to debug.

I'm still going to try swapping case, just to see what happens. Shot in the dark.

Worked like a charm, got working mod previews(and mod lists) on 0.19 now! This should hold me over until Fluffy takes care of whatever went wrong with the mod list situation in the latest build.

Thanks for the tip, MCOfficer.

EDIT: I forgot to put this in my original message, and this is mostly for you MCOfficer. I linked my project against the latest rimworld binaries, and the VS intellisense was telling me that the lowercase form(camel case) of accessing previewImage was deprecated as of... some version number I've forgotten now. Point being, it was recommending what I had already been intending to do; switch to the upper case format as a fix for the issue(which has in fact fixed it; I've had to mess around with my mod list many, many times now during development of another project I've got my hands full with(just counting the times between compiling this new mod manager assembly and now, mind you), as vanilla rimworld loves to unload your entire modlist if it encounters an improperly syntaxed xml file that it cant parse, usually in my case, when I block comment a large number of things for testing instead of just deleting them and relying on undo, and miss a stray comment open clause, lots of fun with a 5 minute startup time... mod lists on the other hand, fully functional, and saving my ass, and so are the previews!).

Thanks for the intel! I wonder why my stack traces never gave me errors like that...

You have to turn on developer mode and verbose logging in the settings.

EDIT: I forgot to put this in my original message, and this is mostly for you MCOfficer. I linked my project against the latest rimworld binaries, and the VS intellisense was telling me that the lowercase form(camel case) of accessing previewImage was deprecated as of... some version number I've forgotten now. Point being, it was recommending what I had already been intending to do; switch to the upper case format as a fix for the issue(which has in fact fixed it; I've had to mess around with my mod list many, many times now during development of another project I've got my hands full with(just counting the times between compiling this new mod manager assembly and now, mind you), as vanilla rimworld loves to unload your entire modlist if it encounters an improperly syntaxed xml file that it cant parse, usually in my case, when I block comment a large number of things for testing instead of just deleting them and relying on undo, and miss a stray comment open clause, lots of fun with a 5 minute startup time... mod lists on the other hand, fully functional, and saving my ass, and so are the previews!).

so - supposedly the change in 634e11970b54e82b6ad574ba0c269eb53474e485 was warranted, but 1.20 is linking against an old version of RimWorld? I'm not too familiar with C#, so bear with me.

Now that Fluffy knows what needs to be fixed, I'm mostly holding out hope for the extra bits that I tacked on to the bottom of my bug report. In all honestly they probably deserve their own separate reports(barring the request to be able to move the window around, as that one is just that; a feature request), but nevertheless it would be nice to see them if Fluffy had the time.

These should most likely go in their own issues, yes.

Also, if i may: you should try to be a bit more concise with your bug reports. It took me quite a lot of effort to read through your wall of text :D It's simply easier to work on issues which are direct and to the point. No offense ;)

I've already got it in developer mode; I wouldn't be developing without that, and the one time I tried verbose mode, it just overflowed my ingame log console with superfluous messages, to the point that I was losing valuable error messages on game startup as the buffer had gotten overrun(I really dislike how short the limit on that is).

As for the bug report itself, yea, you're right. But like I said right at the outset of the report; it was originally written in the context of a steam comment for the mod's workshop page(up until I realized that it both wouldn't fit, and that fluffy wanted all bug reports to be posted here on git, instead). As for the 'wall of text' side of things... that's sadly just more of a personal failing that I have. I find it very difficult to 'pare down' my messages, without feeling like I'm losing crucial information in the process...

Lastly, in regards to the three 'addendums' I have tacked on to the bottom of my issue report, one of which is a feature request; seeing as how I'm very new to git, where would you suggest placing such a thing? I honestly have no clue where things like that go(or if they even do go) on git).

Your feedback has been much appreciated in this matter, and no offense has been taken, MCOfficer.

i'm not familiar with the way fluffy handles things, but i (and pretty much everyone i know) would file one issue for each feature request. think of them as tickets, not necessarily bug reports.

So this is kind of a tangent, one of those 'side note' issues I tacked on; I more or less figured out what was going on with the window resizing grab handles: game bug. Simple one line code fix to the rimworld code base(which could take who knows how long to see the light of day)... or a Harmony PostFix patch to get results now. ModManager isn't really quite the 'correct' place for such a thing, but its where I stuck my copy of the code I wrote to fix it(a whopping 13 lines, and that's counting lines with nothing but braces on them, that could technically be all crammed onto one line).

The main issue is that the since we're leaving the bounding rect for the resize grab handle, its OnGUI Event system stops functioning(you notice this when you drag to the bottom of the screen, but not the right hand side; it turns back to gray instead of blue, as if you had withdrew your mouse; it thinks you aren't hovering it anymore). The main issue here, is that the logic to catch the 'mouse up' event and stop the dragging happens via that system. My patch simply postfix's it to perform a second check using the global input checking library(which doesn't rely on window boundaries or z-depth, which in this application really don't matter at all; we just need to know if the mouse has been let go of or not) and then updates its internal dragging variable accordingly.

That solves the problem one way. Ideally I'd like to see the resizer element have its bounding rect corrected so that it stays properly highlighted(an observable phenomenon) while at the bottom extent of the screen, and the standard OnGui Event system for mouse input will continue suffice(basically, no code modification required to fix the issue, beyond fixing the design of the window itself; though this is the 'idealistic' solution).

I'm not really sure where to send this, or if I should do a pull request or what... ModManager is probably the only mod where I actually run into the issue, sure, but it turns out this is a problem with the whole game, and the patch I made patches the whole game, so I'm not sure if it belongs here either... Then again, it does fix the highly annoying issue in ModManager(well, annoying for people with 300+ mods)... I genuinely don't know what to do here... suggestions?

so, updating to v1.23.832 and reinstalling RimWorld 1.0.2282 seems to have fixed this. i'm not sure if my last rimworld update failed and i was on a wrong version, but it works now. can you try again? @craze42

Hey folks, sorry for the very late reply.

I'm trying to wrap my head around the many issues mentioned in what has become more of a thread. I've fixed the first issue relating to modlist controls not properly responding to mods being in/out of modlists.

I appreciate the effort you've clearly put into your report(s), but in future I would prefer multiple smaller issues. It makes it a lot easier to work with, communicate about, and makes me feel better about being able to complete more tickets ;).

The issue with p/Preview images should also be resolved now, there was a preview build for 1.0 that changed the preview image to a property as part of an optimization run (also changing the capitalization in the process). The problem was that two 1.0 version existed, and for a while, the github build was linking with an unstable version of 1.0.

As for the resize handle; I'll have a look. I'd prefer not to make such generic tweaks in my mods, as they may have unforeseen side-effects - but I have (had to) resort to it before (e.g. scroll wheel input in scrolling UI areas for the Work Tab).

Entire window dragging is on my wish list, I just need to figure out how it will interact with mod drag&drop.

Finally, not sure what's causing you to get false positives for mod updates. They're based on a hash of the mods' folder, are you sure nothing changed in there?

I've added rudimentary draggability to the window. Turns out this is a single Unity function, which means it was both easy to implement, and hard to get working just right.

As of right now, it works anywere but the Mod list areas and the windows' outer margin, so not on the top bar. Yeahh.... I might go for a dirtier hack, or stop using Window.DrawWindowContents, but for now it works relatively well.

@craze42 I ended up adding a patch for the whole game, I'm curious to see how you would've fixed the issue. https://github.com/FluffierThanThou/ModManager/blob/master/Source/ModManager/Patches/Patch_WindowResizer_DoResizeControl.cs

Maybe you could put yours on a gist? Or if you think yours is better, a Pull Request 👍 .

As the other issues here have been resolved, I'm closing the ticket. Feel free to reopen or open a new one for any remaining or new problems.

fluffy-mods / ModManager

Mod lists appear broken in latest build(new issue)? #49