Posts by Chocohead

Waiting for Forge to get into any kind of existing state for 1.13 what you'll have to wait for first. Once that's happened it will be possible to start moving IC2 over to 1.13 as well, until then there isn't especially anything that can be done.

Rift lacks any kind of solid API for doing anything as it is right now, just this week they've changed how blocks and items are registered so porting anything to it would be an uphill battle. For smaller mods though Rift is quite an interesting project, it's sort of a midway point between Liteloader and Forge, almost Modloader like. It's certainly not ready for something like IC2 yet though.

If every single one is crashing without a log there is definitely something systematically going wrong unrelated to IC2, nothing has changed to break them compared to how they've ever worked. Accidentally running J9 or 10 is a logical thing to check first given the lack of any other crash information.

There's not going to be an official Forge backporting I wouldn't think, given there is more changing relating to coremods as the class loading is rewritten. Doesn't stop someone else from doing it however.

In due course I'm sure it will be

Nice to see you back, it's been a long time

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

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

You can see all the recipes IC2 adds to the Thermal Centrifuge in the assets/ic2/config/thermal_centrifuge.ini file within the mod jar. But the general range is 2000 to 4000 heat for processing crushed ore, 1000 to 2000 heat for processing purified crushed ore, and 4000 to 5000 heat for uranium related processing.

If you're only using IC2 then it will do nothing for you. It is designed to allow converting IC2's steam into other mod's such as Railcraft.

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.

Looks like it has, did you accidentally select making a time limited one?

Thank you, it will be included next build.

Which IC2 version is that happening? And is that with something like Sponge?

You do remember there are simulators outside the game too right?

I'd suggest making a request here.

Whoever told you that clearly didn't look very closely at what was happening. Regardless, if you update IC2 to at least 2.8.75 it should all be fine again.

The server is running out of memory whilst starting up, thus Java needs more allocating to it. You'll have to run with -Xmx2G or however much RAM you want to give it and try running again.

That's a whole lot of work retexturing, I'd say definitely worth the effort

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.