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???

 

 

 

Oh yeah... Forge Version 916.

 

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...

 

 

It is simple.

You shouldn't use findGlobalUniqueEntityId() nor global id altogether.

You just found the reason why.

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...

 

It's not a bug, it's how minecraft works and most likely Lex/cpw's most likely not going to change it.

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!

 

What you SHOULD do is move to the normal per-mod spawning mechanics. Which uses a modid + mobid combo to allow you have compleetly seperate ID set and not cause any conflicts, overflow, etc..

We will not "fix" this as you're doing it wrong.

See the EntityRegistry in FML.

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!

 

    /**
     * Register the mod entity type with FML

     * @param entityClass The entity class
     * @param entityName A unique name for the entity
     * @param id A mod specific ID for the entity
     * @param mod The mod
     * @param trackingRange The range at which MC will send tracking updates
     * @param updateFrequency The frequency of tracking updates
     * @param sendsVelocityUpdates Whether to send velocity information packets as well
     */
    public static void registerModEntity(Class<? extends Entity> entityClass, String entityName, int id, Object mod, int trackingRange, int updateFrequency, boolean sendsVelocityUpdates)
    {
        instance().doModEntityRegistration(entityClass, entityName, id, mod, trackingRange, updateFrequency, sendsVelocityUpdates);
    }

Humm humm yes that is SOOOOOO FUCKING CONFUSING!!!!!

Note what it says about the id:MOD SPECIFIC ID

Cuz you know.. id conflicts between mods are stupid and shouldnt happen. Hence Mod specific...

 

Either way, don't be a fucking cunt. The id issue isnt OUR issue. It's a Minecraft issue that we have had resolved for ages.

The ONLY reason the global ID BS is there is for MODLOADER compatibility and it's going aweay in 1.7

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.

 

Ya I dont know what the fuck you're doing wrong but entities do NOT need a global registration. As things are picked up for you already when you do the mod registration as long as you DONT fuck it up by doing the global registry.

 

But ya, banned cuz you're just being a cunt. The class is fairly fine if you read it. And as evidenced by the code snippit I pasted comments DO exist.

 

 

Anyways have fun, be less of a cunt, enjoy modding!