TheyCallMeDanger

Lol! Except that that doesn't work! It ONLY works if you include registering your global ID. IE: LurkingTerrorID = 182; EntityRegistry.registerGlobalEntityID(LurkingTerror.class, "Lurking Terror", LurkingTerrorID); EntityRegistry.registerModEntity(LurkingTerror.class, "Lurking Terror", LurkingTerrorID, this, 64, 1, false); Try learning your own code. Sheesh. And you expect me to sort through all this spaghetti and try to figure out which is old moldy crap, and which is the "new and improved" way of doing things??? Yeah, sure, I'll just read the NON-EXISTENT comments... Oh well. Thanks anyway. I've figured it out and can carry on with life and making a bunch of kids happy again. No thanks to you! Pbbbt! Try being a little less of an ass next time. There is really no need for it.

Y'all are almost as bad as Mojang... Yep. They refuse to fix their bugs too. I looked at EntityRegistry. It is NOT self explanatory. It would appear, from testing and trial and error (because I could NOT find an example of the proper way to create/spawn mobs anywhere!!!!), that this: GoldFishID = EntityRegistry.findGlobalUniqueEntityId(); EntityRegistry.registerGlobalEntityID(GoldFish.class, "GoldFish", GoldFishID, 0xddffdd, 0x669955); EntityRegistry.registerModEntity(GoldFish.class, "GoldFish", GoldFishID, this, 64, 1, false); is at least one way that appears to function. (It doesn't crash, at least!) IS THIS CORRECT? If not, please point me at an example or two or three or four... I could not find any! I would like to know for sure what the CORRECT way is, because I've got a shitload of code that I will have to update, and I really don't want to do that more than once. Thanks!

Lol! Actually, I discovered that more than 30 years ago. Seems the folks at Minecraft still haven't... It's actually a bug in their code, as they expect the compiler to do things in a different order than it actually does them... The offending line, from Packet24MobSpawn.java: this.type = par1DataInput.readByte() & 255; The compiler reads the byte, ANDs it with 255, and THEN converts it to an integer. Obviously they intended it the other way around. On a side note, yes, I had filed a bug report with minecraft detailing the problem, and they did in fact blow it off. "Resolved" it as "incomplete". How it could be incomplete I don't know... I even gave them the fixed code! Sheesh... So... Is there a way to globally override the Packet24MobSpawn class at runtime when Forge loads my mod??? Or perhaps MCP could patch it??? Or you all could patch it??? PLEASE??? I need standard spawning to work properly... Are there any other options??? I desperately need space for moar mobs!

Ddiesieben07: Doesn't matter. I've already gotten into it with y'all and told you how to do it. That you won't, is a personal problem, that unfortunately, we all have to suffer with. MasterAbdoTGM50: Yes. There is. It is simple. It is easy. Everything is world-based and a slave of the server running that world. When you want an item id, you give the server a name to associate with it. The server appends the name of your mod to the item name, and returns you a world-unique id. It then records that pair for the world. This is, of course, only done for a brand new world. For an existing world, the server simply looks up the name you gave it and returns the same number it did last time. One interesting implication, is that a server owns the world, and will refuse additional mods not present during world creation. But, this is good, because all mods that were present when the world was created, should be saved with that world. So too should the game binaries. This ensures that one can go back and play old worlds without any problems. It also ensure that you can't go hosing up a world by accidentally forgetting which mods you had installed. It's all there and already done. It was all set when the world was created. Another aspect, is that because servers own their world and all the ids within, anyone can log in, to any server, and it doesn't matter what mods they have installed. The server will only respond to requests from mods it knows about for that world. In fact, it could tell the player to go get the correct ones, or even offer to download them to the player. The truly cool part, is that this exact same mechanism can be used for blockids, entity ids, biome ids, dimension ids, and whatever other ids there are. The server sets them, and writes them in stone, and world creation time, and everything needed to run that world, is stored with that world. It would make playing minecraft and switching worlds and versions so much easier, so much simpler, so much more invisible to the player, etc, etc. Set up the mods you want, make a world, done. Never have to worry about it again... Short answer, yes. It is easy, if designed correctly. But this is rare indeed, and so I suspect that no, it won't happen...

Except that any number I pick over 127 is going to end up negative when sent over the network interface. findGlobalUniqueEntityId() returns the correct value of 128. par1Packet24MobSpawn.type is wrong, at -128. So, somewhere between when I get a correct positive 128, and send it accross the net, and the other side tries to spawn it, it becomes a negative 128. I have no way to bypass all that crap. In other words, even if I picked arbitrary numbers myself, it would still fuck it up. It's a bug. Please fix...

Still happens in Forge 942. Here is a bit more info... From NetClientHandler.java: System.out.printf("Spawning entity %d\n", par1Packet24MobSpawn.type ); EntityLivingBase entitylivingbase = (EntityLivingBase)EntityList.createEntityByID(par1Packet24MobSpawn.type, this.mc.theWorld); entitylivingbase.serverPosX = par1Packet24MobSpawn.xPosition; (THIS IS WHERE THE NULL ptr CRASH occurs) produces "Spawning entity -128" (the ID returned from findGlobalUniqueEntityId() was +128!!! How did it end up negative across the net???) Adding the line: if(par1Packet24MobSpawn.type < 0)par1Packet24MobSpawn.type = 256+par1Packet24MobSpawn.type; between the printf and the createEntityByID() works perfectly, but I don't know where else this problem might occur, and what other functions may be affected. It also violates Forge code, so I can't use this fix in the actual distributable mod... PLEASE fix...

Oh yeah... Forge Version 916.

Yes, I have a ridiculous number of entities. More than 50. I lost count. It's the OreSpawn mod. Tons and tons of critters... And yet, I'm trying to add a few more! PROBLEM: EntityID 128 does not work. It crashes. Everything below that is fine. Anything 128 and up, goes splat. From my log: 2013-11-03 09:36:40 [iNFO] [sTDOUT] Small Worm ID = 124 2013-11-03 09:36:40 [iNFO] [sTDOUT] Cloud Shark ID = 128 Worm and Cassowary(127) are fine. Cloud Shark and Gold Fish(129) both crash. From the Minecraft log: ---- Minecraft Crash Report ---- // There are four lights! Time: 11/3/13 9:48 AM Description: Unexpected error java.lang.NullPointerException at net.minecraft.client.multiplayer.NetClientHandler.handleMobSpawn(NetClientHandler.java:952) at net.minecraft.network.packet.Packet24MobSpawn.processPacket(Packet24MobSpawn.java:143) at net.minecraft.network.MemoryConnection.processReadPackets(MemoryConnection.java:89) at net.minecraft.client.Minecraft.runTick(Minecraft.java:1966) at net.minecraft.client.Minecraft.runGameLoop(Minecraft.java:909) at net.minecraft.client.Minecraft.run(Minecraft.java:837) at net.minecraft.client.main.Main.main(Main.java:93) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at net.minecraft.launchwrapper.Launch.launch(Launch.java:131) at net.minecraft.launchwrapper.Launch.main(Launch.java:27) From the Forge log: (nothing) It crashes after trying to create the entity by ID, failing, returning NULL, and then accessing NULL.xposition. Seems to be a bug with the entity map, which appears to be 255 bits, but is apparently only useful up to 127. Looks like a signed/unsigned byte problem. Here's a thought.... make it an INT like it should be, and bump the map up to 1024 in size. That would be nice! In the meantime, IS THERE A WORKAROUND???

Lol! server.properties: allow_nether = false That was the problem. Would have been nice to see a message or something! Changed false to true, and poof! It all works again...

Hi! Same old dimension switching code I've had forever.... It works fine in eclipse when I run multiplayer. It works fine in eclipse in single user. It works fine in regular single user outside of eclipse too. In Forge 916, on a real multiplayer server, it doesn't work any more... Basically, the player gets stuck in a blue limbo with clouds. Nothing else. Just blue limbo with clouds in the sky. Can't move. Can't do anything. Before bothering you all with line after line of code... Has anyone else seen this and know the general problem? Can you give me a clue where to look? And no, there is nothing in the Forge logs. No crash. Nothing interesting. I log in, some times goes by, I log out.

But that's not the point, is it. You get SOURCE CODE from mcp. Patch it. I know you can. I see patches fly by the screen all the time. Make those block/item/whatever arrays a LOT longer. And give us auto-conflict-resolution. I know you can! C'mon.... You can do it... Go for it! Be a hero and make everyone's headaches go away! "No more item conflicts! Hurray for Forge! Hip hip Hooray!" Seriously. Quit dawdling around and fix it. 'Nuff said. Good luck!

If there is a conflict resolver to do this, then certainly the code masters at Forge can do this too... AND make it simpler and easier...

4000 item/blockids is more than enough. You can do it. I know you can. Even if MC won't add a few extra item slots. SERVERS are no problem at all, since the client ONLY loads item/blockids for the mods on the World it connects to. In other words, the server determines the itemids in use. These are easily sent to the client. Personally, I've got a couple hundred (3 hundred+) item/blockids I actually use. I've lost count. But even that leaves roughly 3000 itemids, or room for 6 more monstrous mods, or a whole shitload of little ones. Stop making excuses. Players are pissing at me because of itemid conflicts. I've got a config file, and I tell them to change the range, but I SHOULD NOT HAVE TO DO THAT. It should just work. The PLAYERS are hating mods because they don't get along, AUTOMATICALLY. Do it.

That's what I thought. And therein lies the problem. You see, FORGE PROMISED to make this problem go away about A YEAR AGO. It was the reason that I selected forge for my modding platform. It is/was one of the primary reasons that Forge exists. WHY IS IT NOT FIXED? Nothing personal here, and my comments are probably not directed at any of the nice folks replying here... But FORGE as a whole, deserves this: (close your eyes if this does not apply to you) GET THE F*** OFF YOUR A**ES AND FIX THE G*DD*MNED PROBLEM! (ok, open your eyes now) It is NOT difficult. I can do it in a day. public int registerThisItem(Modname+itemname) it returns a unique integer. How? It reads an itemIDs.cfg file in the World directory that the player is connecting to. If it finds Modname_itemname in the file, then it returns the unique number that was saved and associated with it. If it does not find that entry, it picks a new unique number, assigns it, and writes it back into the config file. Easy as shit. You will have to change loading mods. Mods cannot be loaded until the user selects a World. Why? Because each world has it's own set of unique item ids. Why? Because I want to be able to take my world directory and copy it to a different machine with different mods, and still have it run. I'm sure MC will happily extend their block and item arrays a bit to make more room. That's a no-brainer. But still, with thousands of mods out there, and a unique id for each and every item, you're going to run out of ids. Easy problem. Check the desired mod list vs the ids in the file, and remove the unneeded ids from the file automatically. Or give the user a list of mods that have ids in the file and ask them which ones should be removed. Either way, it does SOMETHING rather than just crash the game. But why bother? What's all the fuss? BECAUSE PLAYERS DON'T WANT TO HAVE TO LEARN JAVA JUST TO RESOLVE CONFLICTS AND PLAY A FREAKING MOD! It's like telling my grandma she has to learn all about computer security and viruses. Not gonna happen. IT MUST BE INVISIBLE. Let's remember our target audience here. It's 10 year old boys, NOT computer experts. It should all just work. Live up to the @%$#!^%$#@&^%! promises you made to us modders/players a year ago, and MAKE IT HAPPEN!!!!! Yes. I am furious. And you all deserve a good reaming. I want automagic non-conflicting itemids and blockids. No more excuses.

How do I get a unique blockID/itemID that no other mod is using? I don't see it in the code anywhere...