I doubt that. I've put debug statements in the initialization code for the Laser Drill - it specifically can not generate in that manner. Unfortunately you're asking me to prove a negative, and that's not logically possible. I can set up 50 creative-powered laser drills and run them for weeks and no iridium will ever generate because it isn't possible, not because we haven't waited long enough.
However.
If I do fix the initialization for the laser drill, like I mentioned above, using a patched MFR jar, then I get a nether iridium to pop out in the first hour of running a creative laser drill (with 6 white foci). In fact I get two or three after 90 minutes. This is consistent with the weighting probability for it in the source.
exactly, not to mention 1 drill may take 1-3 weeks, so testing with several hundred drills given days of operation? if we presume one drill can pull one ore every 8 seconds, three real world weeks(1,814,400 seconds) of continuous operation would net 226,800 ore samples. i could be incorrect, but i see no special checks restricting the chance to only specific days of the real or minecraft calendar, or forcing the chance to only occur with a certain precharger count, or only at a specific height(only an efficiency factor affecting power consumption and/or speed).
so rationally massive parallelization should suffice.
by all means if this is incorrect somehow, set me straight. this isn't about being right it is about discovering why this test is failing enough that the relatively small percentage of users who ever bother with the forums have noticed it, in more than one user case, which in turn indicates the problem extends further.
to that end a lack of success with a sample size larger than your three week max precharger theoretical drill has been done, in some cases more than once over. no dice in 2.1.13, no dice in 2.1.14, no dice in 1.0.0 or 1.0.6.
in short, here's the offer. suggest some alterations to the test methodology, suggest an alternative test, or ask for any relevant information you think may help. i am trying to be transparent as to methodology, and aid in narrowing this down.
we have two groups where the results are differing. if it is on the affected users ends in some way so be it, but let us find it so we can forewarn and forearm other users or maybe even prevent the interaction entirely. if theres any data we might have that could help, please ask.
you want the map used for testing previously or the new one in progress mentioned below? let me know and i'll host it. this isn't like a simple crash where there's a nice clean log to go from.
you want me to repeat the test with every lwgl or java version from here to hell and back, fine, if that'll help. i can retry the test with several linux variants, xp, vista and win 7 if you think it may be os related.
the fact you tested 2.1.12 succesfully is usefully actionable data for whittling things down. was that 2.1.12 server as downloaded, or with the minetweaker fixes, or with your minetweaker fix and the manual edit from earlier in the bug thread??? it seems ridiculous to have two groups trying to solve an issue not sharing relevant data.
i am currently laying out at height 199 a 6x6 chunk region of single precharger per laser drill rows, to feed into an me system. i am going to repeat setting the laser drill precharger activation cost from 250mj to 1 mj, and allowing chickenchunks to work offline indefinitely for the purposes of the test.
i have pulled a fresh 2.1.12 server download and just need to know if your tests minetweaker fixes state so i can run this sampling as closely as possible. if you believe the precharger change or chunkloader change will affect results, tell me and i will run it without said changes.
i am laying it out
not in the ssp map copied to the server instance, but using the map from the server download this time.
not that i *believe* it is relevant for the purposes of the test given i am using the server download, but the ftb launcher version is 1.3.9 and
not using the new optimization arguments for fast computers prog added to the launcher. my lawful minecraft username in game is steelblacksky, my primary platforms main host os is windows 7 home premium 64 bit,and primary platform itself is an asus g53sw-a1 notebook(12gb ram, 2x 500gb hdd, gtx460m, core i72630qm. in practical terms the 15" version of soaryns machine).
if the napkin math is correct i should be getting approximately 5 rows of drills per chunk, 6 chunks across, 16 machines per row per chunk so 480*6 = 2,880 drills, one spare row per chunk totals up for an extra 6 rows which fits a further two lines of drills+prechargers (480 *2) for a sum of 3,840 drills for the test setup this time. i will run with every drill using a full 6x white foci.
by my further napkin math this system should eclipse the output of that single aforementioned drills 3 weeks output well inside an hour(59.0625 cycles of the whole rigs' lasers to pull 226,800 ores, so even if they take 32 seconds per drill cycle vs 8, that target should be hit in ~31.5 minutes).
i'd be merrily happy to see the ore pop out even after an astronomical sample count pull this time, even more so for relatively early into the test run, at least that'd give some footing to start finding the cause for when it doesn't. le sigh.
is there anything aside from the possible tri state of the minetweaker fix for 2.1.12 i should add or address for the test case before i set it to running for days? i think this may be relevant as it(minetweaker) was specifically breaking on the renamed mfr radius upgrades.