Posts by Speiger

Quote from Player

The warnings come from IC2 being a coremod and are bogus/unsubstantiated. I'll just delete all package infos/@API support since Forge refuses to fix its bugs and it's commonly misused.

I am thankfull that you took your broken usage of the IC2 API but it seems that you didnt understand how to use the package.info API.
Let me explain you what it is for.

The PackageInfo API (API API in short) is there to Split the API in 2 ways,

1: First that people are no longer forced to use all parts of an API and do not cause issues
2: Second and most important is that you can split the API from the mod so that mods can still use the interfaces and benefit from the things they provide.
Simply a Indirect OreDictionary.
Simply COFH API is based around that concept. COFH is not required but everyone can still use RF without having to check for specific mods. They search just for the API and thats it.
Its a very basic but well running & userfriendly system. The idea behind that is very good.

Also it seems that you have missunderstood the concept and did not even use it properly and call it bad on their side...
I told you how to use it right and you still say its used wrong on common bases?
No its the same thing as the getDisplayName issue i had to tell you to fix it, or the getUnlocalizedName that you had to change twice to make it work properly how it should has to be done (when you just could it done with one time fix)

It seems like more that you do not understand common based systems because FMLs PackageAPI system works as intendet & the idea is behind to split the API with these package API infos into components so you can ask for stuff with @Optional and do not require a mod for that is very good and people did think themseves something when they created something like that...

Edit: And FML Is throwing Errors because you used a Splitting system to mark all components as the same. Which is equal to not using it or using only 1 packageinfo. So you used it wrong.

ok i even accept this!

Ok i do not want to see what happens when i release IC2Classic with my fixed Package.info files and your files that are still the same.
Before you say thats to much work and will take hours. No it takes 5 minutes.... An here is the thing i provide you even all names so they are synced and also allowing part usage of ic2 api without causing issues to other mods thinking the whole mod is loaded...
And it fixes your Forge Throwing Error problem.
If you do not want to add that then delete all other package infos and just leave 1 there... Then your error log is also fixed and i can adjust to that... But fix it.

Here all package infos names:

ic2/api: @API(apiVersion="1.0", owner="IC2", provides="IC2API")
ic2/api/crops: @API(apiVersion="1.0", owner="IC2", provides="IC2CropAPI")
ic2/api/energy: @API(apiVersion="1.0", owner="IC2", provides="IC2EnergyAPI")
ic2/api/energy/event: @API(apiVersion="1.0", owner="IC2", provides="IC2EnergyEventAPI")
ic2/api/energy/prefab: @API(apiVersion="1.0", owner="IC2", provides="IC2EnergyPrefabAPI")
ic2/api/energy/tile: @API(apiVersion="1.0", owner="IC2", provides="IC2EnergyTileAPI")
ic2/api/event: @API(apiVersion="1.0", owner="IC2", provides="IC2EventAPI")
ic2/api/info: @API(apiVersion="1.0", owner="IC2", provides="IC2InfoAPI")
ic2/api/item: @API(apiVersion="1.0", owner="IC2", provides="IC2ItemAPI")
ic2/api/network: @API(apiVersion="1.0", owner="IC2", provides="IC2NetworkAPI")
ic2/api/reactor: @API(apiVersion="1.0", owner="IC2", provides="IC2ReactorAPI")
ic2/api/recipe: @API(apiVersion="1.0", owner="IC2", provides="IC2RecipeAPI")
ic2/api/tile: @API(apiVersion="1.0", owner="IC2", provides="IC2TileAPI")
ic2/api/util: @API(apiVersion="1.0", owner="IC2", provides="IC2UtilityAPI")

These are all names you just copy paste it thats 5 min work...
If you do not want to do that here is the second option but one of them has to happen because i do not want error spam because you guys are to lazy to fix it (and i am laying you the fixed code diretly on your feet)

Just keep this one and delete all others if you do not want to go the first option:

ic2/api: @API(apiVersion="1.0", owner="IC2", provides="IC2API")

Quote from Aroma1997

I'm just keeping the API as open as possible regarding what people can do with it while still having it easy to use. Making it side- and source/sink compatible isn't something, that makes it harder to use, but it makes it more powerful. I won't promise anything regarding use in IC2.

Thats a lie! 100% LIE! When i ask you guys to do improvements that everyone could need (and not just for ic2classic) you ignore it

Quote from Aroma1997

I just added a Colored cable interface. You can use that for colored cable connectivity.

Finally after 2 MC versions where ic2 classic has that implemented and suggested it to the team since months someone decided to support it...
And now you expand it to a anything can be colorcoloded in the Enet...

i do not think ic2exp is going to add that. Their development went down to basicly almost nothing...

Here is a question. Do i have my 1.9.4 rewrite done first or does IC2 Exp have his crops back first?
Because classic when updated will be fully finished and will have everything from 1.7.10 + more after the update

Edit: so far i took the same amount of time that it took you guys to update to 1.8.9 (3 months)

Quote from Aroma1997

That looks really impressive.
Will the entire inside be filled with lava? If so, you don't need to go to the nether anymore, once you found such a thing.

With IC2Exp lava gens you run through this amount actually really quickly. I think this is a 40x60x40 build you can devide by 2 because only 50% of it are lava blocks.
Its only 4800 Buckets of lava... I ran through just with 6 Lava gens a couple hundred (1-2) buckets every 5-10 minutes with that setup... so yeah...

Aroma can you say that getActualState & getExtendet state get called in every case for a function call that requires it?
No you cant.

This is why i do not use IUnlistedProperty. Static variable which remembers the last used state saved my ass in moments like these...

I find it funny that you can eat EU with this mod xD

Quote from Chocohead

Packing part of another mod's API in yours is a very bad thing to do anyway, @Optional exists for a reason. And it hasn't changed to force it, just Forge complains now that all the @APIs on the package-infos are the same.

Well if you do all package info with the same name then it is stupid to do actually more then 1 package info since it requires all parts of the api and no its not bad copying a part of the api to support a mod. But copying everything (unless you are using everything) is bad.
But the IC2 Team forces alll...
I suggest (and sooner later i start to yell at you to do that) to either: change the name of each group or delete all package info and place a main one... Because that what you provide (even in 1.7.10 (even from my side)) is just bad API work... (And i showed often enough that ic2exp does not know how to make a good api)

Quote from roleplayrose

I have no idea what you are saying. Do you have advice for me to fix my issue?

Not really lets hope aroma takes the time to actually rework the Enet because it really requires it. (its at its oldest state + small changes) and it requires big changes... (Even Uncomplications Enet is better then Exps current (which is just a older version of classics)

There is nothing in the log that could help him...
Also armoa another bug reoport:
The API IC2API from source C:\Users\Gibbs\AppData\Roaming\.minecraft\mods\industrialcraft-2-2.5.63-ex19.jar is loaded from an incompatible classloader. THIS WILL NOT WORK!
This is caused because all package.info classes have the same name/id you should split them into indiviual pices so also other bugs do not show up... (Because ic2exp forces now a full API installed to use only 1 part)

In this case i made a mistake and missed something.
As soon it finds one it stops the attacking. (I wonder why they didnt add a filter to the default & make a closest entity check, but i have to do that to but thats now on my todolist)
So its working as intendet at the damage giving (they changed it to that)
So just provide enough power to damage all entities fast enough.. (Its a MV machine)

Its as simple as this:

-Draining 1EU per tick unless its redstone powered.
-Every 32Ticks (1,6 seconds) it will look at the total storage & devides it by 400
-This number is the damage if it is less the 1 It will skip it.
-If it is bigger then it will check in a 9x9x9 radius.
-Every entity it finds in this radius that is not wearing a Hazmat suit gets the damage it calculated before.

(So 10000 / 400 = 25 Damage (12,5 hearts)) that will reduce since you need to fill it up faster.
And it does not matter if you have 1 Entity or 5Million entities in that range. Every entity gets the damage applied. Also the same amount.

The thing you are discribing shows only that the zombies that survive the first shock hat some kind of protection. So they gained some shields from the armor & did not get so much damage as others

Its very simple: it checks for entities apply the same shockdamage to all of them and then uses energy (even if you applied 500 Damage to 50 mobs you still pay only for 1)

try using blockUpdates (place blocks next to it) if that does not help then the cable connection code is not adjusted to a couple cases....

The registry is there simply to allow highpower resistance if a Block has a to high resistance & is not registered in the IC2 Registry it will reset the resistance to 0.5... So just register your block in there.
Also 1 Small little question: Why did you make the 1 block out of a Techreborn core when you could do it without also as easy?

Yeah its because we tried to get a Fix into the API which is partly applied but the other half is simply not supported....its getting really annoying with the IC2Exp API

Hehe yeah and you are forcing to keep the full API implemented else it would crash if someone only has a part implemented and another person uses another part (do not have the api implemented) will think that everything is there because nobody seem to find a reason to make real package.info components...
I suggest you to fast fix it because its just beeing lazy bug...