I was looking at the source for the fission reactor and I’m just wondering how exactly moderation spreads. The only thing that would make sense to me is that the blocks (probably all, not just reactor blocks) are divided into even and odd sets and updated separately. That would make the spread predictable and limited to 1 block per second. Is this right?
3 Likes
Uhh I did not do the Moderation Stuff so @Erik3003 needs to explain that to you, lets hope he is there lol.
3 Likes
Moderation basically spreads or updates through the reactor every second: Every second a reactor rod checks if it was tagged to be moderated last second and when it was, it will be turned moderated, when not it will be turned unmoderated. Then that rod will interact with all adjacent fuel rods and if it is moderated, it will tag those rods it interacted with for moderation. The moderator mod is obviously always be moderated and thus tag all adjacent fuel rods for moderation.
The thing to note is that the moderation is not on the reactor blocks, but on the rods and only fuel rods will be able to get moderated, making only fuel and moderator rods able to spread moderation to adjacent fuel rods.
To get rid of the moderation on a fuel rod in a reactor, simply turn of the adjacent rods that apply the moderation to it for at least a second. Moderation will also updated when the reactor or rods are turned off, so shutting down your whole reactor also will unmoderate all fuel rods, but a shut down fuel rod will still be able to be moderated by an active one.
TD;DR: Moderation spreads every second from all moderated rods (moderated fuel rods and moderator rods) to all adjacent fuel rods, creating more moderated fuel rods which will then spread the moderation to potentially more fuel rods on the next second.
Hope this all helps.
3 Likes
Thanks for clearing that up!
But out of curiosity, how is that implemented? Because I believe the code I saw is dependent on block update order. It would work as you describe if even and odd blocks were updated separately. Is that how it works?
3 Likes
It’s not dependent on the block update order, but when researching my old code for this code I almost thought it was. Now having looked at the code again, I finally realized it is dependent on block update order and the method I used to prevent it is basically useless.
Currently, when it updates a rod, the method that gets the moderation value isReactorRodModerated() tells the rod to update to the moderation value oModeration to be equal to mModeration, mModeration being the value that is set by other functions, and outputs the new oModeration, while setting mModeration back to false. When a rod has been tagged for moderation, i.e. mModeration set to true, it can obviously still be called on the same tick and directly update that to oModeration, which gets directly output. This is obviously only possible, if the rod gets called after being tagged for moderation in that tick and not if it does after ticking itself, meaning that the system is dependent on block update order. It’s basically no different from just setting oModeration and directly outputting that.
The solution to this would simply splitting the isReactorRodModerated() into two methods, isReactorRodModerated() and updateReactorRodModeration(), (and of course isModerated() and updateModeration() on the rods) one which just returns oModeration and one which updates oModeration to have the value of mModeration, but is only called in the second subtick, so after all rods have interacted and set mModeration on the rods.
Not sure if @Gregorius wants to quickly fix this small thing himself or if I should do another pull request soon.
3 Likes
Wait did i not make sure that there is 2 ticks that happen in order, so as to prevent any issues with tick order? Because there clearly is such a thing right there in the code very obviously.
And I dont exactly know what you broke, so I will look at it once you fix it.
3 Likes
Well, I implemented the things specifically to prevent update order from having an effect, my “solution” just is a stupid one that doesn’t work or doesn’t even do anything at all really 
Thankfully this is not really a critical issue with almost no gameplay effect at all (At worst a few seconds less of durability on some fuel rods that get updated too early but no impact to the neutron economy at all).
I’ll quickly fix it, I mean the other stuff in the reactor prevents these kind of issues by doing the neutron stuff on the first call of onServerTickPost() where aFirst is true and doing power stuff on the second call where aFirst is false. I will just update so the moderation values in the second call, which just requires a small new function. Expect a small pull request much later today.
3 Likes
Here is the PR: Fixed reactor moderation updating being update order dependent by Erik3003 · Pull Request #41 · GregTech6/gregtech6 · GitHub
Wasn’t able to compile and test because something in the build configuration is borked:
Could not resolve all files for configuration ‘:compileClasspath’.
> Could not find forgeBin.jar (:forgeBin:1.7.10-10.13.4.1614-1.7.10).
2 Likes
Sounds like you’re still using forge’s maven deps somehow, you are fully updated and you ran something like ./gradlew --refresh-dependencies setupDecompWorkspace to update it all?
2 Likes
Everything should be fully updated, it’s a freshly pulled repo and merged the latest upstream. Even refreshing the dependencies or just cloning the original GregTech6/gregtech6 repo didn’t help, so I still suspect there is something wrong in the build configuration, though I am not at all a gradle expert or even remotely proficient with it.
On a more positive note, I tested the testing release and reactors and moderation still works fine, so it seems I didn’t mess up and the small moderation spread issue should be fixed now.
2 Likes
Well that kind of error is what happens when its still using the broken old forge maven jar’s, but that should be fixed with the prior command (would replace with GT6’s maven), so if it’s still happening then that’s very curious, it works for every system I’ve ran across, across a whole lot of projects that now use the GT6 maven, so if something is borked it would likely affect a lot of people, so I’m really curious as to the cause…
You could try deleting your ~/.gradle cache directory and then run that above refresh dependencies decomp command above to regenerate it properly and see if that helps?
2 Likes
Deleting that for some reasons opened up a whole new can of issues, apparently from 2013 (specified for property ‘fernFlower’ does not exist). That seems to be most likely caused by a problem with my JRE and/or JDK installation, so I have to reinstall those at some point. So I can’t confirm if it would now have worked or not, as the new issues doesn’t allow to even get me to that point, sorry, but I now suspect that the issues are much more likely on my side.
2 Likes
Fernflower being missing is a Forge thing that happened like last week or two ago. @OvermindDL1 do you happen to have tested a fresh dev environment setup after forge pulled that stunt?
2 Likes
Well that was exceptionally stupid, more hardcoded templated paths in forgegradle I had to fix… @Erik3003 can you --refresh-dependencies and try again (the --refresh-dependencies shouldn’t actually be necessary, but it doesn’t hurt just to make sure everything is forced checked for updates)? It should work now. Forge broke their maven even more than it already was a couple weeks ago so that’s worked around now, to not use it all now specifically. >.>
2 Likes
Ok, everything finally works now 
2 Likes
Does “everything” include your moderation changes?
2 Likes
Yes, from what I tested moderation spread works as it should in both the 1x1 and 2x2 reactor.
2 Likes
Woot!
2 Likes
Just updated to newest commit. My moderated Co-60 reactor is still running.
3 Likes