ZeroNoRyouki

OK so, I've edited the file and rebooted the server. Now the computer screen update itself like it used to do and all the linked turbines (24 of 32) were calibrated correctly with the exception of 3 of them. One if spinning up and down on a target speed of 750 RPM (it reach the "stable" state around 720~ RPM, and then rise again to around 760~ RPM and then goes in fast spindown until it become stable again) and two that are still in kickoff state with a target speed of 750 RPM but with the flow rate set the 0 mB/t. All 3 turbines have more than 2000 mB of steam in their internal tank

Edit: the grid is in "charge" mode right now

@XyFreak I'll modify the file and let you know. Is this linked to the fact thet the computer screen don't refresh itself anymore?

Your guess is correct. So far I've only connected the 4 reactors (by connecting only them in the beginning to let them calibrate) and 2 groups of 8 turbines. And the ball of power

Sure, super easy 

I'm running the same old 32 blocks of Ludicrite coils with 80 blades to use the full 2000 mB of steam. 32 Turbines driven by 4 reactors (8 Turbines per Reactor). All feeding power into one Draconic' giant ball of power

Me again, as a player this time around 

Would it be possible to add scrolling support to the Combined/Reactors/Turbines tabs? I could not see all my turbines lol

Also, do you let turbines run free and go on "error" condition on purpose?

Got it, thank you.

Yeah, that's what I assume the players will do with the power taps

@XyFreak: hi there. Could you tell me if you make any assumption about how an actively cooled Reactor shares the available hot fluid between all the connected (output) coolant ports?

Also, you may already noticed it, in the last release of a couple of days ago, I've changed a bit the way power is distribuited to the power taps of a Reactor or Turbine. Now the amount of available power is split equally between the power taps, then they try to send out their share to whatever is connected to them. Any leftover power is left in the internal buffer of the multiblock

On 2/20/2019 at 2:36 AM, CygnusiaX1 said:

@XyFreakAlright... (shutdown, disabled Optifine, restart) I do have a blinking cursor, but I still have to click to manually refresh the screen. I am using a modified version of FTB Revelations, with all mods updated to their latest versions (except Extreme Reactors... their prepping/flattening for 13 fubar'd my Yellorite gen in my world, so I rolled back to the version before.)

EDIT: If I reboot the computer, I have the blinking cursor. If I run the GUI and exit, no more blinky...

Hi there. What exactly happend? I have code in place to convert blocks in existing chunk so your Yellorite Ores should be still there

Thank you. So there is something else that keep holding that lock. I may have to make copies of all those tables before scheduling them on the server thread uhm

@XyFreak I've got a question on your usage of the setControlRodsLevels method. Are you re-using the table you pass in after calling the method?

I'm investigating a crash (https://github.com/ZeroNoRyouki/BigReactors/issues/178) that look like a race condition between a LUA thread (running your code?) and the Server thread running the code of setControlRodsLevels.

@Will135: thank you!

@Draaven: could you send me a log of the crash using a nopaste service please? Are you in single player too?

Yes that would be fine. Are you playing on a server or on a single player world?

When does this happen? Do you leave the reactor alone to do it's things (with or without BRGC running) and then suddenly it happens or do you do something to the Reactor (in the GUI, to the structures, around it, etc)? Could you send me the complete FML log using a nopaste service please?

Thank you

@Will135: was the Reactor assembled at the time of the the crash? Or did you just broke some block of it or added one in to complete the multiblock?

14 hours ago, XyFreak said:

@ZeroNoRyouki I think you might've forgot to check for a 0 somewhere

That's strange. I don't check because that divisor could never be zero in an assembled reactor: it's the number of fuel rods in each fuel "assembly" (control rod + fuel rods) strike that, it's the total number of fuel rods (which is even worse) so it will always be >= 1. Something else is going on

@Will135 could you please post me a couple of pics of the interior of your reactor?

13 hours ago, XyFreak said:

I'll make it official now.

Big Reactors Grid Control Version 4.3.1 has been released!

Changelog:

 - Now using the new ER API (0.4.5.48 and higher). Old API is still supported.
 - Implemented further mitigations for the "too long without yielding" issues.
 - Included a hack/workaround for a bug with OpenOS 1.7.1 (and earlier) and Lua 5.3 mode.
 - Fixed a bug where attempting to format a number as an integer (illegal in Lua 5.3 mode).

I'm sorry for abusing some of you as beta testers

Nice!

Hi there,

I've just uploaded the new version of ER (with the new API) on Curse (it's under review at the moment)

Have fun!

@XyFreak if all goes well, I'm going to release the new API later today or tomorrow

@XyFreak and everyone else interested in the ER Computer API: please check https://github.com/ZeroNoRyouki/BigReactors/issues/162

@XyFreak Yeah don't worry, I've put in an alias for that method so for a couple of version it should be OK. I'm going to send you and preview copy of the mod when I'm done with the API rewrite to test BRGC against it. I've also added a couple of new methods to grab more data in a single call

@XyFreak so.... I'm testing a new implementation of the ER computers API and when I run your program GUI my reactor (the only one connected to the computer) shows up as DISCONNECTED. brgcctrl list show one reactor in the CALIBRATING state. I've update BRGC to the last version. I've also update OpenOS, broken and replaced my computer port, etc etc

The major logical change in the API implementation is that all the set/do methods are not executed right away but they exit immediately after scheduling themselves to be executed on the next tick on the server thread while the get ones are still carried away on the LUA thread. So, for example, if you call getActive() right after a setActive(true) you will get false back if the LUA thread was not preempted in favor of the server thread. All this is done to get back in a thread-safe environment without incurring again the "yeld problem"

I've also renamed the getMinimumCoordinate/getMaximumCoordinate methods but grep is telling me your are not using them. 

EDIT: problem found. I forgot that I've renamed getConnected too

Good!

@XyFreak Yes, the code is not thread safe. It never was (until the switch to the non direct calls made it so). But it worked fine since 1.7.10 so this will be probably OK for a stop-gap solution

I have to redesign the whole thing

Hi,

I've just posted and updated version of ER on Curse (It's under review right now). All the Callbacks are back to the old-direct-call-we-dont-care-about-threads-because-who-knows way of the original code. You must break and replace all your computer ports to see this in action

Z