Open cheesealmighty opened 6 years ago
Use VisualVM for profiling.
grumble grumble google how to use visualVM for minecraft grumble Uh, right. This was a local test with my server files. Because my server provider only gives me FTP access and I don't think I can do more than that (please don't make me do anything of the sort)...
Two snapshots. Right after the first one's end, I break all the engines. If I got how this all works correctly, it's the 30 second mark in the file named noEngines? I have no clue how to read these... Then I waited a while without engines.
(I'm seeing a lot of logistics pipes, which is to be expected.)
Snapshots are here: https://www.dropbox.com/sh/ibm27tc4xh36uw4/AADyvtsxiKbryTY5q360ypiJa?dl=0
So, hydro engines are appearing, but there is no obvious "problem"; everything that is being called is supposed to be called, and while some functions are more expensive, I cannot readily think of an optimization.
Ah. Shame. I guess I'll favor other engines for the time being.
How many hydros did you have total?
16, chained together. Well it's 32 now, I haven't learnt anything.
https://puu.sh/Borng/8f936fc8ce.png
Response times seem to be cumulative as it moves to the end point, which makes sense. And the shaft junction connecting two chains respond even later.
are they checking up the whole tower each tick? because that would be taking a lot of CPU time. Alternatively checking one or two blocks per tick, using currCheck and prevMax vars in the TE, should be immeasurable.
Yes, they check every tick, because anything else is open to exploits.
considering water doesn't update that rapidly, exploiting it would be challenging at best...
Water may not, but the removal of a source block certainly can.
I am wary of something similar to the exploits in the old flywheel, with getting more total power by leveraging inertia by repeatedly cutting off the power input.
That's different here though, as you'd be checking up the waterfall by a certain amount each tick, resetting the counter when a water source, air or neighbour hydro is found. Turning the water on and off would just result in an erratic counter that would cause a lower power input, similarly moving hydros in and out of the water would result in low power due to the counter 'lag', if even possible at all.
Less total power than leaving them on entirely, yes, but more than it should be with an alternating input.
In other words, if the red wave is the input and the blue wave is the output, the integral of the latter is greater than the integral of the former.
With flywheels, this was an enormous exploit - you could "spend" an average of 0.5X MW per unit time (alternating between 1X and 0 every second), but get 0.85X MW average power out do to smoothing.
But unless I'm getting how this works wrong, you still need to alternate from water coming from 64+ blocks, and no water coming on to the paddles. And in a world with infinite water and lack of potential energy you'd need to store getting water up there, I don't think there's benefit to this alternating structure.
And isn't the whole challenge of hydrokinetics supplying them with enough lubricant anyway? The water height thing is mostly fluff. Hell, I think that mechanic mostly limits the way you can build, or makes building a wall of water tempting.
Upon further thought, I have realized something important: Unlike the coils or flywheels, maintaining the water fall into a hydro does not consume energy, so there is indeed no motive to alternate it.
I'm trying to sort out some of the TPS lag that is present in my server. And pardon me if I'm reading this wrong.
But here: https://puu.sh/Bo1Hj/816f1685b6.png 16 items marked by Pos 541 are chained Hydrokinetic engines, with their respective resource use increase as it reaches the end point. Overall: https://puu.sh/Bo1GO/fd98ef50cc.png
After removal, things seem... Marginally better? https://puu.sh/Bo1Ka/1ba6276284.png