Posts by MauveCloud

Quote from willis936

For a compact steam furnace you need multiple conveyor belts pulling into the same item pipe.

Could you please explain this? Also, which kind of item pipes are you using? For all I can tell, it could be the item pipe's capacity limiting you from doing what you want, rather than the conveyor modules.

Edit: I also came across the sentence below in the Wiki page for item pipes, which could be what you're running into:

Quote from Item Pipe Wiki Page

After transferring the items, all slots in all pipes items traveled through will lock up for 1 second.

You want the math? okay:
IC2 generator gets 4000 EU from one piece of coal/charcoal, and outputs 10 EU/t, so each piece only lasts 20 seconds.
GT hp coal boiler burns one piece of coal for 160 seconds at max temperature, and outputs 15 mB/t of steam, which using an LV turbine becomes roughly 5 EU/t by default, for a total of 16k EU per coal.
IC2 geothermal generator produces 20000 EU per lava bucket at a rate of 20 EU/t, so a lava bucket lasts 50 seconds.
GT hp lava boiler at max temperate uses one lava bucket every 500 seconds, and outputs 30 mB/t of steam, which using an LV turbine becomes roughly 10 EU/t by default, for a total of 100k EU per lava buckett.
(I think technically the LV turbine would output intermittent pulses of 32 EU)

Edit: somewhat unrelated, but I just noticed that depleted thorium rods have identical textures to their non-depleted counterparts.

2000 cycles? That's strange. As far as I can tell, I set it to simulate up to 5 million reactor ticks, which if I'm not mistaken is 100 cycles for thorium rods, 250 for uranium rods, or 500 for MOX rods. I'm not sure how to count the cycles for a reactor that uses a mix of two or more fuel types, though. Edit: I noticed one possible source of confusion using your design: it says 1996 items are replaced in that duration, but since you had 4 dual mox rods, that's really only 500 cycles for them.

As far as replacing more than one component type, how would you automate that? I am not aware of any mod that would be able to do that properly. If you're manually replacing components, it seems to me that the simple cycle simulation should be sufficient to determine what it would take to get infinite cycles out of it (in terms of which components would need replacement and how long to let it cool down for).

For the pulsed cycle, I suggest you start by running it in the "single cycle" mode and look at when certain components (or the reactor itself) break, and start with the on pulse being a second or two less than that, and maybe the same duration for the off pulse. Then you can tweak them up or down to increase performance or safety. I don't know if Talonius's planner properly handled the heat exchangers, because I don't entirely understand them myself (as you might recall, I had to ask for permission to adapt the IC2 code for them rather than going by Wiki descriptions), but they make it impractical to use anything but a simulation run to predict when components will break.

As far as Talonius answering me, here's what happened: he hadn't replied to my private message, but I noticed his profile had a link to email him, so I tried that a few days ago, and he was fairly quick to respond (by email) with an explanation of his codes. If you look at post 68 in this thread, you'll see that I've already added support for codes from that planner.

Quote from Mine_Sasha

+ the lappack function can be remplaced by the charging ( aroma like ) batteries in your inventory

Not a totally suitable replacement. Even the charging lapotron crystal is slower than an energypack. When using a mining laser with it but no energypack, I often had to wait for the laser to recharge, even though I was using it in horizontal mode, which is supposed to use 1250 EU per shot, so at tier 3 power of 512 EU/t, it should only take 3 ticks to recharge, and I'm fairly sure I had a longer delay than that between shots. On the other hand, the charging lapotron crystal is more versatile - my GT5u chainsaw and drill (both LV) can recharge from it but not from the energypack. Same for an AE2 portable cell.

Quote from Chocohead

Iridium is really easy to find as long as you find a dungeon.

Yeah, like dungeons are that easy to find... And even when they're found, the chests don't always include iridium.

Quote from Pyure

I don't think it's necessary. But if you feel you gotta do it, it should work both ways:
* If a high voltage battery is discharging into a lower-tier machine, explosion
* If a high voltage machine is discharging into a lower-tier battery, explosion (smaller?)

Seems to me that for the second case, there should be some chance of the machine surviving, and maybe the battery explosion shouldn't be immediate. (after a few seconds is okay, though)

Quote from MauveCloud

Also, to do what you suggest, I think I'll need to overhaul my planner to have three simulation types (with a button for each):
1. Single cycle (like it does now by default: keep going until all fuel rods are spent, and the heat levels of all components have stopped decreasing (checking for no more changes to heat didn't work because of the quirks of exchangers))
2. Pulsed cycle (with durations for the on pulse and off pulse, and maybe Nuclear Control conditions - I haven't actually used that mod before, so I will have to look into it more to find out what conditions it can set up; I know it can toggle a redstone signal based on reactor temperature, but I wouldn't be surprised if there's more to it than that)
3. Continuous automation run (with depleted fuel rods, and optionally other components, replaced as needed, with a time limit (e.g. 2 million reactor ticks) to make sure it can eventually stop the simulation)

The new simulation types are now available in v2.0.

Also, the status colors now appear in bands above each component, and there are small "i" buttons at the top right of each grid position to get more information about said components.

I've put up v1.4.2, which makes the simulation only run when the button is clicked, rather than every time a component changes, accepts codes from Talonius's planner (and gives a warning if that code includes obsolete components), and has buttons for copying/pasting the code.

Quote from SpwnX

Ehm... a small icon on the top right corner of the component?
When you mouse over it, it would show better information.

A small red symbol that when you mouse over it would say "Component melts X seconds after the start of the reactor cycle".
A small yellow symbol that when you mouse over it would say "Component uses X% of its total cooling capacity"
A small orange symbol that when you mouse over it would say "Component takes X seconds to cool down after a reactor cycle" [That is what the orange BG represents, right?]
Those symbols are placeholders, use something else.

Instead of colored symbols, what about a small "i" button up and to the right from the component button in the reactor grid that activates a tab in the area below to show information about the component (instead of trying to fit extra details into the tooltip) and what happened to it in the most recent simulation? It would be inside a border to make it clear which component it is associated with, though I am open to suggestions for what the border should look like.

Quote from Shadowlife

So I just realized that the latest IC2exp version for 1.6.4 is 397, but from the version number (2.0, not yet 2.1) build 402 should still be 1.6.4.
Is that the case? Or just a late switch in version numbers?

In answer to this question, I looked at the change log, and build #398 lists that it was ported to 1.7, and build #403 lists a fix to the version number.

Quote from swarmski

In regards to the deuterium/tritium fusion reaction and making it self sustainable...what are people using for the following

1) How many centrigues/Electrolyzers to keep constant source of input
2) I assume these machines being 32EU variants wouldnt be a problem (just needing more?)
3) I've read that i can use a Processing Array to minimise the footprint of the machines....is there a wiki site i can read up on this?

I haven't actually tried any fusion reactors, but I think I can still at least partially answer your questions:
1. By my calculations: about 32 MV centrifuges, 16 HV, 8 EV, or 4 IV to make enough tritium from deuterium to keep it constant (125 tritium per 16-tick fusion reaction); about 125 LV centrifuges, 63 MV, 32 HV, 16 EV, or 8 IV to make enough deuterium from hydrogen to use for making tritium; add about 25% more to cover the deuterium side of the D-T reaction; the number of centrifuges/electrolyzers you need to get enough hydrogen depends a lot on which recipe you use - there are 2 centrifuge recipes that produce hydrogen gas and 16 electrolyzer recipes. If you want to electrolyze water for a constant supply of hydrogen to centrifuge for deuterium and tritium, that will take 118 (LV)/59 (MV)/30 (HV)/15 (EV)/8 (IV) electrolyzers.
2. The recipe for centrifuging deuterium to get tritium calls for 80 EU/t, so you need at least MV centrifuges for that, and if you're electrolyzing anything other than water to get your hydrogen, you'll need an MV-tier electrolyzer.
3. Here: http://ftb.gamepedia.com/Processing_Array

In that case, see attached.

Crops textured: Blazereed, Brown Mushrooms (GT version), Coppon, Corium, Corpseplant, Eggplant, Enderbloom, Meatrose, Milkwart, Red Mushrooms (GT version), Slimeplant, Spidernip, Tearstalks, Tine

GT Crops left with original textures: Argentia, Bobsyeruncleranks, Diareed, Flax, Indigo, Liveroots, Oilberries, Plumbilia, Steeleafranks, Withereed

Just in case others see this post, without reading the rest of the thread:
Disclaimer: these textures are not my work. IChrisI posted them a few years ago for a mod that effectively became part of GregTech, I just adapted them to be usable with GT5 (and possibly GT6) for Minecraft 1.7.10.

I've just come across some 32x textures that should be applicable to some of the current GT crops once cut into separate files:
[IC²1.112]BrainTech Agricultures Datachip Package v1.7.1 [Now part of GregTech!]

However, since "IChrisI" is apparently no longer registered, I don't know how to ask for permission to release it as a mini resource pack.

Also, I didn't know what the plant to the right of the meatrose in that image was supposed to be, but apparently it's corium, which was originally distinct from corpseplant, unlike recent versions of GregTech 5 that use identical textures for corium as for corpseplant. I don't know when that distinction was lost.

Quote from willis936

the ability to skip LV altogether with TiC aluminium

FWIW, just being able to make aluminium ingots without an EBF isn't really enough to "skip LV altogether" in GT5/GT5u. An assembler is still required to make the circuits for MV-tier machines.

Quote from Speiger

why not instead adding a few extra points to the total number and let a Random pick the a number and then which one is the closest to it... That would be way easier and also handle all crops... (that have points)

I don't really understand what you're suggesting, but the current code is an application of the standard binary search algorithm, so I'm fairly sure it already handles all crops, and will generally have better performance than the sequential search that was used in builds 677 and earlier.

That's wrong on at least two points:
1. Since the array is size 24 when not using other mods that add crops, it starts with (0+23)/2, which equals 11 (integer division truncates, it doesn't round, at least for positive integers - behavior of dividing negative integers can vary between programming languages). This one's a minor nitpick, though.
2. you seem to be missing the point of the if statement - sometimes it increases the min (technically to 12 for the first iteration) and searches higher next (index 17), but other times it decreases max instead and searches lower next (index 5 for the second iteration in that case).

I see no mistake there, except possibly in your understanding of what the code is doing. The previous loop (which you didn't include) made sure that the values in pointArray are non-decreasing as the array index increases. On each iteration, depending on the value previously obtained for "randomNumber" and the value in the middle of the currently-searched array section, either the first half or the second half of the array section currently being searched is excluded from further search. What are you seeing as a mistake?

Quote from Speiger

Well since it is sortet first by ModName and then Crop name it does effect it really because a G comes before a I so the list which you are using is completly differend then i told. Try it out with Vanilla IC2 Exp...

I briefly tried using IC2 exp build 746 with no other mods (though for the sake of my eyes, I did use a couple of resource packs), and starting with the "sugar cane" item, I put them in a checkerboard pattern (except for the center, which had water). Once they grew, I set up crossbreeding. I mostly got reed, but on the first try, I got 1 pumpkin crop and 1 stickreed crop. I crossed the stickreed with reed, and got something that started like wheat. It might have been Hops instead, but I wasn't interested enough in proving you wrong on this point to continue. If you can provide more specific steps to reproduce in-game, I'm willing to try further, though.

Quote from Speiger

Well not almost it is impossible. IC2 Has 24 crops. the first 12 he is skipping. If the 13th is not the one you are searching for then he skips a couple others...

Also addition. As long this bug exists i block every version of IC2 Exp that will be higher then 677. (Until it get fixed)

I think you're misinterpreting the decompiled code. It looks to me more like a binary search for the crop with a result range that includes the number returned from the random number generator. So technically yes, it initially skips the first half of the crop list, but then depending on the ratios and the random number it got, it can go forward or back for the next crop to check.

Quote from Speiger

Yeah i do not have the knowlege about that. But can you calculate that really fast? I mean it takes for a 4x crop breeding (4 crops in a breed) about 16-32 seconds to calculate all possebilies(with a Extra Thread) and that is still very much time... And i do not want to increase it moew because the loading of it starts almost when MC has finished loading..

Sorry, this might be where the confusion came from: I was talking about simple 2-crop crossing, which I presume is all that Immibis's mod covered. I'll grant you that 4-way crop breeding is too complicated for calculating percentages to be practical (especially since iirc, there are even probabilities involved in determining which parent crops to include in the weight calculations, while with 2-way breeding it's either both included or wait for another attempt).

Quote from Speiger

I meant not corretly. To explain: The Current Crop Breeding Skips about 75% (+-20%) of the Crops while Breeding. The First Crops (Wheat, pumpkin, melon, the colorflowers, reed and Sticky Reed) are not even breedable because of that bug... My Nei Plugin says something differend here because i hardcoded the Exp Breeding Code into it... and that part that is causing that is after the Point Calculation...

I have personal experience that contradicts that: I've successfully bred stickreed (both as a result and as parent crops) and several of the others you listed (though mostly as results) in more recent builds. I'll admit I've been using GT5u, but I don't think it changes the underlying functionality of crop breeding.

Quote from Speiger

Well i used a random generator (random.org) to gain a random number and got 544 out: Now we are at a point where you can not calculate something.
So we have the 544 base and run through the crop list.
is 544 smaller then 35 points of the hops? Nope
So now we remove the 35 points from the 544.
New value is 509
now we check on pumpkin.
Is 509 then the 500 points of pumpkin? no.
Now we remove the 500 points of the pumpkin.
let are 9 points.
Next is cocoa.
Is 9 points smaller then the 10 points of the Cocoa? yes
so we pick this crop.
Cocoa is the result.

Do you think it is still calculateable?

Display More

Emphatically Yes!

Going by your description above, when the random number generator gives 0-34, the result will be Hops.
For 35-534, the result will be Pumpkin.
For 535-544, the result will be Cocoa.
For 545-1044, the result will be Wheat.
For 1045-1064, the result will be Reed.

And since each possible int from the random number generate has equal probability (or at least close enough for most purposes, and assuming you don't have prior knowledge of the exact state of the random number generator), you can divide the weights by the total weight to get a percent chance.

Quote from Speiger

Jup thats true but that makes it so impossible to make a percent chance out of it...

How exactly does that make it impossible? I say that's what makes it possible.

Quote from Speiger

Edit: After Exp 678 it is no longer possible to breed crops corretly together (Plugin works after that version no longer correctly waiting for IC2 to fix it, i gave that to the IC2 Team...)

The crop breeding itself works as of about build 688, though for all I know the changes in build 679 might have broken Immibis's plugin.

Quote from Speiger

I do not think so. At least i can not imagine how you can calculate a which crop generates which number... because it is always changing... Else you would gain not a random one...

I beg to differ:

Quote from Java API Docs

public int nextInt(int bound)

Returns a pseudorandom, uniformly distributed int value between 0 (inclusive) and the specified value (exclusive), drawn from this random number generator's sequence. The general contract of nextInt is that one int value in the specified range is pseudorandomly generated and returned. All bound possible int values are produced with (approximately) equal probability.

As a simplified example, if you have only 3 possible results for a certain crossbreeding combination: crop A with 20 points (by your system), crop B with 10 points, and crop C with 5 points, you can know that there's a 57% chance of getting crop A, a 29% chance of getting crop B, and 14% chance of getting crop C.

Quote from Speiger

Partly True. It picks the Number once for every breeding try. Also it get Modified for every crop that is to low on points.

That's different from calling the random function again. Each possible result from the initial call to the random number generator can be mapped to a specific crop.

Quote from Speiger

Then you are wrong... Because the Percentage chance changes every time he tries to breed!
Why? Simply he collect all possible points together (which would make the 100%) and then pick a random number between 0 and that max number.
Then he loops through the Possible Crops (based on how they got registered in IC2) and pick the first one that has a higher points then the random generated number.
(if it is lower it decreases the random number by the points the crop had).
How can you calculate that? Because every time he tries it you gain another result...

That's how a weighted random selection works. It only picks the random number once (outside the loop through the possible crops), and for a given pair of parent crops, the weights of the results are always the same, right? The random number generator has a flat distribution (unless you use nextGaussian or something), so you can determine probabilities.