Without any official word from him we'll never really know, but I think it's up to community members still present to provide good avenues for players to follow in his stead. My biggest fear really is that someone will just make some half-assed "modloader reloaded" basically taking his stuff and recompiling it against the new codebase, I feel like that would be the most damaging thing given how creaky and outdated modloader is, keeping it on life support would seem to be the most damaging thing anyone could do, especially if it were just to grab glory for themselves without really caring about the community either.
That's why I'm actually really glad you're undertaking this and why I'm trying to offer you as much help as I can, choice is good, moving forward is good, and people respect you already for providing the modloader patches so I think they'll take your API seriously. This is all good, someone trying to keep modloader alive is the biggest potential bad waiting to happen.
In my ModLoader patch I actually rewrote several parts of his code because I could not understand what was happening. Loops inside of loops inside of recursive functions all inside an 8-element switch block? Wut? I am glad you are helping with this because with APIs multiple opinions are far better than one. Perfect comic, BTW!
In my ModLoader patch I actually rewrote several parts of his code because I could not understand what was happening. Loops inside of loops inside of recursive functions all inside an 8-element switch block? Wut?
True but never underestimate the ability for decompilation to make normal code look like spaghetti code, it might not all have been like that before. I mean it could have been but there's at least room for uncertainty, plus with game code the prettiest solution isn't always the most efficient and sometimes hacky things are worthwhile if they buy you a lot of performance, try explaining that one to kids just out of university who think that there really is only one way to code and that's the way they were taught! But anyway that's off topic and really only serves to highlight another failing with ML which is that Risu never released the source, instead forcing people to decompile it and leaving them to draw their own conclusions.
I am glad you are helping with this because with APIs multiple opinions are far better than one.
Absolutely, it's easy to over-design when building an API and as you say discussion is good. Both LiteLoader and Macros (which in its own way kind of is a full-blown API) are make heavy use of reflection so if there's anything I can help with in that area then let me know.
Both are open source. There shouldn't be any issue.
Just because you can do something doesn't mean you should, and you still have to respect the license, although in this specific case that's not really an issue. Open source does not necessarily mean free-for-all though. Besides, I wasn't really commenting on the open/closed source nature I just said Huricaaane probably wouldn't be too happy. It's more a case of being polite than whether it's technically possible or not.
True but never underestimate the ability for decompilation to make normal code look like spaghetti code, it might not all have been like that before. I mean it could have been but there's at least room for uncertainty, plus with game code the prettiest solution isn't always the most efficient and sometimes hacky things are worthwhile if they buy you a lot of performance, try explaining that one to kids just out of university who think that there really is only one way to code and that's the way they were taught! But anyway that's off topic and really only serves to highlight another failing with ML which is that Risu never released the source, instead forcing people to decompile it and leaving them to draw their own conclusions.
Absolutely, it's easy to over-design when building an API and as you say discussion is good. Both LiteLoader and Macros (which in its own way kind of is a full-blown API) are make heavy use of reflection so if there's anything I can help with in that area then let me know.
If you don't already read xkcd you really should
Just because you can do something doesn't mean you should, and you still have to respect the license, although in this specific case that's not really an issue. Open source does not necessarily mean free-for-all though. Besides, I wasn't really commenting on the open/closed source nature I just said Huricaaane probably wouldn't be too happy. It's more a case of being polite than whether it's technically possible or not.
I do have a reflection question, actually! The way I am currently doing reflection (to handle re-obfuscation) is to iterate through all declared fields and check the type. When the correct field is found that field is used (set accessible, get/set, etc.) I only do this when the code is called only once or only during already slow tasks (world loading, connecting to servers, etc.) Is this good or is there a better way? I actually had another question but I ended up figuring it out (final fields... they suck... in multiple ways...). Off topic TIL that the java access visibility hierarchy is public>protected>package>private, not public>package>protected>private. I thought my IDE was glitching when it let me access protected fields...
Loving the new commit! Calender features are going to be great for little notifications and bigger things like digital clocks in-game to mobs and blocks, It's going to be really useful I'm really glad I found Blazeloader, and I'm looking forward to porting my Airship and a WIP mod I'm working on to it
I'm glad you like it! I am actually planning on making another calendar system using the in-game tick and minecraft time units. It would be divided into "ticks" and "days". I day is equal to 24000 ticks (20 IRL minutes). This would let mods create in game clocks that are tied to both IRL time and in-game time.First run using TweakLauncher on vanilla Minecraft! Started fine and there is NO jar modding involved! Also first run out of dev environment!
The new features are awesome! Sample mod seems really cool too and I've been poking around in the source Will we be able to register Entities/Items/Blocks soon?
Entities are next on my list, but currently items are automatically registered if they extend Item.class. The constructor in Item adds the Item to the ItemList automatically. Blocks are the same way, although unlike items they throw an exception if there is already a block with that ID. I do plan to add a function to override an existing block, however. Tell me if there are other features you want and I will add them as well! Also if you want to try the API in the normal (non-MCP) game it is functional in it's current state. There are two ways to install it: It can be installed into the jar (manually or with a launcher like magiclauncher), or it can be loaded without modding using the vanilla launcher magics. If you want to try the second method (and maybe find out why it doesn't work with forge?), I can give you my launcher profile files.
Awesome! Glad the Entity A.P.I is in place. Going to start porting my Airship mod over now Would it be possible to add a method to the Entity A.P.I that returns a unique Entity ID?
It should be, I will look some more at the entity list! If anything I will implement it the same way as my block and item unique ID methods (start at 0, increment until that number is free, return it, and start there the next time the method is called.
Awesome! Glad the Entity A.P.I is in place. Going to start porting my Airship mod over now Would it be possible to add a method to the Entity A.P.I that returns a unique Entity ID?
Entity ID method is done, but I have not tested it. It should work fine though.
Managed to get WMLL running on BL, however I have a couple of issues.
The rendering WMLL does flickers very quickly; the same implementation in Forge/ModLoader does not flicker (using eventPostTick()).
When starting the game with BL loaded, it seems to nullify both my username and session ID.
The first one may have to do with the start of runTick() re-drawing the screen before WMLL has updated it's graphics. I will try to add an onTick() into the entityRender, which is where ModLoader triggers from. I don't fully know what is going on with the second, but I have not had this issue in MCP using a custom Start.class. My username is always "acomputerdog" and my session ID is null. Are you running in MCP or in the normal game?
I don't fully know what is going on with the second, but I have not had this issue in MCP using a custom Start.class. My username is always "acomputerdog" and my session ID is null. Are you running in MCP or in the normal game?
I have no problem with you stealing the debug start class from liteloader which allows you to specify your username and password on the command line to actually log in to minecraft.net. This is useful because it actually allows you to test network mods on live servers.
I have no problem with you stealing the debug start class from liteloader which allows you to specify your username and password on the command line to actually log in to minecraft.net. This is useful because it actually allows you to test network mods on live servers.
(In regard to a mod that gives realistic animal genetics):
Would you really rather have bees that make diamonds and oil with magical genetic blocks?
... did I really ask that?
Ok I tried both my new tick function and the old, and both had the flickering you were talking about. I am going to go peek at modloader and see what it is doing differently.
This looks very interesting. It's most definitely an improvement over modloader.
I would like to see block and item rendering handled through an interface rather than render types.
You could just implement the interface in the block class and then the game will just use the rendering logic from there.
Here's an example of how it would be used:
public class ExampleBlock extends Block implements IRenderSpecial {
public ExampleBlock(int par1, Material par2Material) {
super(par1, par2Material);
}
/**
* Renders the block at the given coordinates
*/
@Override
public boolean renderWorldBlock(RenderBlocks renderer, int x, int y, int z) {
return false;
}
/**
* Renders the block as an item in the inventory
*/
@Override
public void renderInventoryBlock(RenderBlocks renderer, int metadata) {
}
/**
* Returns true if the contents of renderInventoryBlock must be used in place of the standard procedure
*/
@Override
public boolean overrideInventoryRender() {
return false;
}
}
In RenderBlocks it can just check if the blocks class implements the interface and if so call the appropriate method.
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):
This looks very interesting. It's most definitely an improvement over modloader.
I would like to see block and item rendering handled through an interface rather than render types.
You could just implement the interface in the block class and then the game will just use the rendering logic from there.
Here's an example of how it would be used:
public class ExampleBlock extends Block implements IRenderSpecial {
public ExampleBlock(int par1, Material par2Material) {
super(par1, par2Material);
}
/**
* Renders the block at the given coordinates
*/
@Override
public boolean renderWorldBlock(RenderBlocks renderer, int x, int y, int z) {
return false;
}
/**
* Renders the block as an item in the inventory
*/
@Override
public void renderInventoryBlock(RenderBlocks renderer, int metadata) {
}
/**
* Returns true if the contents of renderInventoryBlock must be used in place of the standard procedure
*/
@Override
public boolean overrideInventoryRender() {
return false;
}
}
In RenderBlocks it can just check if the blocks class implements the interface and if so call the appropriate method.
Honestly I don't really know how minecraft's block and item rendering works, but I will try to implement this. If anything I can create an InterfaceRenderer that extends the render type and accepts an IRenderSpecial in the constructor.
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.
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):
In my ModLoader patch I actually rewrote several parts of his code because I could not understand what was happening. Loops inside of loops inside of recursive functions all inside an 8-element switch block? Wut? I am glad you are helping with this because with APIs multiple opinions are far better than one. Perfect comic, BTW!
Both are open source. There shouldn't be any issue.
True but never underestimate the ability for decompilation to make normal code look like spaghetti code, it might not all have been like that before. I mean it could have been but there's at least room for uncertainty, plus with game code the prettiest solution isn't always the most efficient and sometimes hacky things are worthwhile if they buy you a lot of performance, try explaining that one to kids just out of university who think that there really is only one way to code and that's the way they were taught! But anyway that's off topic and really only serves to highlight another failing with ML which is that Risu never released the source, instead forcing people to decompile it and leaving them to draw their own conclusions.
Absolutely, it's easy to over-design when building an API and as you say discussion is good. Both LiteLoader and Macros (which in its own way kind of is a full-blown API) are make heavy use of reflection so if there's anything I can help with in that area then let me know.
If you don't already read xkcd you really should
Just because you can do something doesn't mean you should, and you still have to respect the license, although in this specific case that's not really an issue. Open source does not necessarily mean free-for-all though. Besides, I wasn't really commenting on the open/closed source nature I just said Huricaaane probably wouldn't be too happy. It's more a case of being polite than whether it's technically possible or not.
I do have a reflection question, actually! The way I am currently doing reflection (to handle re-obfuscation) is to iterate through all declared fields and check the type. When the correct field is found that field is used (set accessible, get/set, etc.) I only do this when the code is called only once or only during already slow tasks (world loading, connecting to servers, etc.) Is this good or is there a better way? I actually had another question but I ended up figuring it out (final fields... they suck... in multiple ways...). Off topic TIL that the java access visibility hierarchy is public>protected>package>private, not public>package>protected>private. I thought my IDE was glitching when it let me access protected fields...
I'm glad you like it! I am actually planning on making another calendar system using the in-game tick and minecraft time units. It would be divided into "ticks" and "days". I day is equal to 24000 ticks (20 IRL minutes). This would let mods create in game clocks that are tied to both IRL time and in-game time.First run using TweakLauncher on vanilla Minecraft! Started fine and there is NO jar modding involved! Also first run out of dev environment!
Entities are next on my list, but currently items are automatically registered if they extend Item.class. The constructor in Item adds the Item to the ItemList automatically. Blocks are the same way, although unlike items they throw an exception if there is already a block with that ID. I do plan to add a function to override an existing block, however. Tell me if there are other features you want and I will add them as well! Also if you want to try the API in the normal (non-MCP) game it is functional in it's current state. There are two ways to install it: It can be installed into the jar (manually or with a launcher like magiclauncher), or it can be loaded without modding using the vanilla launcher magics. If you want to try the second method (and maybe find out why it doesn't work with forge?), I can give you my launcher profile files.
It should be, I will look some more at the entity list! If anything I will implement it the same way as my block and item unique ID methods (start at 0, increment until that number is free, return it, and start there the next time the method is called.
Entity ID method is done, but I have not tested it. It should work fine though.
The first one may have to do with the start of runTick() re-drawing the screen before WMLL has updated it's graphics. I will try to add an onTick() into the entityRender, which is where ModLoader triggers from. I don't fully know what is going on with the second, but I have not had this issue in MCP using a custom Start.class. My username is always "acomputerdog" and my session ID is null. Are you running in MCP or in the normal game?
I have no problem with you stealing the debug start class from liteloader which allows you to specify your username and password on the command line to actually log in to minecraft.net. This is useful because it actually allows you to test network mods on live servers.
Oh that would be great! Where could I find that?
I added a new eventRenderTick() that may help with the flickering. It is worth a shot.
That's interesting. When running in Forge, what happens if you hit F1 to hide the GUI?
If I hit F1, all of the GUI hides except for WMLL, which flickers. I had just assumed it was a mod conflict on my end, and did not worry about it.
* Promoting this week: Captive Minecraft 4, Winter Realm. Aka: Vertical Vanilla Viewing. Clicky!
* My channel with Mystcraft, and general Minecraft Let's Plays: http://www.youtube.com/user/Keybounce.
* See all my video series: http://www.minecraftforum.net/forums/minecraft-editions/minecraft-editions-show-your/2865421-keybounces-list-of-creation-threads
(In regard to a mod that gives realistic animal genetics):
Would you really rather have bees that make diamonds and oil with magical genetic blocks?
... did I really ask that?
Here. You need to add the launcher jar into the workspace because it uses the Yggsdrasil support from there.
Thanks a lot!
Ok I tried both my new tick function and the old, and both had the flickering you were talking about. I am going to go peek at modloader and see what it is doing differently.
Woop fixed the rendering! Use eventRenderTick() to perform rendering and there will be no flickering! I will update the repo soon!
EDIT: Actually I think I will just move the call to eventTick(), so that can be used.
I would like to see block and item rendering handled through an interface rather than render types.
You could just implement the interface in the block class and then the game will just use the rendering logic from there.
Here's an example of how it would be used:
In RenderBlocks it can just check if the blocks class implements the interface and if so call the appropriate method.
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)
Honestly I don't really know how minecraft's block and item rendering works, but I will try to implement this. If anything I can create an InterfaceRenderer that extends the render type and accepts an IRenderSpecial in the constructor.
In renderblocks you would add something like this:
Edit: Stupid forum. Posting stuff before I'm done writing.
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)