Posts by Player

The png files in your texture pack are very efficiently compressed, the textures on the GPU are not. Even if it'd fit all into the GPU memory it's still up to the driver how to allocate everything. You could try to run FastCraft 1.6 with a texture pack which has about twice as many large textures for both blocks and items. If this causes similar issues my theory could be verified.

I'm not exactly sure what you are referring to, I'll just assume it's the Recipes class.

The fields macerator, extractor, compressor etc. all share the same interface (IMachineRecipeManager), but each one gets its own instance assigned, i.e. the actual data behind isn't shared.

If you implement your own machine instead of just adding a recipe to one of ic2's, you won't actually need to use the IMachineRecipeManager system. It doesn't do anything by itself, there's always some code required to do the actual processing, which you can just hard code in your machine's updateEntity() override. Think of IMachineRecipeManager more as a database storing the various input->output recipes a machine offers.

The IC2 infrastructure to build machines more readily isn't exposed via the API and wouldn't be that easy to use anyway. Out base class for normal machines is ic2.core.block.machine.tileentity.TileEntityStandardMachine and the normal implementation of IMachineRecipeManager is ic2.core.BasicMachineRecipeManager, but those have a lot of code and functionality not needed for addon use.

So to have your own machine you should start quite a bit lower -> create a block, a tile entity and later on container+gui. There are various examples available for Minecraft Forge. You can use ic2.api.energy.prefab.BasicSink as the easiest way to eventually hook things up to the ic2 energy net.

Hmm it looks like your texture pack is massive with 394 512x textures. It just barely fits into a 16384*8192 atlas texture, 1 more 512x texture and it'd have to double. That's just for the block textures.
FastCraft duplicates the texture atlas for double buffering which apparently exhausts your GPU memory, making the driver re-upload the texture every frame.

I'll add a config setting to control the duplication and probably some heuristics for the default behavior, it's obviously better to optimize for memory with very little GPU RAM or very high resolution textures.

Edit: LloydSev's case seems similar.

How's the attached build?

EBrarian i need your fc_debug.txt from that crash.

I think it's about time to remove it.

And another debug build for everyone with crashes or corruption-like issues. This should already take care of some non-standard texture handling by mods like jabba.

That's a rounding issue, I'll look into it.

Version 1.8 should fix this crash.

Please try to reproduce the crash with the attached version and send me the fc_debug.txt from after it crashed. It should be in your game directory, next to options.txt.

Version 1.4 fixes interacting with fully unidirectional RF blocks, the i/o detection is now conservative.

New version, should fix another heavy code path sometimes causing heavy freezing. This one may be a bit unstable, thus needs testing

It reduces the lag, you can use it on the client as well to help there, but technically it isn't needed.

CraftGuide is the other popular recipe display mod.

There is the full set of advanced vanilla and bronze tools as well, the drill isn't supposed to render those completely useless. Overall the drills aren't all that expensive and they last forever.

I'll try soon, although some of the optimizations of FastCraft and Cauldron overlap, reducing the combined benefit.

BC 6.1 won't happen until it's released, it's just incompatible with 6.0 APIs.

Actually the multi-purpose machine is to be removed in favor of the simpler dedicated ones.

No that's a performance thing. I'm not aware of any bugs.

I've added support for Factorization Charge (bidirectional) and replaced the polling with a tracking mechanism directly hooking into tile entity loading and unloading.

The FZ turbine currently has exploitable super-linear charge/steam conversion most likely due to a bug. For production use it's currently recommend to change the Charge conversion ratio to yield very little EU or disable charge -> eu completely until it's fixed.