It is Optifine doing all the shadow handling and FC disables most of its render optimizations with OF+shadersmod present,. I don't know what's wrong, maybe the player gets culled by FC in the shadow pass. I'm busy working on FC2 for 1.12.2, so unfortunately this bug can't be fixed at this point.
A 1.12.2 build is out, see https://old.reddit.com/r/feedt…craft_2_preview_for_1122/
Sampler is freely redistributable as long as its jar remains unmodified.
All your accounts are so new!
Welcome back 
Ideally blocks are placed through the associated item's use action against a solid surface as if a regular player was placing it. AFAIK there's no proper API for automated placement.
Can you provide a copy of the world, configs and mods and instructions on how to reproduce the bug? You can PM if you want to keep it private.
The linear search/list is only for pending tile entities. Pending TEs are TEs that were created while processing another TE until they get flushed to the regular data structures the next tick. Due to the very temporary nature the list is usually empty and otherwise small. TE queries mostly happens via getChunkFromChunkCoords(...).func_150806_e(...) in the middle of getTileEntity(...).
There may be corner cases where the list intermittently grows to a significant size, but I don't remember having seen anything severe enough to warrant a targeted tweak.
The O(1) map lookups involved in fetching a chunk+te are usually the real problem. Mods with lots of neighbor interaction employ caches to limit the impact, the regular lookup is already optimized by Fastcraft. I however can't/don't want to add local caches to arbitrary mods. TileEntitySteamHeater could check its heaters only every n ticks, which is more powerful than anything I can do in a generic way.
Fluids are usually not namespaced, we just prefix ours with ic2 to avoid interacting with other mods and the resulting balance issues. IC2 coolant e.g. is called ic2coolant, but others fluids are using their plain names like water or (presumably) fluid_redstone. The names are being defined while adding fluids to Forge's fluid registry, the origin of those names is arbitrary code and thus implementation specific.
The variant names (#<something>) we use are essentially shortcuts to infer the correct metadata and nbt tag. For fluid containers the variant is the fluid name as registered to forge. Examples: ic2:fluid_cell#ic2coolant, ic2:fluid_cell#water, ic2:fluid_cell#fluid_redstone.
You should be able to obtain the IC2 variant name by holding the item of interest and running the command /ic2 currentItem.
I'll tentatively support both, there's no significant difference between the versions.
Sorry, this was a bug in the cable placement logic. The latest build (1.12) should resolve this issue and fix any existing incorrect cables.
I've pushed the new log option, see debug -> logEnetApiAccessTraces, which should point you right at the issue.
Note that FML may log to fml-junk-earlystartup.log in some cases.
These removals don't (shouldn't) happen by themselves, so some api call to removeTile/EnergyTileUnloadEvent must be leaking through. The log shows that the TE instance is still the same, which implies that shouldRefresh is working.
I'll add some debug logging for ENet API accesses to track the source, it currently only logs some internal processing steps that aren't even on the same thread.
A log with logGridUpdatesVerbose turned on in IC2's config and as few IC2 ENet participants in the world as possible should help debugging the grid changes, especially whether shouldrefresh does what it's supposed to.
You can also use IC2:debug_item to rightclick your tile entity before and after it changes to verify that it's still the same TileEntity instance after changing state. If the TE class doesn't override toString, the reported hash code (in <cls name>@<hash>) shouldn't have changed. Keep in mind that it reports for both server&client, the TE instances between server and client should be different.
Not at this point, the environment is currently not particularly developer friendly.
Trisscar: You may have some luck with version 1.25, the rg error is rather fatal for getting the world to be rendered. It's most likely an incompatibility with another mod like Optifine.
retep998: I updated the post here since I'm not likely to fix it in a better way soon, interacting with CurseForge however is unfortunately broken until they fix it. Something in conjunction with the Twitch integration prevents me from uploading files or responding to PMs there.
BasicSink and friends have some example code in their Javadoc. To make the example code independent of IC2, all code accessing IC2 needs to be moved to a separate class and the field type needs changing to Object. The field can be also omitted by fetching the instance from the ENet as needed like in my IC2Integration.onTeUnload example does above.
I've just pushed some changes to Jenkins that make Basic* more easily usable as Proxies. Overriding the energy storage setter+getter and the capacity getter allows to directly access an energy buffer in the parent tile entity.
There's are 3 problems to solve with energy net integration:
1. Getting the IEnergyTile object (sink, source or conductor)
2. Knowing when it becomes valid (put/loaded into the world)
3. Knowing when it becomes invalid (chunk unload/block break)
Usually mods do (2) and (3) through neighbor notifications and polling, their cables try to detect when an adjacent grid participant appears or disappears. This is usually broken with chunk unloading, but more importantly IC2 doesn't necessarily own all cables. We allow addons to provide their own cables, so there's possibly not a single IC2 native tile entity in a grid that could detect changes.
Capabilities can't do (2) nor (3), they just solve (1) somewhat. Forge's capabilities don't receive any such notifications they can forward, neither do we get any suitable global events when a capability holder loads or unloads.
The obvious solution is to notify the energy net from TileEntity.onLoad(), .onChunkUnload() and .invalidate().
However once you do that, you may as well include the IEnergyTile object in this notification, i.e. tell the energy net that IEnergyTile x has been loaded or unloaded. As a result it's no longer needed to query the tile entity for x. The capability system is what handles that query, no query = no point in having a capability.
Since MC 1.7.10, IC2 supports x being an arbitrary TileEntity instance that implements IEnergyTile, whether it is the the in-world TE or not. All that matters is that its position and world are set correctly and someone tells the energy net about loads/unloads to determine the liveness. In later MC versions x can implement ILocatable instead of extending TileEntity, making this leaner and more obvious.
Overall there's nothing to gain from a capability. The delegate support during registration already provides everything needed to interface with IC2 without implementing the IC2 API in the actual TileEntity class. Either way the "annoying" part is funnelling the load/unload notifications to IC2.
An example integration implementation may work like this:
- TileEntity.onLoad: call Integrations.onTeLoad(this)
- TileEntity.onChunkUnload: call Integrations.onTeUnload(this)
- TileEntity.invalidate: call Integrations.onTeUnload(this)
- Integrations.onTeLoad: call availableIntegrations.foreach(x -> x.onTeLoad(te))
- Integrations.onTeUnload: call availableIntegrations.foreach(x -> x.onTeUnload(te))
- IC2Integration.onTeLoad: call EnergyNet.instance.addTile(new Ic2ProxySink(te))
- IC2Integration.onTeUnload: call EnergyNet.instance.removeTile(EnergyNet.instance.getTile(te.getWorld(), te.getPos())) if getTile didn't return null
- Ic2ProxySink implements ILocatable and IEnergySink similar to BasicSink, but accesses your own energy buffer in the real te instead of being a stateful battery. I'll probably add another class to simplify this.
This may be the old 1.8+ porting bug, which should be fixed in newer builds.
The batbox will send full packets only, but machines can reject energy partially and multiple receivers may cause splitting. IC2 machines shouldn't ever reject energy, but let their buffer overflow a bit. If that's not the case for you in recent IC2 versions, there is a bug somewhere.