Your IC2 config has invalid entries, just delete it and let IC2 create a new one.
Posts by Player
-
-
-
-
-
-
rdsn: Using optifine most likely just makes Fastcraft disable one of its optimizations. I'm quite busy atm, I'll look into it as time allows.
GregoriusT: The client needs to do those calculations, otherwise there's some situations where lighting won't be correct. That code is one of several light glitch fixups.
ArloTheEpic / Bogdan-G: Can you isolate a specific mod or subset of mods causing this? It certainly doesn't happen with just FC+Forge. Please try removing mods other than FC until the problem disappears to find out what's conflicting.
Razul Antiwield: There's nothing special to it, FC doesn't have any client <-> server dependency. It works just fine on only the client, only the server, both or even with mismatched versions. I've explicitly implemented compatibility with Optifine, you can use them at the same time.
-
drakray: The incompatibility is due to FC currently not detecting the mod, thus leaving compatibility code disabled.
Veeno: That's just my tick method, FC uses it to change the scheduling of ticks to make it (slightly) more efficient. It's very unlikely to ever point to a problem in FC, just like "net.minecraft.server.MinecraftServer.run" doesn't point to a problem in MC itself. The specific issue you are having is caused by a command having an inconsistent comparator, e.g. by having a non-fixed name or a broken custom implementation of compareTo. You'll have to find the mod adding the problematic command(s).
-
-
The warnings are bogus, just ignore them.
-
-
-
-
New build: http://files.player.to/fastcraft-1.23.jar
It should fix compatibility with ruinsmod and named entities with invalid AABBs used for serverside banners. Turning off enableCullingTweaks doesn't crash anymore.
-
-
RF can't handle multiblocks, not even energy sources with multiple output faces/connections, with a fixed output power. An individual block doesn't know the proportional energy demand for each connection. It doesn't even know if anything is connected somewhere - there's no API for conductors.
The best one can do is coming up with a heuristic splitting the output based on previous transfers. The power per face/connection concept, as used by e.g. TE energy cells, is really just a workaround for a technical problem that's hard to solve. IRL you can't increase the power of a generator by plugging more cables in, likewise it makes little sense for IC2.
Regarding voltage+current on RF.. well it'd be solely relying on conventions with practically all implementations not respecting them, good luck transferring more than a "packet" per tick through a foreign conductor. Even if you can, your current is limited to integer multiples, which isn't practical for IC2's use.
-
-
-
-
-
Tsyklop: I have not received any feedback on the linked issue yet, so it's unclear whether the build is beneficial at all. It's not really release worthy.
I wanted to type dropper, ofc the hopper ticks. The chest ticks for the lid state, once to de-glitch the in-use state and once to step through the opening angles.