[ReactorCraft] ReC Mechanics Thread

[Pyure]

Maybe the reward could come in the form of good relations with the Voidspawn faction after a while, who could be traded with for some alien materials that aren't on the known periodic table of elements in small(ish) quantities, "unobtanium" perhaps (lol), which could be used as a clean but highly perishable alternative fuel source? Maybe? I dunno.

I like Voyager as much as the next guy but now you're just being odd

I don't have any specific machine or block ideas, I just want a reason to not instantly void all the waste my reactors produce. As long as that reason isn't "my world will be ruined" if I do, then it should be perfectly fine.

Agreed.

Speaking of blocks: if waste were rendered as a "block" rather than an item (your reactor would have to have a "room" where the state of this waste block would accumulate), the dev has considerable more control over what happens to that block.

 

[keybounce]

Well, lets see. Void monster as punishment? Nope?

ok, turn all of the items into entities, like Mystcraft books? Does that still let you know when they are put into an AE system, or destroyed from within an AE system? Heck, what if they are just put on a drive, and the drive taken out and put into a chest. Still "around", not destroyed, but never to be powered up again ...

Ok, so, we want things that cannot go into a normal chest, cannot go into a normal forge backpack or other inventory, cannot go into an AE system, etc.

Hmm ... Might be kinda hard to make an item like that -- a non-storable item? Does forge even permit such a thing?

 

[Pyure]

Well, lets see. Void monster as punishment? Nope?

ok, turn all of the items into entities, like Mystcraft books? Does that still let you know when they are put into an AE system, or destroyed from within an AE system? Heck, what if they are just put on a drive, and the drive taken out and put into a chest. Still "around", not destroyed, but never to be powered up again ...

Ok, so, we want things that cannot go into a normal chest, cannot go into a normal forge backpack or other inventory, cannot go into an AE system, etc.

Hmm ... Might be kinda hard to make an item like that -- a non-storable item? Does forge even permit such a thing?

Nope. Items can go into chests period. You can dev a chest that doesn't store certain items, but you can't make items that won't go into chests.

Really the only options are to make waste a block with special functionality (and even then there's probably going to be workarounds), or a variable such as thaumcraft vis (TC5). Neither of which are super appealing to Reika (which I know from previous conversations on the topic).

I think he'd get closer to his vision by rendering waste as a block rather than an item, but its his decision.

 

[Someone Else 37]

Java's Object class does have a finalize() method, called when the JVM detects that no more objects reference it, but before the garbage collector disposes of the object. If Reika overrode this method in his nuclear waste objects (which may require extending the ItemStack class, if that's even possible), he could effectively detect when one if the items is voided and then spawn a radiation leak.

Although finalize() might also fire when the item is stacked with more nuclear waste, or decays on its own, or was in a chunk or dimension that just unloaded, or is placed in an ME system, or probably several other cases.

Likely to be a bug-filled pile of hack? Yes. But if it works, this could be a very effective way to discourage people from voiding nuclear waste.

 

[RavynousHunter]

I don't know about Java, but .Net books tend to scream at you if you make unnecessary calls to finalization or disposal methods. The reason being that managed code is supposed to handle all that for you, and the only resources you need to explicitly clean up (with anything other than a close method) are those from calls to unmanaged code, such as native libraries. The rule is: don't make a finalizer unless it is absolutely necessary. Game balance concerns are NOT one of those cases.

 

[Pyure]

Java's Object class does have a finalize() method, called when the JVM detects that no more objects reference it, but before the garbage collector disposes of the object. If Reika overrode this method in his nuclear waste objects (which may require extending the ItemStack class, if that's even possible), he could effectively detect when one if the items is voided and then spawn a radiation leak.

Although finalize() might also fire when the item is stacked with more nuclear waste, or decays on its own, or was in a chunk or dimension that just unloaded, or is placed in an ME system, or probably several other cases.

This (finalize()) was my question/suggestion to Reika 2.5 years ago (I actually came across the post yesterday). Although I called it a "destructor" method since that's what I'm familiar with. He pointed out that items finalize at inopportune times that would make this not work.

 

[RavynousHunter]

Yeah, the simplest way I can think of would be to either hook into an event that trashcans and the like fire when deleting items, or using some kind of ASM/reflection trickery to detect it. Evrn then, that'd be a lot of work for relatively little gain. I mean, if trashcans no longer woek, then people will just tesseract them to somewhere far away and drop them into the bottom of a void world.

 

[Pyure]

Yeah, the simplest way I can think of would be to either hook into an event that trashcans and the like fire when deleting items, or using some kind of ASM/reflection trickery to detect it. Evrn then, that'd be a lot of work for relatively little gain. I mean, if trashcans no longer woek, then people will just tesseract them to somewhere far away and drop them into the bottom of a void world.

+1. At the end of the day its not worth the effort, especially when (in my opinion at least) there are better ways to achieve the same end goal.

 

[Someone Else 37]

Yeah, you guys are probably right. Hooking into a method that trash cans and the like call when deleting an item would certainly be the way to go if such a method existed, which is likely not the case, as literally nothing else in the game cares about that.

Detecting when an item is thrown into fire or lava might be easier (as doing do sets the item entity on fire), so Reika could do something nasty to discourage that... but it still doesn't help much as far as discouraging trash cans goes.

A better solution overall would be to make nuclear waste more useful somehow. But how to do so in a way that's even somewhat realistic and is actually useful in Minecraft?

Some of the isotopes produced could be used in RTGs, but RoC's DC engines produce more power anyway and are much safer and easier to build. Radioisotopes are also be used to power lamps that can run for decades without needing to be refueled, but we've already got torches and glowstone that do the same thing for much less hassle.

Maybe there could be a version of the neutron irradiation thingy (the one that makes tritium) that runs on an internal inventory of nuclear waste, rather than an external source of neutrons? Still wouldn't be a whole lot easier to use than just slapping one in the middle of your reactor, so hrm.

 

[Pyure]

Last I checked, the items were invulnerable to fire/lava. So that problem is already addressed: if you toss that stuff on the ground (in lava or w/e) you're going to be punishing yourself.

Yeah, making the waste useful in a reasonably-realistic way isn't really a huge problem: waste is radioactive. It emits neutrons, which means it can be a part of an energy or fuel production cycle. But its energy density is lower. Ideally such a facility would be a larger facility. A penalty for trying to get energy out of waste is, ahem, wasted space.

 

[keybounce]

Finalize is worse than you think.

First, it isn't even guaranteed to be called. When the program shuts down, Finalizers can be skipped. Second, consider shutting down the current world, the save() routines are called, and then objects are destroyed, and finalizers want to do ... what?

Third, consider a case of a chunk unloading. You save the active items into the save file, garbage collect the chunk, finalize the objects, and ... now what is it supposed to do?

It's potentially worse. The objects/entities want to know where they are, so they are referencing the chunk somehow. Garbage collection can still find this -- the loop of objects is not referenced anywhere else, so eventually (key: eventually; it takes a major collection [full GC in the classic/throughput collector] which can be very very long later) it wants to be removed. So now what happens? You've got an object referencing a chunk that is not active, mostly forgotten, but still in memory. What next?

Finalize is really a very badly designed language mechanism. I haven't even gotten into the worst aspect of it. Normally, object destructors are called when an object goes bye-bye, and the object is going to go bye-bye. Finalize is called when the object is detected as having no more references, and the routine has the ability to give it a reference.

Yea, you can take "this", and store it somewhere, and your "dead" object is back to life. Even if it is now referencing an inactive chunk, now "live", and consuming memory, with an entity referencing it, but potentially none of the other data that minecraft is tracking about the chunk up to date.

That's a complexity that really made it difficult to write a good garbage collector, by the way. It was less of an effect on the early "stop the program, clean up everything, resume" things. But knowing that an object is "ready to be destroyed" simply means "ok, mark it for later, we have to call code and give it a chance to come back to life, we can only actually remove it if it is still dead after all that code is called and run". I read (a while back, probably the J4 or 5 days) about how much that made the CMS collector significantly harder to make work properly.

===

So there's no way to make an object that cannot go into a chest? Hmm. Ok, how do you get some inventories that can only take certain objects? Does forge have an event bus action for "Can this object go into this container"? (And if not, why not???). Can that be extended to vanilla chests?

No? Alright. What about your basic minecarts? They're entities, they exist in the world, and they have an item form. So there's something that turns them from world-things to item-things. So lets remove that "conversion" -- ... oh, wait, that doesn't solve it, because at some point, you are going to be carrying the waste container with the waste entity inside it, and it's back to being an inventory item. Hmm...

(I'll go with not worth solving as well

 

[ChemE]

I'm showing up a bit late here but 1) Pyure is correct that throwing nuclear waste into lava does not destroy it but it does spread radioactivity
2) I have noticed in my own derping around that dropping nuclear waste onto a cactus does destroy it 3) Does anyone know how to trigger the "can do" achievement? I assume it is in reference to CANDU reactors but one can't put heavy water into a reactor as far as I know.

 

[RavynousHunter]

Not 100%, but I think you can put heavy water into the coolant cell blocks. If I'm reading things correctly, that should trigger the achievement.

 

[ChemE]

Not 100%, but I think you can put heavy water into the coolant cell blocks. If I'm reading things correctly, that should trigger the achievement.

Worked like a champ. Much obliged!

 

[RavynousHunter]

Not a problem, homes!

 

[Boldar]

How is one supposed to deal with a Meltdown? Every try on a SSP test world rendered the world unusabe due to radiation entities accumulating. When several thousand of them are there, the tick time rises to unplayable levels, and they don't seem to stop being accumulated until the Corium is removed.
May i suggest changing how Corium Works? Let it expell a fixed amount of Radiation at Creation (only like 10 Entities per Block at max, because with a 10x10 reactor that equals to 1000 in sum, which is already quite laggy), and make every single one worse, and then let the Corium "cool" into some other form, which stops it from emmiting radiation as long as there are more than x radiation entities in the surrounding area? That would reduce Entity coun't a lot, and ensure that a server could survive a meltdown. If i have to load a backup or destroy the Reactor with MCedit everytime a Meltdown occurs because i can not even come near the area without massive lags, that kind of destroys the whole point of them.
Or, as another approach, maybe try to bundle them - have the Radiation entities track "severity" or "count" and on creation of a new one, check if there are more than x in the surroundings, and then instead just make an existing one worse instead of adding a new one.
However, the actual mechanics seem to render the world unplayable as soon as a reactor melts.
I do think a Meltdown should have a severe impact, but not in such a way as effectively crashing the server.

 

[ChemE]

How is one supposed to deal with a Meltdown? Every try on a SSP test world rendered the world unusabe due to radiation entities accumulating. When several thousand of them are there, the tick time rises to unplayable levels, and they don't seem to stop being accumulated until the Corium is removed.
May i suggest changing how Corium Works? Let it expell a fixed amount of Radiation at Creation (only like 10 Entities per Block at max, because with a 10x10 reactor that equals to 1000 in sum, which is already quite laggy), and make every single one worse, and then let the Corium "cool" into some other form, which stops it from emmiting radiation as long as there are more than x radiation entities in the surrounding area? That would reduce Entity coun't a lot, and ensure that a server could survive a meltdown. If i have to load a backup or destroy the Reactor with MCedit everytime a Meltdown occurs because i can not even come near the area without massive lags, that kind of destroys the whole point of them.
Or, as another approach, maybe try to bundle them - have the Radiation entities track "severity" or "count" and on creation of a new one, check if there are more than x in the surroundings, and then instead just make an existing one worse instead of adding a new one.
However, the actual mechanics seem to render the world unplayable as soon as a reactor melts.
I do think a Meltdown should have a severe impact, but not in such a way as effectively crashing the server.

Something like this would be an excellent change to ReC. On our server, we only use fission reactors in a specific RFTools dimension. This way if there is a meltdown, we can just trash that dimension instead of starting the whole world over. If someone broke ranks and had a meltdown in the OW, it could potentially crash the server which surely is not what Reika intends. Really just one radiation entity per chunk could get the job done as far as damaging the player at a distance and changing blocks.

 

[RavynousHunter]

If you have CoFH stuff installed (TE, MFR, etc), you can use the /cofh killall command and supply it with the name of radiation entities to nix em all. If that's too cheaty, you could add a recipe for the radiation goggles, make/fill a cleanup tool, and do it manually. Not sure if it was implemented or not, but I think sprinklers can also help manage radiation.

 

[Boldar]

I know about these ways, but in my tests with ~20 Corium Blocks, the Radiation entities were building up so fast that it started lagging after seconds. When using the kill all command, i could remove several thousand entities every 20 seconds or so. That does not give enough time for a legit cleanup. The lag just adds up too fast.

 

[RavynousHunter]

Aah. I wouldn't really know, I'm extremely anal about building in a creative test world, first.