ZeroNoRyouki

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

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 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

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

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

So today I put together a small ManagedPeripheral that use the same stings lookup that DE use with just a couple of methods and the delay did not go away. Implementing ManagedEnvironment and NamedBlock too changed nothing. I've also switched to the SidedEnvironment capability from the Environment one because the former is queried first by the OC cable than the latter but no luck.
I've also traced how callbacks are executed by OC / Lua and the code path is identical for my owns and the DE ones. 
The only big differences between ER and DE at this point is that I use capabilities to interact directly with the OC cables while DE need the adapter block but I'm not sure this is significant
The VM JIT could also have a play at this (maybe DE use the same method used by it's callback while drawing the big energy orb on the screen and so that method is called so much that the JIT optimized the hell of out it) and so I've let the other reactor-controller program I've used so far run for an hour or so but again, no differences
Not sure what else is there to try at the moment...

Hi there!
So, I've run the "test" program in my 1.10.2 devenv and got the same bunch of 1s. I then changed getEnergyStored() to always return a fixed values without querying the reactor and tested again: same result. This is good, as it's not the reactor code that it's slowing thigs down
What I basically have, code wise, is an OC'Enviroment with a bunch of @Callbacks (getEnergyStored, getFuelAmount, etc). DE also implement an Enviroment but it use a string lookup (from ManagedPeripheral) to call the methods. If OC is using reflection to find the correct method on every method invocation we could have and explanation of the delay. I'll have to look around a bit more in OC code
Z

Hi there!
So, I've run the "test" program in my 1.10.2 devenv and got the same bunch of 1s. I then changed getEnergyStored() to always return a fixed values without querying the reactor and tested again: same result. This is good, as it's not the reactor code that it's slowing thigs down
What I basically have, code wise, is an OC'Enviroment with a bunch of @Callbacks (getEnergyStored, getFuelAmount, etc). DE also implement an Enviroment but it use a string lookup (from ManagedPeripheral) to call the methods. If OC is using reflection to find the correct method on every method invocation we could have and explanation of the delay. I'll have to look around a bit more in OC code
Z