Extended block IDs. Any objections?

The place to talk about how BTW might be different
Post Reply
User avatar
FlowerChild
Site Admin
Posts: 18753
Joined: Mon Jul 04, 2011 7:24 pm

Extended block IDs. Any objections?

Post by FlowerChild »

I'm currently considering adding in extended block IDs to Better Than Wolves.

I never wanted to do this in the past as I was worried that when the mod upgraded to a new version of Minecraft, if they changed the system around, people might lose their worlds. However, given I have since decided to remain on 1.5.2 indefinitely, and given that even if on some off chance I eventually did update to modern MC the extensive changes to world gen would likely require players to restart their worlds anyways, I've realized this is no longer something I should be concerned with.

Meanwhile, every time I consider adding something new to the mod, I always hesitate to because I don't want to exhaust the few remaining block IDs (currently 17) just in case I come up with something awesome down the road and need a few left in reserve. I may or may not choose to add additional blocks to BTW, but I'd certainly like to at least have that option open up again.

So, I just wanted to float this idea here of finally biting the bullet and implementing (or more like completing Jeb's old implementation) extended block IDs in the mod, to see if anyone had any objections.

I most like won't do this immediately, so no need to panic if this affects your add-ons or what have you. Rather, if I make the decision to do this, I'll like start filling the remaining 17, and only implement extended when required. I'll also make sure to take into account existing add-ons that might be affected by this (only Deco I believe) to make sure it doesn't mess with those either.
User avatar
FlowerChild
Site Admin
Posts: 18753
Joined: Mon Jul 04, 2011 7:24 pm

Re: [V2.1] The Deco Add-On. Now on Github!

Post by FlowerChild »

BTW Yhetti, would you mind if I used the Deco extended BlockID code as a base (or at the very least, a reference), for something similar within BTW itself?

I figure that since you've had it deployed for so long, your version is likely quite bullet proof, and I'd prefer not to take any chances with people's worlds.

I'll be sure to give you credit if you're cool with it.
Niyu
Posts: 265
Joined: Tue Mar 20, 2012 7:15 pm

Re: Extended block IDs. Any objections?

Post by Niyu »

Well I don't use any addons. So if from the technical side there's no issues and it will make the mod better (no pun intended), i'd say go for it.

EDIT: In fact, the other day, while looking at the BTW canvas of the difrent dimensions I remembered the original discussion about the extended ids and thought it could make sense to do it now that the mod was now forever 1.5.
User avatar
Zhil
Posts: 4486
Joined: Thu Jul 14, 2011 3:12 pm
Location: Belgium

Re: Extended block IDs. Any objections?

Post by Zhil »

Yeah, I say go for it. I think Yhetti also has some code in for loading plugins without having to have base class edits. I think if you pull in his extended block id's and the plugin loader, he's actually better off than he was before and so are any of the other addons still left as they could potentially get up and running a little cleaner if they need a rewrite due to incompatibility down the line.

Off the top of my head, the only addons I still see out in the wild are Craftguide, Astrolabe, Deco and the patched mods in MCPatcher. Since Deco is still active and Craftguide is just a convenience, I think the only thing you are in trouble of breaking is probably Astrolabe. I'm not sure if Jorge is still around, I think he's on Discord sometimes.

The real hairy one is MCPatcher. People really want to use it for their texture packs (there's a few with a LOT of work put into them). IIRC, it's the only way to get higher res textures for BTW? Not sure about that, I haven't used a TP in a long time. The issue there is that it's getting harder and harder to install on top of BTW, mostly due to the same issues that cause BTW to become harder to install with the launcher shenanigans. Extended block IDs might break it all together, I'm not sure. Somebody more knowledgeable would have to tell me.

In any case, if you do finally go over the original limit, we get to berate you for being so wasteful :)
Come join us at Vioki's Discord! discord.gg/fhMK5kx
User avatar
Yhetti
Posts: 427
Joined: Sat Feb 09, 2013 7:57 pm

Re: [V2.1] The Deco Add-On. Now on Github!

Post by Yhetti »

I designed it in hopes that other people in the community would use it for addons, but having you use it....I would be honored. :)

I have worked out a lot of the bugs with it but I suspect there are still a few here and there. Most of what it does is resize arrays. Feel free to take what code you need or ask me for help.
User avatar
FlowerChild
Site Admin
Posts: 18753
Joined: Mon Jul 04, 2011 7:24 pm

Re: [V2.1] The Deco Add-On. Now on Github!

Post by FlowerChild »

Yhetti wrote:I designed it in hopes that other people in the community would use it for addons, but having you use it....I would be honored. :)
Thank you man. I very much appreciate that.
I have worked out a lot of the bugs with it but I suspect there are still a few here and there.
Anything in particular you can think of, or are you just being cautious there? I just got very nervous :)
Most of what it does is resize arrays. Feel free to take what code you need or ask me for help.
Looking it over on Git think I have a pretty good handle on how it's working. I think the only thing I'll confirm is that everything related to this is contained within CheatBlockIDs(), correct?

Really though, I just want to make sure that I cover all the same arrays you've already found, so I'll likely go through one by one from yours as I code my own. As such, it's unlikely to be a verbatim copy, but will likely be similar enough that I wouldn't feel comfortable doing so without asking or crediting you.

So thanks man, that's very helpful indeed. I'd be very nervous about missing something if I were coding this without reference.
User avatar
FlowerChild
Site Admin
Posts: 18753
Joined: Mon Jul 04, 2011 7:24 pm

Re: Extended block IDs. Any objections?

Post by FlowerChild »

Gilberreke wrote:Yeah, I say go for it. I think Yhetti also has some code in for loading plugins without having to have base class edits. I think if you pull in his extended block id's and the plugin loader, he's actually better off than he was before and so are any of the other addons still left as they could potentially get up and running a little cleaner if they need a rewrite due to incompatibility down the line.
I'll take a look, but I don't think I'd be comfortable with integrating additional plugin code, as that would likely come very close to me supporting something akin to a mod API. Yes, I realize that I could just put it in and refuse support or something, but that really isn't my style, and I know it would likely drag me into something I've learned is best for everyone involved if I stay the heck out of :)
I'm not sure if Jorge is still around, I think he's on Discord sometimes.
I don't think Astrolabe will be a problem. According to the thread, he's only using id's 170 & 171, and I can easily stay away from them.

Really, I think the only blocks left I'll add in the original 255 range are a couple of stone blocks to replace the strata variants during chunk generation to help optimize that (chunk gen uses a byte array for the basic terrain). I originally implemented them as metadata variants to avoid consuming block ids, but if I no longer need that limited range, I'd much rather get rid of the slight stutter on chunk gen that slowly gnaws at my soul every time it occurs :)
The real hairy one is MCPatcher.
I don't see it causing any problems with Deco, so I really doubt it would be an issue. If anybody knows differently, please let me know, but I suspect it's not a problem.
In any case, if you do finally go over the original limit, we get to berate you for being so wasteful :)
Hehe... after around seven years on one of larger MC mods without exceeding the original limit, I won't take it personally :)
User avatar
dawnraider
Posts: 1876
Joined: Sun Dec 11, 2011 7:00 pm

Re: Extended block IDs. Any objections?

Post by dawnraider »

I've used MCPatcher in conjunction with the Deco addon for over a year and I've never had any issue with it so I don't believe it should cause any problems.
Come join us on discord! https://discord.gg/fhMK5kx
Get the Deco Addon here!
Get the Better Terrain Addon here!
Get the Vanilla Mix TP here!
Get the Conquest TP here!
User avatar
Zhil
Posts: 4486
Joined: Thu Jul 14, 2011 3:12 pm
Location: Belgium

Re: Extended block IDs. Any objections?

Post by Zhil »

dawnraider wrote:I've used MCPatcher in conjunction with the Deco addon for over a year and I've never had any issue with it so I don't believe it should cause any problems.
Ah sweet! Thanks for confirming that.
Come join us at Vioki's Discord! discord.gg/fhMK5kx
Mason11987
Posts: 1159
Joined: Wed Jul 06, 2011 11:03 am

Re: Extended block IDs. Any objections?

Post by Mason11987 »

I'd say just do it. If you want to add "a bunch of stuff", to me that's more than makes up for any possible negative to doing this.
User avatar
Yhetti
Posts: 427
Joined: Sat Feb 09, 2013 7:57 pm

Re: [V2.1] The Deco Add-On. Now on Github!

Post by Yhetti »

FlowerChild wrote:CheatBlockIDs(), correct?
Yes.

I know of no bugs related to the extended block ids.
User avatar
dawnraider
Posts: 1876
Joined: Sun Dec 11, 2011 7:00 pm

Re: Extended block IDs. Any objections?

Post by dawnraider »

Mason11987 wrote:I'd say just do it. If you want to add "a bunch of stuff", to me that's more than makes up for any possible negative to doing this.
I definitely agree. Worst case scenario, I'd have to start a new world, and if it means that cool new stuff gets added I consider that worth it. If I ever want to revisit an old world in that case nothing stops me from loading it in an older version.
Come join us on discord! https://discord.gg/fhMK5kx
Get the Deco Addon here!
Get the Better Terrain Addon here!
Get the Vanilla Mix TP here!
Get the Conquest TP here!
User avatar
FlowerChild
Site Admin
Posts: 18753
Joined: Mon Jul 04, 2011 7:24 pm

Re: Extended block IDs. Any objections?

Post by FlowerChild »

Well, I don't want to get anyone's hopes up that this is going to usher in a flood of content. Right now I'm just getting a little tired of censoring myself every time I want to add something new into the mod, so I'd like to remove that limitation and see what happens.

I should have probably been a little more careful about how I worded that in the OP. Will edit it slightly.
User avatar
FlowerChild
Site Admin
Posts: 18753
Joined: Mon Jul 04, 2011 7:24 pm

Re: Extended block IDs. Any objections?

Post by FlowerChild »

Moved a bunch of posts discussing this in the Deco thread over here so as not to clutter it up.

Yhetti, I'm working on this now and what you had is acting as a great base in helping me track down all the places where the old 256 blockIDs are assumed.

I found a few more so far, but mostly related to secondary things, like what kind of blocks mobs carry around, or what kind of blocks arrows stick into. I doubt they're anything that would cause anything other than visual glitches though, and I certainly didn't run into any more fixed sized arrays like the ones you dealt with.

EDIT: And after doing searches on the full code base for values of both "256" & "255", and going over each and every individual occurrence to make sure it's not related to block IDs (yes...I actually did this over the last few hours, and lost the sanity points to prove it), I think I'm now satisfied that I got all the little bastards :)
User avatar
Yhetti
Posts: 427
Joined: Sat Feb 09, 2013 7:57 pm

Re: Extended block IDs. Any objections?

Post by Yhetti »

One more important thing: it would be real nice if you didnt use the section of Ids that I am using. I think I have a list of them somewhere in the addons thread.
FlowerChild wrote: doing searches on the full code base for values of both "256" & "255"
I actually did this a few years back, looks like I missed a few, maybe I searched for one and not the other, guess I was a n00b.
User avatar
FlowerChild
Site Admin
Posts: 18753
Joined: Mon Jul 04, 2011 7:24 pm

Re: Extended block IDs. Any objections?

Post by FlowerChild »

Yhetti wrote:One more important thing: it would be real nice if you didnt use the section of Ids that I am using. I think I have a list of them somewhere in the addons thread.
Yup, I'm already taking that into account man. You're up at 3000+ right? I was planning on starting extended blockIDs for BTW at 1000, and I already have itemIDs in the 2000+ range, so unless I'm doing a thousand of either, we should be fine :)
FlowerChild wrote: I actually did this a few years back, looks like I missed a few, maybe I searched for one and not the other, guess I was a n00b.
The additional ones I found were a bit messy and I doubt were very noticeable in play.

Like the trickiest was probably the arrow entity which has an "inTille" variable that was being masked against 255 on load, but I think the only impact that would have really had was potentially resetting the decay timer on it because the arrow would think it was stuck in a different block than previously.

The others I think were mostly just held blocks/items for the zombie, witch, and I think the enderman carried block (where you did fix the array for what can be carried) being saved as a byte rather than a short. I think those would probably have resulted in carried extended blocks looking weird on those mobs (which probably never happened anyways unless the enderman was specifically told to grab some), but probably not much else.

There was also some other trickiness with data watcher variables that were being compressed to a byte when transmitted from server to client as well, but I forget which bit that was related to (might have been the carried blocks again). If I missed any others, it's likely those kind of byte conversions (I only caught that one because it was masked vs. 255 during the conversion), so maybe I'll do a search on "byte" as well.

But yeah, I'm fairly sure you caught all the really important ones, including that really nasty one in the map items, which I suspect would have resulted in a crash. I'm uncertain how you managed to spot that one given how nightmarishly obfuscated that code was, but I'm very glad you did :)

Thanks a million once again for this man. Without the head start you gave me on this, and the years of testing players of your addon put in, I doubt I would have had the guts to pursue this. I'm very excited about the possibilities it will open up for the mod.
User avatar
Yhetti
Posts: 427
Joined: Sat Feb 09, 2013 7:57 pm

Re: Extended block IDs. Any objections?

Post by Yhetti »

Okay, so I just realized that there is a bug with the extended block ids where the block dispenser will treat the new blocks as items and spit them out instead of placing them.
User avatar
FlowerChild
Site Admin
Posts: 18753
Joined: Mon Jul 04, 2011 7:24 pm

Re: Extended block IDs. Any objections?

Post by FlowerChild »

Yhetti wrote:Okay, so I just realized that there is a bug with the extended block ids where the block dispenser will treat the new blocks as items and spit them out instead of placing them.
Already got that one during my bulk search, thanks :)
User avatar
jorgebonafe
Posts: 2714
Joined: Mon Sep 19, 2011 3:22 am
Location: Brasil

Re: Extended block IDs. Any objections?

Post by jorgebonafe »

Hey, sorry, I just read this thread. I've been away this christmas, and I'll be busy with work for a while, but I'm still around, and if there is any trouble with the astrolabe addon after the changes are made to BTW I'll make sure to fix them as soon as I can.

And by the way, yeah, I'm all for it :)
Better Than Wolves was borne of anal sex. True Story.
User avatar
Zhil
Posts: 4486
Joined: Thu Jul 14, 2011 3:12 pm
Location: Belgium

Re: Extended block IDs. Any objections?

Post by Zhil »

Potential bug:

Code: Select all

java.lang.ClassCastException: java.lang.Integer cannot be cast to java.lang.Byte
    at ns.a(SourceFile:88)
    at rv.o(EntityEnderman.java:441)
    at bgx.a(SourceFile:25)
    at bgx.a(SourceFile:13)
    at bgy.a(RenderManager.java:222)
    at bgy.a(RenderManager.java:191)
    at bfy.a(RenderGlobal.java:444)
    at bfq.a(EntityRenderer.java:1167)
    at bfq.b(EntityRenderer.java:998)
    at net.minecraft.client.Minecraft.K(Minecraft.java:866)
    at net.minecraft.client.Minecraft.run(Minecraft.java:756)
    at java.lang.Thread.run(Unknown Source)
Somebody on IRC posted this. Saw the Integer/Byte mismatch and EntityEnderman.java and thought it might potentially be an issue with ID extension.

Extra info: this was on a server, the crash log is from a client that got into the world, was looking around and crashed

EDIT: might be some sort of install issue, can't really get to the bottom of it.
Come join us at Vioki's Discord! discord.gg/fhMK5kx
User avatar
TheGatesofLogic
Posts: 511
Joined: Tue Nov 06, 2012 5:35 pm

Re: Extended block IDs. Any objections?

Post by TheGatesofLogic »

My server is the one where this is coming up, and to add: I received a near identical crash report when I accidentally loaded up the server without btw installed on it. When it happened when the server was correctly installed we double checked that all parties have btw V4.A4 properly installed, servers and clients. I don't get this crash, but another person does, which is also interesting.
Two feet standing on a principle
Two hands longing for each others warmth
Cold smoke seeping out of colder throats
Darkness falling, leaves nowhere to go
User avatar
FlowerChild
Site Admin
Posts: 18753
Joined: Mon Jul 04, 2011 7:24 pm

Re: Extended block IDs. Any objections?

Post by FlowerChild »

On both client and server, line 441 of EntityEnderman.java refers to the same:

Client:

Code: Select all

    public void setCarried(int par1)
    {
    	// FCMOD: Changed
        //this.dataWatcher.updateObject(16, Byte.valueOf((byte)(par1 & 255)));
        dataWatcher.updateObject( 16, Integer.valueOf( par1 ) );
        // END FCMOD
    }
Server:

Code: Select all

    public void setCarried(int par1)
    {
    	// FCMOD: Changed
        //this.dataWatcher.updateObject(16, Byte.valueOf((byte)(par1 & 255)));
        dataWatcher.updateObject( 16, Integer.valueOf( par1 ) );
        // END FCMOD
    }
Declarations of watchable 16 from entityInit() on client:

Code: Select all

    	// FCMOD: Changed
        //this.dataWatcher.addObject(16, new Byte((byte)0));
        dataWatcher.addObject( 16, new Integer( 0 ) );
        // END FCMOD
server:

Code: Select all

    	// FCMOD: Changed
        //this.dataWatcher.addObject(16, new Byte((byte)0));
        dataWatcher.addObject( 16, new Integer( 0 ) );
        // END FCMOD
So, looks like everything should be legit. HOWEVER, the thing with data watchers is that they automatically communicate their values from server to client, so if someone were to join with a previous version, or an otherwise modified EntityEnderman.java (like if they had another mod overwrite that file), it would make sense that you'd get the type casting errors as you'd have the server sending them int variables when they are expecting bytes.
User avatar
TheGatesofLogic
Posts: 511
Joined: Tue Nov 06, 2012 5:35 pm

Re: Extended block IDs. Any objections?

Post by TheGatesofLogic »

Thanks for looking at it! Good to know it should be an install issue. I’ll try reinstall BTW on both my client and my server, ask the guy who’s game crashed to do the same, and see if we can get it to stop happening.
Two feet standing on a principle
Two hands longing for each others warmth
Cold smoke seeping out of colder throats
Darkness falling, leaves nowhere to go
User avatar
FlowerChild
Site Admin
Posts: 18753
Joined: Mon Jul 04, 2011 7:24 pm

Re: Extended block IDs. Any objections?

Post by FlowerChild »

TheGatesofLogic wrote:Thanks for looking at it! Good to know it should be an install issue. I’ll try reinstall BTW on both my client and my server, ask the guy who’s game crashed to do the same, and see if we can get it to stop happening.
I really wouldn't be looking to reinstall on your server. The error message Gil posted specifies it's a crash while converting an integer to a byte (so new extended blockIDs being converted into old), which means that the data is fine coming from the server, but the client is mangling it into the wrong format.

There's some informed guesswork involved on my part here, but I think it's more than likely that it's an install problem on the client end. Since it's also working for other players, I'd bet money that it's one guy with a messed up install.
Post Reply