Issue with monitor order

[justinpopa]

I have a pretty large power setup currently. 4 active reactors feeding 16 turbines. I would really like to be able to have a fancy monitoring wall of all turbine and reactor statuses, but I'm having a bit of trouble getting each monitor to display the specific reactor/turbine I want. I'm also noticing some odd behavior.

From the readme I discern that the furthest connected monitor should be the furthest by length from the computer. So, from the modem on the computer I have the following:

From my computer modem I have a "tree" of 5 3x2 monitors. I want the lowest four to be for the reactors, and then the top to be the overall status. I wired it so that from the computer it goes to the four reactor monitors first, then after 5-6 more networking cable, it goes to the final monitor.

(note: cables going up go to the monitors, cables going down go to the reactors, and eventually will go to the turbines.)

However, as you can see the bottom left, which should be second closed from the computer, is made into the overall status.

What am I missing here?

[sandalle]

ComputerCraft is supposed to load in a specific order, but it doesn't always follow that, from what I've seen. mechaet has some dev code in his branch that lets you configure which monitor loads which turbine/reactor in a configuration file, but needs more testing and a re-write of the Monitor code. If you're familiar with LUA or want to try, help is always appreciated. :)

The current modpack I play on, Modderation: Permabanned, is now using Open Computers, so that's what the next update will likely be targeting. There are some servers I play on that still use ComputerCraft, so mechaet and I are hoping to have the code support both at the same time.

[sandalle]

Also, from what I've seen, ComputerCraft remembers the modem and even if you re-place it to try to redo the order, you'll get the same device ID back.

[justinpopa]

I removed all modems, stopped the server, cleared out all the computer information from the /world/computer folder, and placed all new modems with brand spanking new IDs. Same result. Oddly when I change the cabling just a little bit it shifts around but never in a predictable manner.

[sandalle]

My search-fu is failing and I am not finding any documentation on what order ComputerCraft loads devices. Supposedly it's closest-first, but I've had similar issues to yours where it doesn't always seem to be that way.

[justinpopa]

I tried to find the same info but came up short, sorry.

That said, I don't think it's front to back, or back to front by distance. I'm going to set up a test world tonight to give it a go, but I kept seeing random placement of monitors without rhyme or reason.

Should connection of reactors/turbines at different places in the cabling cause changes in the monitors do you think? I did try connecting everything in series and in parallel, but never got positive results either way.

[Znubbis]

I hope for a monitor config like you have for the reactors/turbines with custom monitor name and what info it shall show. Like justinpopa i cant figure out how to get the monitors where i want them.

Other that that this is an awesome script, really nice looking and working like a charm! :+1:

[Znubbis]

I have a small dirty hack fo help you with this if anyone don't mind digging around in the code, Find: local function findMonitors() Under: monitorList, monitorNames = getDevices("monitor") paste in the following code

local newOrder = {1,2,4,5,3}
local tempList  = monitorList
local tempNames = monitorNames
monitorList = {}
monitorNames = {}

for order = 1, #newOrder do
  monitorList[order]  = tempList[newOrder[order]]
  monitorNames[order] = tempNames[newOrder[order]]
end

Check the order of the screens when you start the program and adjust the newOrder array to your prefered order, if you add more screens you need to update this!

Dont forget update the startup script so it won't overwrite your changes.

[sandalle]

The monitor code needs a re-work, that's for sure. :) At some point I'd like to add a matching of Reactor/Turbine to a Monitor by ComputerCraft/OpenComputers device name and save that in the configuration, since those are set (at least for CC, I haven't played with OC yet) when the device is placed in the world (IIRC) and is globally (again, IIRC) unique. This way you could then modify the file to re-arrange which Turbine/Reactor/Status is on which monitor based on the name in-game and it would not change when you add/remove monitors.

For now, the snippet above would work as well. When I have some time I'll look at adding and testing the above, though I do accept pull requests as well. ;)

[AxxiD]

How about this: Having a button to iterate over the reactors and/or turbines beeing displayed.

E.g.: Monitor 28 currently displays reactor 2 but you want reactor 3 to be displayed there. Simply click the ">" button next to the reactor number and monitor 28 displays reactor 3.

This way the control is given to the user and you don't need to worry about having them loaded in a wrong order.

[thetaphi]

Looking into this, it's been bugging me too.

[thetaphi]

Question to @sandalle: Do we still support CC <1.6? I'm asking because of the term.native() headache.

[mechaet]

I'd say yes, since NST Diet and NST Maxx are still out there. How much of a headache are we talking about? If it something that can be dropped to a boolean flag and used to if-conditionally bypass the call?

Date: Wed, 1 Apr 2015 13:12:49 -0700 From: notifications@github.com To: minecraft_bigreactor_control@noreply.github.com Subject: Re: [minecraft_bigreactor_control] Issue with monitor order (#34)

Question to @sandalle: Do we still support CC <1.6? I'm asking because of the term.native() headache.

— Reply to this email directly or view it on GitHub.

[thetaphi]

OK, valid reason.

Well, the purpose is to reliably write to the original terminal. I'm not deep enough into the code to be able to tell what that's going to take, but I guess it's manageable. Either a wrapper function or teaching the terminal redirecting code to un-redirect after use should do it.

Speaking of which, what is the purpose of termRestore() exactly? I don't understand the naked term.native() call, afaict it's a noop. Thought popped up while typing: If the purpose was to restore output to the original terminal, changing that term.native() to term.redirect(term.native()) fixes a bug and my problem.

[sandalle]

We could write obfuscations for ComputerCraft (and later OpenComputers) APIs which change which just wrap the correct call to term.native() or term.redirect(), which is what termRestore() is for. :)

term.native() (and in CC 1.5 term.restore()) return the terminal output to the prior device it was pointing at, since in PrintLog I redirect the terminal output to one of the extra monitors if debugMode is true as well as in the drawing functions (such as drawBar() and drawPixel()) as the paintutils.* functions only work on terminal output (at least in CC 1.5 when I wrote them), so I have to redirect the terminal to the output monitor, and then restore so that the logs go to the computer console and not a monitor.

If we can get the bars without using paintutils, or if they can be made to work directly on monitors, most of the term.redirect()/native() code goes away and we can modify printLog() to not use terminal output.

[thetaphi]

Alright, I think I got the intention. But as of 1.6, term.native() just returns the native terminal, it doesn't clear the redirects. So I went ahead and made the change to term.redirect(term.native()), and it works beautifully under 1.7. I guess the bottom line is, as soon as I have something working, I'm going to really appreciate any help testing that stuff.

Next question: One config file for all monitors, or one config file per monitor? I'd prefer the first option.

The plan is to have _G hold a table where {monitor -> what to display on it}, save and load that structure from file, and in absence of the file do an initialization that has the same results as the existing logic. Also, for those who don't want to edit config files, the terminal will have keyboard commands to manage those assignments, and a help command.

[sandalle]

Ahh, I misread term.native() when I did the conversion, thanks for catching that @thetaphi .

Depending how you can and do format the config file, one or many files should make no difference. I believe the reason (or at least one reason) @mechaet split the Reactor and Turbine configs into separate files for each was to avoid doing structure inside each file to define which device each block of configs belonged to, especially since even if their load order (index) is changed, their name is globally unique for that server.

[thetaphi]

I'm not yet prepared to do a pull request, but if anyone wants to give it a spin... Comments, questions or test results are very welcome.

[sandalle]

Wow... for commit https://github.com/thetaphi/minecraft_bigreactor_control/commit/6d08d5373665c0b053edf8b5105f7918b0bc4f90 , @thetaphi , you clearly know LUA better than I. :)

I did some quick testing before work this morning and the monitors at least display all my devices, so no regression there. :) However, using the menu keys does not seem to change anything. Keep in mind that the current key event code is for the ComputerCraft computer only and does not work by just looking at a monitor and pressing the key (I tried looking at the monitors and using the keys as well as opening the ComputerCraft Computer screen and pressing the keys).

The overall goal of the changes and the way you're trying to do so looks great. :+1:

I've put your code on my test branch pastebin if others want easy testing.

[thetaphi]

Thanks! I appreciate it :) But, to be perfectly honest, this is my first time writing LUA, so the credit goes to those whose stuff I googled.

Yeah, the keys only work when having open the computer terminal itself, I noticed that as well. But at least that worked for me, so maybe we're looking at our first version difference? My test world runs AlienMC 1.5.9 for now, CC 1.7. In any case, I might pick up an idea from above in this thread, and just render clickable < > to select what device to render, if I find spots for them on the monitors.

Many thanks for the feedback. :+1:

[sandalle]

I was testing on Never Stop Toasting: Diet using Minecraft 1.6.4 and ComputerCraft 1.63.

You could cheat and do what I did with other spots, where I use the text as a toggle.

e.g. where it says "monitor_16", the right-clicking the left side of that text would decrement the monitor # that this device is on, right-clicking on the right side would increment. Or for "BigReactors-Reactor_6", right-clicking on the left side of the text would decrement which reactor # is shown on this monitor, and right-clicking would increment.

Or move the text around a bit so that there is room for a "<" and ">" on the left and right, respectively, of those text markers to make it more obvious.

[thetaphi]

I went with abusing the upper divider bar. thetaphi@d499fa48c0e0cad6087a12a6388110162eb732aa

What do you think?

[sandalle]

@thetaphi , so right-clicking the "<" in "< ---------------- >" (top divider bar) on monitor_16 of my screenshot will decrement through attached BigReactors-Turbines (so BigReactors-Turbine_2)? And move the other corresponding monitors with turbines, or Turbine_2 would now be displayed on two reactors? I kind of like the latter, and I believe that's what you were talking about earlier. :)

Right-clicking any of the "-" in "< ---------------- >" on monitor_16 would switch to showing Reactors (since it's currently on Turbines), then Status, then back to Turbines on the third click? Is there a reason to separate between those modes and not just cycle between all devices (currently Reactors and Turbines) and Status?

[thetaphi]

Correct on all counts.

And move the other corresponding monitors with turbines, or Turbine_2 would now be displayed on two reactors monitors

Yup, the latter. I figured having one monitor switch other monitors creates a nightmare where the user has to headsort the correct order for switching everything to what he actually wants. And you are able to have two or more monitors for the same thing, which I imagine is nice for control rooms/headquarters separated from the reactor area. The automatic setup should replicate the status quo, so if someone doesn't want to mess with it, he doesn't have to.

Is there a reason to separate between those modes and not just cycle between all devices (currently Reactors and Turbines) and Status?

At first, the code just fell into place like that, because of the way I set things up for keyboard control. Then I thought about larger installations, and being able to get to Status in three clicks instead of fifteen or more (We're planning a 42 turbine setup) just feels right. Device class switching almost always uses same number of clicks or less than cycling through everything, the exception being you're on Status or the first turbine and want to switch to the other.

The downside is that it's really not obvious. It's a divider bar, so you don't expect it to be an active, essential part of the UI. Any pointers or ideas how to fix this are appreciated (edit: I might just have had one: move the < > to the bottom, framing the device name, make clicking the name switch class, AND have < > switch class if you run past the last device. Need to see if there's enough space.). I already made a note in the script header, but who reads that?

I briefly thought about instead of monitors configuring themselves, having another monitor type, where you see the other monitors and configure them. But that might be overdoing it, and I don't see a solid advantage.

Current state of affairs: The crashes when adding/removing devices from the network should be gone, but that took a major restructuring. Byproduct of that was a nice responsiveness gain for the monitor selection UI. Next step is carrying that improvement over to the rest of the UI, which will be another rather heavy commit.

[sandalle]

So far, monitor control seems very stable, thanks @thetaphi :). I updated the instructions with https://github.com/sandalle/minecraft_bigreactor_control/commit/1f49a35334dc1f21ba02d785715141d9dd3b486b based on how it seemed to work for me when fiddling, please feel free to correct the instructions if I misunderstood what was going on.

[thetaphi]

:+1:

[Znubbis]

Thank you!

On Wed, Apr 15, 2015 at 12:21 PM, Nicolas Kratz notifications@github.com wrote:

[image: :+1:]

— Reply to this email directly or view it on GitHub https://github.com/sandalle/minecraft_bigreactor_control/issues/34#issuecomment-93305306 .

MVH Magnus Olsson