Engine Cooling is buggy.
Speiger opened this issue · 29 comments
Engine cooling is not working. If you use water then is everything right but as soon you put in fluids that can cool a lot more than Water it stays infinite. I mean Put in one bucket and you do not have to care anytime again.
The thing is because the Engine get cooled even if there is no fluid beeing drained at all.
Try it out with Forestrys liquid ICE you will see even after a full year it will be not used any mB at all.
I checkt it and it is a BuildCraft bug please fix it.
I saw the code but you made 1 little mistake.
What if the coolant is so big that the Engine would overheat with that? I mean 150* are not much and can be overtopt really easy (cryothium should be able to do that), i solved it by draining 1 mB,
to fill a basecoolant (which get affected by the biome) and drain the basecoolant whenever it is needed. (That does not get effected by the biome (lag preventation)) that is more save and prevent overheating case and also reduce then amount of BiomeRequests to a minimum.
I don't think 1mB of anything should cool the engine by 150°C in any biome... The coldest biome temperature scalar is 4x, so it should have over 37°C/mB to cause problems. For perspective, water is 0.0023°C/mB. A coolant TEN THOUSAND times as potent as water would still cause no major problems. If come coolant does that, it needs to be rebalanced.
Also, not many people would choose to live in(or even come across) a "cold taiga", the only biome with a coolant modifier over 2x, anyway, so it would need to be over 100°C/mB for any normal biome(40000x the cooling of water).
Fixed in #2535.
Well Liquid ice has standart +8000 Times more cooling effect then water so the engine need to heat up quite a bit to cool down then? If we count then the Biomemultiplier^^" Then i say WTF are you fuckt up....
The Engine may not blow up but turns orange to turn to green again. I think that my solution is more safty because its not requesting every tick the biome data and generally do not request so much data at all. Only if you have a high drain then it comes there a little closer but then it automaticly adjust the drain of fluids and raise it so we do not need to request so often stuff.
That is a thing i was thinking of too but that is sadly not supportet from Forge FluidTanks...
So the code you have to make is more complex then really needed...
But i have to correct myself for a little thing. Forestry Liquid ICE is not +8000 Times more cooling then water. It is only +4000 Times (I thaught it had a cooling of 20F, but its only 10F), but as far as i know Liquid ice is not at the lowest Temerature possible so if TE3 (or a addon) adds Liquid Cryothium to the cooling list (and i will do that with my modupdate if another mod did not do that already) then it will have enough cooling (i assume that) that the engine can explode... (I mean i think Liquid ICE is about -10/-40 *C, and liquid Cryothium is at the -200 *C area?) I have to research that^^"
That means if another mod causes a bug in buildcraft because of adding stuff to it means that buildcraft has to fix it and it is his fault not preventing it. I got more then enough of these bugs in my old TinyChest mod... And now i know how to prevent stuff like that... And if i make a mistake then i fix it.
Well, forestry liquid ice is, as far as I know, a pretty hard-to-get bee material, which is why it's normal for it to have an absurdly high cooling rate, and it's still only causing a flicker between green and orange, and that only in the most extreme rare biomes.
Cryotheum, on the other hand, is just redstone, snowballs and power(or a blizz farm), so if anyone registers it as a BC coolant it can't possibly be as strong as Forestry ice. It would be just overpowered.
On the other hand, your suggestion is valid too. IF I understood it correctly, you said 1mB should always be pulled and stored in an internal buffer, which is then used to cool the engine before draining more from the tank? That would indeed work nicely...
Is this what you had in mind @Speiger? It does always drain 40mB, if it's available, but it doesn't drain again until it used up the buffer, and it's definitely not enough to cause floating-point errors until someone decides to create liquid bedrockium with a cooling level of 1 billion :P.
@Speiger You are assuming other mods, including us, balance around Forestry. That is an incorrect assumption and they might as well have an overly high value. Gameplay trumps realism, though.
@asiekierka a lot of people said to me (and they are right): You have to expect the stupidness of people (Nothing against people) and go work against that
Sorry for that weird typekind, i had like 20 ideas to answer that and that is the result out all together^^"
Well isn't that basically what I've done? The sudden drop of 40mB isn't really noticeable so I think it's better than calculating every time how much to drain and having less in the buffer.
Nope its not my code is completly differend^^" The current code has the old bug again^^" I upload my source as soon as i can (takes maybe a hour)
TinyModularThings/BuildCraft@44180ca
Here is my Version of it. I made some changes because i nodest a huge bug so i decided to change that a little bit^^"
Nope it is not draining always 40 mB.
It is draining maximum 40mB and make a minimum cooling buffer with that so it does not need to drain that often coolant.
That is my solution^^" The problem is after i made a caculation that it drained the whole tank always to fill a buffer and then he had like a cooling like insane (for 200 heat points)
To the LiquidCryothium. Look at the FluidData it has a really cold temperature, even if it craftet out of redstone and stuff, it still needs blizzpowder which is extremly cold.
The problem at my caculation is that i can not see the heat amount that is getting produced over time (even so it is mostly a hardcoded number), because with redstone pulses you can correct it.
So i decided to say make a buffer and look how much coolant you get from 1 mb and looo that you get a minium of 40 together (i should lower that number) and if the result number drains more then 40 mB then limit it to 40 mB. So your drain is not that extrem.
And yeah the idea it is only draining when it is needed and then wait until it is needed again. so you have smoth cooling^^" The water consum is still the same but a little bit clockwise which may pipes do not like^^"
Why on earth did you reupload the whole bc code, instead of cloning?
Anyway your code is wrong, it only cools if there is cooling left, else it wastes the update just to retrieve coolant. In case the coolant can't keep up with the heat, it would cool half the amount it does now (one tick to get coolant and one tick to actually cool). Also if it somehow it had negative coolingleft (which hopefully it can't) you would waste another update just to make it zero, and then waste one to retrieve coolant before actually cooling the engine.
1.6.4 Sourcecode has no longer a branch so i can not clone it.
The second thing is yeah it cools only when there is cooling left. Else it would be stupid. And it does not try to refill the coolant if it can not cool. So that simply means it checking constantly the heatlevel.
And yeah that i waste a tick to refuel the Coolant is true but i am still experementing with that stuff and want to try out what i need and what not. And the last part was just a old code which i left as backup thing since people maybe add engines and engineer stuff like draining coolant differendly then it resets it just a backup code. But the MainEngine do not use that codepart at all its deadCode, because as soon as he drains the storedCoolant it makes directly a < 0 Check.
At line 256.
The last part again is not really true that the engine does not keep up because it is draining a lot more fluids then it uses at one tick so this one tick refueling (i hope you use that submission) does not matter, because it drains for i think 40 Ticks cooling.
Again stil experimental code. Still testing it out. I mean i work on now 8 Mods (4 of them are small, the other 3 are huge (the last one is bc itself)) (let me count..... yeah 8)
at the same time and try to make my things ready that i soon can update to the newer MC version (which i choose i do not know) so it will take a little bit time....
1.6.4 Sourcecode has no longer a branch so i can not clone it.
You can clone BC and create a branch at the last 1.6 commit (you can use the tags to find the commit of the last 1.6.4 version)
Edit: git checkout -b branchfor1.6.4 4.2.2
FluidStack result = tankCoolant.drain(Math.min(MAX_COOLANT_PER_TICK, Math.min(maxCooling, fluid.amount)), true);
You drain at max MAX_COOLANT_PER_TICK, which is how much the engine can use for one tick not 40 ticks. In the worst case scenario where the coolant is not good enough to cool the engine, or the engine has accumulated heat before the coolant was inserted, since you waste an update just to retrieve coolant you would cool at half the speed it was getting cooled before. Even if not in this scenario, you are wasting a fraction of your time just to retrieve the coolant which decreases your cooling speed inversely proportional to the cooling capabilities of the liquid.
You don't understand. You are not wasting 1 tick to calculate, you are wasting every second tick to calculate.
But because water would require 17buckets (17000mB) to drain i said even so that you need more to fill your cooling buffer to the max you are only allowed to drain 40mB per tick.
The 40mB you are draining, are the max you can use in a single tick. That means you use one tick to drain 40mB and then one tick to use those to cool the engine. Then since you drained all the cooling you spend the next tick to drain another 40mB and then wait a tick before you use them all to cool. You are only cooling the engine every second tick therefore halving the cooling speed. This is less when the engine is not too hot, it is 1 tick per (heat created each tick / (cool.getDegreesCoolingPerMB(heat) * MAX_COOLANT_PER_TICK)).
tryCooling() should not be in that else, and infact it should be before "if(coolingLeft > 0)" just like in viliml's commit.
Also in this:
java int maxCooling = Math.max(1, (int)((float)MAX_COOLANT_PER_TICK / cool.getDegreesCoolingPerMB(heat)));
the "MAX_COOLANT_PER_TICK" makes no sense, the calculation happens to be correct only because MAX_COOLANT_PER_TICK is 40 which is the same number as your max cooling buffer. You should either use 40, or create a different variable to represent it, else noone who reads the code will understand what it does. MAX_COOLANT_PER_TICK is measured in mB/tick while max cooling buffer is measured in F.
@asiekierka sry but i have to do that now. So please ignore that now.
@psxlover you are wrong and right.
First you are right: I am draining 40mB by the loading of the coolant. But you made a really big mistake that code line which you show me as argument is something that is made as Limiter. So it does not need to drain 17 Buckets to get to the highest Cooling buffer. (Which is the number 40F).
And yes i am wasting 1 Tick.
Now to the Part where you are wrong:
Thinking of 1 am wasting 1 Tick for cooling. Now get to the Worst case senario where the engine is already hot i mean close to explosion. And the Person fills Fluids in to cool the engine down (With a bucket of water) now the first tick he is draining 40 Millibuckets from the Tank and Add 40 Times draining 1 mB add the coolant of it to the buffer, and at the second ticks it applys the cooling effect and that happends every tick. And if you put one bucket in the Generated heat will be not able to keep up with the cooling effect. If that would be the case old engines would also drain that often.
But here comes the case where you get a problem with your code:
Now if we use Liquid ICE as example it has 10F Heat Decreasing. You do drain it that is true.
But your case the liquidICE will overflow your cooling buffer extremly. I mean people see that a lot get every now and then drained but do not understand why. So you overdflow your Buffer with 400F of Cooling buffer and it is only using 0,0138F of the Cooling buffer every tick. So it takes actually 24 Minutes to drain that single Coolingbuffer. And people that try to use it waste so much cooling whenever they change something.
So i decide to set a limit on that. Simply i calculate how many mB it takes to make the maximum buffer full. that is the line
int maxCooling = Math.max(1, (int)((float)MAX_COOLANT_PER_TICK / cool.getDegreesCoolingPerMB(heat)));
That is calculating the Maximum require Millibuckets. In case of water that are 17buckets (+ a little bit),
in case of Liquid ICE it would be 4 mB. But the 1 that you see there is telling even so that the cooling is so imense i drain at least 1 mb no matter what.
now to this line:
FluidStack result = tankCoolant.drain(Math.min(MAX_COOLANT_PER_TICK, Math.min(maxCooling, fluid.amount)), true);
that thing is calculating how much is he need to drain and how much is aviable. But because water would require 17buckets (17000mB) to drain i said even so that you need more to fill your cooling buffer to the max you are only allowed to drain 40mB per tick.
coolingLeft += ((cool.getDegreesCoolingPerMB(heat) * result.amount) / this.getBiomeTempScalar());
this line applies now the cooling thing. he turn math everything out and add that to the cooling buffer.
float extraHeat = heat - idealHeat;
something really cold.
float cooling = Math.min(Math.min(extraHeat, coolingLeft), 40F);
heat -= cooling;
coolingLeft -= cooling;
if(coolingLeft <= 0)
{
coolingLeft = 0.0F;
}
that part applies the cooling as you know but there is a thing that is calculating how much it needs, how much get has and how much it applies. And also there is a smaller then 0 checker thing.
Anyways i know that some parts are not perfect and as i say i do still have to test stuff still but i also think that my result is the optimal solution and do not cause so much bugs then yours (user bugs (losing stuff and co)).
I hope you see the mistake at your side i am aware of your conserns but i did think a lot of times about it and i tested it even with an engine which is producing 4 more times heat then the combustion engine with fuel and everything seemed to be fine and it is keeping up...
(Same code).
I give it up to explain it to you. If you can not follow my Mindpath then you have trouble good luck fixing the bugs. Bye
@Speiger That's a rude attitude.
Sorry but that needs to be said.
@TheBunny No need to beat a dead horse. The bug has been fixed. The issue is closed. Let's just forget about this.
@asiekierka Sorry for bothering you, but could you please lock this issue? I unsubscribed but I'm getting @mentioned and people keep coming and reviving the argument.
It's time for Vazkii's thread necromancer pic :D
Am 15.03.2015 um 15:00 schrieb Vilim Lendvaj [email protected]:
@asiekierka Sorry for bothering you, but could you please lock this issue? I unsubscribed but I'm getting @mentioned and people keep coming and reviving the argument.
—
Reply to this email directly or view it on GitHub.
