I want to add more nuclear fuels but im not sure how to implement them without seeing the 
reactor tick code and the 
uranium code. Also the IReactor interface has no method to get the size of the reactor. Im also not sure how the acceptUraniumPulse methods works. Am i meant to sent it to nearby components and not care about the result? Also if the heat run is done first how am i meant to calculate heat since i might get pulses from components ticked after mine? 
I want to make an addon that adds more nuclear fuels but since only the API has the source visible i have no idea how the reactor ticks
-
-
Also i would like to replace the ic2 uranium ore with my glow-in-the-dark ore. How would i go about disabling the oregen or replacing the blocks it generates?
-
From the point of view of a reactor component reactors are quite simple. Every second a reactor will tick all the IReactorComponents in it via #processChamber, first for the heat run then for the power. The only reason it is split is so MOX can react to the heat a reactor has reliably rather than depending on the components before and after it changing the reactor's total heat.
Uranium (and MOX) calculate the amount of heat from the pulsable components around them (ie components that #acceptUraniumPulse returns true for) during the heat phase. You look around using IReactor#getItemAt(int, int) remembering you get given the stack's coordinates, if it falls outside the reactor's chambers you'll get null, if the slot is valid but empty you'll probably get ItemStack#EMPTY. They then look around surrounding components that return true for #canStoreHeat, attempting to balance their heat output via #alterHeat. Any spare heat is given to the reactor via IReactor#addHeat. For the non-heat run they will call their own #acceptUraniumPulse where they'll add a 1 to the reactor's output using IReactor#addOutput. Then they'll call the same method on the components around them. They'll apply the damage to themselves once this is complete, and turn into depleted forms if they run out fully.
IReactors are meant to be very relaxed about if they're given invalid slot positions, they'll just give you a clearly invalid stack which you should check for before using the result rather than being careful about which slots you ask about. #acceptUraniumPulse depends on how you want to implement it, but for Uranium Cells they avoid changing the reactor heat in the method itself and do it within #processChamber instead. The result is very much for whether you received the pulse or not for other components gauging whether to increase heat or not.
As for uranium ore, you should be fine to change the model rather than anything more drastic if you're just making it glow in the dark. If you want redstone ore style particle effects then that probably won't be enough, but it definitely depends on what you're trying to do.
-
The fact that uranium cells calculate heat by looking whats around them is quite a roadblock. it means i cant have for example an ender based fuel that pulses random components since it wont produce extra heat. i could add the heat myself but i would need to know how much heat a cell produces which is not possible for cells added by other addons. Another thing i cant do is multiple pulses per cycle. It would be much more convenient if they did the EU run first and remembered how many pulses they got.
Also i dont think i can override the rendering of existing blocks.
-
It is definitely a limitation of the system, but a logical one for the way uranium cells have always been designed. Because they handle the heat balancing logic too, it makes it much more efficient for them to know exactly how much heat they're generating to move it all at once than to keep having to push heat about when they receive a uranium pulse. There is certainly a degree of trade-offs from what is possible in favour of better performance with reactors.
Multiple pulsing is still possible however, dual and quad cells run the same logic multiples times per call to #processChamber.
The whole 1.8 model system was about being able to override block rendering, so long as you're not adding particle effects to it or dynamically changing render states that the base block doesn't have. If you spell out what kind of an effect you're going for it should be fairly obvious whether you can do it with just model changes or whether you do indeed need to fully replace the block.
-
I managed to decompile the code and no there is no multi pulsing. the cells make no difference between singles, quads or reflectors. And running the EU phase first would not make heat calculations harder, but easier since you dont need to look at neighbors a second time.
I guess i could override the vanilla cells to make complex stuff work but cells from other addons would not work then.
Also the block rendering is a backed model. i dont i can override it.
-
If you mean multi pulsing in terms of components being pulsed multiple times by #acceptUraniumPulse then no, given the way uranium is written it doesn't expect to be. The interactions between pulsables could become quite complicated if they're pulsing multiple times as a single component rather than as dual and quad uranium does acting like multiple uranium cells all being at the same position.
Running EU first breaks MOX as the power would then lag behind the heat. The heat being first means it can rely on the reactor temperature being stable for the process run, without waiting for the next tick for it to happen. This delaying applies to anything else also depending on the reactor heat.
The renderer being a baked model is not a limitation, you can override the model JSON or do it within code.