I already have concrete. The problem is in the actual containment implementation.
Mod Feedback [By Request] RotaryCraft Suggestions
- Thread starter Reika
- Start date
-
The FTB Forum is now read-only, and is here as an archive. To participate in our community discussions, please join our Discord! https://ftb.team/discord
Hey Reika,
I saw that you were asking for a LP of Reactorcraft/RotaryCraft. I am currently recording and posting a LP of a modpack I made that focuses on your mods. I am by no means a great LP'er, and am completely unfamiliar with your mods prior to this LP. Also I have not quite gotten to reactorcraft yet, and am bumbling my way through Rotarycraft. With all that being said, if you want a link to my LP playlist I shall provide it.
As an aside what do you plan to implement for cool new features into the upcoming V7 release?
I saw that you were asking for a LP of Reactorcraft/RotaryCraft. I am currently recording and posting a LP of a modpack I made that focuses on your mods. I am by no means a great LP'er, and am completely unfamiliar with your mods prior to this LP. Also I have not quite gotten to reactorcraft yet, and am bumbling my way through Rotarycraft. With all that being said, if you want a link to my LP playlist I shall provide it.
As an aside what do you plan to implement for cool new features into the upcoming V7 release?
I suspect I already know the answer, but is there a way to change a biomes temperature? I've built my base and got quite far with various mods, but now I'm starting to delve into rotarycraft and, although my bar is in a rainbow forest biomes, it's registering it as a cold one so temps start at -15. I'd rather not have to relocate, but may have to if :/
Reika frequently handles bug reports on this thread, but you can also post to his mc forum thread which may be more appropriate:
http://www.minecraftforum.net/topic/1969694
The mc forum is just fine, but there is a github issue tracker: https://github.com/ReikaKalseki/Reika_Mods_Issues
Celestialphoenix
Too Much Free Time
Post it anyway. I'll certainly watch the first few.
Besides; watching someone play it blind is a hell of a lot more interesting than the scripted stuff that certain LPers churn out.
It gets a lot hotter when you get close to bedrock. Also try experimenting with the heater [the ones that takes furnace fuel, not the friction one].
I'm not sure if the terraformer changes the biome type or just does aesthetics, but there's also a few mechanics from Thaumcraft and possibly Botania?? that'll actually change the biome type [and therefore temp/humidity]
Alright, You are welcome to take a gander at it. I don't start messing with Rotarycraft until a few episodes in(Episode 7 to be exact). I did some initial testing in a creative world just to get a handle on some of the mechanics but pretty much everything else is just me derping about. If you have any feedback on improvements that'd be fantastic (do it via private message to not clutter Reika's posts) but mainly this is just there as an answer for a LP request.
https://www.youtube.com/playlist?list=PLbTZ0lD6vgP3bfIIGhsM45qLsMVFba8fN
*edit* turns out I didn't notice something at the begining of episode 7 and I have a retake of my intro. I just cut that out but youtube is slow when editing so sorry for the double intro haha.
Last edited:
What about uses for the chlorine gas produced when acquiring sodium? Obviously it could be weaponized, perhaps in special rail gun shells or the aerosolizer, but it could also be combined with water to make hydrochloric acid and hypochloric acid, which have a number of industrial uses
I have run into an implementation problem I would like to see ideas about.
Basically, for those who do not know, I have many "Mod Handler" objects I use for reading the content (usually items, blocks, and configs) of other mods. All of these work off the Java strategy known as "reflection", where fields and methods (variables and functions in most languages) are fetched from a class object by their names (and the class itself is also found by its name).
The problem lies here:
This system of course relies on the mods' code remaining unchanged. If, for example, Forestry renames its "Recipe" class to "CentrifugeRecipe", Class.forName("forestry.factory.gadgets.MachineCentrifuge$Recipe") will return null and the whole handler fails. Similarly, if MagicCrops restructures and renames half its fields, the item fetching there fails.
Now, traditionally what I have done is only support the most recent version. This mostly worked, but it meant that those not updating the other mod saw the compatibility break.
So I switched to a version-based system, where it intelligently loads the correct handler for the version. This worked, except:
The way these classes were created was as a singleton, i.e. only one instance was created, and that instance was fetched with a static getInstance() method. From there I could call whatever code I needed. However, this method, being static, was a property of the class. Therefore, if, for example, I want to load the OreBerry bush handler, I call OreBerryHandler.getInstance().bushID or whatever I need. The problem is, with multiple versions, that getInstance() only returns for the class I directly referenced. To dynamically load, I would need to use the same version checking metrics as the initialization does, and then have a massive and mess if-elseif-else system to differentiate.
Now, I could write a registry of sorts that intelligently returns the correct handler object....except:
They are not identical between versions. Some items get added, removed, or renamed, and as such methods, fields, and similar might be renamed, added, or removed. So, for example, the MagicCrops handler's old version has a "dropID" field for the experience drop. That field was removed for the new version, as that item was removed in the new MagicCrops.
I am on the verge of giving up on the whole version support system.
Basically, for those who do not know, I have many "Mod Handler" objects I use for reading the content (usually items, blocks, and configs) of other mods. All of these work off the Java strategy known as "reflection", where fields and methods (variables and functions in most languages) are fetched from a class object by their names (and the class itself is also found by its name).
The problem lies here:
This system of course relies on the mods' code remaining unchanged. If, for example, Forestry renames its "Recipe" class to "CentrifugeRecipe", Class.forName("forestry.factory.gadgets.MachineCentrifuge$Recipe") will return null and the whole handler fails. Similarly, if MagicCrops restructures and renames half its fields, the item fetching there fails.
Now, traditionally what I have done is only support the most recent version. This mostly worked, but it meant that those not updating the other mod saw the compatibility break.
So I switched to a version-based system, where it intelligently loads the correct handler for the version. This worked, except:
The way these classes were created was as a singleton, i.e. only one instance was created, and that instance was fetched with a static getInstance() method. From there I could call whatever code I needed. However, this method, being static, was a property of the class. Therefore, if, for example, I want to load the OreBerry bush handler, I call OreBerryHandler.getInstance().bushID or whatever I need. The problem is, with multiple versions, that getInstance() only returns for the class I directly referenced. To dynamically load, I would need to use the same version checking metrics as the initialization does, and then have a massive and mess if-elseif-else system to differentiate.
Now, I could write a registry of sorts that intelligently returns the correct handler object....except:
They are not identical between versions. Some items get added, removed, or renamed, and as such methods, fields, and similar might be renamed, added, or removed. So, for example, the MagicCrops handler's old version has a "dropID" field for the experience drop. That field was removed for the new version, as that item was removed in the new MagicCrops.
I am on the verge of giving up on the whole version support system.
Hmm...just spit-balling something here, but what if you created an ArrayList (whose indices are based on the version of the mod you're supporting, in ascending order) of the classes containing the handler objects? That way, you could do something on the order of OreBerryHandlerArray.get( 0 ).bushID for the earliest version you support and OreBerryHandlerArray.get( n - 1 ).berryBushID for the latest version that you support. Another idea might be to create a version differentiation method somewhere that takes a string (the version of the mod we've got) and fetches the proper handler class. It might still be a mess of a switch statement (I'm not sure if Java switch statements can use strings, C# can), but at least you'd only ever have to code it once.
String switching is Java 7+, so not safely usable in mod code.
As for the rest, the problem is not getting the right handler for a version - that is easy - it is that I want to handle all versions, and that not every handler may have the same code. For example, "bushID" may be gone in one handler and renamed "cropID" in another.
Because I regularly get users using Java 4 or 5, let alone 6 or 7. As it is, my use of Java 6 code causes about one bug report a day, usually from "NoClassDefFound: ReflectiveOperationException".