AFAIK, config files alone can't do that in the 1.7.10 version of IC2 experimental. However, there's a small addon that allows bringing back the "classic" E-net. Here's a link to it: [IC2 Exp][1.7.10|1.8.9|1.10.2] Uncomplication, IC2Classic E-Net, IC2Classic Recipes, Old UUMatter... And all of that for IC2Exp.
Posts by MauveCloud
-
-
and 14 gb of dedicated ram.
-Xmx14G -Xmx512M
Somewhere your attempt at giving it 14 gb of dedicated ram is being overridden by a parameter that only gives it 512 megabytes. If you didn't leave that in the launcher settings, there may be an environment variable or something that's providing the second memory setting.
-
I'm not sure about a "cover" over construction foam, but there is the Obscurator:
https://wiki.industrial-craft.net/index.php?title=Obscurator
I haven't used it much myself, since I only play single-player and prefer to have my cables visible.
-
That matches the in-game behavior, though I'm aware it may be confusing to those accustomed to its EU reactor behavior. It is documented on both https://wiki.industrial-craft.….php?title=Fuel_Rod_(MOX):
QuoteMOX Fuel Rods behave rather more sedately in the fluid reactor, outputting normal efficiency at reactor heat <50% and 2 times normal efficiency for reactor heat >50%.
and https://ftbwiki.org/Fuel_Rod_(MOX)
It is also mentioned in the tooltips when you select MOX fuel rods from the component palette in the upper right section of the planner.
https://ftb.gamepedia.com/Fuel_Rod_(MOX) has apparently not been updated to cover fluid reactor usage.
-
Looking at the author's profile, he/she hasn't been active since 2015, but as far as I can tell, the link is only broken due to changes in curseforge site structure. A little searching, and it looks like it is available here:
-
I'm not sure why you posted this in the IC2 forum, since that is a Buildcraft pump, and as far as I can tell, there are no IC2 blocks in that screenshot. However, I will try to help anyway. You need to provide power to the pump, not just the wooden fluid pipe attached to it, and the pump will auto-output to any fluid pipes attached without needing a wooden fluid pipe (I just checked using Buildcraft 7.99.24.1). The pump can technically operate when powered by a redstone engine, but idk whether that will be fast enough to keep up with your arboretum (which as I recall has variable water requirements based on how long it has been since the last rainfall and possibly other factors)
-
It's a rather low chance for any given crossbreeding attempt - I usually make at least one 9x9 field with 40 regular reed and 40 cross-crops in a sort of "checkerboard" pattern (water in the center with some sort of slab over it), and even then it can take 3 or 4 passes before I get any stickreed (more regular reed is a lot more common).
-
Look in the "Advanced" tab. There's an option to make it output old-style codes.
As far as the mobile app, I am not involved in developing that.
-
albijoe based on your screenshot, you're using an older build of the IC2 experimental reactor planner. I seem to have neglected to announce it in the planner's forum thread, but in v2.3.1 I added output of Base64-encoded reactor codes (with "erp=" prefix) which are considerably shorter than before, and moved the code field below the reactor grid. Latest build is now v2.3.4.2
-
Alternatively, you could add https://minecraft.curseforge.com/projects/tatw especially if your server already has mods with RF-carrying cables of some sort.
-
Sorry for necropost, but I recently realized I never really got an answer as to whether this was intentional. Should I file a bug about it?
-
With my current crop breeding strategy, it isn't a big deal whether I can remember the stats of scanned seeds I have planted and are growing, but why require using the cropnalyzer again for that? If the seeds have already been analyzed, it seems to me that Hwyla or TOP should also be allowed to show GGR details of the growing crop.
After reading the "tongue-in-cheek narrative description of SeedManager", the Seed Library from that mod would be very helpful for my strategy (I'm currently using a YABBA AntiBarrel for temporary seed bag storage), as well as a backpack-type item with extra capacity but limited to holding seeds - since they have a stacksize limit of 1 (and frequently different NBT data, which would prevent them from stacking anyway), generic backpacks from other mods quickly fill up - a diamond backpack with storage emphasis from the Iron Backpacks mod is 77 slots (although I'm using default config, which indicates it is supposed to be 54 slots
), a fully size-upgraded BetterBackpack from the BetterChests mod is 90 slots, and the Wearable Backpacks mod apparently allows configuration up to 102 slots (17x6)Edit: sometime after this post, I realized that a Portable Grid from Refined Storage (even with just a 1k storage disk) works well for transporting seeds.
-
Are you asking for the ability to fully analyze planted crops, like the GT portable scanner? I think that was discussed in an earlier suggestion thread. If you're talking about how the existing cropnalyzer shows the crop name and discoverer, but the harvested seed bags still show as "unknown seeds" (as if they haven't been scanned at all), I might file that as a bug.
-
GregTech 5 Unofficial has a scanner that can batch-scan IC2 seed bags, but that's only for 1.7.10, and the mod makes a lot of other changes. I also came across [IC2 1.109] SeedManager v3.0.2 - Taking the hassle out of agriculture. but that hasn't been updated in 6 years. I'd like to be able to do this in MC 1.12.2, whether it becomes part of IC2 itself or an addon. Having to feed each seed bag through the Cropnalyzer 4 times gets annoying quickly.
-
albijoe that site is apparently blacklisted by StopModReposts. Also, I looked at the CurseForge page earlier (I haven't played the mod myself), and the comments mention that the 1.12.2 version is currently a closed alpha (i.e. not publicly available yet).
-
(assuming those get directly integrated into the planner to determine the behaviors)
Actually, the planner has its own classes to represent the reactor components, which has a few advantages:
1. I can easily add functionality not orignally covered by the original items. (such as collecting statistics on how much hull heating or vent cooling they provide each second)
2. I don't have to worry about the overhead from things like inherited methods from net.minecraft.item.Item that handle world/player/container interactions, when said methods are completely unnecessary to the planner.
3. I don't have to figure out how to make sure certain Minecraft libraries are available for the planner to use.
-
First off, sorry if this is in the wrong subforum, I really had no idea where to put it.
Personally, I'd suggest either "Pending Addons" or "Addon Discussion". I haven't decided whether I'd use this mod myself when it becomes available for download, but I will want to be able to find the thread so I can add the components to my planner. Also, I hope it will be okay to include the assets for said components in the planner when the time comes.
-
Yes, excellent examples. Obviously my "predictions" idea needs some refinement if I'm to implement it at all (which I'll admit is becoming less likely now). I get the impression you're not a programmer, otherwise you probably wouldn't have even suggested this:
3. Simulate my manual calculation (The most complicated but accurate if done correctly)
But perhaps now you're getting more of an idea how difficult that would be, especially when it comes to generalizing it.
-
I gave this a bit more thought, and I can show the following details for a simulation (and possibly as predictions):
1. Hull heating (from fuel rods with no heatable neighbors)
2. Component heating (from fuel rods that do have heatable neighbors)
3. Hull cooling (how much the hull is (or can be) cooled down by various components - there are currently 2 types of vents and 3 types of exchangers that can do this) - in some cases, the "used" hull cooling might be less than the "possible" hull cooling.
4. External venting (how much components are (or can be) cooled by vents with the heat transferred to coolant for a fluid reactor, or completely out of the reactor (for an EU reactor)) - this can fluctuate, especially when using exchangers, but for a given reactor tick, 2x this gives the HU/t of a fluid reactor (40x to get it in HU/s).
Of these, my planner currently shows peak external venting (which might not be such a useful metric, but related to 4) out of possible external venting and max total heating (1 and 2 combined).
Here's my idea for calculating predicted values of those, which I'm hoping will match up with your manual calculations (never mind the "reliable" part for now - "reliable prediction" is kind of an oxymoron, right?
) :1. Calculate hull and component heating.
2. Calculate hull cooling.
3. Calculate best-case exchanger transfers (i.e. ignore the possible fluctuations and take as much as the "component exchange rate" will allow from any neighbors heated during steps 1 and 2, then transfer as much as possible to any neighbors that haven't been heated)
4. Calculate external venting.
All of these would be based on initial setup, without iterating for multiple reactor ticks, and ignoring possible component breakage (the latter two are where the simulation comes in).
As far as what I meant by "universal", consider this crazy design:
020000000000000000000000000A00000000000A0A0A140A0A0A000A141414131414140A000A0A0A140A0A0A00000000000A00000000|esn
I think the idea I described above for calculating predicted values would have trouble with this one.
I hope this doesn't turn out to be an NP-complete problem. -
Why do you call that "Predictions"?
1. What do you mean "fed to the reactor"? Do you mean raising the hull temperature? Or does it include heat fed to the reactor and then pulled out by components?
Because these are details that can be predicted ahead of time by the program (without actually running a simulation). As far as "fed to the reactor", that means it raises the hull temperature (regardless of whether said hull temperature subsequently gets reduced by components before a player would see it in-game - that's where the second prediction detail comes in)
The example that you gave is caused by the reactor ticking algorithm. Since the reactor ticks from the left to the right, the left fuel rod dumps 4 heat into the reactor, and then all pulled out by the reactor heat vent. Then, the fuel rod next to it dumps 4 heat into it again, and left the right vent idle. The vent can only vent 5, so heat stacks up by 3/s.
In that case, I would say that actual used cooling is 5, with a probable exception in the tick when the left vent broke.
Yes, the ticking algorithm is involved, and in this case I kind of agree about actual used cooling, but it's 5 of a theoretical 10 vent cooling. Seems that example kind of turned the tables on me, though this one runs long enough that average HU/t output of it as a fluid reactor can be used for calculating an estimate of that - also, CSV data claims this design as a fluid reactor will output 360 HU/s very briefly at the moment when the left vent breaks.
That might actually be a bug, but if so, it may be quite difficult to track down, and I want to try the design in-game first (to make sure it really is a bug).Edit: Brief 360 HU/s confirmed in-game.Also, you might have done the math wrong. "Reactor will explode at 3666 seconds." How did you get 2084 sec?
Key word from my post: more. I said 2084 more seconds, because without the right vent, the reactor will explode at 1582 seconds. 3666 - 1582 = 2084.
