impyre

  • Content count

    121
  • Joined

  • Last visited

Community Reputation

75 Excellent

About impyre

  • Rank
    Member
  1. This has been requested many times over. Responses range from "That's stupid, it would take pipes and pumps, just place a pitcher pump" to "OMG I need this now!" I personally fall into the latter category. I can't stand the way it is now. I don't have space to place large water reservoirs all over my base, and even the smallest pitcher pump reservoir needs a liquid vent to keep it from running dry. I have to run a pipe there anyway... why not cut out the extra wasted space and just pump it directly to a bottler. It also makes sense that since they don't have to pump it, it would be faster. Also, the thing could have a water bottle ready for use before it's needed. There are a couple of downsides that usually get brought up: A) It's not uncommon for a water bottle to be 100+ Kg in size, especially when carrying water for emptying at a bottle emptier. Filling that would take a single dedicated pipe and pump 10 full seconds. B) At that use rate, it couldn't keep up with multiple dupes carrying water, whereas a pitcher pump can. The pitcher pump reservoir acts like a sort of "water battery". To rebut these arguments though, I submit that the same could hold true for a plumbed water bottler. Do one of two things: A) Limit the size of the water bottles it puts out to something more reasonable for cooking/farming/algae terrarium use. or B) Keep the size as is, and just include a 1000 Kg water storage in the device that's used as needed, and refilled at 10 Kg/s.
  2. I doubt it would be a huge change honestly. Leave the current building fetch errand as it is: buildings need materials, higher priority buildings go first. closest matching materials are fetched in order. Then change the following: Compactors no longer create building fetch errands. (Easy fix, even if you have to create a new subclass for storage (which there probably already is anyway... or at least should be)) Allow us to designate "cleaning zones" (or alternatively just default to using player built rooms as clean zones) Zone painting is not that dissimilar from painting any construction job, the code for selecting areas already exists. The biggest hurdle here is creating an overlay to display them. I imagine one could use the room overlay as a template with relatively little work. Any object in the zone left on the floor is automatically designated for cleanup (by priority). (Pretty self-explanatory, in fact you could avoid having to run this check on every item in every frame by simply checking it any time it is dropped or moved (in case it changes zones) and ignoring it otherwise) Allow us to set some objects to be left (such as eggs) (this is also easier if you allow player-defined zones, since you could specify what is allowed to be cleaned in a given area) Managing the zones could be tricky. You could reuse some of the compactor and/or sweeper code, but a lot of it would have to be built without a template, including a new interface. All objects designated for cleanup are kept on a roster by priority, and taken care of accordingly as dupes have time to perform the hauling. (Keeping a list is probably the easiest thing for a computer to do, there are potential memory pitfalls here for players with very large cleaning areas with lots of items in them. But the list only really needs to contain a reference to the item. If you want its priority to be able to be dynamically changed, then keeping that information as well could be useful.) These rules can also be applied to autosweepers, since they would function more or less the same, except some things could be forbidden and you could give priority to others. Not saying this is the way it should be, but it's definitely a way it *could* be. I don't know the inner workings of the source code, so I can't be sure how difficult it would be to implement... but I can't imagine it being too difficult if the code has been well-organized and well-maintained.
  3. I love that post. It's a very good demonstration of using intuitive basic boolean algebra for circuit simplification. (A^B^C) = --(A^B^C) = -(-A + -B + -C) And since if A = Sensor over 500Kg, then -A = Sensor below 500Kg, so we can change our sensors trigger from above to below and change -(-A + -B + -C) to -(A+B+C) which is way simpler to build. Really, it's realizing that changing the sensor trigger condition basically negates the sensor output that changes how you can approach the problem. BTW: If anyone wants to use the above distributive rule to help with simplifying their own circuits, it's this easy... ^ is AND, + is OR, and - is NOT, - and - cancel each other out when in pairs. Signals (variables) that are grouped in parentheses represent a multi-input or grouped gate. The 8 input gate above would be -(-A + -B + -C + -D + -E + -F + -G + -H). The last rule is that when you move a NOT (-) from inside a parentheses to the outside, or from the outside to the inside, you have to switch all the operators and distribute the sign to every variable. So for example: -(-A + -B + -C + -D + -E + -F + -G + -H) --> OR gate with 8 negated inputs and one negated output** take the outermost symbol and distribute it (--A + --B + --C + --D + --E + --F + --G + --H) but don't forget to switch all your operators (--A ^ --B ^ --C ^ --D ^ --E ^ --F ^ --G ^ --H) Then finally you can cancel (A^B^C^D^E^F^G^H) --> AND gate with 8 inputs** The cool thing about this math is that it works both ways. And you can always add a double NOT without changing anything... just stick a -- wherever you like, especially if it gives you some things to move around so you can simplify it. Just remember that we almost always prefer OR to AND since it decreases number of gates needed. **Notice that an OR gate with all inputs negated and all outputs negated is essentially and functionally identical to an AND gate with no negation.
  4. I generally don't fuss with it too much. I find that optimization is the most important thing, so that everything always gets done in a timely manner. Although I did find that bumping up the subpriorities for certain critical tasks help ensure they get done faster. Terrariums, waste disposal, and hygiene devices are all subpriority 7. Also this allows me to reserve subpriority 9 for emergency use. This means I can use 8 when I really want something done now, but not if it means someone dies because of it. Yes, performing tasks helps. Cooks don't gain job mastery from cooking, but all the other jobs gain mastery from performing jobs. The act of performing jobs also helps to raise the associated skill.
  5. That was a really nice description of a CPU. For anyone interested in learning, the language of hardware is generally referred to vaguely as "assembly" language, and there are a few games that can help you learn how to approach solving problems with its limited capabilities: TIS-100 and Tomorrow Corporation are good examples. (If mentioning other games is prohibited I will happily edit this out) https://schweigi.github.io/assembler-simulator/ Above is an assembly language simulator that simulates what a cpu does when it's working, and it comes with a preloaded example script. It may seem tough to decode at first, but it's not that difficult once you figure it out. For the first run through, just scroll to the bottom and hit "assemble" and the script is loaded into the "memory". By default, instructions are highlighted blue in the memory panel so you can see where the instructions are. Also, the labels are shown below the memory panel and clock speed settings. Labels (and the DB thing at the top of the script that looks like an instruction) are *not* instructions and are *not* loaded into memory. These are notes to the assembly compiler (or they would be if it existed... since this is really just a simulation) so that it knows when you are just loading up data to be referenced later and so that it knows where it should tell the cpu to go in memory when you reference a label. This is for ease of use, so that way you don't have to keep all those memory locations in your head. All you need to do is write JMP start, and the compiler says "okay, let's see where that will end up being put in memory so I can put the correct instruction", in this case 1F is the JMP instruction, and 0F is where the compiler has told it to go. 0F is hexadecimal for 16, and the memory panel conveniently arranges the memory addresses into rows that are 16 bytes wide, so 0F is the last one on the first row. If you look over there you see 06 is the next instruction, this is the MOV instruction which will move something somewhere. I'm sorry if that's vague because what gets moved where can be very dependent on architecture. In the example we are moving the location of the hello label into register C, it's written as MOV C, hello; however, it's not putting hello into that register, it's putting the location of the hello label into the register (which is 02). Looking at the memory panel will also reveal that the memory location of register C is 02. With a bit of hunting you can find out that register A is 00, B is 01, and D is 03. These register values (A,B,C,D) are interpreted by the compiler also, and inserted into memory where needed. Some clarifications: MOV in the simulator has several instructions available: 06, 03, and 05 are *all* different MOV instructions. 06 is what is called a "literal" assignment, it means whatever comes next... put that value in the register, it's used like MOV A, 3. This will store the value 3 into register A. 03 is a memory load, it takes the form MOV A,B or MOV A,label. In this case they used [C] to show that it's a pointer. This means "Go to the address location specified in register B, and put that data into register A" 05 is a memory store, it takes the form MOV A, B or MOV label, B. In this case they have used [D] to show that it's a pointer. This means "Take whatever is in register B, and store it at the location held in register A." If a register contains something other than an address location but you treat it like it has an address in it(which is possible if you aren't careful) then this does amazing and wonderfully unexpected weirdness... like your program re-writing itself and combusting. Now that you know how to identify instructions, you can figure out the rest by examining the sample code and documentation. Above the memory but below the display you see several things. A, B, C, and D should be obvious by now, but if it isn't... those are your four registers. IP is a register that contains the "instruction pointer". This is the thing the cpu looks at to tell where it needs to go next. JMP 3F actually does the same thing as MOV IP, 3F. All it does is change the ip so that the cpu goes to the new place next (because by default the ip just gets incremented by one each time it does something). Basically the cpu will do the instruction at location A3, then it will go to A4 and do that instruction, and then A5 and so on, but JMP allows you to change that flow. SP is a register that contains the "stack pointer". The stack pointer is a handy thing that lets you store data for later, and easily retrieve it. Everytime something is "PUSHed" onto the stack, the sp is moved by one, and the data is stored, this all happens automatically. When something is "POPped" from the stack, the sp is moved the opposite direction. In this simulator the SP grows into lower address space (and this is not uncommon), this is to reduce the risk of accidentally overwriting your code by pushing to the stack too many times. So the sp is decreased by 1 when you push, and increased by 1 when you pop. The key thing to remember is that the stack works just like a stack of boxes, you can't get to the thing on bottom. Whatever was the last thing put on top, has got to be the first thing to come off. Condition codes: These are represented by the Z, C, and F. They are extremely important and there's really no way to get around using them. Z is the zero flag, C is the carry flag, and F (I can't be sure about this) is the overflow flag. You shouldn't need the overflow flag much, and if it comes on there's a problem somewhere. The condition codes are automatically updated after any instruction that performs any kind of operation on the data in the registers. For example: Let's say I take whatever is in register A, and I subtract 0x48 from it (bearing in mind that hex 48 = 72 decimal), and then the Z flag becomes true. This means that the value in register A is 0x48, which is ascii for 'H'. You might wait for the user to hit a key, then decided whether or not to do something based on what they press. Get the value they enter, store it in a register, and test it against other known values and/or literals to find out exactly what they entered, then do something based on that result. A Z result is useful when searching for an exact match, but what about comparing two values? The easiest way is to subtract them from one another. If you subtract register B from register A, you can discard the result and check the C flag. If C is set, it means that the result was negative, so B is larger. If it isn't set then they are either equal or A is larger. If you need to know which you would check the Z flag also. By subtracting then check both Z and C, you can check if two things are equal, or if not which is greater. This is usually implemented by the architecture automatically in the form of various different types of JMP instructions. JNZ is a common instruction which means JMP to a given address if the Z flag is false. JNZ is sometimes called JNE, but they work the same. These conditional jump statements allow your program to make decisions based on changing data. To bring it all back around, above he mentions ldA instruction, this is basically like a MOV instruction.
  6. 2's complement is easy to do, and even if you added a subtractor it would just do the same thing, just might save a cycle.
  7. This is pretty incredible. Once you add some memory and a few more functions I'll be playing around with it. I have some experience working with x86, I can't imagine it's all that different from ARM on the software side. A load is a load after all, right? I guess the only real question is big-endian or little-endian lol.
  8. As of right now learning doesn't affect how fast you master the cooking job. That's because even if you *could* cook faster, cooking doesn't increase cooking mastery. I feel like it's also important to point out that this whole time (up until now that is) I've been talking about job mastery. Though I think you caught on to that at some point. Skill affects how well you perform a task (in various ways) while job mastery is what happens when your job gets to 100% mastery. This usually confers a bonus of some kind (usually a skill bonus, but sometimes a boost to other attributes), and is a prerequisite before that dupe can take a job in the next tier. I think (but i'm not sure) the cooking skill does decrease the amount of time it takes to cook on the grill, but I think it's very slight. It used to be 10% faster cooking, but by the time you hit 20 cooking skill cooks could feed a veritable army in no time. Every cook was essentially a part-time cook.
  9. Yes, that is reasonable. It has nothing to do with what I was talking about though. Assuming you're talking about this part: However, as it currently stands there are some bugs with job mastery. I've tested cooking and digging. In the Sous Chef position, job mastery is the same for all dupes and only occurs at the background learning rate. Cooking doesn't increase it faster, and neither does the cooking interest. I tested with interest and with no interest... i also tested no cooking vs. cooking with microbe musher vs. cooking with grill. What I'm talking about is this: For every job there are supposedly two ways of gaining mastery: 1) passive mastery gains and 2) performance mastery gains. Passive mastery gains happen all the time at a steady rate. For the lower tier jobs it works out to be somewhere around 1 mastery every few seconds. The passive mastery gain ensures that there is a maximum amount of time it can take a dupe to master a job... even if he/she does nothing else. Performance mastery gains are applied every time an activity is performed that is related to that job. For digging, you get a small amount of mastery every time you dig up a tile. It seems like most jobs have this in place and working as intended. This means that a dupe performing his job will get both the performance mastery gains *and* the passive mastery gains, while a dupe doing other things will only get the passive gains. This means that performing the job helps them learn it faster. For cooking, this does not happen. A chef that makes meals all day for 3 cycles gets exactly the same job mastery amount as a chef that spends 3 days cleaning outhouses. They will both master their jobs at the same time. If this were true for all jobs, there'd be absolutely no reason to specialize your dupes... since at the moment the *only* benefit of specializing is faster mastery. The benefit of *not* specializing is that all of your dupes can perform all tasks, so you don't have to worry about your entire colony going under if your farmer dies.
  10. Currently the Sous Chef position doesn't gain any mastery from cooking items. This was tested with the electric grill and the microbe musher. No mastery gain was shown at all beyond passive mastery gain.
  11. Digging and building are the only two tasks which benefit from having more dupes, as every other task scales in the amount of work required as the number of dupes goes up. EG: More dupes means more farmers, but more dupes means more farms... so the thing goes. As with water requirements, power requirements, oxygen requirements, etc. You can expect your colony to spend a certain percentage of available "dupe hours" performing a given task. This doesn't change with population (with a few very narrow exceptions which I'll demonstrate below (a) ). This means that if you spend 12.5% of available "dupe hours" farming (that's one eighth) and you have 8 dupes, then you'd need one dupe farming for a full 8 hour day to support 8 dupes (including himself). If you have 3 dupes though, you'd need far less food (3/8ths as much to be exact... less than half). With only 3 dupes, 12.5% of available "dupe hours" means you'd only need one dupe to spend 3 hours out of his available 8 on farming (3/8ths the number of dupes, 3/8ths the work needed)... with the rest being freed up for other tasks. Considering this though, even digging and building suffer indirectly from adding more dupes. Since more dupes requires more resources, let's revisit the farm. For eight dupes you need eight dupe's worth of plants which takes up 8 units of space and requires 8 batches of farms to be built. This means 8 units of space must be dug up. For three dupes you only need to dig up three units of space and build three batches of farms; again, this has cut the amount of work by more than 50%. (a) Many things can support multiple dupes. For example, a single SPOM can conceivably be expected to support up to 8 dupes who aren't mouth-breathers... or potentially more who have divers lungs. Something like this means if you have 12 or 13 dupes, you may need two SPOMs instead of just 1. And it also means that 8 dupes get more out of this design than just 3 since all the other work is the same whether you use 8 dupes or 3. The use of power and water can be throttled for 3 dupes though so it isn't a horrible loss. This also goes for water piping, power generation, etc... EG: One single water pipe can supply enough water in a day to farm enough bristle blossom and sleetwheat for 109 dupes; however, whether or not you really need 109 dupes just to outweigh the cost of installing those pipes is an exercise I leave to you. The *real* advantage of having more dupes is to allow specialization. The greater percentage a dupe spends of his/her time performing a single task, the quicker they will become proficient at it. In our farming example, our farmer should only learn farming 37.5% as fast as a farmer who *only* does farming and nothing else. However, as it currently stands there are some bugs with job mastery. I've tested cooking and digging. In the Sous Chef position, job mastery is the same for all dupes and only occurs at the background learning rate. Cooking doesn't increase it faster, and neither does the cooking interest. I tested with interest and with no interest... i also tested no cooking vs. cooking with microbe musher vs. cooking with grill. I did confirm that for apprentice miners, performing the task *does* increase the rate of job mastery, but it's not an insane amount. For dupes with low digging skills, it's almost doubled when they spend all their time digging... which means a dupe that does no digging learns half as fast. This makes specialization just a tad less important. At high skill levels though, specializing can create a tremendous effect since the action will be performed much faster. Also noteworthy is the fact that if a dupe is "interested" in a job, the 50% mastery bonus is *not* applied to the passive job mastery rate, only to the mastery received from actually performing the task. I wasn't really interested in testing it to verify whether other professions are bugged or not. Someone wanna get on that?
  12. My current style of play typically uses 4 or 5 dupes max. I find that with 4 or 5 dupes, you don't suffer needlessly long construction times, and you still get most of the benefit of having a small colony. My initial realization of this fact occurred when I waited so long to get dupe number 4 that he died trying to construct a tunnel that the other dupes were working in just fine. His athletics were so low compared to the other dupes that he couldn't get to the end and back before suffocating. It's easy to not realize how much they improve over just a couple hundred cycles, especially when they all share all the labor. That having been said, I personally think they should change morale requirements to be on a per-job-mastered basis and change the requirements accordingly so that a single dupe can reasonably be expected to master a single branch. This would make astronaut training prohibitively difficult if it remains set up as it is, but then I never liked the idea of having to basically master two separate careers to become an astronaut anyway; it makes more sense to rearrange the jobs, or create a special job tree for astronauts.
  13. Also, I want to point out that I don't think it's really a *critical* thing. We can get by without a button for accessing the menu... and every first-person game *requires* keyboard access to the menu. I personally felt like it was an oversight though, because almost every other game that has a button-based gui/hud also implements a button for accessing the save/load/options menu (trying to avoid the word pause lol). In any case, it isn't a huge deal either way.
  14. Even some solids and liquids have hints at things like that.
  15. bingo... because you can't. Just bring up the menu when you click the pause button... or add a menu button so you can access options/save/close, etc with the mouse.