Posts by Chocohead

    It's 1.12 Greg, the RAM usage doesn't model according to 1.7 rules. Things have changed since 4 years ago.


    The usage will increase further if the game actually manages to load, the world itself takes some. There is probably also more being loaded generally if it is managing to finish loading rather than crashing out mid way through. Either way, that is detached from the crash which is something between Hardcore Questing and Thermal Foundation. You can try with keeping -ea and using -da:ic2.core.uu.UuGraph too, but I don't see it helping drop RAM usage or fixing that issue.

    You're running with assertions enabled, which certainly isn't going to make the game run any faster as it will be performing more checks as it goes.


    As for the actual crash, Tech Reborn look to have added an invalid recipe output which the UU graph caught (which being an assertion would normally have been ignored). If you run with

    Code
    1. -da:ic2.core.uu.UuGraph

    it should all be happy again, but disabling asserts completely with -da (or not including -ea or -enableassertions as arguments) is probably going to save future hassle with other over zealous asserts (such as Netty's when you try opening certain GUIs).

    You'd want to have a look inside the Binnie's Mods jar to see the structure of the assets/<mod>/textures/* files and folders to see how much it lines up to the resource pack's. If you're lucky there shouldn't be too much to move around.

    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.

    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.

    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.

    Hrm... they do appear to be better than I remember them from before I started playing GT6 last year. I still wish they would be in conventional linux kernel/git format of subject line, blank line, better description of one change, as opposed to here is a numbered list 10 unrelated things I've done today. Lumping multiple unrelated changes together makes it a pain when you try to review the changes, or cherry pick something and have to work out exactly which lines of code changed were related to the one thing you care about. Or when you are doing a blame and trying to figure out why a given line of code is the way that it is, and have to figure out which one of the 10 things in the change log this particular line had to do with.

    The details links give the full Git commit messages, the changes page really just shows the subject of the commits pushed since the last push. It is probably more of a layout concern if the full description is huge it would make the page much more unwieldy. The Git repo itself has no idea about anything Jenkins does, so if you do need to blame or cherry pick it is still at the commit level rather than as semi-arbitrary blocks. Of course this isn't much use if you've not got the repo too, but I do mark which version a fix is added for bugs on the tracker which is the only time you'd likely need to be searching for specific changes outside of say tracking compatibility code.

    There is the BatPack and upgraded forms of that which allow recharging, as well as the Charging RE-Battery and upgraded forms that also allow recharging tools in the inventory. It is at the expense of either the chest armour slot or a normal inventory slot, but that is not an especially bad price to pay. The charging forms especially have very few downsides if you've got another mod adding a backpack for storing ores and the like in rather than relying just on inventory space.


    There was an old addon called Combo Armours that allowed the merging of Batpacks, Jetpacks and normal armour to effectively remove the drawbacks, but that's not been updated in years.

    Very nice, there used to be a few resource packs for 1.7 that did this but you're definitely the first to make it past 1.7 to do a complete one. Are all the textures for new things your own or based on the old ones if possible?