Monday 18th: Ok so last week was cool. Still demoralizing redoing basic mechanics of the game, but satisfying to see it work well and very happy to make brand new progress with Mating and Babies. Before jumping back into testing, there are some chunky things on the list. First: Set the 'HumansOut' Outpoint on each Processor. Need to go through each Building Processor and set the Outpoint used for Humans. Brainless work. Before getting onto the Item Filter UI and coding I did a bit of testing. It seems it's bugging here because when the Human dies (in this case from the Blood Drainer) we do 'Kill', which runs 'Clear Occupation' to clear any Buildings they were on their way to. This is so that, if the Human dies or is grabbed or whatever, they will unoccupy whatever Building they were going to. If they are currently on the Blood Drainer, when the Blood Drainer tries to eject them Occupier returns null because it was cleared on the kill script. Before, I had an exception where this wouldn't happen on Buildings with Processors, but that definitely won't work for everything. Solution: I don't need to check EVERY building a Human might be occupied to to clear it. It would always be related to their 'Target'. So I ought to re-write and improve this script. I need to only clear some Occupations on 'Kill'. If the Occupation is cleared by looking for the 'Target', rather than checking all Buildings, this won't occur because on Conveyors and Processors, the Human will have no 'Target'. This took me a while to figure out but this change would hit 2 birds with one stone. Pretty fun and interesting bit of puzzle solving which is hard to explain. 'It just works'. So: 'ClearOccupation' gets renamed to 'ClearTarget' (this also helps me find all instances of it by going through the red errors). Here, instead of looking for all Buildings, checking if I am the Occupier and if so, clearing it, we say 'if target != null' and then if it's a Human that means they were waiting for Me so they can DecideNextMove, and if it's a Station (its parent) then set that to null. This won't interrupt anything happening with stations that they entered via Conveyor or being placed, which are the ones that can kill them. If they die on a Conveyor they have no target and are occupying nothing. So this just works! What if they die while on a Manual Station, like the Treadmill or Toilet? For the Human Gate, it should just send them through normally with them appearing to die on the Conveyor or after walking through. For the Toilet, they would die immediately on exit. For the Treadmill, and any other Continuous Station, I just need to include 'HP < 0' to their list of things that make them stop when they complete a cycle. ClearTarget happens on Grabbing the Human, when it dies (HP < 0), at the beginning of DecideNextMove for good measure, and finally it will occur on a few Spells later down the line. Very nice, very clean. Happy to have that under the hat. Good start to the week. Testing and still acting a bit weird. No errors though. Detective hat on now. Had a really rough time figuring out a couple things. Found it in the end. Great! Got them smoothly going accross the conveyor line and all the machines on it. Stacks up nicely as well. Next, before I do the Item Filter UI (which I will do first thing tomorrow I think) I can see that the Chopper isn't quite working. Doesn't know when to stop. So, next is to fix that. I think the problem is that the Size of the Human, which ticks down with each Chop and ejects at 0, is being updated in the Human's 'SlowUpdate'. It still works in the event of the Human running out of Parts, so that's great news. So what does the Human's SlowUpdate do? Every second, it updates their 'Actual' stats, reducing them for teenagers and adding the bonus. It also updates their Speed. Also, the part causing the problem, updating the size based on the Age of the Human. So, maybe I should use something other than 'Size'? I could easily just set the Human's Size to set the Chopper's MaxProgress and then aim for that. But then Players could pick them up and put them through again. I could disable the Human (works for the Grinder), but then problems may arise if I change the animation. I could turn off the Collider so there is no way of parting the Human from the Chopper once it has started, which would solve the problem of the first solution [... doing this]. Did the same for the Grinder while I was at it, just to cover myself if I change the model/animation and have to discover this all over again. Ok Success with this too! Everything from the Human Gate to the Blood Drainer to the Chopper is working! Now, the next thing to build in the base is definitely the Item Filter so I can start grinding my Offal. So, nowhere to go but there for the moment, then I can consider expanding my base! Tuesday 19th: Ok, Item Filter today. Big change here is that it's actually simpler than before, with only one Item being filtered per Item Filter. Using a string for 'Filtered Item' is great, very easy to save and load and everything. The Item List will be generated in the Unique Panel. Ok nice, got it working! UI very simple and easy to use. Saving and loading nicely. I noticed a couple issues: one of the Humans managed to get off the Conveyor somehow? Also, I think there's one Item that comes out of the Chopper that is returning null, so I put a debug on it so I can maybe find out which one it is. One thing at a time... The null item from the Chopper was an empty Item in the HumanParts List on the Human which was blank because the prefab had 2 empty spaces. Fixed it by removing them on the prefab but also made sure to clear it when it is first created on the Human script. Next is to add Human and None as options to the Item Filter. Cool, did that, plus a few other things to make sure it all works at the Transport's end. Currently switching to the correct Outpoint based on the Cargo and Item Filter happens in my wonderful 'OutCargo' script, and on 'FlipOutpoint', which occurs to make sure Transports with multiple outs cycle between them, I made it so it doesn't happen if there is an active Item Filter on the Transport. Getting really stuck on a silly issue where the item coming through the Chopper is set as inactive until it reaches the next Transport. No idea why. Looking at all instances of setting the item as inactive in Transport, Processor, CommonFunctions, Container, everywhere I can think of, and no idea where it might be triggering. Seems in the code to 'MakePart', the part where is says 'If we're adding to a Container, do that and set the object as Inactive to make it invisible', that happens just after Container.Do, which is where the code to set the Object as Active is stored if we are going to a Conveyor. Anyway, it's fixed. One step forward and two steps back, I call it dancing. We're making progress. Also, as a testament to all my work, I have a fairly big base and for whatever reason, the 'Garbage Collector' has quietened right down. Running at >250 fps! Veeery smooth. Ok, Item Filter is done! Fixed a little issue where a blank Building would appear in the centre after selecting it from the Build menu and before mousing off the Button. I want to simplify the Decapitator. At the moment, it puts out the Head and the rest of the Human on the same Outpoint. This is just asking for bugs. Should be a lot simple to do it like the other Buildings, with a Container and Outpoint separate for the Head. This means throwing out the design I have for it and using a placeholder. This also adds to the need to jump into Maya before I release this update. It's 4:30 so I'll make this my goal for today and then I have a clear runway tomorrow to test and fix through more of the content. Ok, did the new Decapitator, even did some animation so it works better as a placeholder. The code was mostly done, I don't know when I did it but it was all ready, just had to set up the Outpoints properly in the Editor. Ok, clear runway for tomorrow. Next on the list is 'Test and Fix'. Wednesday 20th: Went to meet a lovely jeweller to make our wedding bands. Now, back to making my factory farm for humans. Fixed my way through a few things and now next is some bugs with the Incubator. Found some immediate fixes for the Incubator and finished working on my base a bit for a better testing environment. Found another bug, the 'Remember Source' on loading Processors is bad. Need to change a fair bit here. Essentially, it looks for an Item with the matching ID. I did make a 'Processor.CurrentHuman' but I'm not using it in the end. Problem is errors could occur if a Human and Item has the same ID. So I figured, why not make it so they never have the same ID? Ok, so fixed a bunch of files and now everything on this end should be straight forward and simple. Incubator is now working fine after a few fixes. More fixes. Got a little list of cosmetic fixes to start tomorrow with. Human script ramps the Garbage Collector right up, so I know where to look when it comes to improving performance. Then it's on to more testing and fixing. Nice. Not a hugely productive day today, but not bad. Thursday 21st: Stopped sound and animation on Stations when a Human is removed from one. Fixed a minor bug on the Grinder progress bar. Checked all instances of 'UpdateAppearance' for the Human to see if there were any redundant ones. There weren't. Next one is a meaty task. When I changed the ID system today, I noticed I could clean up my script a bit by using my 'CommonFunctions.MakeItem' in a few more places. I can locate these places by searching for nextid += 1, since this should really only happen in one place using the Common Function. First one I locate is for the Fabricator. This is a tricky one to start with because it does have a unique piece of script in that it takes the Human who made it into account when effecting the quality. So I have to think a bit about how to do this. Clothes was another tricky one. Redid the calculation for Quality, with a list of floats being created and the average drawn between them. So, if Obj1 is a Human, we add its quality to the list. Same for Item in Obj1 and 2, and finally if Maker != null (the Human making the Item), a specific skill of theirs is added to the list. For example, if the Building is Forest, add their ActualDexterity. Food and Clothing also sorted. Ok that's done. The effect of this is just slightly cleaner and easier to manage and debug code. One of those days where I'm too tired to work, play or do anything really, so I might as well work, but I end up working at a turtle's pace. Friday 22nd: Started by fixing a couple little things I found yesterday. I have them mating so I want to get that fully working again since my recent improvements. At the moment, it seems like they are aiming to Mate and getting their target Human to Wait, but then don't attempt to approach them, so they get stuck waiting. Need to find out what's causing that. Simplifying the hell out of the Human Mating stuff. I did this thing where they would set their TargetHuman's intent to 'Mate' and then wait to be summoned by them. However, I think would be easier to just check if they are busy, and if not, stop them then go to them and get straight to it. Ok, fixed up Humans targeting each other and getting each other to stop. This applies to Mating and Feeding/Breastfeeding Babies. Now to test it. Ok, they Mated! Could still be a bit buggy but seems to work. Sometimes the other Human seems to stop waiting for them sometimes but they do it anyway. I don't think I want that feature in this game just now. No-one seems to be feeding the Baby though. Ok getting it to work but then finding other problems. It's a bit of a mess this whole system. First step to fix this is to refine my 'GetNearbyHumans' script and use it wherever needed. This is a script with a bunch of bools like 'excludebusy', 'excludecantseeme', etc, and it returns a list of Humans that pass all these designated hurdles. Then, when I call it, I can put further hurdles on the list that are more specific. ...Ok, the work bled over into Saturday but I got it. That's all the instances of Humans targeting each other and making them wait tidied and accounted for. That means if I see any bugs occur, it will be easier to fix in future. Now, again, free runway for testing and fixing.