Auto dialog-or-vanilla selector code places the dialog below the "Character Editor" in the Z-order, hiding it.

[slippycheeze]

Repro:

1. Install VUIE, and Character Editor.
2. Do something in Character Editor that triggers "full dialog" style display.
3. Wonder why Character Editor isn't doing the thing.
4. Move the Character Editor window, and see the VUIE delivered "full dialog" (from default automatic lots of items => dialog) is being displayed behind that window.

If this isn't sufficient I'm certainly happy to help provide a better repro case, or more debugging, but as far as I can tell this is sufficient to demonstrate the issue.

My expected fix: the dialog, or vanilla, style "drop-down" selectors always show above the active window in the Z-order, either by being the most topmost of topmost things, or whatever. :)

[legodude17]

I’m aware of the issue but I need to dive into Character Editor’s code to see why it happens, and I haven’t had the time for that.

[slippycheeze]

I didn't realise that time to investigate was the issue. Character Editor sets their layer to WindowLayer.SubSuper in their widgets; see CharacterEditor.CEditor.WindowLayer where they declare that.

Y'all sit at the much more normal WindowLayer.Dialog I'd expect. Certainly I can't see any evidence that anything in your code, or Verse, adapt the menu layer to that or whatever.

I just have no idea what the correct fix is, though it turns out my assumption (CEditor.Layer is internal static, so will be inlined everywhere) is wrong, and a real field lookup is used, so I can probably fix this myself by pushing the CE window down to a more normal layer with a quick, hacky patch....

[slippycheeze]

...ah! nope, turns out that is on you; set your float menus to have WindowLayer.Super; see the Verse.FloatMenu constructor, where they by default set this.layer = WindowLayer.Super for their drawing. I'll see if I can test a patch for this...

[slippycheeze]

...yup, that works. I could write a YOLO patch for you, but you can fix this by emulating the vanilla code and adding this one line to the constructors of your float menu windows. Doesn't seem worth it since you would need to do all the build and release steps by hand (presumably) yourself anyway.

diff --git a/Source/VUIE/FloatMenus/Dialog_FloatMenuGrid.cs b/Source/VUIE/FloatMenus/Dialog_FloatMenuGrid.cs
index 06124cc..813146f 100644
--- a/Source/VUIE/FloatMenus/Dialog_FloatMenuGrid.cs
+++ b/Source/VUIE/FloatMenus/Dialog_FloatMenuGrid.cs
@@ -16,6 +16,8 @@ namespace VUIE

         public Dialog_FloatMenuGrid(IEnumerable<FloatMenuOption> opts)
         {
+            this.layer = WindowLayer.Super;
+
             doCloseX = true;
             doCloseButton = false;
             closeOnClickedOutside = true;
diff --git a/Source/VUIE/FloatMenus/Dialog_FloatMenuOptions.cs b/Source/VUIE/FloatMenus/Dialog_FloatMenuOptions.cs
index 647ea79..e18e30e 100644
--- a/Source/VUIE/FloatMenus/Dialog_FloatMenuOptions.cs
+++ b/Source/VUIE/FloatMenus/Dialog_FloatMenuOptions.cs
@@ -18,6 +18,8 @@ namespace VUIE

         public Dialog_FloatMenuOptions(IEnumerable<FloatMenuOption> opts)
         {
+            this.layer = WindowLayer.Super;
+
             options = opts.ToList();
             doCloseX = true;
             doCloseButton = false;

---

PS: definitely not your fault, but like many mods it's a pain to get this building. It'd be nice if you consider using Krafs.Publicizer to create the publicized core game assembly; I also found that this gist and Krafs.Rimworld.Ref made it so much simpler to get a mod building. (OTOH, third party dependency, so maybe you don't want that, IDK.)

You can also use this in your .csproj to use the nuget version of harmony, without it shipping the DLL on you. Ref to version 2.2.0 is, of course, because that is what the harmony mod currently ships.

    <PackageReference Include="Lib.Harmony" Version="2.2.0">
      <IncludeAssets>compile</IncludeAssets>
      <ExcludeAssets>runtime</ExcludeAssets>
    </PackageReference>

That doesn't solve the reference to VFECore.dll being missing, but at least everything else the mod depends on to build can be fetched from nuget and/or generated automagically. :)