Fix cable throughput readout and show it in Waila - #7914
Open
Elyspio wants to merge 4 commits into
Open
Conversation
PowerNodePath fed its voltage counter through AveragePerTickCounter.addValue, which sums everything recorded in a tick. applyVoltage runs once per hop and per packet, so the counter piled up voltages instead of energy. Scanning a cable carrying 35 A at 8192 V printed "Voltage Out: 24,576" (8192 x 3 packets) next to a maximum expressed in EU/t, so the two halves of the line were not even the same unit. Energy now has its own counter, fed with amps times the post-loss voltage. The voltage counter uses a new addMaxValue, since a voltage does not add up when several packets share a tick. The displayed maximum comes from the path's cumulated loss and its minimums instead of one cable block's own fields, which was also wrong on long runs. While in there, mLoss is reset in processPipes; it accumulated with += while mMaxAmps and mMaxVoltage were reinitialised. Scanner and Waila go through the same PowerNodePath.getReadout so they cannot drift apart. getWailaNBTData does not call reloadLocks, unlike getInfoData: reloadLocks mutates shared lock state and walks the whole segment, and Waila polls several times a second for every player looking at a cable. The Waila lines sit behind a new client toggle, Show Cable Throughput, on by default. Heads up on a behaviour change: getVoltage also feeds GTUtility.applyElectricityDamage. It used to pass the summed voltage, so electrocution damage scaled with the number of hops. It now passes the real post-loss voltage, which lowers shock damage on multi-hop networks. GT5U.infodata.cable.voltage_out and .avg_output are replaced by .voltage, .throughput and .avg. I dropped the stale ru_RU lines rather than guess at a translation; the keys fall back to English until a Russian speaker fills them in.
Author
|
Waila : 
Portable scanner : |
Contributor
|
Throughput is different from voltage, Voltage here should be good but I cannot agree with the change for throughput. |
Member
Could you elaborate a bit more please, so the author can adjust his PR? |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
I hit this while debugging a power network in game: I scanned a cable carrying 35 A at 8192 V and the Portable Scanner told me
Voltage Out: 24,576 / 786,432 EU/t. 24,576 is 8192 x 3, and the real throughput should be 35 x 8192 = 286,720 EU/t.What was wrong
PowerNodePath.applyVoltagefed its counter throughAveragePerTickCounter.addValue, which sums every value recorded in the same tick.applyVoltageruns once per hop and per packet, so that counter was piling up voltages, never energy. The number I saw was just "8192 V, three packets this tick".The right-hand side of the same line,
(mVoltage - mCableLossPerMeter) * mAmperage, is a power. So the two halves ofVoltage Out: 24,576 / 786,432 EU/twere not even the same unit. That max is also wrong on its own: it uses one cable block'smCableLossPerMeterinstead of the loss accumulated over the whole path segment.While I was in there I noticed
mLossaccumulates with+=inprocessPipes()without being reset first, unlikemMaxAmpsandmMaxVoltagetwo lines above.What I changed
Energy gets its own counter, fed in
addAmpswith amps times the post-loss voltage of the packet being pushed.applyVoltagealways runs on a path right beforeaddAmpson that same path (PowerNodes#processNextNodeand#processNodeInject), so the voltage is the one those amps are travelling at.The voltage counter now uses a new
AveragePerTickCounter.addMaxValue, which keeps the highest value of the tick instead of the sum, since a voltage does not add up when several packets share a tick.The displayed maximum comes from the path's cumulated loss and its amp/voltage minimums, so it is right on long runs too.
Scanner and Waila both read
PowerNodePath.getReadout(), so they cannot drift apart.Cables will have a Waila throughput display , (ew client toggle
Show Cable Throughput(on by default).Behaviour change worth flagging
PowerNodePath.getVoltage()also feedsGTUtility.applyElectricityDamagefromMTECable.onEntityCollidedWithBlock. It used to hand it the summed voltage, The current change will reduce the damage taken during electrocutionLang
GT5U.infodata.cable.voltage_outand.avg_outputare gone, replaced by.voltage,.throughputand.avg.