Wait, has Notch committed to removing obfuscation? That would be great news, if true!
What rock have you been developing mods under? That's been his plan the entire time, officially. The current version was SUPPOSED to have the modapi (which he says is the REAL source code of minecraft, unobfuscated, with comments and everything) but he says that it was delayed until version 1.8.
In other posts Notch has stated that he intends for there to be a mod marketplace, where users would be able to pay money for mods. He also states that particularly desirable mods may be licensed directly by Mojang and included in the regular game.(I think he already bought one mod a few months back, the one that compresses chunks). If Notch buys any mods at all, a mod that expands and repairs redstone completely seems to be something that has a excellent chance of being purchased. You may end up with a nice paycheck at the end of the day after all, Eloraam.
And, presumably, automatic mod installation would be part of the package. (so my idea above might be defunct in 2 months)
Or if Notch doesn't buy it, a single mod that is buildcraft/industrialcraft/integrated redstone/wireless redstone, offered for, say $1.99 or $2.99 (and $10 for the server license) could sell tens of thousands of copies. (there's 3 million people who have purchased minecraft for $10-$15 a copy. Those mods combined would be more content than the entire original game)
I mentioned those 4 mods because they synergize well with each other (each mod lets you do more things with the other mods), and because banding together to offer a single package offers more value to buyers (and cuts transaction costs)
Since y.class is included in minecraftForge, i assume it includes the fix you mentioned here:
If this is the case, does forge include the whole RedstonePower Core or will we have to install it anyway?
Yes, MinecraftForge does fix that bug. RedPower Core 1.6.0 doesn't include y.class anymore, but it's not quite out yet.
RedPower Core has a lot of code that has nothing to do with MinecraftForge. y.class was the only overlap.
RedPower Core 1.5.1 has the exact same y.class file, so IF you are running MinecraftForge on your server, you don't need to install RedPower Core in the .jar anymore - you can put it into the server mods directory like any other base-clean mod. You need the bugfix to run RedPower on a server, but you get that with MinecraftForge now.
Offtopic: Anyone has a suggestion for a fly mod (I don't like SPC's /fly) which doesn't need to overwrite gs.class (Player) used by the Forge? Zombe's and CJB both overwrite it
Nice.
Two questions:
1) It uses less original classes than MCE?
2) What about block id's? I'm currently using about 800 id's, so having infinite sprites are good when you also have many id's.
Good luck in development, I really respect you, Eloraam and Spacetoad.
Since Minecraft Forge needs only a couple of hooks in base files, can you get Kahr onboard? He updated xau's texture patcher, and presumably can add a patcher for Minecraft Forge as well, which would basically mean "no more conflicts". And if you would manage to get Flan/SDK, Rusigami, Shockah and smith_61 onboard, that would mean "NEVER more conflicts and only one mod to install instead of six".
This open source project was a really good idea!
But it should just be the beginning.
Let's explain:
At the moment there are many different APIs around there and it is quite complicate for non advanced users fo find the right APIs, check for incompatibilities and so on.
And not all modders are really willing to look after those issues and to create patches to gain better compatibility.
The solution:
1. This project should finally focus on to create a merged API set for about EVERYTHING that modders need to avoid the need to edit the original minecraft classes by themselves.
Important system based enhancements like OptiFine should be integrated from the beginning to gain better performance.
While adding enough hooks to run most of the major mods has always been an objective of this, adding something like OptiFine is not. That's way outside the scope of this project.
While adding enough hooks to run most of the major mods has always been an objective of this, adding something like OptiFine is not. That's way outside the scope of this project.
Glad to hear it. All this talk of integrating other mods into this one was my major hesitation with regards to this project. If you guys are against including stuff like MCE, then I am much more open to it
I think your timing couldn't have been better on this. I think with the release of the Aether, mod compatibility has suddenly become a much bigger issue than it was before, and after taking a look at ShockAhPI, I really don't think that's the general-purpose solution the community should be leaning towards adopting.
I also really like how open you seem to be to integrating new hooks and taking on new contributing authors. Currently, my mod (Better Than Wolves) is dependent upon modifying the world.class, which I frigging hate, and which could easily be solved with the addition of some VERY simple hooks.
Anyways, great idea guys. I'll investigate a little deeper before hopping on board (I'm very hesitant to require additional downloads for my mod), but you've definitely peeked my curiosity
Glad to hear it. All this talk of integrating other mods into this one was my major hesitation with regards to this project. If you guys are against including stuff like MCE, then I am much more open to it :smile.gif:
I think your timing couldn't have been better on this. I think with the release of the Aether, mod compatibility has suddenly become a much bigger issue than it was before, and after taking a look at ShockAhPI, I really don't think that's the general-purpose solution the community should be leaning towards adopting.
I also really like how open you seem to be to integrating new hooks and taking on new contributing authors. Currently, my mod (Better Than Wolves) is dependent upon modifying the world.class, which I frigging hate, and which could easily be solved with the addition of some VERY simple hooks.
Anyways, great idea guys. I'll investigate a little deeper before hopping on board (I'm very hesitant to require additional downloads for my mod), but you've definitely peeked my curiosity :smile.gif:
I would absolutely love to have BTW using MinecraftForge. It would make it worth us adding World overrides.
Even if you don't wish to become a contributing author, I'll gladly work with you to add whatever hooks you require. A lot of people use our mods together, and I really didn't want to disappoint them.
It's my intention at least to keep this API lean, and keep a lot of extra library code out of it. Core hooks and little else.
Also, the license for Forge is pretty permissive. You could always hotlink to the download from your forum thread.
I would absolutely love to have BTW using MinecraftForge. It would make it worth us adding World overrides.
Even if you don't wish to become a contributing author, I'll gladly work with you to add whatever hooks you require. A lot of people use our mods together, and I really didn't want to disappoint them.
It's my intention at least to keep this API lean, and keep a lot of extra library code out of it. Core hooks and little else.
Also, the license for Forge is pretty permissive. You could always hotlink to the download from your forum thread.
Thanks for the quick response man! I've tried to contact both Risugami and Shocker about potentially adding hooks in the past and got no reply out of either attempt, so having someone involved with an API that is actually responsive to those that will be using it is definitely important to me :wink.gif:
I'd be particularly hesitant about any API that started expanding block IDs and that kind of thing as that can be a real performance drain, and I really don't think it's required by anyone who doesn't use an EXTREME number of mods at the same time. Like, I think both BTW and the Aether are probably the most block-id hungry mods out there, with both of us using around 30 each, and even with both installed, a user would have enough block ids left for about 3 more mods of the same size before running out. Unless Mojang makes changes to the core architecture to permit more block ids, I think a line definitely needs to be drawn at some point with regards to just how much cross-compatibility should really be expected by a player.
So yeah, I don't think catering to the small minority of players that would use so many mods simultaneously as to require additional block IDs is worth the performance trade-off in terms of making the mods that use an API potentially unplayable on lower-end systems when they would run just fine otherwise.
Terrain and sprite indices are another story entirely though, and I am glad you decided to include that aspect in the API. I was actually investigating another solution to solve the terrain index problem before seeing this thread ( forum thread ), and it leads me to a question about the API:
Using your method of expanding terrain indices, would it be possible for me to retain my individual modloader-style texture-files, or would I be required to move all my textures into my own version of terrain.png? One of my hesitations with the other method I was considering is that it would basically break my mod's compatibility with all the texture packs that have already included support for it, and require them to rework their pack to adapt to my changes. If at all possible I'd very much like to avoid having that happen.
Since you briefly mention it, I think I'd definitely consider becoming a contributing author on this mod IF I sign on. Frankly, I think having this kind of collaborative effort going on between mod authors to help with compatibility is a brilliant idea, and one that is long overdo.
I'd be particularly hesitant about any API that started expanding block IDs and that kind of thing as that can be a real performance drain, and I really don't think it's required by anyone who doesn't use an EXTREME number of mods at the same time. Like, I think both BTW and the Aether are probably the most block-id hungry mods out there, with both of us using around 30 each, and even with both installed, a user would have enough block ids left for about 3 more mods of the same size before running out. Unless Mojang makes changes to the core architecture to permit more block ids, I think a line definitely needs to be drawn at some point with regards to just how much cross-compatibility should really be expected by a player.
To be honest, the conversation about MCE was just a spillover from my own thread. I'm not expecting to see that become a part of Forge itself. A Forge-compatible extender, perhaps, but not the core.
Terrain and sprite indices are another story entirely though, and I am glad you decided to include that aspect in the API. I was actually investigating another solution to solve the terrain index problem before seeing this thread ( forum thread ), and it leads me to a question about the API:
Using your method of expanding terrain indices, would it be possible for me to retain my individual modloader-style texture-files, or would I be required to move all my textures into my own version of terrain.png? One of my hesitations with the other method I was considering is that it would basically break my mod's compatibility with all the texture packs that have already included support for it, and require them to rework their pack to adapt to my changes. If at all possible I'd very much like to avoid having that happen.
The normal way is to add your own sprite pages, which contain only your own sprites. I've been using this method for quite a while myself, because my own mods use so many terrain sprites (at last count, RedPower+Integrated Redstone was using 288).
The texture pack makers for my mods have had no trouble adapting to that format. It only takes a couple minutes to copy-paste the individual textures into a sprite sheet. If they've already taken the time to make sprites for your mod, I don't think too many of them would mind that extra step.
Adding ModLoader-style overrides is possible, but it's a fair bit of code, and I've never personally been happy with the ModLoader method anyway. It uses a dynamic texture updating hook to replace textures, which among other things causes textures on blocks to display as purple rectangles after load until the game starts running. Those visual anomalies don't happen if you use your own sprite page.
Since you briefly mention it, I think I'd definitely consider becoming a contributing author on this mod IF I sign on. Frankly, I think having this kind of collaborative effort going on between mod authors to help with compatibility is a brilliant idea, and one that is long overdo.
To be honest, the conversation about MCE was just a spillover from my own thread. I'm not expecting to see that become a part of Forge itself. A Forge-compatible extender, perhaps, but not the core.
Yup, that would be exactly my approach to it actually.
The normal way is to add your own sprite pages, which contain only your own sprites. I've been using this method for quite a while myself, because my own mods use so many terrain sprites (at last count, RedPower+Integrated Redstone was using 288).
Fair enough, and yeah, it certainly would be nice to get rid of that flash of day-glow pink upon load
Some other things I would LOVE to potentially see added to this mod:
-A unified system for mods to add achievements to the game.
-A unified system for playing custom audio files (ala AudioMod).
-A unified block interface for common block functionality (testing if a block is replaceable, testing for whether it is air, returning a facing). I already have a common interface for my mod blocks, but I think such a thing would serve the community VERY well and help correct the OOP fail that is much of the Minecraft code-base.
Anyways, perhaps I'm getting a bit ahead of myself, but let's just say that I am very excited by the potential that a common standard like this represents
BTW, do you guys happen to have an IRC channel or something similar where I could communicate with you directly? My apologies, but I've had to turn off my PM entirely on this site to avoid the flood of messages I was getting, and there are a few questions that I have with regards to this thing that would probably best not be asked to the community at large.
-A unified block interface for common block functionality (testing if a block is replaceable, testing for whether it is air, returning a facing). I already have a common interface for my mod blocks, but I think such a thing would serve the community VERY well and help correct the OOP fail that is much of the Minecraft code-base.
There's actually a new hook in Forge already for overriding block replacement. RedPower uses it as part of its multi-part block system.
Anyways, perhaps I'm getting a bit ahead of myself, but let's just say that I am very excited by the potential that a common standard like this represents :smile.gif:
BTW, do you guys happen to have an IRC channel or something similar where I could communicate with you directly? My apologies, but I've had to turn off my PM entirely on this site to avoid the flood of messages I was getting, and there are a few questions that I have with regards to this thing that would probably best not be asked to the community at large.
A common framework is the reason that SpaceToad and I collaborated on this in the first place. Getting a couple prominent mods to use it will help adoption a lot.
We don't have an irc channel right now, but if you want to meet on esper.net, I'm on as Eloraam. Pick a channel, or just send me a PM on irc.
Hello I noticed this gives infinite terrain and sprites? does it only work for the mods that that are made using this API? or does it just give infinite terrain and sprites in general like MCE? I used to use MCE but now that it isnt compatible with ShockAhPI and it also breaks the nether i havent been able to use it. I DID download Minecraft Forge client and installed it and after installing all of my mods and correcting block id problems and what not im still getting the "No more sprite indices left" error when opening minecraft
Just wanted to announce that I (and Better Than Wolves) am on board with this API. I'll be using it in my next release.
Remember before when we had issues? I just wanted to formally apologize:
It has come to my attention that my actions of trolling could be seen as offensive, annoying, and selfish. I never intended to make you not like me. I want to you to understand that i was merely trying to point out that some issues I had with your mod, though i can see now that it may appear that i was trolling. Please accept my sincere apology. Moving forward, I will attempt to never to repeat these actions again. That said, I would very much appreciate it if you would forgive me.
Sincerely, your [future] mod-user Reddpandda2
So with that out of the way, keep up the great work!
Hello I noticed this gives infinite terrain and sprites? does it only work for the mods that that are made using this API? or does it just give infinite terrain and sprites in general like MCE? I used to use MCE but now that it isnt compatible with ShockAhPI and it also breaks the nether i havent been able to use it. I DID download Minecraft Forge client and installed it and after installing all of my mods and correcting block id problems and what not im still getting the "No more sprite indices left" error when opening minecraft
This mod is not like MCE and it only works with mods written with it - so spread the word, tell people about it, maybe they will use it! :smile.gif:
_______
I would like to see this API to have an eventual goal to replace modloader.
Remember before when we had issues? I just wanted to formally apologize:
It has come to my attention that my actions of trolling could be seen as offensive, annoying, and selfish. I never intended to make you not like me. I want to you to understand that i was merely trying to point out that some issues I had with your mod, though i can see now that it may appear that i was trolling. Please accept my sincere apology. Moving forward, I will attempt to never to repeat these actions again. That said, I would very much appreciate it if you would forgive me.
Sincerely, your [future] mod-user Reddpandda2
So with that out of the way, keep up the great work!
No worries man. I appreciate the apology and I hope you understand the huge amount of pressure that comes along with having a few hundred thousand people suddenly turn their attention towards you and start making demands.
Under that strain, I can't say I've always behaved as I would have liked to either and have definitely been short tempered and downright hostile with folks on occasion.
So yeah man, don't give it another thought, and once again, I appreciate you saying the above.
What rock have you been developing mods under? That's been his plan the entire time, officially. The current version was SUPPOSED to have the modapi (which he says is the REAL source code of minecraft, unobfuscated, with comments and everything) but he says that it was delayed until version 1.8.
In other posts Notch has stated that he intends for there to be a mod marketplace, where users would be able to pay money for mods. He also states that particularly desirable mods may be licensed directly by Mojang and included in the regular game.(I think he already bought one mod a few months back, the one that compresses chunks). If Notch buys any mods at all, a mod that expands and repairs redstone completely seems to be something that has a excellent chance of being purchased. You may end up with a nice paycheck at the end of the day after all, Eloraam.
And, presumably, automatic mod installation would be part of the package. (so my idea above might be defunct in 2 months)
Or if Notch doesn't buy it, a single mod that is buildcraft/industrialcraft/integrated redstone/wireless redstone, offered for, say $1.99 or $2.99 (and $10 for the server license) could sell tens of thousands of copies. (there's 3 million people who have purchased minecraft for $10-$15 a copy. Those mods combined would be more content than the entire original game)
I mentioned those 4 mods because they synergize well with each other (each mod lets you do more things with the other mods), and because banding together to offer a single package offers more value to buyers (and cuts transaction costs)
I've had my head stuck in a code editor the whole time. I've barely come up for air. :wink.gif:
Yes, MinecraftForge does fix that bug. RedPower Core 1.6.0 doesn't include y.class anymore, but it's not quite out yet.
RedPower Core has a lot of code that has nothing to do with MinecraftForge. y.class was the only overlap.
RedPower Core 1.5.1 has the exact same y.class file, so IF you are running MinecraftForge on your server, you don't need to install RedPower Core in the .jar anymore - you can put it into the server mods directory like any other base-clean mod. You need the bugfix to run RedPower on a server, but you get that with MinecraftForge now.
Two questions:
1) It uses less original classes than MCE?
2) What about block id's? I'm currently using about 800 id's, so having infinite sprites are good when you also have many id's.
Good luck in development, I really respect you, Eloraam and Spacetoad.
While adding enough hooks to run most of the major mods has always been an objective of this, adding something like OptiFine is not. That's way outside the scope of this project.
Glad to hear it. All this talk of integrating other mods into this one was my major hesitation with regards to this project. If you guys are against including stuff like MCE, then I am much more open to it
I think your timing couldn't have been better on this. I think with the release of the Aether, mod compatibility has suddenly become a much bigger issue than it was before, and after taking a look at ShockAhPI, I really don't think that's the general-purpose solution the community should be leaning towards adopting.
I also really like how open you seem to be to integrating new hooks and taking on new contributing authors. Currently, my mod (Better Than Wolves) is dependent upon modifying the world.class, which I frigging hate, and which could easily be solved with the addition of some VERY simple hooks.
Anyways, great idea guys. I'll investigate a little deeper before hopping on board (I'm very hesitant to require additional downloads for my mod), but you've definitely peeked my curiosity
I would absolutely love to have BTW using MinecraftForge. It would make it worth us adding World overrides.
Even if you don't wish to become a contributing author, I'll gladly work with you to add whatever hooks you require. A lot of people use our mods together, and I really didn't want to disappoint them.
It's my intention at least to keep this API lean, and keep a lot of extra library code out of it. Core hooks and little else.
Also, the license for Forge is pretty permissive. You could always hotlink to the download from your forum thread.
Thanks for the quick response man! I've tried to contact both Risugami and Shocker about potentially adding hooks in the past and got no reply out of either attempt, so having someone involved with an API that is actually responsive to those that will be using it is definitely important to me :wink.gif:
I'd be particularly hesitant about any API that started expanding block IDs and that kind of thing as that can be a real performance drain, and I really don't think it's required by anyone who doesn't use an EXTREME number of mods at the same time. Like, I think both BTW and the Aether are probably the most block-id hungry mods out there, with both of us using around 30 each, and even with both installed, a user would have enough block ids left for about 3 more mods of the same size before running out. Unless Mojang makes changes to the core architecture to permit more block ids, I think a line definitely needs to be drawn at some point with regards to just how much cross-compatibility should really be expected by a player.
So yeah, I don't think catering to the small minority of players that would use so many mods simultaneously as to require additional block IDs is worth the performance trade-off in terms of making the mods that use an API potentially unplayable on lower-end systems when they would run just fine otherwise.
Terrain and sprite indices are another story entirely though, and I am glad you decided to include that aspect in the API. I was actually investigating another solution to solve the terrain index problem before seeing this thread ( forum thread ), and it leads me to a question about the API:
Using your method of expanding terrain indices, would it be possible for me to retain my individual modloader-style texture-files, or would I be required to move all my textures into my own version of terrain.png? One of my hesitations with the other method I was considering is that it would basically break my mod's compatibility with all the texture packs that have already included support for it, and require them to rework their pack to adapt to my changes. If at all possible I'd very much like to avoid having that happen.
Since you briefly mention it, I think I'd definitely consider becoming a contributing author on this mod IF I sign on. Frankly, I think having this kind of collaborative effort going on between mod authors to help with compatibility is a brilliant idea, and one that is long overdo.
I feel like i am stalking you.
To be honest, the conversation about MCE was just a spillover from my own thread. I'm not expecting to see that become a part of Forge itself. A Forge-compatible extender, perhaps, but not the core.
The normal way is to add your own sprite pages, which contain only your own sprites. I've been using this method for quite a while myself, because my own mods use so many terrain sprites (at last count, RedPower+Integrated Redstone was using 288).
The texture pack makers for my mods have had no trouble adapting to that format. It only takes a couple minutes to copy-paste the individual textures into a sprite sheet. If they've already taken the time to make sprites for your mod, I don't think too many of them would mind that extra step.
Adding ModLoader-style overrides is possible, but it's a fair bit of code, and I've never personally been happy with the ModLoader method anyway. It uses a dynamic texture updating hook to replace textures, which among other things causes textures on blocks to display as purple rectangles after load until the game starts running. Those visual anomalies don't happen if you use your own sprite page.
Sounds good to me.
Yup, that would be exactly my approach to it actually.
Fair enough, and yeah, it certainly would be nice to get rid of that flash of day-glow pink upon load
Some other things I would LOVE to potentially see added to this mod:
-A unified system for mods to add achievements to the game.
-A unified system for playing custom audio files (ala AudioMod).
-A unified block interface for common block functionality (testing if a block is replaceable, testing for whether it is air, returning a facing). I already have a common interface for my mod blocks, but I think such a thing would serve the community VERY well and help correct the OOP fail that is much of the Minecraft code-base.
Anyways, perhaps I'm getting a bit ahead of myself, but let's just say that I am very excited by the potential that a common standard like this represents
BTW, do you guys happen to have an IRC channel or something similar where I could communicate with you directly? My apologies, but I've had to turn off my PM entirely on this site to avoid the flood of messages I was getting, and there are a few questions that I have with regards to this thing that would probably best not be asked to the community at large.
Those two get my interest for sure. I've been thinking the same thing.
There's actually a new hook in Forge already for overriding block replacement. RedPower uses it as part of its multi-part block system.
A common framework is the reason that SpaceToad and I collaborated on this in the first place. Getting a couple prominent mods to use it will help adoption a lot.
We don't have an irc channel right now, but if you want to meet on esper.net, I'm on as Eloraam. Pick a channel, or just send me a PM on irc.
Remember before when we had issues? I just wanted to formally apologize:
It has come to my attention that my actions of trolling could be seen as offensive, annoying, and selfish. I never intended to make you not like me. I want to you to understand that i was merely trying to point out that some issues I had with your mod, though i can see now that it may appear that i was trolling. Please accept my sincere apology. Moving forward, I will attempt to never to repeat these actions again. That said, I would very much appreciate it if you would forgive me.
Sincerely, your [future] mod-user Reddpandda2
So with that out of the way, keep up the great work!
This mod is not like MCE and it only works with mods written with it - so spread the word, tell people about it, maybe they will use it! :smile.gif:
_______
I would like to see this API to have an eventual goal to replace modloader.
Ahh thanks! I will certainly do that, seems like a great idea that could lead to bigger and better mods, and also having many mods together at once (:
No worries man. I appreciate the apology and I hope you understand the huge amount of pressure that comes along with having a few hundred thousand people suddenly turn their attention towards you and start making demands.
Under that strain, I can't say I've always behaved as I would have liked to either and have definitely been short tempered and downright hostile with folks on occasion.
So yeah man, don't give it another thought, and once again, I appreciate you saying the above.