Posts by Player

The debug output is incomplete, please check the console.

Can you still right click the invisible block with the debug item ("/give @p IC2:debug_item")? If yes what output do you get?

As of build 136 on Jenkins (http://jenkins.ic2.player.to/job/IC2_110/) it's possible to use a command to right click blocks without a hitbox. In your case "/ic2c rightClick <x> <y> <z>" while holding the debug item. xyz specifies the position of the invisible IC2 block.

You may have to disable culling (enableCullingTweaks=false) to make holograms work since they are actually outside the player's view as the entity position is concerned.

...

What you are describing there is merely another bug in the validation logic, FML confuses general validation (the class loader check) with validating against existing copies of the same annotation (unimplemented owner/version consistency check). It doesn't make any sense to not always do the class loader check, which in itself is conceptually broken since it's not applicable to APIs contained in their owner mod jar, but only mods using foreign API.

While unfixed this issue will fail to execute the check and thus hide the warning if there's only one instance of every involved provided API. The problem isn't declaring identical APIs like IC2 did, not doing so is just a workaround, which breaks as soon as someone else ships our API.

@API is and remains severely broken regardless both from a design and implementation POV. The only feature it's ever been good and initially intended for - implicit mod ordering - doesn't help IC2 as its coremod part makes it load as early as possible anyway.

You are wrong, inform yourself better or stop bugging us with poorly researched nonsense.

The warnings come directly from "if (Loader.instance().getModClassLoader().containsSource(this.getSource()))", which effectively just checks for coremods through the class loader differences.

It is not, this is a major design flaw in @API itself and you seem to have no idea how it actually works.

All it tells you is that the package is present, whether there are actually any classes besides package-info is completely arbitrary with zero guarantees. Thus using API mod containers in @Optional just as wrong as assuming that required-after:<some API mod container> allows you to expect any classes to be available on the class path. The system would have to use annotations on classes, not on packages, to represent the availability of classes.

Of course the splitting is NOT the cause of the warnings. If you looked at the source code of their origin for more than 30 seconds, it'd be blindingly obvious that you are plain wrong there too.

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.

Their port is still WIP, they aren't gone.

Nightreaver: Updating NEIDs should help there.

The 1.10 update is WIP, but a lot of effort as to be expected.

Ignore getUnlocalizedName(). It has been added by someone else mistakenly and isn't being used anywhere. I'll change getName to getId and getDisplayName to getUnlocalizedName. With getName it wouldn't be advisable to use getUnlocalizedName since that strongly implies getName was the localized one.

I already explained that and why IBlockState and its serialized form are not mirroring each other. They are usually the same, but that's not mandatory - even less with my plans to serialize some unlisted properties. They aren't even the same on the client due to incomplete serialization coverage from unlisted properties. Investigate how block states with Forge's additions work in depth before claiming obviously incorrect facts.

No, this works exactly as designed. The Javadoc is IMO precise enough, you are just confusing it with MCP's poor naming scheme.

getName() and getOwner() uniquely identify the crop for persistence, items etc. and are not exposed to the player.

getDisplayName() is the user visible name, before localization of course. A pre-translated getDisplayName makes hardly any sense, it prevents the server from querying it, which contradicts the "dumb client" model MC is increasingly adapting. If formatting capabilities are desired, we can consider making it return ITextComponent instead of String.

The problem is typically caused by very large networks, which take over-proportionally long to calculate and eventually require the main thread to wait for the calculation threads.

You can use the command "/ic2 debug dumpLargeGrids" to find them (excl. those in unloaded chunks). Fixing the issue involves splitting the large grid into smaller ones by inserting transformers and storage blocks.

The machines shouldn't cause any problems, regardless of how fast they run.

This is odd, try deleting the mods/ic2 folder.

The 1.10 version will take a while, it's tricky.

You can use jdb, but it won't be able to resolve local variables. I suspect the armor just doesn't allow external discharging, which is easily verified by testing whether an IC2 energy pack works instead.

Setting externally to false shouldn't cause this problem, usually discharging internally is less strictly limited than externally.

They currently expose their slots without any side preference, so unfortunately not.

Hmm no, the item needs to call IElectricItemManager.use, discharge is the raw discharging, which bypasses batpacks etc. My previous post was about the armor side's implementation requirement, not the tool that uses the energy.

The armor has to allow external discharging to be able to power ic2 tools, i.e. it has to return a value greater than 0 in IElectricItemManager.discharge() with the externally parameter being true. MPS afaik uses its own electric item manager, if it just uses IElectricItem the property gets delegated to IElectricItem.canProvideEnergy().

IamOmicron this is a compatibility problem with NEIDs, something about my detection of its ID range isn't working properly right now.