Posts by Player

The basic concept is easy, it works by tracing a homogeneous ray pattern radially from the center of the explosion. The rays decay with distance and explosion resistance of the blocks they pass through and remove those blocks while not being decayed sufficiently.

The ray resolution/spacing has to suffice the criteria of having full resolution even at maximum achievable distance, which means that the amount of rays required is easily in the 6-8 digit area. The trickery starts when it comes to making it fast, memory friendly and good looking through biasing the explosion resistance values and some other magic numbers and avoiding artifacts

I've changed it to not melt and TEs, we'll see how this goes.

That's intentional, but you need much less UU than before to actually produce things.

The iridium value of 12000 is not in mB, it's in cobblestone units, roughly describing how much cobble could be mined in the same time as the item specified.

You need 120 mB per iridium ore, i.e. 120 uu mattern gen runs or 120M EU without scrap.

Just disable worldgen and all the recipes?

It just determines how long the user has to wait until the item is fully charged in a mfe etc, about 10-30s for a full charge depending on the tool should work well

This may not happen as much on 1.7, try chunk loading it if you don't want to update.

That's a bit of a lost cause, there's no clean way to insert the explosion code. You can probably monitor the IEnergySink tile entities from the world's ticking TE list and check if they gained more energy than expected during a tick while not having a battery being discharged.

They have to go outside buildscript {}, that block is exclusively for Forge.

It works just fine for me. Did you try with only IC2+Forge?

You have to use ic2-experimental, not ic2-lf

Update Forge and use the latest build. You may be just using legacy recipes, not experimental recipes, though.

If it's your own item:

- override requiresMultipleRenderPasses to return true (just to unlock the next hook,not actual multipass rendering)
- override getIcon(ItemStack itemStack, int pass) and return the item you want after determining it from the supplied itemstack argument (ElectricItem.manager.getCharge(itemStack) or similar)

If it's not your own item you afaik can't do this without major hackery.

Addon discussion is usually the best forum to ask this type of question.

Once GT is sufficiently stable on 1.7, I'd highly suggest using that.

FTB lite is poorly designed, it contains several mods with severe performance and memory issues.

SimplyJetpacks has many "similarities" with IC2's implementation both on the macro and micro level. It starts with having the same overall approach, continues with the class hierarchy, solutions to individual problems, partially identical method and variable naming, semantics, down to exactly matching syntactical elements at times. While it may be a coincidence that some of these happen to end up the same if someone implements a similar thing himself, the probability decreases with each instance and there are a lot of those. Additionally there are some occurrences where he's using implementations seen in IC2 which are not reasonable for the scale of his mod or which are just legacy from the past due to IC2 just being a mod much older than e.g. Forge. There's also fairly obvious implementation style/approach inconsistencies towards the features he has added of his own.

Overall it'd be very naive to claim that SimplyJetpacks did not derive from IC2's implementation. The mod authors disagreeing are simply not considering the combined likeliness of all factors or are biases themselves. If law required absolutely bulletproof evidence, there would be no proof, which isn't the case. I have no doubt that there is very strong combined evidence to prove that SimplyJetpacks does indeed use code taken from IC2, it'd be up to Tonius to prove the opposite from that point.

I'm not interested in suing anybody, esp. over a mod, but if he doesn't comply I have no options besides either doing so or tolerating it. Considering how easy it'd be to just make it an IC2 addon which can be made to work with thermal expansion as well or just implementing it from scratch, I have to assume malicious intend and thus can't tolerate it. It is not enough to ask to at least provide a non-derivative implementation if you copy the idea already.

I did ask him discretely to take it down, but if that doesn't work I'll have to enforce it. If we didn't care, the mod would be public domain. Licenses and copyright are worthless if you don't back then up in the end.

It's also quite the antisocial move from some people to push Tonius into non-compliance, it's mostly his risk to take, not theirs.

The EU cost is still high, but replicating something will use much less uu as before. The overall energy required to produce something is unaffected by proportionally lowering uu output while lowering uu usage at the same time.

You probably call it client side, only the server should do this, typically from the tile entity providing the slot.

No, the step cost is definitely on my todo list and has been for a while.

Without that cost any uu material post-processing wouldn't have a benefit, you'd just order the final item instead of some intermediate or raw product to process it conventionally.

Besides that the UU graph calculation time will likely be a lot lower and more controllable as the minimum value search converges faster.

In the later 1.7 versions it'll indeed evaluate all the recipes, making it possible to e.g. clone a quarry, assuming all raw materials are known and the recipes can be parsed by ic2.

try adding 256, it may expect unshifted ids.

I already made it produce 1000 times less per cycle and the recipes cheaper to make UU worth a lot more per block/bucket.