The game gurrently uses a big if statement based on the value returned byt Block.getRenderType().
In renderblocks you would add something like this:
private static boolean HasSpecialRender(Block block) {
for (Class i : block.getClass().getInterfaces()) {
if (IRenderSpecial.class.isAssignableFrom(i)) {
return true;
}
}
return false;
}
/**
* Renders the block at the given coordinates using the block's rendering type
*/
public boolean renderBlockByRenderType(Block block, int x, int y, int z)
if (HasSpecialRender(block)) {
return ((IRenderSpecial)block).renderWorldBlock(this, x, y, z);
} else {
return "default minecraft rendering behaviour"
}
}
/**
* Is called to render the image of a block on an inventory, as a held item, or as a an item on the ground
*/
public void renderBlockAsItem(Block block, int metadata, float color)
if (HasSpecialRender(block) && ((IRenderSpecial)block).overrideInventoryRender()) {
((IRenderSpecial)block).renderInventoryBlock(this, metadata);
} else {
"default minecraft rendering dehaviour"
}
}
}
Edit: Stupid forum. Posting stuff before I'm done writing.
Ok so I earlier started to implement this in the method "RenderBlocks.renderBlockByRenderType()", but I was using
/**
* Renders the block at the given coordinates using the block's rendering type
*/
@Override
public boolean renderBlockByRenderType(Block par1Block, int par2, int par3, int par4) {
if(!(par1Block instanceof IBlockRenderer)){
return super.renderBlockByRenderType(par1Block, par2, par3, par4);
}else{
return ((IBlockRenderer)par1Block).render(par1Block, par2, par3, par4);
}
}
Would this work? I thought you could check interfaces by using instanceof.
EDIT: Oh yeah that is in a class that extends RenderBlocks
Ok so I earlier started to implement this in the method "RenderBlocks.renderBlockByRenderType()", but I was using
Would this work? I thought you could check interfaces by using instanceof.
EDIT: Oh yeah that is in a class that extends RenderBlocks
Yes I believe that would work. I wasn't sure myself when I wrote that code, hence the overly complicated method.
But if all else fails we can always try it and see what happens.
Rollback Post to RevisionRollBack
I'm not active on these forums, so forgive me if I don't respond!
If you want to contact me, try going through Discord or you can find me on GitHub where I am still updating the below mods (and more):
Yes I believe that would work. I wasn't sure myself when I wrote that code, hence the overly complicated method.
But if all else fails we can always try it and see what happens.
Ok I finally looked at the places where RenderBlock is instanced, and I don't think this will be easy at all. Instead of having a single RenderBlock and using it for all blocks (which it fully supports and is designed to do), there are TEN instances all running at the same time to render different types of blocks! TEN! Of the same class with the same parameters, same instance variables, same everything! Mojang!
I see, it would be difficult to do without some kind of base edit. I have also seen that it created RenderBlocks on the fly and sends them as parameters to a method.
Do you think it is possible to redefine the RenderBlocks class using the tweaker?
I've heard that it allows you to load alternate versions of classes before the game starts. (don't quote me on that).
I'm not active on these forums, so forgive me if I don't respond!
If you want to contact me, try going through Discord or you can find me on GitHub where I am still updating the below mods (and more):
I see, it would be difficult to do without some kind of base edit. I have also seen that it created RenderBlocks on the fly and sends them as parameters to a method.
Do you think it is possible to redefine the RenderBlocks class using the tweaker?
Hmm that would probably work, but the way I have BL set up now it can be started without the tweak launcher if necessary. Currently I have 1/10 instances of RenderBlocks overridden...
Would it be possible to add methods similar to Modloader's
public Packet23VehicleSpawn getSpawnPacket(Entity var1, int var2)
and
public Entity spawnEntity(int var1, World var2, double var3, double var5, double var7)
? If you could that would be great! Also, Just two small things, nothing major, but ApiGUI needs to be ApiGui and in the ModConfig the sample constructer is a bit outdated (loadSettings is now loadConfig and ModConfig takes two arguments) but nothing too major
Edit: Would it be possible to add the ability to register localisations in Items (so we can name items instead of item.name.id?)
I think the spawn entity and packet should be doable, I will work on those. Also thanks for pointing out the ApiGUI and the other thing. The localisations is something I have not been able to figure out even in my other mods. I liked it a lot better when there was a method "getUntranslateableName()" or something like that that was automatically called on mod blocks. Of course it was removed soon after.
lol some of ModLoader's stuff isn't bad, it's really only the stuff that changed since 1.3.2 that is terrible. After that he didn't really update, he just wrote workarounds.
That is a good point, but I will probably end up having to rewrite it anyway
lol some of ModLoader's stuff isn't bad, it's really only the stuff that changed since 1.3.2 that is terrible. After that he didn't really update, he just wrote workarounds.
Well indeed, but I'd also advise caution in going too far down any route right now given how many things change in 1.7, you may be inventing solutions for things which are already solved.
Well indeed, but I'd also advise caution in going too far down any route right now given how many things change in 1.7, you may be inventing solutions for things which are already solved.
Good point. I have actually been thinking hard on the removal of block IDs. I have yet to see (unobfuscated) how that works from a code perspective, but from what I saw from rej it looks like the game assigns block IDs automatically, which could make mod load order a nightmare. And if a mod loads before a vanilla block? All your block IDs are screwed up and bye bye world.
I think you should focus on 1.7 instead. Maybe be the first loader for 1.7. That would surely boost it's popularity.
That would be cool, but I don't think it is quite ready. I could release a beta version, though. I really need to write those batch scripts to automate building a zip...
I am currently planning to release the first version of BL after updating to 1.7.2. This would allow it to be one of the first APIs to update, giving it some publicity. Not underhanded at all... Anyway would anyone have any objections to this?
I am currently planning to release the first version of BL after updating to 1.7.2. This would allow it to be one of the first APIs to update, giving it some publicity. Not underhanded at all... Anyway would anyone have any objections to this?
Back before I used MCP I used to always strive to have Macros updated in record time so that it could be released before all the mods which were waiting for MCP, it worked, so I'd say for sure that it's a good way to raise awareness of your API. At the same time I'd warn against releasing something half-baked, as it will only hurt you in the long run. So basically: if you get it to a state you're happy with, then definitely release ASAP to capture attention; if you're not, then better to release something stable and rely on other means of promotion - of which there are plenty in this community.
I had a little time earlier and mocked up some ideas for logos for you (since you still seem to be lacking any branding for this) and if you like any of them I don't mind developing a little further. These are just the ones I was happy with but I have others if none of them are to your liking:
Also I made the blaze rig in 3dsmax and have a whole bunch of renders if you just wanted that to make your own logo.
Back before I used MCP I used to always strive to have Macros updated in record time so that it could be released before all the mods which were waiting for MCP, it worked, so I'd say for sure that it's a good way to raise awareness of your API. At the same time I'd warn against releasing something half-baked, as it will only hurt you in the long run. So basically: if you get it to a state you're happy with, then definitely release ASAP to capture attention; if you're not, then better to release something stable and rely on other means of promotion - of which there are plenty in this community.
I had a little time earlier and mocked up some ideas for logos for you (since you still seem to be lacking any branding for this) and if you like any of them I don't mind developing a little further. These are just the ones I was happy with but I have others if none of them are to your liking:
Also I made the blaze rig in 3dsmax and have a whole bunch of renders if you just wanted that to make your own logo.
Thanks for the advice! I am currently happy with the way BlazeLoader is (for a first release) as I have gotten rid of all the major bugs except the one that seems to prevent forge from properly loading. I definitely want to fix that bug before anything else. Anyway, those first two logos are pretty cool! I think the first one is the best, except it could be slightly darker (to help the word blaze stand out) and it could use a small border to prevent the background from blending in if it is not on a white background. Good work on those, the first two are pretty much the two designs I was thinking about already! Except there is no way I could have made them as good as these
Thanks for the advice! I am currently happy with the way BlazeLoader is (for a first release) as I have gotten rid of all the major bugs except the one that seems to prevent forge from properly loading. I definitely want to fix that bug before anything else.
That's totally fair, I was really just speaking from past experience really, nothing hurts the cause of a software product more than a ropey first release, apart from maybe clueless devs but you don't have that problem
The other thing to bear in mind is that you're not really treading on anyone's toes since my loader is firmly aimed at client-side non-game-changing mods and Forge is a huge API for seriously-game-changing mods so you're sat neatly in the middle. In fact I hope that in time we come to refer cases to each other based on which is the most suitable platform for the job, I've already pointed a couple of people in your direction and would be forever grateful if you'd return the favour by pointing people in my direction if you feel LiteLoader is more suitable for their needs.
Anyway, those first two logos are pretty cool! I think the first one is the best, except it could be slightly darker (to help the word blaze stand out) and it could use a small border to prevent the background from blending in if it is not on a white background. Good work on those, the first two are pretty much the two designs I was thinking about already! Except there is no way I could have made them as good as these
They were only rough drafts so I'll happily poke at them till you're happy. The font is one called Robo and I felt it really fit well with the text. I did knock up a few with the "2D blaze" motif that's in the last example but I couldn't really get it how I wanted despite really liking the idea. I take the point about the border on the first one but wasn't sure what aspect/crop to use but figured it would be nice to have the "blurred fire" backdrop as a separate part so that it could be used as website backdrop or similar with the logo as a transparent png. I'll add a border to it though as well.
That's totally fair, I was really just speaking from past experience really, nothing hurts the cause of a software product more than a ropey first release, apart from maybe clueless devs but you don't have that problem
The other thing to bear in mind is that you're not really treading on anyone's toes since my loader is firmly aimed at client-side non-game-changing mods and Forge is a huge API for seriously-game-changing mods so you're sat neatly in the middle. In fact I hope that in time we come to refer cases to each other based on which is the most suitable platform for the job, I've already pointed a couple of people in your direction and would be forever grateful if you'd return the favour by pointing people in my direction if you feel LiteLoader is more suitable for their needs.
They were only rough drafts so I'll happily poke at them till you're happy. The font is one called Robo and I felt it really fit well with the text. I did knock up a few with the "2D blaze" motif that's in the last example but I couldn't really get it how I wanted despite really liking the idea. I take the point about the border on the first one but wasn't sure what aspect/crop to use but figured it would be nice to have the "blurred fire" backdrop as a separate part so that it could be used as website backdrop or similar with the logo as a transparent png. I'll add a border to it though as well.
I'd be glad to point people towards LiteLoader, and I even have an old un-released ML mod that I need to port to a better system! It was basically a tweak plugin for Rei's minimap, but ML was extreme overkill for it and some of ML's stuff even got in the way. I think if I do finish it I will release a Forge, BL, and LiteLoader version since in theory it never has to be updated (except with ML...).
The font you used is great, it really does fit name! I really appreciate you making the banners!
Will the first 1.7 release be pretty much the current features but updated or will it have new some newer features (mob spawning etc)? I'm wondering because my primary mod is an entity mod, but I have a few alternative ideas for new mods that are more item and block based that I could make for 1.7
I will probably not add many API changes until I can see the code of 1.7. With all that removing block and item IDs, refactoring 25K lines of code, and all the other changes I will probably wait to see what API needs to be fixed first. If you want to work on an Item or Block mod you are probably fine since I do plan to re-implement item and block IDs for the API.
Ok cool, I understand I'll probably need to have a look at how boats and entity rendering are handled too, because the rendering system was completely rewritten and boats changed slightly ( I extend boats in my Airships for the controls) so that will probably take up most of my time! Hopefully the changes in 1.7 aren't overly drastic, though I have a feeling it's not going to be as "mod friendly" as it's made out to be
The code changes are big but not huge, as far as I could tell from obfuscated sources. For the controls, take a look at the horse controls. They work very similar to the old boat controls. I hope your updating goes well!
Ok so I earlier started to implement this in the method "RenderBlocks.renderBlockByRenderType()", but I was using
Would this work? I thought you could check interfaces by using instanceof.
EDIT: Oh yeah that is in a class that extends RenderBlocks
Yes I believe that would work. I wasn't sure myself when I wrote that code, hence the overly complicated method.
But if all else fails we can always try it and see what happens.
If you want to contact me, try going through Discord or you can find me on GitHub where I am still updating the below mods (and more):
PRESENCE FOOTSTEPS - (github)
VOID FOG - (github)
Ok I finally looked at the places where RenderBlock is instanced, and I don't think this will be easy at all. Instead of having a single RenderBlock and using it for all blocks (which it fully supports and is designed to do), there are TEN instances all running at the same time to render different types of blocks! TEN! Of the same class with the same parameters, same instance variables, same everything! Mojang!
Do you think it is possible to redefine the RenderBlocks class using the tweaker?
I've heard that it allows you to load alternate versions of classes before the game starts. (don't quote me on that).
If you want to contact me, try going through Discord or you can find me on GitHub where I am still updating the below mods (and more):
PRESENCE FOOTSTEPS - (github)
VOID FOG - (github)
Hmm that would probably work, but the way I have BL set up now it can be started without the tweak launcher if necessary. Currently I have 1/10 instances of RenderBlocks overridden...
I think the spawn entity and packet should be doable, I will work on those. Also thanks for pointing out the ApiGUI and the other thing. The localisations is something I have not been able to figure out even in my other mods. I liked it a lot better when there was a method "getUntranslateableName()" or something like that that was automatically called on mod blocks. Of course it was removed soon after.
EDIT: ApiGUI is already called ApiGui.
Given that it's ModLoader, probably very badly.
That is a good point, but I will probably end up having to rewrite it anyway
lol some of ModLoader's stuff isn't bad, it's really only the stuff that changed since 1.3.2 that is terrible. After that he didn't really update, he just wrote workarounds.
Well indeed, but I'd also advise caution in going too far down any route right now given how many things change in 1.7, you may be inventing solutions for things which are already solved.
Good point. I have actually been thinking hard on the removal of block IDs. I have yet to see (unobfuscated) how that works from a code perspective, but from what I saw from rej it looks like the game assigns block IDs automatically, which could make mod load order a nightmare. And if a mod loads before a vanilla block? All your block IDs are screwed up and bye bye world.
That would be cool, but I don't think it is quite ready. I could release a beta version, though. I really need to write those batch scripts to automate building a zip...
Yeah, I am going to advertise it again on /r/moddingmc when I release it.
Back before I used MCP I used to always strive to have Macros updated in record time so that it could be released before all the mods which were waiting for MCP, it worked, so I'd say for sure that it's a good way to raise awareness of your API. At the same time I'd warn against releasing something half-baked, as it will only hurt you in the long run. So basically: if you get it to a state you're happy with, then definitely release ASAP to capture attention; if you're not, then better to release something stable and rely on other means of promotion - of which there are plenty in this community.
I had a little time earlier and mocked up some ideas for logos for you (since you still seem to be lacking any branding for this) and if you like any of them I don't mind developing a little further. These are just the ones I was happy with but I have others if none of them are to your liking:
Also I made the blaze rig in 3dsmax and have a whole bunch of renders if you just wanted that to make your own logo.
Thanks for the advice! I am currently happy with the way BlazeLoader is (for a first release) as I have gotten rid of all the major bugs except the one that seems to prevent forge from properly loading. I definitely want to fix that bug before anything else. Anyway, those first two logos are pretty cool! I think the first one is the best, except it could be slightly darker (to help the word blaze stand out) and it could use a small border to prevent the background from blending in if it is not on a white background. Good work on those, the first two are pretty much the two designs I was thinking about already! Except there is no way I could have made them as good as these
That's totally fair, I was really just speaking from past experience really, nothing hurts the cause of a software product more than a ropey first release, apart from maybe clueless devs but you don't have that problem
The other thing to bear in mind is that you're not really treading on anyone's toes since my loader is firmly aimed at client-side non-game-changing mods and Forge is a huge API for seriously-game-changing mods so you're sat neatly in the middle. In fact I hope that in time we come to refer cases to each other based on which is the most suitable platform for the job, I've already pointed a couple of people in your direction and would be forever grateful if you'd return the favour by pointing people in my direction if you feel LiteLoader is more suitable for their needs.
They were only rough drafts so I'll happily poke at them till you're happy. The font is one called Robo and I felt it really fit well with the text. I did knock up a few with the "2D blaze" motif that's in the last example but I couldn't really get it how I wanted despite really liking the idea. I take the point about the border on the first one but wasn't sure what aspect/crop to use but figured it would be nice to have the "blurred fire" backdrop as a separate part so that it could be used as website backdrop or similar with the logo as a transparent png. I'll add a border to it though as well.
I'd be glad to point people towards LiteLoader, and I even have an old un-released ML mod that I need to port to a better system! It was basically a tweak plugin for Rei's minimap, but ML was extreme overkill for it and some of ML's stuff even got in the way. I think if I do finish it I will release a Forge, BL, and LiteLoader version since in theory it never has to be updated (except with ML...).
The font you used is great, it really does fit name! I really appreciate you making the banners!
I will probably not add many API changes until I can see the code of 1.7. With all that removing block and item IDs, refactoring 25K lines of code, and all the other changes I will probably wait to see what API needs to be fixed first. If you want to work on an Item or Block mod you are probably fine since I do plan to re-implement item and block IDs for the API.
The code changes are big but not huge, as far as I could tell from obfuscated sources. For the controls, take a look at the horse controls. They work very similar to the old boat controls. I hope your updating goes well!