Shutterpriority

A couple days so far... the host server is *mostly* 24/7 barring any major power outages, but it's only getting me logging in/out to check on the lua-script logs to make sure the timestamps kept increasing, occasionally check some tidbit of Atomic Science testing, and the lua scripts running on the CC computers.

Ok, will check it out, thanks. I'm not testing on single player, BTW. It's a separate Debian linux VMware instance running tekkit 1.1.5 server on a server platform on my local network. I dropped a dimensional anchor and have multiple computers running instances of my code. I'm going to put MCPC+ on next to see if I can reproduce it there.

Pewx, Relative to the ComputerCraft issues - it looks like you can use a wireless modem still, correct? Reason(s) I'm asking: 1) dan200 seems to think it's an MCPC+ caused issue and supports "pure Forge only", and the MCPC+ team thinks it's dan200's - i.e. this won't get resolved any time soon, and I've been trying to recreate it on a 'stock' 1.1.5 Forge-only server locally and can't 2) I've looked at all the similar tracebacks on this (including yours on the MCPC+ github), and basically it looks like the TileEntityCable.attach call is where the locks/thread blocking starts... so wired modems only is the presumption. 3) It -does- look like a basic computer placed next to each peripheral I'm monitoring can see them via the peripheral API (i.e. the redstone energy cube states/values) So I was looking to overcome this by modifying my earlier code to replace wired modems with a remote wireless computer and have each establish a channel back to a 'head-end' advanced computer that can do the control of the various other elements (or send commands off to other remotes), and make pretty graphs, etc. But obviously I'm not looking to be the cause of a crash :-) - thoughts? It's just I'm hitting bugs in the PRC with client-side crashes tracing back to the PRC GUI trying to use it, and some variables in the PRC are getting stuffed with odd values. Not to mention lua code is easier for me to read, lol. I never did well with logic-gate/machine-code logic. :-) As an aside, it looks down again - but this time not even the Dynamicmap comes up, in case you're not aware. *Edit:* It's back up now, so I guess you're aware!

Agreed - strange bug. I'm going to probably spin up a local tekkit SMP instance on a VM to test this a bit more, see if I can figure out root cause or at least point people in the right direction.

Thanks Pewx - it was probably me then - I'll be sure to yank all the wired modems/cables I may have left - if you haven't done that yet - and stay off my CC coding for them until that gets updated... although I still don't see an update in 1.56 for it from the changelogs, so not sure if Cloudy is updating or waiting for more reproductions?

Nope, that didn't help - it crashed again. I saw it was up a little while ago, but by the time I sat down to get on, it's crashed. I created one computercraft program using the peripheral API in the last few days to read the redstone energy cell levels via the peripheral API on the power station and graph the charge rate/total MJ stored and turn off the fusion reactor as needed when they were full, but it shouldn't have restarted for any server reboots since I never set it to run at startup yet since we're rebuilding the fusion reactor in the crater. So unless it's just the presence of those computers sitting idle, it's probably not those (in my case, unaware of other CC usage by players)

Here's to hoping that it's just down to get updated to the next version of Tekkit main that came out... Besides, it looks like with some of the fixes in the AS mod I can finish that 300MJ/tick single core fusion setup with large turbines instead of small ones.