Posts by Player

Energy is usually being split according to the conductance of the available paths, not taking those into account which have a higher loss than the total amount of eu emitted from the energy source. Paths leading to targets which currently don't accept energy (usually because their internal buffer is full) will be ignored as well.

The previous calculation yields the minimum amount of eu sent to the various destinations, however there are some targets which don't get their full share because they are either almost filled up and the energy gets partially rejected or the share is not larger than the path loss. Those lost shares are being collected and sent in further distribution rounds, just like the original method, but with randomly eliminating targets in stalemate situations. This situation occurs when all shares were unable to be distributed as in everyone would get less than 1 eu = effectively 0. Reducing targets increases the share of the others, ultimately to one which gets everything or even zero if the last possible path is too lossy.

leg's energy consumption is actually still not working, hard to fix though.

You can disable the generation of ic2 ores in the config, maybe that's the case?

I'm not aware of any recent issues with the world gen in Forge.

Those are actually (static) nested classes without a reference to an instance of the surrounding class.

I highly object the opinion of your professor, nesting increases the readability a lot if it's used correctly.

We don't "apply" any data on world load server-side.

IC2 transmits the extra TE data once the client loaded the TE by its request over the network. If that breaks bukkit sent incorrect chunk data in the first place.

Our induction furnace implementation doesn't have sounds.

Does the machine have plenty of power available? It alternating between on and off may cause additional cpu load.

Our recipe implementation changed, CT III has to adopt if it's using it through reflection.

update to 1.97

We did implement that, yes

However RP2 doesn't publish all of its stuff in the ore dictionary yet, so you'll still have to add block ID 140 to the miner grab list.

Does the attached toolbox class work any better?

It goes into the ic2 server jar at ic2/common

the volume setting should be fixed in git

Sounds quite nice, the existing chunk loaders are too cheap to maintain.

I updated the download links, the new additional changes are:

- Added audio source management and damping by blocks (experimental)
- Added ID consistency checking to the maps (only active once the map has been loaded with 1.96+ at least once)
- Added a debug item which dumps block/te data to the console (not craftable)
- Changed the ticking mechanism to FML's
- Changed the recipes to support ore dictionary items directly, allows to mix ores (e.g. tin from ic2 and forestry in the same recipe)
- Changed Forge version requirement to 3.3.7 or later

Those were not for performance reasons, they were required for the old charging code. However since we can charge with a resolution of 1 EU now, it's no longer needed and even makes the solar's behavior a little inaccurate.

yes, possible also rp2 specific API similar to what BuildCraft did for the blueprints.

I think I got the jetpack finally fixed.

This sounds like a config mismatch between the server and client, make sure that config/IC2.cfg on the client matches the server's.

I fixed it for the next version and removed the video link to prevent too much abuse.

Thanks for the report.

Placing cables mid-air isn't supported in the current version, will be fixed in the next one.

Frames are just a dirty hack which violates the normal behavior of tile entites. There's nothing we can do about it without TE relocation support from Minecraft.