LexManos

https://github.com/cpw/FML/blob/6417ad0a3c7048db75d7e836bf9b9d0d678b8509/common/fml_at.cfg#L63

You can't really compare the two like that. FML is an API, and ML is a system that allows it to exist. Allows what to exist?

Mark your packet as a chunk packet.

Would sound like it yes. ModLoader providing block coords is rather.. stupid...

Delete your server project Everything was merged to client. If you want to debug the Dedi-server environment, run MinecraftServer.main. Nothing is missing, it was one on purpose to make everything a unified codebase.

How exactly is having one item overwrite another not conflicting? Things may not explode right away no. But I'm sure modders would fuck something up and expect oen things from the item that isnt there if it's overwritten. Like reading the item from the list and trying to cast it to it's internal class, for example. Either way, advocating id conflicts is still retarded. Modders just need to learn to work together.

There are ones already.

Advocating id conflicts is stupid. Modders should just do better.

Perhaps try looking for what MC does...

You have to rewrite a lot of the things you're doing. Directly accessing effect renderer from common code is bad, as you wont have access to it on the server Same with the old Minecraft.usePortal you'll have to sue the server's version. A lot of your stuff needs to be cleaned

Or, modders could just use the Ore dictionary.

Extracting textures to a folder would be retarded. That would defeate the purpose of texture packs. As they are texture packs work just fine with mod textures if they simply put them in the correct place.

Before the first official release we will try and sync everything back up and make ML mods work properly again. We'll look into it.

I didnt 'miss' anything. You're just lazy and expect side to directly correlate to your index. You can always use .ordinal() to get the same exact values as what they used to be. But you're better of doing it properly, and returning a valid index directly, not returning the side.

Along with the plethora of things in that code that makes my eyes want to bleed. You should not be using addOverride. But, as long as those files exist, they should work.

it moved to FML.

Forge Version: 4.0.0 Minecraft Version: 1.3.2 Dependencies: None Jenkins Build: #200 Downloads: Universal (Adfly) (Direct) Source (Adfly) (Direct) Minecraft Forge 4.0.0 Changelog: ============================================================================ Updated to FML #289 MAJOR: Minecraft 1.3.2 WHOOT! With the merge of the client and server in 1.3, as well as Mojang finally syncing the obfuscation. We are now distributing both the client, and server download, in the same download. This means that there is no Client/Server version. There is only Universal. Forge will combine the client and server code at decompile time and create a new workspace for you to work in. This should allow you to easily develop and test your mods for both Local Server, and Remote server. And should allow any forge mod to follow the pattern of releasing a 'universal' package. Exposes the full power of the argo, guava, and asm libraries to mods, allow fuller control over the minecraft environment for modders. Re-wrote the old handler system to a new event based system, to move Forge more in line with Bukkit, and the future Minecraft API Re-orginized the internals of Forge into it's own package, so please do some searching before asking where something went. Removed or consolidated many interfaces/functions that were redundant or deprecated. As ModLoader for 1.3.2 has not come out, we are currently not compatible with it, however, when it comes out, we will update accordingly. More to come after I have gotten some sleep.

humm im gunna have to figure out why some people don't take the patches until the 2nd time around. its reallly stupid and shouldnt happen. And as for the server files... Check the src folder... notice anything.. new..?

Server side only having a few files is not an issue, its a feature And saying 'i have errors dur dur dur' is like saying 'The sky.. exists...' tells us nothing.

You probably screwed soemthing up again. And things being named func_/field_ is normal, what is this, your first time modding?

You fucked up, clean mcp and get clean jars and try again

There is a known NPE when connecting to a Server with the current builds The jenkins is for MODDERS ONLY. I will be liberally applying the banhammer for anyone who ISNT a modder who posts support requests for 1.3 builds. Also for anyone who continiously post bugs that we know about EXA: THe NPE when connecting to a server. You have been warned. Also, aside from that browse the jenkins with Adblock disabled and i'll <3 you {its got the adfly script for downloads that is disabled if you use adblock}

Well, actually the main issue is that all of the world generation is encoded into a byte array. Someone should look into what exactly would need to be changed for world gen to use a short array as opposed to a byte array. Its in quite a few files. Seems the start of it is ChunkProviderGenerate.providceChunk, and touches all BiomeGen classes, as well as all the other world generation classes... It would be quite a large change. Not to mention throwing compatibility right out the window with any non-forge mods. I think the simplest soltution for now, is to either do your world gen stuff in the populatChunk callback. Or to make sure your world-gen blocks are < 256

Thats fucking retarded. who taught you how to program? You have a BiomeGen which extends BiomeGenBase You override anything that uses the byte limited ids. Replace them with a short. How hard is that? This has NOTHING to do with World at all This is ALL inside BiomeGenBase Seriously Its not difficult

Yes it does, things all work fine with vanilla forge. So as long as you don't do something stupid it should be fine.