[1.0][MODLIST] Fluffy's Mods - New mini-mod: Power Cleaner [BETA]

Started by Fluffy (l2032), September 14, 2015, 06:16:45 AM

Previous topic - Next topic

BlackSmokeDMax

I also say remove the direct link, a link to the github release area is fine.

Then perhaps just a link to your steam workshop in general rather than independent. Or keep those, suppose they don't change.

wwWraith

Quote from: Canute on January 11, 2018, 08:28:58 AM
Just set a link to the github project release tab and no direct download anymore.
Then you just need to update the version number.
And i am not sure if you realy need the workshop link, didn't got the workshop a own good search function.
And if you like to keep a direct download link, do it like Kiame, just upload the new release with the same name to keep the link.
I'd not recommend Kiame's way, it already led to several confusions, too, so it won't make things much better. Imho the first suggestion is more reliable.
Think about it. Think around it. Perhaps you'll get some new good idea even if it would be completely different from my words.

Harry_Dicks

Quote from: wwWraith on January 11, 2018, 08:44:34 AM
Quote from: Canute on January 11, 2018, 08:28:58 AM
Just set a link to the github project release tab and no direct download anymore.
Then you just need to update the version number.
And i am not sure if you realy need the workshop link, didn't got the workshop a own good search function.
And if you like to keep a direct download link, do it like Kiame, just upload the new release with the same name to keep the link.
I'd not recommend Kiame's way, it already led to several confusions, too, so it won't make things much better. Imho the first suggestion is more reliable.

I already had a confusion with Kiame's way, as per the discussion me and Canute had on the Change Dresser thread. I think you should only have a link to the github release page. However I think you should just leave a "note" or whatever it is, saying the version number or last update. Look at this for Change Dresser, for example: https://github.com/KiameV/rimworld-changedresser/releases/ It says it was uploaded on October 25th, but I knew that he had made updates to the mod since then. So I figure that release is old, and I download from the master branch, but it wasn't setup that way for people like me (still missing some files). It would be nice if in you little "info" part you could put your mod's version number, or when you last updated. Because on the release page for Change Dresser, even though it says uploaded on October 25th, it had been updated since then, but it had no information there to display that to you, which is why I like when in the description box modders will put the date of upload, version number, and a small changelog.

EDIT: Also Fluffy, do you ever make a post saying when you do updates? Like your Colony Manager for example says it was updated 2 days ago, but I have mine downloaded from January 3rd. I don't remember seeing anything about the updates, or do you just do them silently and not post about it?

neltnerb

Hi Fluffy!

I have a thought about work tabs from a realization today.

I was previously unaware that crafting skill doesn't increase work speed for smithing, tailoring, or smelting. So, my speed at those tasks is far more dependent on the colonist than their skill. I use the expanded prosthetics, and even with tons of upgrades I have a crafting level 20 character who smiths at 127% speed because they happen to be lazy.

It would be super useful, now that I realize this, if each colonist's work speed at a task was displayed when you hover over the box on the work tab. The path to getting to the information is pretty messy, you have to click the "i" on the colonist and scroll down (pausing the game) in order to see this information otherwise.

Or even better, a visual cue on the skill box showing relative speeds.

Thanks for the great mod!


wwWraith

Quote from: neltnerb on January 11, 2018, 11:52:14 PM
Hi Fluffy!

I have a thought about work tabs from a realization today.

I was previously unaware that crafting skill doesn't increase work speed for smithing, tailoring, or smelting. So, my speed at those tasks is far more dependent on the colonist than their skill. I use the expanded prosthetics, and even with tons of upgrades I have a crafting level 20 character who smiths at 127% speed because they happen to be lazy.

It would be super useful, now that I realize this, if each colonist's work speed at a task was displayed when you hover over the box on the work tab. The path to getting to the information is pretty messy, you have to click the "i" on the colonist and scroll down (pausing the game) in order to see this information otherwise.

Or even better, a visual cue on the skill box showing relative speeds.

Thanks for the great mod!

I don't think it's a good idea because there are other things that depend on skill levels and often they are more important than just speed. E.g. the quality of resulting items. You should rather try Numbers mod, it will show you the sortable list of your colonists (or even other pawns) with pretty much any stats you want.
Think about it. Think around it. Perhaps you'll get some new good idea even if it would be completely different from my words.

neltnerb

I'm not suggesting removing the crafting skill level from the display, of course it remains important.

I'm suggesting adding the work speed as additional information in the hover text, because the other way to find that information is very tedious and a matrix of tasks by colonists is a fairly sensible place for it to be found.

SpaceDorf

Quote from: neltnerb on January 12, 2018, 01:08:51 AM
I'm not suggesting removing the crafting skill level from the display, of course it remains important.

I'm suggesting adding the work speed as additional information in the hover text

Thats sound pretty convincing not only for crafters but for other Traits that add or remove percentage values from worktypes as well.
Considering that there are some clothes and Trait mods.
Maxim 1   : Pillage, then burn
Maxim 37 : There is no overkill. There is only open fire and reload.
Rule 34 of Rimworld :There is a mod for that.
Avatar Made by Chickenplucker

Sarge

This is a great suggestion, but I have to add; I believe the problem lies with the way the (i)nformation window works entirely. It is frustrating when I want to find 'the best pawn' at anything on there. Most commonly for me this has been movement speed when I want to hunt a dangerous creature, chase down a fleeing raider for reasons, etc. Had I known about the crafting speed thing before, it may have been that though.

So really, in a perfect world, the fix should be that skill levels affect crafting speed (because it's just silly that it doesn't), the (i)nformation functionality needs reworking instead of band-aiding and I need to be handsome and filthy rich.

Fluffy (l2032)

@all; Thanks for the suggestions! I think I will stick to linking the github releases page, as well as the latest release (github.com/fluffy/mod/releases/latest auto-links to the latest release). I'm not sure why some of these appear to have broken, I'll look at the main page's blob of bbcode soonish. As for "Kiame's way", it's not for me to judge, but if he really is replacing releases 'in-place', that seems like a horrible practice. Not to mention pointless, since hosting with GitHub is free anyway.

@neltnerb; that's a great suggestion, I'll look into how feasible it is to implement. The main problem I can foresee is that workspeeds for specific jobs are defined in code, not in defs. That would mean I would have to manually find and copy/reference all the applicable formulas, and it would be hell to update for even vanilla jobs, not to mention jobs added by mods. If that is indeed the case, I'm not going to do it.

@Harry_Dicks; for incremental updates and bug fixes, usually not. I'll post here if the update was in response to something mentioned here, or if it's an update large enough that I want to get some specific feedback. I've got updating the mods on steam and github automated in a nice little build script, but sadly I haven't yet been able to automate creating a post or updating the main post on the forums.


Fluffy (l2032)

NEW (OLD) MOD!

I've spent a week and over 300 compilations in order to bring the Research Tree back*. It's still not perfect, but it's much better than it used to be.

Get it from steam; http://steamcommunity.com/sharedfiles/filedetails/?id=1266570759
Or from GitHub; https://github.com/FluffierThanThou/ResearchTree/releases/latest

Please let me know what you think!

======================================================
A better research tree.

# Features
- automatically generated to maximize readability*.
- 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 functionality to quickly find research projects.

# FAQ
*Can I add/remove this from an existing save?*
You can add it to existing saves without problems. Removing this mod will lead to some errors when loading, but these should not affect gameplay - and will go away after saving.

*Why is research X in position Y?*
Honestly, I have no idea. The placement of projects (nodes) is automated to minimize the number of crossings between dependancies (edges), and reduce the total length of these edges. There are many possible scenarios in which this can lead to placements that may appear non-optimal. Sometimes they really are non-optimal, sometimes they just appear to be so. See also the *technical* section below for more information.

*Can I use this with mod X*
Most likely, yes. Added researches and their requirements are automatically parsed and the tree layout will be updated accordingly. ResearchPal implements a lot of the same functionality as this mod, and the research queue will likely not work correctly if both mods are loaded.

*This looks very similar to ResearchPal*
Yep. ResearchPal is based on a legacy version of this mod that was kept up-to-date by SkyArkAngel in the HCSK modpack. I haven't worked on this mod in a long time, but I recently had some spare time and decided to give it another go. Feel free to use whichever you like better (ResearchPal has an entirely different layout algorithm). You can run both mods side by side to check out the different tree layouts, but be aware that the research queue will not work correctly if both mods are loaded.

# Known Issues
- The vertical labels for tech levels are drawn in the wrong location when UI scale is not 1. This is a known problem for me, the same issue appears in my Work Tab mod. As soon as I have a working solution, I'll go and fix it.
- Layouts are not perfect, if you have experience with graph layouts - please do feel free to look at the source code, and/or implement a Sugiyama layout algorithm for me that runs in C# .NET 3.5 (Mono 2.0).

# Technical
So how does this all work?

Creating an optimal layout is a known problem in the area of *Graph Theory*. There's serious mathematicians who've spent years of their live trying to figure out this problem, and numerous solutions exist. The group of solutions most relevant to our research tree (a *directed acyclic graph*, or *DAG*) is that derived from Sugiyama's work. Generally speaking, these algorithms have four steps;
- layering (set the *x* coordinates of nodes, enforcing that follow-up research is always at a higher x position than any of its prerequisites, this is a fairly straightforward heuristic)
- crossing reduction (set the *y* coordinates of nodes such that there is a minimal amount of intersections of connections between nodes)
- edge length reduction (set the *y* coordinates of nodes such that the length of connections between nodes is minimal)
- horizontal alignment (set the *y* coordinates of nodes such that the connections between nodes are straight as much as possible)

The final step is the hardest, but also the most important to create a visually pleasing tree. Sadly, I've been unable to implement two of the most well known algorithms for this purpose;
- Brandes, U., & Köpf, B. (2001, September). Fast and simple horizontal coordinate assignment.
- Eiglsperger M., Siebenhaller M., Kaufmann M. (2005) An Efficient Implementation of Sugiyama's Algorithm for Layered Graph Drawing.
Luckily, the crossing reduction and edge length reduction steps partially achieve the goals of the final step. The final graph is not as pretty as it could be, but it's still pretty good - in most scenarios.



BlackSmokeDMax

OOOH, new version of research tree! Exciting, I am in right now!

Sarge

Dayhum Fluffy, I literally just got my research tree to work with a lot of help now you do dis?

BlackSmokeDMax

Quote from: BlackSmokeDMax on January 12, 2018, 10:00:04 AM
OOOH, new version of research tree! Exciting, I am in right now!

And....

It is beautiful!! With a search option!!! (that works wonderfully!)

Thanks Fluffy!

Sarge

It seems to slow my PC down to a near standstill but only while I'm in the research window. Severe lag when trying to scroll in any direction.

Fluffy (l2032)

@Sarge; how many mods are you playing with? How many research projects are there? Do you get any errors in the output_log? If so, please upload it for me.

I saw that you also used ResearchPal, does that give similar slowdowns? There should be very little difference in the rendering times, if anything, Research Tree should actually be slightly faster.