Posts by lperkins2

Aye, but I always just assumed Steve has an evil-genius style shrink ray, so the mass of all that gold gets reduced to a couple kg.

Most of those can go in the fusion reactor for either elemental synthesis or energy production.

It's already known in the release notes, that there are ghost items left behind. It's missing a call to updateSlots() after starting the processing run. If it's not already fixed in trunk, I'm sure it will be soon.

Huh, somehow I managed to miss that with grep, must have miss typed Assembling or something. It was renamed on 2016-04-11 from tungstensteel gear box. It also appears that my server-side localizations file is out of date. Speaking of which, I had to use minetweaker to set the localized names on the server, so that open computers could see the proper names; is there a config I'm not spotting to make the server register the localized names?

Quote from Blood Asp

Updated to GT 5.09.22

Huge Changes:
Added Assembly Line multiblock.
Picture construction and use guide.

Your written description with the picture for the layout is wrong. It lists the block in between the reinforced glass as 'Assembly Line Casing', but from the picture and the source code it's wanting 'Tungstensteel Gear Box Casing', I don't see any reference to 'Assembly Line Casing' in the source.

For anyone having issues, the block id is gregtech:gt.blockcasings2:5

Okay, a couple of things. First you've got debug mode on. You might try turning it off, since it adversely impacts performance, and see what you get. (Gregtech.cfg/general/Debug[1,2])

I'm not certain that this is the source of the problem, as I don't see a way for it to loop infinitely. You should be able to get the stack trace for every thread via kill -3 <pid> (assuming *nix, otherwise you'll need to look up how to make java dump the stack).

Otherwise you could try disabling GT ore generation, I don't see a config for it but I thought there was one. Worst case you could recompile with ore generation disabled.

I see in the log that atomicstryker.battletowers also is doing terrain generation, so it might be a conflict with that. Like I said, I've mostly had this problem from Chocolate Quest. I'd try removing one of the terrain modifying mods at a time until the problem goes away.

Chocolate Quest also can cause serious lag spike issues, but it sounds like it's trying to generate too large of a vein or something. The most effective thing might be to hit it with a java profiler and see what it's actually thinking. You could compile gregtech with a stack trace print in executeWorldgen:91.

What other mods do you have that affect terrain generation in the nether? I've run into problems with CustomOreGen before, also, if you can give us the full stack trace where it is spamming the log we are more likely to be able to help.

I just reimplemented the overclocking balance changes in a clean fashion and pushed them to my fork on github. There's also a build (with RF input for machines) at http://alestan.publicvm.com/bin/gregtech.jar

The new overclocking system is disabled by default (MachineStats.cfg/B:newOverclocking_false) I've got it up and running on my server, if I don't find any issues within the week, I'll see about making a pull request for it. In the meantime, if anyone wants to look it over, try it out, and give feedback, that'd be great. Oh, and if someone wants to make an overclocker cover icon, that'd be awesome. I tried getting it to just use the ic2 overclocker icon, but it doesn't seem to work right. Otherwise I'll find some time this week to make one, but my artistic skills are sorely lacking.

There's also the fluid reactor, which has a page on the ic2 wiki. Basically it's a normal reactor with a reactor pressure vessel around it, and filled with IC2 coolant. When it runs, it outputs hot IC2 coolant, which you can use to drive a steam turbine or stirling engine.

With at least some of them you can, not that you get more energy out than you put in, but I suppose it might make an okay energy storage and transport system... I have some ideas for reworking the fusion system in general, which involve using helium->helium plasma to cool the reactor, but I've not worked out the details yet.

Quote from Blood Asp

Can you make that a PR on the github? Planned to add that long ago but did not find time till now and coding something that already exists is unnessary.

Also something i had planned long ago and would like to see a PR about this.

There is a config option for that because of the old foresty version. No need to code that.

Sure, I just created a pull request for the advanced miner fix, I don't know how to make additional changes to my repo without them getting included in the PR, so I'll add the plasma change once this one is dealt with.
As for the bees, it's an old patchset I wrote for GT5 and have just reapplied with the move to GT5U and with each update. I hadn't checked if it got properly fixed; since it is now configurable, I'm rebuilding it without that patch and will upload the bee-enabled version in a couple minutes.

https://github.com/Blood-Asp/GT5-Unofficial/pull/542

Quote from Muramasa

lperkins2 Any more progress on the machine tier changes?

I think I've got the bugs worked out. I deployed the changed version to my server; so far everyone seems to love the changes and there's been a bunch of machine upgrading taking place. I still have a bit more work to do, just from a code quality perspective. I basically just hacked over the existing algorithms instead of properly implementing the new ones (faster to write when I wasn't sure if it would balance well). That said, it runs as intended.

If anyone wants to check it out and give feedback, that'd be great. Download is here: http://alestan.publicvm.com/bin/gregtech.jar

There are a couple other minor changes to note if you run it on an existing world.

Tool life is extended about 100 fold, unless you abuse the tool (attacking monsters with wire cutters, digging with a wrench, et cetera).

Gregtech machines, batteries, and generators accept and output RF. I'm still working a bit on this: rf cables connect to anything, even if the machine doesn't have any capacity (like an input bus). That problem is mostly cosmetic. It also introduces a hard dependency on the COFH API, since I hadn't intended to publish it and didn't check if COFH is available. You can disable this if you copy GT_MetaTileEntity_BasicMachine.class from the standard jar file into the custom one.

Advanced Miner 2 silk-touches up any ore block (not just GT ones), and then pulverizes them.

Plasma turbines output the cooled version of whatever plasma you feed them, assuming a cooled version exists and there is space for the output.

GT Bees are disabled (conflict with old version of forestry)

Quote from Invincible92

Hi everyone

Before opening a GitHub issue without the further testing in other machines than the transformer, can anyone explain me the config of InputRF (in Overpowered Stuff) what it means?
Does it mean that RF conduits/kinesis pipes/fluxducts can connect and power GT machines with RF or it only allows the connection of RF cables to a transformer in order to be converted to GT EU?

As Blood Asp said, GT transformers will pull RF from RF storage blocks, this includes Fluxduct, since it has an internal capacity, but not Super-Laminar fluxduct, since it does not. It does not make the GT transformer implement IEnergyReceiver, so RF cannot be pushed into the transformers. If you don't mind building GT5U yourself, adding true RF support (either to just the transformers, or to everything) is trivial.

Edit: If you want, I can supply a patch that makes all GT blocks accept RF, I can't supply a build unless you want sundry other changes.

Quote from Sapient

Could you please make pull request in https://github.com/Blood-Asp/GT5-Unofficial with that fix?

Done: https://github.com/Blood-Asp/GT5-Unofficial/pull/526

If anyone wants pull requests or patches for any of the other changes I've made, I can provide them.

Quote from lperkins2

Hm, that should be fairly simple to fix, it just needs to look for a second stack of the same type, which is probably a good idea even if no one likes my solution. I'll see about figuring out how to do that later.

I was right, it was a trivial fix. The processing array culls duplicate item and fluid input types, keeping only the largest stack and tank. Simply skipping the culling makes it move on to the next stack/tank when the first is too depleted. I can provide a diff for just that change if anyone wants it. Also, the players on my server are happy with the rebalance and are actually starting to upgrade their machines. We've identified a few machines that are unlikely to get upgraded, since they are I/O limited to processing a single replicate at a time (autoclave and lapotron laser engravers being the most prominent).

I've not fixed the other multiblocks yet, but the processing array properly scales now. All the multiblocks properly scale now.

Quote from Sapient

This problem is with input slot, not output. Single recipe requires 10 redstone. So 16 centrifuges needs 160. But only one stack are available, so only 6 of them works.

Hm, that should be fairly simple to fix, it just needs to look for a second stack of the same type, which is probably a good idea even if no one likes my solution. I'll see about figuring out how to do that later.

Quote from lperkins2

Hm, that's a good point. Can probably have it buffer the output when the recipe produces more than 64 of something in a single go, but I'll have to think about how best to handle that.

Okay, I have an alpha implementation. If anyone is interested I can make the source and a build available. I ended up not having the higher tier machines cycle any faster than lower tier machines, but they do process larger batches, and have a 5% energy efficiency boost. If the output would be above the maximum stack size, they automatically scale down (and lose efficiency). This particularly affects LV electrolyzer recipes.

I also registered IC2's overclocker upgrade as a machine cover, you can place 4 of them and still power the machine, or 2 with fully automated I/O. Each overclocker upgrade scales like the machine tier did previously (4x power, 2x cycle rate). Between the 2 overclocker upgrades and an IV machine, LV recipes run at 20x base speed instead of 16x, and consume 64x the energy. For processing single items at a time, they consume 320x the energy of the unoverclocked LV machine, so are only suitable for bulk processing.

Quote from Sapient

We already have problem with multiplying input. Processing Array with centrifuges cant process redstone with full efficiency
because of limitation of stacksize.

Hm, that's a good point. Can probably have it buffer the output when the recipe produces more than 64 of something in a single go, but I'll have to think about how best to handle that.

So, there's been discussion previously about how to encourage players to upgrade the single block machines instead of building massive lines of duplicates. These discussions usually have one faction arguing to have all the tiers be the same efficiency, by increasing the speedup from 2x to 4x, which is countered by another faction pointing out that LV recipes would then process at 256 times the basic speed, instead of the 16x it is now, which would be rather ludicrous. The idea of making the power scale at 2x alongside the speed increase is sometimes mentioned, but dismissed as not practical to implement. It's also been suggested that the pollution mechanic can encourage upgrading, by making higher tier machines less susceptible to pollution, but this makes players choose between more power efficiency and convenience rather than actually encouraging upgrading (just spread your thousand LV machines out more, and chunkload a bigger area).

As a server maintainer, I've got a vested interest in encouraging people to upgrade machines, since (ceteris paribus) fewer machines means less server load. The processing array helps with this a lot, since it takes 192 LV centrifuges down to 12 processing arrays, but would only take 1 IV-filled processing array, if it wasn't disastrous to the power usage.

Since I was compiling the latest GT5U anyway, to make some minor changes (tool damage / use), I decided to take a look at the meta tile entity that controls the single-block machines. At first I was thinking of just reducing the power scaling rate (isn't actually hard, just requires a separate variable for tracking the number of times to apply the overclocking multiplier), but then I came up with a different idea that might be of interest.

Instead of increasing exponentially, increase linearly, both by increasing the number of items processed at once and by decreasing the time taken. Also, don't calculate the power requirement based on the number of items being processed, so higher tier machines must be kept full to benefit. Specifically, a 32V 100 tick recipe in a MV machine would draw 128 EU/t for 50 ticks, and produce 2x the output, from 2x the input. This is the same efficiency as an LV machine. The same recipe in an HV machine would draw 256 EU/t for 37 ticks and produce 3x the output. In each of these cases, the energy required is right around 3200 EU (slightly less for HV+ since the number of ticks is rounded down), but if only one item is available to process, it jumps to 9500 EU / item for HV. Then overclocking covers could be added to let a machine work faster and drop the efficiency to stock levels.

Anyway, I'm not done implementing it yet, and I may make adjustments once I see how it actually works, but I think it strikes a decent balance between increasing cost and complexity of the machines and increased output.