The MCPC and Bukkit ports are not done by the IC2 team, they're done by a third party. Go to mcportcentral and bug them.
Alblaka has said before he has no intention to learn how Bukkit works and create a Bukkit port also.
There are no MCPC ports any more, unported mods work on MCPC+. That means there's no other party who can be responsible for Bukkit functionality.
There are no MCPC ports any more, unported mods work on MCPC+. That means there's no other party who can be responsible for Bukkit functionality.
Really? Never knew that.
But still, Alblaka said that he had no intention of learning how Bukkit worked. Not sure about RG and Player though.
bukkit and forge both open source, you can code everything yourself and post ported version if you really want to.
bukkit and forge both open source, you can code everything yourself and post ported version if you really want to.
Someone did that, but:
1) It same amount of work for dev and nondev, as long as you know what are you doing.
If you dont know what are you doing, possible comments from source wont help you much.
2) Little patch to stupid railcraft and everything will go just fine.
also you can patch forge itself, rc obviously check signature via forge API, altering API will provide required results without altering rc.
As i can see from second "statement" you dont know how java works and someone who did patch dont know how forge works.
1) It same amount of work for dev and nondev, as long as you know what are you doing.
If you dont know what are you doing, possible comments from source wont help you much.
For one thing, they'll have to make a new patch for every IC2 version.
2) Little patch to stupid railcraft and everything will go just fine.
Forestry also does signature checks, including some that are hard to find. Now the person has to make 3 patches.
also you can patch forge itself, rc obviously check signature via forge API, altering API will provide required results without altering rc.
It's a built-in Java API...
native java API provide methods to check signature of jars inside mods directory specially just for minecraft?
you really dont know how java works and how such patches are done.
Raw Code, dont you know what the META-INF is for? It is a native Java Mechanism, which makes sure a jar doesn't get changed. If a Mod uses a jar instead of zip File (probably also works with zip), then you can go into the Mods and Coremods Folder and check every single jar to detect simple modifications and differences to the META-INF. The minecraftserver.jar even refuses to start when deleting its metainf, while the minecraft.jar refuses to start when the Meta-Inf-check detects modificatios (thats why crash reports know that it is a modded jar).
RawCode, I somehow think you dont have any Idea of how Java really works. You can just hack some small things and thats it.
GregoriusT
go read some manual, your post full of nonsense.
serverjar refuse to load without metainf because it contains link to entrypoint class, i can run server without metainf from external loader justfine.
as you dont know for some reason, if you replace files and leave metainf, classloader will ignore modded classes, but only default classloader will, if you load jar directly and alter classloader, it will run without warning with intact metainf and modded classes, in such case, any protection that just check metainf will fail.
@Mod.FingerprintWarning public void fingerprintWarning(FMLFingerprintViolationEvent event) { Proxies.log.info("Fingerprint of the mod jar is invalid. The jar file was tampered with."); FMLInterModComms.sendMessage("Railcraft", "securityViolation", "Fingerprint of jar file did not match."); FMLInterModComms.sendMessage("Thaumcraft", "securityViolation", "Fingerprint of jar file did not match."); FMLInterModComms.sendMessage("IC2", "securityViolation", "Fingerprint of jar file did not match."); }foresty does not use meta-inf directly, it use fingerprintevent that can be patched out from forge and no mod that use it for integrity check will be able to react on jar modifications, event just wont fire.
ah yes foresty actually use meta directly and sha-1 digest for calculations.
they ever attemped to obfuscate code facepalm...
but evoiding this still possible.
here fix for stupid foresty, shoud work fine with updates as long as naming unchanged
native java API provide methods to check signature of jars inside mods directory specially just for minecraft?
you really dont know how java works and how such patches are done.
Yes, a native Java API does provide methods to check the signature of a jar file for any class.
Specifically, TheClassYouWantToCheck.class.getProtectionDomain().getCodeSource().getCertificates() returns the certificates the class file was signed with.
Yes, avoiding it is still possible, but then you have to patch three mods instead of one. As a bonus, Covert and Sengir will both hate you forever. Now see what I meant by more work?
i will publish permanent fix for this stupidity soon(C) it will:
1) Alter forge by changing mod class loader, looks like it's possible with coremod, soo it will be coremod jar.
2) Custom class loader will redirect calls versus MessageDigest and other classes involved in signature check.
3) Mods will stay intact, but will lose ability to actually check signatures, since MessageDigest will return value stored inside fingerprint field, soo it will always match.
forestry is first mod to fix, stay online.
As a bonus, Covert and Sengir will both hate you forever.
Lol, everyone hates RawCode already, nothing to loose for him. He does what ever the fuck he wants anyways.
A Loose cannon, he plays by nobody's rules. Not even his own!
Covert and Sengir nobody for me, they not allowed to decide how i shoud run my game.
If i want patched or unsigned jars - i used patched jars, if foresty (that i dont use anyway) stop me from running patched jar i will patch foresty too, if multiple mods decide to stop me, i will run patched forge, but i still will run whatever i want and will share my workaround with anyone who ask.
expect some idiot to decide "my mod soo awesome i will keep whitelist of other mods who allowed to run with it and will punish user who attempt to run something else including his own mods" cos this is same thing.
Covert and Sengir nobody for me, they not allowed to decide how i shoud run my game.
If i want patched or unsigned jars - i used patched jars, if foresty (that i dont use anyway) stop me from running patched jar i will patch foresty too, if multiple mods decide to stop me, i will run patched forge, but i still will run whatever i want and will share my workaround with anyone who ask.
expect some idiot to decide "my mod soo awesome i will keep whitelist of other mods who allowed to run with it and will punish user who attempt to run something else including his own mods" cos this is same thing.
so basically tekkit?
Can't MCPC+ just check every time breakBlock is called?
Can't MCPC+ just check every time breakBlock is called?
Yes, and it does – but problems arise when mods alter the world through other code paths.
For example, the IC2 mining laser uses World setBlock..(), directly altering the world when a block is hit by the mining laser entity. This bypasses CraftBukkit's BlockBreakEvent, since it is only sent from ItemInWorldManager breakBlock(), but not World setBlock().
Now you may think, couldn't MCPC+ simply send events from setBlock(), or perhaps Chunk setBlockIDWithMetadata(), hooking deeper to catch more events? Well I tried this in fact, but this is too deep, beyond the point where critically important information is available. Specifically, at this layer, the player is not known – best you can do is introspect the stack trace to determine the calling mod to synthesize a fake player, unless you want to special case each mod (like MyTown). But worse yet, you can't reliably cleanly "deny" the block break at this level. Sure you can prevent the block from changing, but many mods will still run their own logic to determine item drops. When I prototyped this concept with Buildcraft, it caused the quarry to repeatedly attempt to mine a block and drop its item drops infinitely, a pretty bad duping issue. Only practical expedient way at least I could tell we could fix this was to modify Buildcraft appropriately, making a "ported" mod for MCPC+ with the required events.
I hear that alexbegt has completed an IC2 port for 1.115, using muCkk's events, but it is a couple builds out of date by now, last I know of. So I agree with immibis, something better to solve this problem would be nice, rather than someone making a ported version of each build.
But note the problem isn't just with block break. Anywhere a mod alters the world can potentially bypass protections. For IC2, this includes nukes (EntityExplodeEvent), lasers damaging entities (EntityDamageByEntityEvent), construction foam spraying (changes blocks), tree tapping, and so on. There are nearly 100 edits for MCPC+ in the IC2 ports.
However one problem being discussed here is fairly easy to solve — to preserve the jar integrity signatures, the mod can be patched at runtime via a coremod, instead of on disk. This is how TickThreading's patcher operates.
