• Content count

  • Joined

  • Last visited

 Content Type 




Klei Bug Tracker

Game Updates

Hot Lava Bug Reporter

Posts posted by bzgzd

  1. 7 hours ago, Heister said:

    float uptime= 0f;
    private void Update() { uptime += Time.deltaTime; }
    public Uptime { get { return this.uptime / Game.timeplayed; } }

    No need to store anything but a float, I don't even see much of a reason for this statistic either, not something I ever missed in ONI...

    This would be uptime since game start.
    They show uptime for last 600 seconds or 6000 seconds.

    In such case knowing that something was used 10% during last 10 cycles is not enough information for future calculations.
    It could have been used evenly 10% each cycle or also it could have been used fully during just one cycle 9 cycles ago or ...


  2. 3 hours ago, wachunga said:

    I think this is a bug with debris in general.

    I believe there is no specific debris handling in code so this seems to be bug with splitting stacks in general. That means also stuff that is in containers is affected.

    I put 3100kg hot gold into one container inside cold water. That made it one stack and then I moved 1000kg into one, 2000kg into another, and left just 100kg in original storage.

    100kg was loosing temperature slowest at speed of 3100kg. Moving that 100kg into another container fixed it to correct 100kg behavior.










    • Thanks 2

  3. 1 hour ago, Blazing Falken said:

    In other words: while on the rail, the temperatures are calculated as masses of 20kg, 20kg, 20kg, 20kg, and 100kg in that order.

    This looks like another buggy behavior.
    This one is related to conveyor rails. Not only with medical pills or wood or other things in that group.



    I put 41kg igneus rock in loader and that last 1kg is heating up slower then first two 20kg so probably acts like 41kg. I didn't try what would happen when splitting those packets onto different rails or something like that.


    • Thanks 1

  4. 22 minutes ago, BLACKBERREST3 said:

    Ah, ok. According to mathmanican, for containers you have to have a critical mass before it resets. I'm trying to keep track of all the ways a reset can happen.

    Seems all to be just cause of the same very basic thing.
    When dupe, or sweeper arm, or conveyor loader creates new chunk by splitting it from bigger chunk.

    Bigger stack could be 2kg when something takes just 1kg from it...

    It happens in almost everyone base every cycle.
    Just watch temperature of food your dupes eat. (after picking from storage or taking it from bigger pile on the ground)


    • Like 1
    • Thanks 1

  5. 13 minutes ago, beowulf2010 said:

    Hey now. I didn't say the official use was actually useful. :D

    I actually used gravestone officially as I killed one of my dupes that I was not satisfied with...

    And gravestone is not just to put dead dupes inside it but also for removing "Mourning" debuff that lasts 3 cycles when not removed and adds 20% stress per cycle. Dupes go to gravestone and cry a bit and then debuff is removed.


    • Like 2

  6. 50 minutes ago, fragtzack said:

    Both you and the video maker should go back and correct the false statements in "guides" about fridges so as not to lead folks astray.

    Don't look at videos and forum posts as 100% always correct.
    Game is changing and also people don't always get everything 100% right even when it might seem so at that moment.

    You can do your own tests because you found out from video that there is some temperature bug happening and make your own "misleading" results. :)

    Like you posted yesterday:

    14 hours ago, fragtzack said:

    The convey belt is indeed the key thing, not the fridge nor the loader. 3 things I discovered in testing:

    1. Must be a 20KG packet. 2. Must be genetic ooze 3. Must be a conveyer belt

    When probably in reality this bug is more fundamental and has nothing to do with conveyor belts.
    Just dupe picking some wood from big pile of wood and same bug happens.

    I usually put in stuff like "I think" or "I believe" or "probably" but that can be basically always there when you post something so not needed...


  7. 46 minutes ago, 0xFADE said:

    Is around 20c some default temperature? Maybe some calculations failing at some point and just resets to default?

    Yes default temperature used in code on many locations is 293K.
    It is used as default when new stuff is created, like when you get things from care package.

    public static GameObject CreateBasicEntity(string id, string name, string desc, float mass, bool unitMass, KAnimFile anim, string initialAnim, Grid.SceneLayer sceneLayer, SimHashes element = SimHashes.Creature, List<Tag> additionalTags = null, float defaultTemperature = 293f)
    public static GameObject CreateOreEntity(SimHashes elementID, EntityTemplates.CollisionShape shape, float width, float height, List<Tag> additionalTags = null, float default_temperature = 293f)


    I think calculations are not failing but just not done for those "entities" like food, medicine or wood.

    And this temperature issue seems to be happening for the same entities where you can get over 25t stacks and then also get to material loss with 100t+


    • Like 2

  8. 4 hours ago, Blazing Falken said:

    Don't toss the poor guy to the curb over some misinformation. Maybe take a... chill-pill. :D

    And also we where spreading "misinformation" even here in this thread... this bug has nothing to do directly with conveyor belts (at least according to my current theory :) ).


    I was thinking a bit about this bug because as mentioned few posts earlier I noticed this temperature reset first when dupe was picking 1kg vitamin to eat (nothing to do with conveyors).

    So my suspicious was that this bug is not with conveyors but with splitting existing mass and creating new chunk. (like conveyour loader does when making 20kg packets)

    To test it I made 20kg hot barbeque and set fridge to limit 19kg and as you can see those 19kg because they where created from original 20kg are now (already in sweeper arm) reset to 19.9C


    In other words this bug is happening in most people bases every single cycle when dupes are picking their food to eat. No matter if from storage (fridge or ration box) or from food pile on the ground. What they pick to eat has 19.9C


    • Thanks 1

  9. 1 hour ago, fragtzack said:

    Again, as posted above. Run a 5 minute test to prove/disprove this the current build.

    You are correct. Fridge doesn't reset temperature to 20.

    I thought there was maybe some fix since this thread:

    But I didn't play 2 months ago and can't compare source code and see if there was fix for fridges.







    However when I spawned dupe and he was eating one pill I noticed it was reset to 20 before eaten.
    So I tried sweeper and sweeper to fridge did no reset but sweeper to conveyor belt is where it sets temperature to 20.

    No fridges needed just conveyors.





    • Like 1

  10. 14 hours ago, Zarquan said:

    But I need the frames!

    I was trying 100 dreckos to see what is the FPS difference on my PC between one tile or 3 tiles I use for them.

    There was not much (if any) but when I hold mouse over those 100 dreckos... minus 30 FPS despite 97% of those tooltips where off-screen.








    • Like 1

  11. 4 hours ago, kevork said:

    Your most likely right on this.  That saved game did have replay enabled at a lowish resolution (now turned off). Klei might be using the timestamps on each item to generate the replay...

    I really doubt that they could even try to simulate whole game cycle within few seconds because of replays...

    I think replay feature is just series of png images saved in directory RetiredColonies.
    First that directory was inside save_files dir and about 3 weeks ago they changed it to get more stable zoom and view and also moved RetiredColonies to same dir level as save_files.

    Also I checked the code and this feature (saving active/inactive operational times) was added recently in version 364722.

    Probably something for more detailed graph statistics but a bit overkill?

    Before it had specifically set [SkipSaveFileSerialization] flag but probably saving is quick enough so why not to add more data... :)






    • Like 1
    • Haha 1

  12. 40 minutes ago, Lilalaunekuh said:

    To add my 2 cent to this discussion and introduce a new angle:

    Don´t you consider the number of pipe segments of the cooling loop which are inside the steam chamber

    (or call it the hot room around the aquatuner) ?

    Yes another negative of valve is that it can't be build inside walls.

    I have only one AT in my current game and I used same version as you, but that is the one called "wrong" here. :)


    • Like 1

  13. 42 minutes ago, BLACKBERREST3 said:

    With variant C, you could use insulated pipe so it does not change temp on the bridge blob very quickly. This will act as a temp buffer in a way until the blob can move again, i.e when the AT is off. If the AT never turns off, then You wouldn't need the bypass to begin with.

    Normally you would have insulated pipes there anyway, but still one blob sitting there while others are cooled down and looping...

    I would say that turning off AT with pipe temperature sensor on pipe segment just before AT should always result with AT either having that 10kg inside or not having it, but ONI is not very deterministic in this kind of exact timing situations. And then there is also possibility of power going off at any moment so putting in correct amount of water and then disconnecting refill seems best in all 3 cases (or using reservoir).

    And using valve (same loop lengths) makes it easiest to put correct amount of water in as AT can be ON or "OFF without blob inside" when filling. Only negative is 200kg steel for valve.


    • Like 1

  14. 23 minutes ago, TLW said:

    About the only way to have a stable loop is:

    1. Use variant C above.
    2. Fill it fully with the aquatuner never having been turned on. (Or rather, without any liquid in the aquatuner).
    3. Disconnect the filler.
    4. Then enable the aquatuner.
    5. And never connect the filler again.

    Disconnecting refill is the best for sure because why to keep it when there is already enough water.
    And removing exactly one water blob in case it got too much is easy.

    For me variant A that means with valve is better. With C you have one water block not looping when AT is running (it is not visible because it is on bridge white entry point).
    And B is also not that bad because one empty segment in the loop when AT is on causes no issues.


    • Like 1

  15. 2 hours ago, Saturnus said:

    Well, you can't overfill the loop in any way if you use the bypass version I posted (unless you try to fill the loop through the bypass but that would just be silly), so no need to worry about that.

    Here is how it overfill (same way as other versions):
    AT can be off and have one water segment inside.
    If there is refill at that point into loop it will get water to max. capacity inside bypass loop.
    At that point system has already too much water that fills whole bypass and +1 in AT so next time AT goes off without water inside it gets stuck.


    • Like 3

  16. 1 hour ago, Saturnus said:

    On the bottom is the correct bypass version. See how it does not leave a gap?


    So there are 3 versions.

    A. Same pipe length when going through AT or bypassing (using valve)
    B. One segment longer pipe when going through AT (top)
    C. One segment longer pipe when bypassing (bottom)

    But I don't think version C is the "correct" version.
    All 3 can get stuck same way (when refilling is not removed) and C can cause some more problems.

    I would say A is the best as pipe loop is almost always full (except when sometimes off AT has one blob inside).
    B has empty segment "looping" with AT on and C has one segment not looping and sitting at the bridge which might be a problem and can brake pipe if that one blob gets too hot inside steam room or something.


  17. Version with valve can get overfilled and stuck as well the same way.

    I think there is no difference between fully open valve and bridge except in length.

    Problem is that aquatuner can have one liquid block inside and so you can overfill the loop by turning aquatuner off when it is running and with some "luck" have that one liquid block staying inside even when aquatuner is off.

    First I tough only turning off power can cause this but then when I was recording it happened even with just turning off using automation.


    So I would say just remove refilling pipe and there is no problem with bridge or valve system...