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 126.96.36.199). 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 v188.8.131.52
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.
(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:
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.
Could you please upload the archived reactor planner? Somehow I can't open (download it from) that website.
No, because A. I can't find the licensing details for Talonius's planner, and B. Chocohead already attached a copy to this post.
Also, my native language is not English so I am very likely to have some problems trying to explain exactly what I mean without misunderstanding. Therefore, I'm going to clarify again - to my understanding, it means the usable ability of venting heat.
I don't know what your native language is, but if there is someone else on the forum who speaks the same language, perhaps having them act as an interpreter might work better, because I'm sorry to say that this doesn't clarify anything for me.
However, perhaps part of the confusion comes from ambiguity in what is meant by "venting", which the IC2 Wiki may be partly to blame for - see the below taken from https://wiki.industrial-craft.…tle=Overclocked_Heat_VentQuote
Self Venting Rate refers to the amount of heat the Heat Vent will vent from itself per reactor tick
Hull Venting Rate refers to the amount of heat the Heat Vent will remove from the reactor hull per reactor tick
Component Venting Rate refers to the amount of heat the Heat Vent will remove from adjacent components per reactor tick
The heat handled by Self Venting and Component Venting is transferred to coolant for a fluid reactor (or just eliminated for an EU reactor), but the heat handled by Hull Venting is stored in the component (at least initially - some of it may be self-vented, component-vented by neighbors, or transferred by exchangers), so I dislike calling that "venting".
I think I can add a "Predictions" tab with the following details:
1. Heat generated by fuel rods (split into how much is fed to the reactor vs. how much is fed to neighbors).
2. Heat pulled from the reactor by various components.
3. Theoretical maximum venting (potentially into coolant).
Actual used cooling is harder to predict (or at least I haven't thought of a reliable, universal way to make my program do it) - perhaps this example will help to demonstrate:
Until the left vent breaks (at 333 seconds), the right vent will be idle, but afterwards it will operate at full speed and give the reactor 2084 more seconds before it explodes.
Since your complicated design only feeds heat to the reactor, I thought that replacing the rods and reflectors with heat-capacity plating and starting the reactor with really high heat would allow the max HU output to be used to calculate the actual used venting, but that gave 1282 HU/t, which would correspond to 641 used venting, while simulating it as an automated reactor showed your manual calculations of 640 venting per reactor tick were spot-on - it ran for at least 357 cycles (based on components replaced) without going below 6000 heat or over 7280, and average output was 1280.00 HU/t. I'm not sure how it peaked at 1312 HU/t (26240 HU/s) output though (at about reactor tick 315 according to CSV data). Also note that the following components continued to have fluctuating output during the cycle: Advanced Heat Vent (R0C3), Advanced Heat Vent (R0C7), Component Heat Vent (R1C3), Component Heat Vent (R3C1), Component Heat Vent (R3C7), Component Heat Vent (R4C0), Component Heat Vent (R4C4), Component Heat Vent (R4C6), Advanced Heat Vent (R5C0), Advanced Heat Vent (R5C4), Component Heat Vent (R5C7), Advanced Heat Vent (R5C8)
When I asked for input from "others", I kind of meant besides you.
However, those are some good examples for helping me gain further insight into what the old planner meant by "vent cooling". For that first example, the old planner shows cooling of 0 (5), though I'd need to search decompiled code to find the logic it uses to determine that the component heat vents should be treated as having 0 vent capacity in this design. If I move things up and place a dual uranium fuel rod below the reactor heat vent (and use pulse configuration to make sure it stops before that vent breaks):
The old planner shows 17 (17), matching my planner. Is that what you meant by "changing components"?
The second example shows 0 (148) in the old planner, and remains the same if I remove all the component heat vents, which gives me a clue where to look.
The third example shows 0 (80) in the old planner.
On the other hand, one could argue that Talonius's planner is obsolete and shouldn't have to be matched exactly. Based on your own words:
I think the key word in Omicron's post is "capacity". Here, it should mean the ability of venting heat.
and https://wiki.industrial-craft.…title=Component_Heat_Vent a component heat vent can reasonably be considered to have vent capacity of 4 per coolable neighbor (other vent types, exchangers, or coolant cells) - it has the "ability" to vent that much heat, even if it never uses it.
Edit: looking at the more complicated design you posted on GitHub:
I think I'm starting to understand your manual calculations and what you want "effective vent cooling" to mean, but trying the closest approximation I can get in the old planner ( 21p7gjnnw20e91es8hy61d1c8mbcxzt9gitwjy3qlgkgbzr5pmf5mgmenu0v2cwebkf9i6v3l3tfcw0 ), either the "vent cooling" shown meant something different than what you're looking for or its calculations are buggy - at 0 initial hull heat, it shows 451 (608) vent cooling, and at 8400 initial hull heat, it shows 644 (664) vent cooling.
Feature request: display the cooling system's total heat removal per second capacity and the fuel rod's total heat per second generation as separate values.
After some discussion in https://github.com/MauveCloud/Ic2ExpReactorPlanner/issues/36 I have realized I don't fully understand what these meant in Talonius's old planner (or maybe I did, and I've forgotten). Do others here (especially those that have looked at the source code) think my planner calculates these values appropriately? If so, how can I clarify what they mean? If not, how should they be calculated instead and why?
Also, for the 1 bug/feature 1 issue thing, do you really want 20-30 issues being opened in a single day?
If you really still have that many ideas, go for it. However, I hope you won't be too upset if I mark some of them as "wontfix" (though I'll try to provide justification for that)
Is reactor output added to the CSV output? It seems that I can't find it.
Sorry, I guess that one slipped my mind. I plan to take a few days break from working on the planner, but then this can be the first change to go into the next release. I am starting to see why some developers insist on one bug/feature per issue - having a bunch crammed into one issue makes it too easy to accidentally skip details like this.