A handful of connector issues, Goggles show incorrect values and a couple other bugs, questions and suggestions

[McFow1er]

Hey man, I would like to say before any of this that love the work you've done with this mod, I've been playing around with it for a good two weeks now and have a couple installations using the alternators in place with a few other ideas planned but I was a bit disappointed and confused by a few settings that didn't really hold and figured I'd come by and ask about them. I'm running this in a large mod pack on a server so this may provide some additional insight for why some things are wonky?? But I did do my research into why certain things were happening as they seemed as though they should have been just fine but I've identified that all of these stem from the code itself in one way or another, or at least I believe so as these are the only culprits I see being the reasons for these.

Also tell me if I should actually separate these into individual posts or not cause, yeah that's a lot down there.

Okay, onto the actual info:

• BUG: Connector & Conductor transfer rates are, as far as I can tell, unintentionally limited to 4096 FE/t. From what I could gather looking through the code this limitation comes from the max transfer being defined by MAX_BUFF in EnergyNetwork.java instead of pulling the maximum from the value defined by the config file. I discovered this when I and a friend decided to use the connectors as our power network as the other options we have available to us aren't as pleasant to look at nor could be hid in plain sight so we tried extending the max transfer amount to 25k to be balanced that "these aren't supposed to be the best or worst we have" only to discover they only let through a max of 4096 despite the fact that the config values stuck, this only affects the connectors and conductors, everything else can transfer to 3rd party mod energy transfer items just fine. Also looking forward to the introduction of wire energy loss and the electrum wires!

• QUESTION: While on the topic of power transfer, would it be possible to change the energy transfer methods of the various blocks to allow for their internal capacity to be smaller than their transfer rate while maintaining the config defined transfer rate as a max throughput? As it currently stands the reserve capacity acts as a seemingly unintentional bottleneck for transfer rates of energy in and out of blocks if it's smaller. I was thinking something along the lines of going from the current input > reserves > output to input & reserves > max output transfer clamp as currently the only way to reach peak output of any block is for the reserve capacity to match or exceed the transfer rates. This was a rather limiting factor I ran into regarding the Motor, Alternator and Accumulator as well as the Charger, according to a friend, I haven't tested anything else regarding this but I would assume the same would happen.

• BUG: While trying things out I also discovered that the goggles do not provide accurate info regarding changed config values that are only on the server's side such as SU capacity/use and FE generated per tick. I have not tested if these values update if applied to the client config but I assume they should and would? Only the energy network transfer values appeared to be correct, at least as far as I could tell given the hard cap of 4096 internally.

• BUG/LIMITATION: Motor and Alternator RPM is limited to 256 RPM max by the config definer. This in particular made me quite sad when I discovered this trying to set the value past 256 only for it to reset to it as Create's RPM limit can be extended much further, it would be nice if the max value possible was changed to match that of Create as this would enable the ability to have high stress and energy amounts at higher than default RPM values in Create, while also allowing for reasonable but meaningful values when run at lower RPM values along with the suggestion below.

• SUGGESTION: Separate RPM limits for the Motor and Alternator with master SU and FE values balanced based off highest RPM. Using separated RPM limits for the Motor and Alternator with master SU and FE values would allow for balancing of everything based off of the highest RPM value between the two and not allow for a motor to infinitely power an alternator, effectively taking the current system and just applying a limiter to one so that it can only go so fast but maintains equivalent SU/FE values. I would personally use this system to allow the alternators to spin as fast as the currently active Create max RPM config allows (4096 in the case of our server currently) and apply a decent value of power to make that speed and amount of stress worth the effort of achieving while only allowing the motor to rotate at a max of say 512-1024 RPM so it's only able to run an Alternator at a quarter of full power for looped power comparison.

• SUGGESTION: In game SU capacity manipulation of Motors for energy efficiency. Having the ability to change the SU capacity of a motor based off of the master SU and FE values defined above with alteration of the values based on what it's RPM limit (and thus it's usual top SU capacity) is through some secondary menu means to the RPM gauge and through computer terminals as a .torque() parameter would be amazing for using only as much power as you really have to for things, just as you would in the real world. (This value would represent max SU @ max Motor RPM) For example imagine an Alternator had a max of 256 RPM, 4096 SU and 1000 FE/t and a Motor had a max of 128 RPM so it would only report it's "max" values as being half at 2048 SU and 500 FE/t, you could increase the SU capacity to 4096 which would raise the energy usage to 1000 FE/t or drop it to say 512 SU which would drop the energy consumption to 125 FE/t all while it stays at 128 RPM max keeping balanced, though probably a good idea to have a configurable max SU multiplier... Through this and a bit of CC code you could for a good use case, make a very energy efficient, only active when needed elevator made of either fans or a rope winch, only delivering exactly as much RPM and SU as needed for as little power draw as possible.

Additional context

• Mod version: createaddition-1.16.5-20210819a
• Forge version: 1.16.5-forge-36.2.2
• Create version: create-mc1.16.5_v0.3.2d

[mrh0]

Thanks for the thorough report.

1. Will be addressed in the next update.
2. This is just the same as raising the main buffer, you would just have another "output" buffer.
3. Know issue, for now just make sure to sync server and client configs.
4. Will be addressed in the next update.
5. It's this way because separating them would make it very easy to accidentally create an infinite energy loop unless you are careful. (many people reported inf energy loops before I merged it into one value)
6. Yes this would be great however as you say this requires some sort of new type of interface and this also adds complexity for new users.

[McFow1er]

Hey dude thanks for the heads up, looking forward to the update! However I realised over time I didn't exactly explain some points you brought up because, well I just suck at explaining things usually, that post took me the better half of a day to compose, but also I'm a spontaneous thinker so some details are lost at the time or realised well after I actually have sent and written stuff down.

Also as I'm not sure if you'll see this otherwise given the way notifications seem to work on gihtub, @mrh0

1. Super hyped
2. My explanation of this was honestly garbage for the intent I had in mind, though it very well may still be the exact same case as you described. In the most basic sense I was wondering and hoping it would be possible to have say 20kFE in/out transfer on a connector while it can only hold, lets say 2.5kFE internally. The way I see it working potentially is that it remains a single buffer except that instead of it being "The input feeds the internal capacity which feeds the output" it's instead "The input feeds the internal capacity and the output with the internal capacity being drawn from upon a tick that the input fails to deliver the demanded amount of energy, otherwise it just charges using the remaining free energy" which, in my mind basically provides a bypass method. A lot more complex than just each stage drawing from the previous but I feel that would give a more intuitive in game feel, plus using a network of connectors, needing each to have an internal buffer that matches the 25kFE/t in/out rate would basically turn it into a passive battery which I want to avoid. It's also kinda closer to mechanism but also not, it's power conduits are weird, some how the transfer rate of each pipe used adds up...
3. That is handy to know, glad for the heads up
4. Super duper hyped
5. That's actually why I specified using the highest RPM for balance reasons. The only change I see being required is to turn the current MOTOR_RPM config defined variable into an internal PEAK_RPM variable defined by a bit of simple "larger than" math to determine which of the two variables NEW_MOTOR_RPM and NEW_ALTERNATOR_RPM is higher and use that value returned for all the already in place math in both the alternator and motor and use the individual new variables as the RPM limits. For example imagine the max RPM to work from is the motor at 256 RPM while the alternator is at 96 RPM or, the alternator at 4096 RPM while the motor is at 32 RPM, the math in both would be based off the higher RPM of the two, aside from that setting the max RPM limits of the blocks would only limit their max possible RPM in game. Thus leading to the already current state of the mod as essentially it's an enforced version of for example; you, myself and group of other people all just agree that we don't exceed a certain speed either coming out of the motor or going into the alternator. The power and stress generated from an alternator running at 50% max speed would still be the same if we set the alternators max RPM to half that or the motor and vice versa.
6. I was honestly unhelpfully vague with a proper implementation of this one, though I will concede that it would probably be complex to new users. That said I myself am still a relatively new user to create in general but with what I've played with in the main mod, I'm quite certain the following would actually be intuitive. For the "secondary menu means" I initially thought something like a GUI but really disliked the idea then thought of a new RPM tweaker gauge on the sides of the block or similar, however I remembered that there are already items that do this sort of visual behaviour in Create, the remote redstone switch plates with their channels, having two tweak gauges on the back next to each other horizontally or vertically would expose both values to players in a clean intuitive sense, alternatively you could make it something for more advanced players, requiring that you crouch or even be crouched while wearing the goggles to swap the gauge from RPM to SU. This would require a ponder update for the new info explaining the mechanic but it would be a good way to add and make this feature fully accessible without computercraft. Along side this to actually make this feature understood without ponder, I would recommend making it say something like this on the gauge: [TWEAKED_VALUE] SU @ [CONFIG_MOTOR_MAX_RPM_VALUE] RPM so for example of default values with both the motor and alternator having the same values in context of my response to 5 above 4096 SU @ 128 RPM or using the second example of my response to 5 with the same stress value 32 SU @ 32 RPM

[mrh0]

1. Fixed in 20210902a.
2. How it currently works is that the buffer in the connector is only for input into the network, output works like you describe, the reason it is this way is for compatibility with other Forge Energy blocks. Essentially: the connector actively pushes energy from the network (not the buffer) at max-out but passively receives energy from blocks that actively output to the connector, thereby limited by the max-in and capacity. Having the connector actively pull energy could depending on how other people have implemented the block's logic either not work or pull twice every tick.
3. Fixed in 20210902a.
4. Sounds unnecessarily complicated, I still think the one variable is best.
5. My previous stance remains.

[mrh0]

I think everything in here (except config sync issue) has been adressed by now