ResearchPal - Forked

• Dynamically generated research tree based on graph layout algorithm.
  
• Shows research projects, buildings, plants and recipes unlocked by each research project.
  
• Projects can be queued, and colonists will automatically start the next project when the current research project completes.
  
• Search research projects by project name, unlocked recipe and mod name.

• Shift + Scroll: Zoom in / Zoom out
  
• Shift + Left-Button Drag: Pan
  
• Middle-Button Drag: Pan
  
• Scroll: Scroll Vertically
  
• Alt + Scroll: Scroll horizontally
  
• Left-click: Replace queue with research (and its prerequisites)
  
• Shift + Left-click: Add research to the back of the queue
  
• Alt + Left-click: Add research to the front of the queue (Added by this mod)
  
• Hold shift: enable numeric progress mode (Added by this mod)

• Group Research by Tech-Level: Whether or not explicitly separate techs by their tech-levels (neolithic, medieval, industrial etc.) (Will result in a MUCH larger and sparser-looking graph, and noticeableslower generation).

This mod completely rewrites the ResearchPal's graph layout algorithm and adds quality-of-life features to the original ResearchPal.

In this forked version:

• Most of the strange behaviors of original ResearchPal layout are eliminated. (e.g. Some arrows make U-turns when there's literally nothing blocking their ways, arrows sometimes go through other nodes etc.). And hopefully the layout looks better in general.
  
• Mouse-wheel scrolling doesn't affect the zoom level of the map.
  
• Highlighting works at any zoom level, and work with unavailable techs.
  
• Researches of different mods could be placed together (See below).
  
• Search keywords includes name of the mods the tech belongs to.
  
• During searches, unmatched techs are darken and matched unavailable techs are lighten a bit.
  
• Mouse-hovering over any techs highlights the prerequisites and children.
  
• Right-clicking icons brings out info cards of the item or recipe.
  
• Right-clicking nodes to pin a highlight, click anywhere else or right-click again to unpin.
  
• Drag and drop to add to, remove from research queue and reorder items in the queue.

• DON'T IGNORE HIDDEN PREREQUISITES: Fix the issue of original ResearchPal that completely ignores hidden prerequisites of research project. Default is true and is recommended be left that way.
  
• Align Nodes Closer to Prerequites: The heuristic will place nodes closer to their prerequisites instead of children (This affects the layout heuristic which does not guarantee anything, could result in some drastic change). Default is `false`.
  
• Group Techs from the Same Mod: Put techs from mods separately from the vanilla techs. Default is `true`.
  (Currently all vanilla expanded series techs are grouped together (based on the name of the mod "Vanilla XXX Expanded - YYY) with this option turned on. It is only a temporary solution of mod grouping).
  
• Minimum Separate Mod Techs Count: With the option above enabled, it determines the minimum amount of techs of a certain mod for it to be placed separately from vanilla tech tree (so that mods adding very few techs will still be placed along with the main tree). Default is `5` (So a mod adding 5 techs or more will be grouped together and placed separately).
  
• Search by Descriptions: Whether the search function consider the descriptions of techs. Default is false.
  
• Delay Layout Generation: Generate the layout at the first use of research tree, instead of when loading the game. Default is `false`.
  
• Background Layout Generation: Generate the layout on background when the game load. Current default is `false` but probably would be `true` in the future if works as intended.
  
• Always Display Progress: Always display the leftover points of ongoing research projects. Doesn't affect the zooming out display.

• WikiRim / HelpTab: Original integration no longer works.
  
• Any mod that imposes special unlock restrictions other than vanilla restrictions: Researchpal is likely to bypass those restrictions.

Save compatibility?

You can add it to existing saves without problems. Removing this mod causes some errors when loading, but these should not affect gameplay - and will go away after saving.

Why is research X at position Y?

Mostly it's determined by a heuristic-based algorithm, which means that in general we try our best to guess the better position of a tech to be at, but not actually know why they are eventually there. Details see below.

Loading performance?

Reportedly much better than the original ResearchPal, but do let me know me if you believe the mod is causing serious loading performance issues. You can also try to enable the background generation option and see if situations improve.

This looks very similar to ResearchTree and ResearchPal

There was first Fluffy's research tree, then NotFood and Skyarkangel's ResearchPal is a fork of it, and this mod is a fork of the latter. We're all basically using the same UI framework (supposely created by Fluffy) so of course.


Let's start with a quote:

Originally posted by Fluffy:

Why is research X in position Y? Honestly, I have no idea.

The new algorithm is mainly based on the Sugiyama's original work[ieeexplore.ieee.org] with some my personal tweaks, which:

1. Separates nodes in a graph to layers.
2. Applies heuristics trying to minimize the total amount of arrow (edge) crossings between layers and determines the order of nodes in layers.
3. With the order of nodes fixed, applies heuristics to place nodes in each layer near their (ancestors or children).

You may not know what I'm talking about, but the core algorithm has two important implications:

• It does NOT guarantee the absolute minimization of crossings (even worse, it doesn't say at all how far away from the optimal the result would be). Nodes could still be placed at obviously-suboptimal positions.
  
• It says (almost) nothing about the total length of edges. So edges may travel a bit of detour in order to get the destination.

It alone actually performs worse than the originally implemented algorithm in general, so I added an simple additional step after step 2 to further tune down the total edge length and number of crossings, but I still don't believe the result is anywhere near optimal.
After step 3, I added an additional step to adjust the position of some nodes to strictly better positions without compromising the core idea of the algorithm.

github repository of this mod[github.com].
Please feel free to make technical suggestions to the algorithm if you have any idea how to improve it.


I'm a computer science student who have almost no idea of rimworld modding in general and hardcore c# programming. So should there be bugs or compatibility issues besides the core algorithm, I will try my best to resolve them but I can't really promise anything beyond my capabilities.