Improved Monitor Control #57
Merged
Conversation
This file contains 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
The concept of "steam production capacity" was nice for display, but useless when you don't know what's max capacity. Not without a calibration procedure on startup at least, and I *almost* implemented it. But that would have broken existing setups, and straight supply/demand numbers in mB work as well. In the process, I fixed some flow rate peculiarities. Under certain loads, RPM would drop until double time kicked in, since flow rate took too long to pick up after a coil disengage on buffer full. Now the coil engage on buffer empty sets flow rate based on an estimate for the configured RPM.
Don't calculate unknowable numbers
Instead of looking for activly cooled reactors, I simply took the list size. Untested code, late night brainfart fix. TODO: Same for turbines.
This reverts commit 9fe6ed98194212bcf8c34063586e1b8ef3ebf375.
Reconfiguration of which monitor displays what. Load order agnostic, persistent, configurable via config file or terminal UI. Bonus feature: Multiple monitors can display the same thing, in case you want one status monitor in you reactor room and another in your command hub. Please refer to sandalle#34 for an idea of why and how, I'm too tired for a detailed writeup. Beware: I have only made it work, not tested it (yet). WIP, PoC, falling blocks of code ahead. You have been warned.
Click on the new < > in the second monitor line to switch within a device class, click the ---------- to switch device class. I'm not entirely sure how obvious to the user that latter is, and I'd hate for anyone to find out only by accident. README time? Also, started using log levels, as the debug spam was eating what I wanted to see. That might see some extended use in the future.
Also, I started messing with the version number again, as I'm putting it on http://pastebin.com/gZ3aZxHE for the guys on my server. No need for sandalle to take the blame for my bugs.
Dealt with a strange bug in the process, which resulted in a spruced up log display
by killing it from the runtime data structure. The next reboot will notice it's missing, and throw it out of the config. Not entirely convenient for people hand editing their monitors.options, but now that we have autodiscovery on restart, it's easy enough to fix.
...which are now causing the system to reinitialize. That means you can simply plug in a new monitor (reactors and turbine and use it, no reboot necessary. Plug and Play, baby! It started when I was hunting a bug where clicks simply didn't register when configuring monitors, and I think I found the culprit in sleep(). Replaced it with wait() from the wiki, and because having two event poll loops in the same process is a Bad Idea, I shuffled some code around. Since the event handler now runs out of wait() called by main(), the wrapping loops and parallel execution were unnecessary. That in turn means we don't have to watch out for concurrency issues any more, and THAT means we can happily update the UI from the event handler. The gain in responsiveness is noticeable.
Since that pulls the affected code out of the display call path and into the event handling path, which updates the displays afterwards, responsiveness should be vastly increased.
As discussed in sandalle#34, clicking the lowest monitor line now switches device class, and going past the last device of its class via arrow click now also switches device class. Also: * Untangled a few things in printCentered(). It was overwriting and then reprinting the monitor names, and the math was subtly off. * added formatReadableSIUnit(number), to shorten the buffer numbers on status screen, which were too big for display along the navigation arrows.
|
This is for Issue #34 for reference. 👍 |
sandalle
added a commit
that referenced
this pull request
Apr 8, 2015
Improved Monitor Control for Issue #34 .
|
I'll give it a test on my CC 1.63 running Minecraft 1.6.4 with NST: Diet. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Changes:
I call that "feature complete". There might be bugs that I didn't find, or didn't have a chance to find, since I'm running CC 1.7, and only have a limited testing setup (Two reactors, two turbines, seven monitors). I'm working on the autobuilding of turbines, but I think the code is at a point where the input of others is more valuable than trying to think of everything myself.