LexManos

Forge works fine without 'premium accounts' its mineshafter that are the retards and don't support us. However we don't give a fuck about people sob stories there is ALWAYS a way to obtain a legit account. And we don't like people who 'shaft' mojang because they are dicks. So all in all don't bitch to us, bitch to the shitty people who can't even steal a UNPROTECTED game properly.

I would be more then happy to try and track this down. However we are unable to reproduce this issue. So it's reliant on you server admins to help us. The simplest solution if you can do it is to send me a copy of your setup, all server files. So that I can run the server myself in a test environment and try and reproduce the issue. If you're willing to do that, either post a link here publically, or e-mail me it at [email protected]

'MagicMinecraftLauncher' aparently does nto install everything that is included with forge. Namely the fmlversion.properties file that is in the zip that tells fml what deobf data it should download and what checksum it should have. Install Forge properly, or go speak with the maker of MagicMinecraftLauncher

Then you are failing somehow as out install instructions have not changed in ages. Hell they have gotten easier. Simply put the shit in forge's zip into minecraft_server.jar Or if you're super lazy and cant figure that out just have forge's zip and minecraft_server.jar in the same folder. And run Forge's zip instead of the server jar: java -jar forge.zip

Talk to the author of the xray mod, we don't support that crap here.

Quite interesting. One of your methods is obfusicating to the same thing as another one. Mind uploading your pre and post obfusicated class files for me to take a look at?

try without optifine.

Umm What the fuck are you talking about? Forge does not 'remove' anything. 'integer level data values' ... what? Honestly I think you're just being stupid and trying to load a world with mismatched block ids. And VANILLA MINECRAFT will ignore those values.

https://github.com/MinecraftForge/MinecraftForge/blob/master/patches/minecraft/net/minecraft/item/ItemInWorldManager.java.patch#L222 Derka Derka!

We have had the OreDictionary which has been there for a long time.

Adding the console log to the mojang screen was actually something i was thinking of doing but just keep forgetting to do....

Interesting does thius happen in servers with multiple peouple? What it looks like is the client isnt being added to the entity tracker properly. Ill do some testing when i get home to see if i can repriduce this myself and go from there

Vids if you can reporduce. Also, if you can give us a download of your world with steps to reproduce. Have not been able to reproduce things.

No things don't get 'magically updated' Especially between 1.4 and 1.5 You will ALWAYS have to update to handle changes in minecraft with things you interact with. However, 1.5 and 1.5.1 is the perfect example of why runtime deobfusication is a good thing. The obfusication changed between 1.5 and 1.5.1 because there were a few new classes introduced. HOWEVER no real functionality changed. There were a few changes with the MC Realms stuff but nobody uses that. So any real mod who was made for 1.5 and reobfusicated to srg names will most likely works fine for 1.5.1. Basically, the real benifits are for things between minor mc releases. For example, if we had this in 1.4, it is quite likely that most mods would not of had to update for 1.4.1, 1.4.2, 1.4.3, 1.4.4, 1.4.5, or 1.4.6 {kinda seeing why its a good thing?} I've explained this many times before. However I guess I will do it again. There are 3 'types' of names for minecraft: Notch, or Obfusicated: Classes named crap: 'a', 'b', 'asd', Fields/Methods name really useless names like 'a', 'b', 'qwe', these change between EVERY minecraft version. SRG Names: Classes receive good names 'Item', 'Block', and all Fields/Methods get unique names 'field_1234_b', these names are designed to be constant cross minecraft versions, unless minecraft actually removes/changes signatures the names will be the same. Mapped Names: Based off SRG names, but fields/methods are given community names such as 'getMiencraftDir', 'update' etc.. The problem with these names is that they are community based. And change on whims. So, its the logical choice for us to go with SRG names as they are stable cross versions. So basically. if you reobfuscate to srg names, your mod MAY be able to work cross obfusication changes. If you don't it has ZERO chance. You would only have to update your mod if minecraft changes things that you mod actually uses. As the vast majority of minecraft is stable code, the vast majority of mods will be able to have a stable platform.

The distro of python that FML/Forge ships has been tested and verified to work on windows 95-8. Both 64 and 32-bit. So im not exactly sure how you're having issues. Either way as you said, installing python yourself and telling the install scripts to use it would work fine.

They answered your question, you're not overriding the correct function. And don't bump without reading -.-

Just for note everyone. There is a reason why Forge now ships ALL classes int he paulscode package instead of JUST the one we actually provide. It is mac's DEFAULT behavior to REPLACE folders instead of merging them. This may not be the default with unzip however 99.9% of our mac userbase don't know what the hell terminal is. So the default jump to 'get a better archiver' WAS a valid response untill we started shipping all of the paulscode package. This guys first post had the org.apache.xerces.jaxp.DocumentBuilderFactoryImpl Error which was quite obviously killing the background thread that loaded sounds. However this is not anything that is under our control, so it would be on his end to figure out what was wrong with his installation of xerces. Either way, final thoughts, don't get all pissy.

Forge Version: 7.7.1 Minecraft Version: 1.5.1 Downloads: Universal (Adfly) (Direct) Source (Adfly) (Direct) Javadoc (Adfly) (Direct) Minecraft Forge 7.7.1 Changelog: ============================================================================ Updated to Minecraft v1.5.1 New: New TextureStitchEvents called before and after a TextureMap gathers and stitches textures together. Bug Fix: Fixed Activator rails activating TNT carts Fixed ShapedOreRecipe checking mirrored recipes Fixed multipass item rendering so that it uses the right spritesheet for the item. Fixed pistons generating snowballs Fixed imporoper show cover forming under snowmen in certian places it shouldn't Fixed equipment slots for items when right clicked, and dispensed using a dispensor. Fixed placing of certian items on Redstone Blocks. Fixed potential concurent modification with ChunkDataEvent.Save Fixed issue with Event.hasAnnotation ignoring it's parameter. And cached its values for potential performance gain. Fix NPEs when modders stupidly register null texture names. Guys this is a fairly minor update from 1.5, few bugfixes and nothing really important. However the Obfusication changed between 1.5.1 so mods will needed to be updated. unless they were using the new srg name obfusication feature of FML! And a final note, there are some new events related to ItemEnchanting and Entity data however, these were not properly vetted and forgified {u.u cpw!} and need changing so anyone modder who uese them be wearly and make sure you soley rely on the builds before 7.7.1.

For note these are new features that I have not reviewed fully as I have been out of town. I can however tell you for a fact that these things WILL be changed when I get back from Sakuracon as they need cleaning. However, there has been the basic functionality to tag any entity with extra NBT info for a long, long time. So just use that.

Fore does not work with bukkit. There are alternatives but nothing officially supported at this time.

Ah we may have to bring this to cpw's attention. It looks like, i'm gunna assume SpawnerGUI? Thats adding a class TileEntityMobSpawnerLogicExtended and it's set to package private. Either tell the mod author, or make a issue in FML's git. We should probably make everything public that was in the default package.

As long as you reobfed properly it should work fine 2013-03-26 18:04:20 [iNFO] [sTDERR] java.lang.RuntimeException: Don't register null! 2013-03-26 18:04:20 [iNFO] [sTDERR] at net.minecraft.client.renderer.texture.TextureMap.registerIcon(TextureMap.java:229) That shows that you're running in a mapped environment. Which typically means you're in MCP/eclipse... So you need to update your name.. Here is where the @Override annotation comes in handy make sure to always use it!

No, the mod you're using is broken and needs to register it's icons correctly, See the 'Dont register null!'s above, ya tell the mod author to fix it.

Something that magiclauncher is doing is causing the entire class to get validated, and fail it. However, I can say that the classes forge ships are valid and work. Either you're screwing up and mismatching mods/baseedits/versions/etc.. Or magilauncher is doing something extramly funkey,. Either way this doesn't look like a forge issue.

Nope, never been able to reproduce. And nothing should cause the mobs to go invisible as long as the client knows where they are. Walkihg away like you said makes me honestly think that you've got your tracking radius for your entity to higher then the view distance of the client, which would cause issues as when the client unloads a chunk on there end it drops the entities. And if the server still thinks that chunk is loaded then it would cause issues. Thats just a guess because i have never seen this issue. I am going to have to leave it up to you as someone who writes the mod with mobs and who can sit down and try debugging it in a non-live environment.