Hi @Marzolan,
thanks for reporting this issue and for looking into this.
Unfortunately, it looks like a failsafe / shutdown optimization mechanism is triggered here that I implemented some time after I came up with the breeder. I'll look into making it possible to disable it.
If you want to play with it please have a look at lines 131 - 141 in /usr/lib/draconic_control.lua.
function DraconicController:decideShutdown(reactorInfo)
if reactorInfo.generationRate == 0 then
return false
end
if reactorInfo.fieldDrainRate * self.drainback / reactorInfo.generationRate < 0.7 or reactorInfo.temperature < self.limitTemperature then
return false
end
return true
end
You CAN make that function always return false, in which case your reactor SHOULD shut down with roughly 99.51% fuel conversion - and a shutdown time of well over 15 hours. And the whole thing gets extremely scary towards the end
What I'm also curious about is that the reactor works fine using the simulator so I wonder if there's something else that's causing the condition "reactorInfo.fieldDrainRate * self.drainback / reactorInfo.generationRate < 0.7" to become false (starting the reactor with high energy saturation maybe). I need to look into that. If you want a quickfix i suggest you change the function into something like this
function DraconicController:decideShutdown(reactorInfo)
if reactorInfo.generationRate == 0 then
return false
end
local conversion = reactorInfo.fuelConversion / reactorInfo.maxFuelConversion
if conversion > 0.05 or reactorInfo.fieldDrainRate * self.drainback / reactorInfo.generationRate < 0.7 or reactorInfo.temperature < self.limitTemperature then
return false
end
return true
end
Of course making the function always return false does not fix your issue then the floating point thingy might be true. Although I'm pretty sure lua uses doubles, as does my simulator and so does draconic evolution. And floating-point math SHOULD be consistent throughout C++ (simulator), LUA and JAVA.
@Marzolan , sweet
The other part isn't actually a failsafe but rather a shutdown condition optimization. The condition becomes false as soon as energy generation is going down really heavily. This usually means that the cycle is almost over. As a result the cooldown time will dramatically (!!!) be reduced while maximizing output. As I said... without the optimization in place you'll run into a situation where the reactor is going to take 15hrs to cool down (compared to the <1 hr with it). The change you made essentially makes the function always return false. The actual code that enforces the temperature limit is somewhere else (line 183 and 194-196). If you don't care for the safety part of the function I highly recommend you hardcode some sort of fuel conversion level so your breeder doesn't take ages to cool down ;).
I assume you know this already but let me put it down here anyways: The more chaos is in your reactor, the longer your reactor takes to cool down. And that scales exponentially. So the difference between 61 mb fuel left (that's close to the point of no return btw - i haven't calculated that yet but i think somewhere around 55mb your reactor will be unable to cool down and past that it'll continue to heat up due to its inability to dicipate heat) and .. let's say 120 mb is 15hrs to 3hrs or something.
Anyways - have fun with your breeder