Menu

Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Show posts Menu

Messages - stigma

#106
I really like the expanding of animals that can be used as pack-animals. Vanilla limits this FAR too much - and arbitrarily so (elephants should be obvious).

The other tweaks seem ok I guess - but I tend to prefer that mods are split up when they aren't all about the same thing. Yes, these are all animals mods, but the mechanics being tweaked are very unrelated.

QUESTION:
Can you elaborate a bit on how pack-animals work now exactly? If I hunt an elephant will the entire herd come after me now and wipe me out? It's not at all clear what you insinuate in the description.

-Stigma
#107
PROBLEM:
Later in the game movement becomes a bottleneck very fast. You can't really do much far away from your main hub where people eat/sleep/produce because it becomes increasingly inefficient. By the time people arrive to do something at a distant location they will turn right around because they have a need for food, sleep ect.

SOLUTION:
A modified floor-tile you can call "moving walkway". These exist in real life and you have probably seen them at the airport and such. Basically a transport-belt for people.

Compared to a normal floor:
- They would have much higher movement speed (a simple value tweak). Maybe somewhere in the range of 150-200%? To be determined in balancing obviously.
- They require low-moderate electricity pr. tile. (but have inbuilt conduits like a solar panel)
- They have considerably higher cost than any other floor for balance purposes. Probably just steel (or other metal-like materials) I'm thinking. It would be nice to require components too, but I don't see a way to use less than 1 component pr. tile which is too much...
- They require MUCH more work to construct... not trivial to build at all
- Slightly ugly beauty. They are there for practical applications, not to look nice.

The idea is that you can make some high-speed connections for the most important areas - especially those areas outside your core, but the cost in work and resources will be high enough that you have to consider carefully when and where it is worth making them.

Since this is essentially just a modded floor I suspect that it shouldn't be terribly hard to create? For simplicity's sake we assume they can move in any direction, so simply a movespeed multiplier in the XML - and this should work perfectly with vanilla pathfinding.

If anyone wants to make something like this I would gladly help in testing and finding good and balanced value for costs, work ect. and generally assist in any way that I can. I've never modded for rimworld before, but I do some coding now and then.

EDIT: Oh, and if something like this already exists then please let me know. I wouldn't be surprised ... but I have looked and the only references I have found was for very early builds.

-Stigma
#108
As far as I understand insulation in this game I think this might be a problem...

because walls don't actually have an insulation value (they are all the same). The way the game determines how heat changes is considering the outside ambient as a baseline temperature and then also looking at the walls of the room (and one block outside the walls).

The result is that 2-thickness walls (no matter the material) is as-good-as-it-gets insulation, and it won't even matter if that room is inside a hot room or outside - both of those will leak heat the same.

I think that it is very hard to improve or change this system without a fundamental re-write of how the game handles the heat-leaking calculation - and that system is pretty primitive currently. It's not really a simulation but more of an aproximation that only gives logical results under simple and "normal" situations - and I don't even think that double-walls were really considered when the algorithm was made - which makes for some very weird results sometimes.

Like for example: On an ice-sheet, make a big room that is super-hot. Now place a double-walled room inside the hot room. That room will be over time turn very cold. It makes no sense... but since the algoritm doesn't look more than 2 tiles outside the walls it doesn't even recognize that the doublewall-room is not outside... and that's why it eventually moves towards ambient (unless you heat it from inside obviously).

TLDR: I suspect that you can't do what you ask unless the heat algorithm is greatly improved - but that's probably on a to-do list somewhere for future versions. A lot of primitive aproximations from very early versions are still left over in the current game. It depends on what Tynan feels is more important to deal with first I guess.

-Stigma
#109
I'm just airing an idea here, but I think that what a lot of players get frustrated with in Rimworld has to do with hauling being done in stupid ways.

PROBLEM:
Just as an example, Bob is set to mine, so he goes out and mine 100 steel. Job done.
Now he has cooking to do, so he heads back to base... but he does't bother to carry any of the steel back with him even though the cooking bench is right next to the stockpile. Instead, Alice who has a high priority on hauling has to run all the way out to the mine to pick up the steel - essentially a whole roundtrip wasted because Bob didn't have any common sense.

SUGGESTION:
When any new job A (any type) starts:
If this pawn has hauling enabled (any priority):
check X tiles radius around current location - is there anything set to haul here?
if yes: check if the destination for job A with X tiles radius and see if any of those hauling items are supposed to go there. If yes, choose the item with the least walking distance and haul it first, and queue the original job A to be done immediately after.

- Ideally, make radius X configurable in UI - but a value in XML would be fine too.

- Consider excluding the check for the most obvious emergency-jobs where every second counts - like firefighting.

- Keep radius X fairly low to avoid annoying over-emphasis on the added hauling. Only do it when you don't really have to go much out of your way.

- A more advanced implementation would consider the path to job A and not just the destination tile for it, so that hauling with a drop-point along the way could also be done efficiently, but this no doubt requires considerably more logic.

My thinking is that this should result in more intelligent and efficient use of time and basically get more hauling done almost for free since pawns will carry stuff around while they are doing all their other stuff and running around like ants anyway...

Is this feasible you think? I've seen a lot of tweaks to hauling so far, but nothing that tries this aproach of considering it in the context of other work that is being done.

-Stigma
#110
yup, modular tables are great and work in A17. I use them myself.

They are pretty expensive (in terms of resources) for their size, but also have more beauty. These values should be easy to tweak to your liking in the XML however if this bothers you and you want it closer to the same cost and beauty pr tile as vanilla tables.

These are basically the only tables I use now because all other tables tend to be too large and unwieldy. Being able to table'ify just exactly those tiles you want is wonderful! More people joined? No problem! Just expand that dinnertable! :D

-Stigma
#111
Thanks for the quick reply.

DEADLOCK JOBS
You are right that defining what is problematic dead-lock work is not easy. It's not clear-cut for many jobs, but assuming that it is possible to exclude certain jobs on technical level I think that some jobs are no-brainers for exclusion (like research, I don't see any good reason why workflex should consider this at all really).

I would also be very interested in a version that only did hauling because IMO better/smarter hauling efficiency as pawns move around is 90% of what this mod brings to the table anyway. Cutting away other problematic tasks reduces the problem right away (and I would use a haulonly-workflex even with no other changes).

The ideal thing would be for included jobs to be user-selectable of course. An ingame UI would obviously be the best way - but IMO if you can easily edit in the mods text-files somehow then that is almost as good if you don't know how to do the UI stuff.

CONTROL SYSTEM / INTERRUPTS
Currently the only way to control/limit workflex to keep it from inevitably deadlocking (for the rest of the day anyway) is to use the scheduling with some periods of "work" set up - but this overkill and has unintended consequences (work restricts a lot of things a colonist can do other than just workflex jobs). You also need to constantly monitor and adjust it since it's static.

All that is needed to prevent all this are some interrupt-points where jobs are re-evaluated to keep workflex from hogging 100% of the worktime (just like a CPU works with threads). It's very convoluted logic or anything. I don't understand why you are so against it :(

scheduling "work" on and off is exactly the same thing as what i'm talking about really, except that it's very "dumb" and static because it happens at set intervals (and also blocks other actions that you might not intend). Much better if the interrupts just happen whenever workflex-jobs have used too much consecutive time (dynamic). Add a couple of values for how sensitive that interrupt is and it sounds like it would resolve the whole problem more or less.

I really like workflex for the smarter hauling behaviour it creates - but I don't think I can justify using it as long as the only way to prevent disasters is to bruteforce interrupt it via scheduling and hope that it is enough and at the right time ect. to not block critical work. (or else feel like I have to constantly babysit my colonists).

I hope I can somehow convince you on implementing a better control system :D
Everything I say here is only meant as constructive criticism.

About UI I wouldn't sweat that to start. I think advanced users who mod rimworld probably aren't scared to change a number in the XML files. As long as options exist there that's a pretty good stopgap solution, and you can worry about UI in later versions when the functionality is how you want it.

PS: I don't suppose it's possible to get a look at how the sourcecode looks? I've never created a mod for rimworld before, but it would be interesting to see how the internals work and if I think I could maybe tweak it a little bit to make something I like for personal use until if/when you make an improved version :)

-Stigma
#112
I love map reroll. It saves a ton of time if I'm looking for a specific set of terrain features for my playthrough (or if I'm just not in the mood for an open base and would like to find a place that is reasonably defensible).

That said - I have no friggin clue why you chose to make the re-roll function tied to an in-game item that you have to claim in this new version. That's just incredibly inconvenient (and unnecessarily error prone). You really need to make that optional and bring back the old menu IMO.

I just don't understand what the point is of making you have to play the game and spend time on a map that you don't want to use in the first place. What possible function does this serve? Hiding something on the map is what you do to delay access to a feature - but the whole point of this feature is to use it immediately (and it becomes useless later). So .. why?

(I'm going by the description here - I haven't loaded it up yet, so perhaps I'm just misunderstanding something but...)

If the previous poster is right that this re-write did not fix the memory leak that results in crashing from multiple re-rolls then I am a bit disappointed. IMO that is the only major problem that the original map-reroll had (constantly having to restart every 5 rerolls takes up a lot of unnecessary time). If it's out of your control because it's leaking somewhere in the core game however then I understand, but if it is fixable then that would definitely be the #1 quality improvement to make.

I do like your ideas on future features for partially rendering maps to give you a preview though. Anything you can do to speed up the re-roll seems like a good idea - but I really hope you won't keep this monument thing as a forced thing. Otherwise I can't ever see me wanting to use this over the old reroll - previews or no.

Don't take anything I said here as anything but constructive criticism. I love your previous work and appreciate your efforts greatly.

-Stigma
#113
Some very good ideas here. I love the new zone controls. Uniform growing zone is really handy to mark out those rich soil spots. Before I always went all OCD and "had" to check and mark every single tile that was rich soil. Now it's eeeeasy :D

Workflex intrigues me - and I've only had limited experience with it so far.
It seems like a good idea and results in a lot of good efficiency choices like "hey, why not haul that thing next to you back to base while you are already out there"

That said it also worries me greatly that it seems to lack a good control mechanism from going overboard and ignoring your priorities. I haven't noticed too many critical situations popping up yet in a small starter colony, but I fear the potential for big issues will increase later on in the game as things start to scale up.

- As you mention, long-term or "unending" jobs like research may never stop being prioritized just because it is nearby, even though there is critically important other work that needs to be done.

- If your pawn enters an area with loads of low-priority jobs nearby (hauling, cleaning ect.), they might end up effectively deadlocked doing nothing else - and that sort of describes any late-stage base. (basically the same issue as the one above, but for another reason).

- It breaks "haul urgently" pretty much, or renders it's priority not all that urgent, which is not so great. (added by a popular mod as I'm sure you know).

The only control mechanism you mention is that if you set the schedule to "work" then this effectively disables the "nearby work" check in that time period. This lets you have some control I guess, but it still seems a little weak and is very reliant on you being able to judge very accurately exactly how much work-scheduling you actually need to have during a day to make critical work priorities don't get ignored. If you don't constantly keep on top of this then there is definitely a chance that things could go very badly wrong ("I'm gonna go research since it's close instead of treating that colonist who is infected with plague")

I feel that a better control/deadlock mechanism is REALLY needed here... Exactly what is optimal is hard to say but something along these lines:

- Exclude priorities (in workflex) that are obvious or very likely long-term or unending. Research and art definitely (I don't see any need for workflex to act on these at all), crafting, cooking, smithing ect. are also pretty much in that boat. A lot of other stuff too like bedrest probably don't really belong. Having workflex consider all types of jobs is a mistake I think. I think there is a very valid argument to be made that hauling (and maybe cleaning) is maybe the only really critical job workflex should take into account.... (and it would be so GREAT if you could adjust this to your liking in an in-game options menu!)

- Have some sort of automatic limiter on workflex, so that no matter what you don't get deadlocked and high priority work WILL get done at least intermittently. I don't know the best implementation of the top of my head, but for example you could have a check that "if a pawn has been doing only workflex-tasks for X amount of time then disable workflex priorities for Y amount of time for this pawn". A timeout is probably also required (especially if longerm/unending jobs are considered),  so something like "if current workflex-job has taken more than X time, stop the job and re-evaluate what to do). This should break any deadlocks that prevent normal high-priority jobs from ever being done due to workflex.

TLDR:
Until there is some sort of automatic system for dealing with deadlocks I am really hesitant to use workflex even though I really see it as having huge potential (especially in hauling efficiency). I'd also looove to see an ingame options menu to let you adjust the most important variables like range - and what job-types workflex considers.

A few quick questions:
- Can you remove workflex from an existing save safely?
- If you set the range in XML to be 0, does this effectively disable workflex? (in case you can't remove it safely this would be a workaround).
- in your description you say that even "sleep" scheduling is ignored to do workflex tasks. I assume this doesn't mean that pawns will potentially ignore sleep needs? ... I haven't seen this happening so far at least. Will they still go sleep if they run out of rest?

Thanks for the hard work on the mods so far - and I really hope that you will expand on workflex to resolve the issues it currently has and bring out it's true potential :D

-Stigma
#114
Great mod - but for me this crashes the game consistently after I reroll more than 5 times (without restarting).

It's a minor inconvenience since you can just save before, but you should look into correcting that. It does take a lot of time to restart Rimworld with many mods and it can get a bit annoying if you are OCD and want to reroll a lot looking for something spesific.

-Stigma
#115
"Tablediner configurable" is a nice option too if you don't want to take quite as drastic measures but you are still annoyed that colonists won't use the damn tables. I've had a great experience with it, so I'll leave a link:

https://ludeon.com/forums/index.php?topic=33372.msg340273#msg340273

Essentially it just lets you increase the range (with visual assistance) colonists will attempt to travel to find a nearby table (the default range is really short, which is the cause of frustration for a lot of people).

Didn't mean to derail the thread or anything - sorry (not my mod).
-Stigma
#116
@Fluffy

Hey, is there a way to +1 or -1 all jobs inside of a category without making them all uniform?

Currently you can scroll up "cooking" to make all sub-jobs go from 4 to 5 for example, but if those subjobs had varying priorities then they all become the same number. This makes temporary adjustments to priority a pain - since I have to instead increment/decrement all of the sub-jobs to keep the relative priorities - and then reverse all those changes later. That's a lot of manual actions for a pretty minor adjustment in the logic.

IMO I think that would be a better default behavior because if you are messing about inside the sub-jobs anyway then I think you can trust that player to not confuse themselves with sub-jobs being hidden.

Maybe I just haven't found a function that already does this? I'd be almost surprised if you didn't already include this because your mods are all top-notch and usually have all the convenience features you could want :D

-Stigma
#117
Releases / Re: [A17] ResearchPal and HelpTab
July 05, 2017, 09:03:43 PM
HelpTab is REALLY useful.

Lots of large mods currently have little to no documentation, wikis ect. so this actually let's you look stuff up (and know it is up to date because it's taking the info straight from the XML as I understand it). This helped me a lot get to grips with mods that add a lot of new stuff - like vegetable garden. Just browsing the recipe list I could easily get an idea of what foods were good for what.

I really love that you can click links to follow them to the relevant page. It saves a lot of manual clicking and typing.
What I miss however is a button to "backtrack" to the previous page you were on. The same as the "back" button in a modern browser essentially. Without this I find myself having to go back to a page I was on a second ago over and over again and it gets old very fast.

Maybe there already is a button I don't know about? Or maybe one can be added without too much trouble? Sounds like a relatively uncomplicated feature code-wise unless hooking a button is a problem (even a mouse-clickable one would be great through).

-Stigma
#118
This mod seems very interesting. Everyone find Factorio's belts fun, so it seems like such a natural fit to Rimworld.

Especially since it offers up a way to alleviate some of those late-game problems that come from hauling starting to scale very badly with many items and large distances.

I hope balance (in hardcore) can become real tight so that the mod doesn't end up feeling cheezy or trivializing stuff. There needs to be high enough costs that you have to think if rollers really are necessary to build or not if it is a small job. If making rollers is always best then it's probably not balanced. Does this require research? It definitely should. I will mess around with it and look :)

-Stigma
#119
Outdated / Re: [A16] Hauling Hysteresis
June 30, 2017, 02:29:21 PM
I just learned that hauling hysteresis has apparently been incorporated into another mod called "storage search" - and that mod IS updated for A17. I don't really know if that means that this mod won't get updated or not as a standalone, but at least there is a working A17 alternative.

Just a heads-up to people searching around for this like I did :)

-Stigma
#120
Outdated / Re: [A16] Hauling Hysteresis
June 28, 2017, 03:57:56 PM
This mod, or something like it, is critical in my opinion because without it you are bound to experience endless churning that totally eclipses all your other attempts at making production efficient. What's the point of trying to optimize the smaller details when the AI gets stuck being 95% inefficient to the point where nothing gets done? Crafting hysteresis is similarly essential, but although it doesn't seem to be updated to A17 yet it sounds like "enhanced crafting" may be able to replace it.

So what's the word on making this work with A17? If the author isn't around anymore, is there some mod alternative that does something similar, or is there any word on anyone else taking up the mantle on this?

-Stigma