-snip-
Despite being a Linux user myself, I spent a considerable portion of tonight working on the Windows installation. It's getting a lot closer to being easy to use. Right now, the easiest way is to do an SVN pull (either downloading directly from SourceForge or using an SVN client (I think TortoiseSVN was mentioned for Windows users?)). Once you have that, just move the directory from the pull into a 'forge' subdirectory of your mcp folder, and run the setup.bat file.
-snip-
I've been a closet linux user, but I've been pushing into some windows dev and long since abandoned my very, very old distros. I don't even dual boot anymore. I'm not familiar with SVN, but I'm sure someone with a little spare time and a willingness to read things can figure it out. Thanks again.
EDIT: Successfully decompiled with modified base classes, the source isn't strictly necessary unless you intend to modify it with your own hooks, then, is it?
All in all, I think calling it difficult to install a bit of a misnomer. ;D
At any rate, will be converting my items to use the new ITexture formats and creating my sprite sheets. I'm excited to see an indices-free Equivalent Exchange. :happy.gif:
The idea is that it can be used either way. For large content mods like BTW, it's possible to include the Forge source directly.
For the general mod compatibility it would be better not to include MCForge in the individual mods, only to give a link to this thread. So installing a single older mod can not break the rest of the mods by installing an older version of MCForge.
On a side note, MCForge will have to be very strict about backwards compatibility to avoid breaking somewhat older mods.
For the general mod compatibility it would be better not to include MCForge in the individual mods, only to give a link to this thread. So installing a single older mod can not break the rest of the mods by installing an older version of MCForge.
On a side note, MCForge will have to be very strict about backwards compatibility to avoid breaking somewhat older mods.
Overall I agree with that assessment, but it's not my place to make that policy for everyone. It's a community project.
I don't expect all that much churn on the hooks, the important ones should stay pretty stable throughout the life of the project. The first few versions of any hook may change a couple times, but once it's figured out, it should stay figured out unless there's a really, really compelling reason to change it.
By the way, how is it easier to bind to a static function than an interface? I figured that mods that wanted to be compatible could just include the interface that was being linked against, but if you can explain to me why it's helpful, I can look at the changes you mentioned.
I've been a closet linux user, but I've been pushing into some windows dev and long since abandoned my very, very old distros. I don't even dual boot anymore. I'm not familiar with SVN, but I'm sure someone with a little spare time and a willingness to read things can figure it out. Thanks again.
EDIT: Successfully decompiled with modified base classes, the source isn't strictly necessary unless you intend to modify it with your own hooks, then, is it?
All in all, I think calling it difficult to install a bit of a misnomer. ;D
At any rate, will be converting my items to use the new ITexture formats and creating my sprite sheets. I'm excited to see an indices-free Equivalent Exchange. :happy.gif:
Odd, I'd heard that there were problems decompiling it. It worked for you? Interesting.
Just a follow-up to the texture swapping issue, I've studied the code and now I'm reasonably sure that I can set up a multiple Tessellator setup by modifying only Tessellator and WorldRenderer. I haven't made the change yet so I can't say for sure that I didn't miss something, but I'm going to give it a try quite soon.
It'll bring a performance boost to our custom texture support with relatively low impact. I don't think any mods override Tessellator itself, and only a couple rendering mods (like Optifine) touch WorldRenderer, which we override already anyway. Assuming I didn't miss anything, that's worth doing, so I'm on it.
By the way, how is it easier to bind to a static function than an interface? I figured that mods that wanted to be compatible could just include the interface that was being linked against, but if you can explain to me why it's helpful, I can look at the changes you mentioned.
I am looking from the point of view of OptiFine which has to overwrite the base rendering classes and simulate the functions of MinecraftForge in order to be compatible.
Currently OptiFine supports ModLoader and DynamicLights without having to compile against their classes, which is a big plus for me. It would be very nice if a support for MinecraftForge can also be added in this way.
A sample from RenderBlocks:
// TODO Added ModLoader
if(Config.hasModLoader())
{
return Config.callBoolean("ModLoader", "RenderWorldBlock", new Object[]{this, blockAccess, i, j, k, block, l});
}
Calling a static function has several advantages:
- it is simpler and easier to organize with reflection.
- if the implementation changes in the future (for example: who is a MultiPassRenderer and when it should multi-render), the change can be limited to the MinecraftForge classes and no change in WorldRenderer will be needed => no need to make a new OptiFine version. If the number of parameters changes, then a change will be needed but it is much simpler. I can even detect how many parameters are needed and support both the older and the newer version at once.
OptiFine modifies heavily the WorldRenderer, Tessellator and RenderGlobal in order to make the multithreading work. Having as little foreign code in there as possible helps a lot. The static method calls are for me the best way to do it.
Edit: The interfaces are fine, they can just be moved inside the MinecraftForge static method.
I have a question about the configuration class. Why is there a custom class for properties if there is a java.util.Properties class which can handle most of that if used as an instance in the Configuration class.
hey Spacetoad, uh... im not sure if it is because of minecraft forge im having this issue or not but id like ur feedback on it
java.io.EOFException
at java.util.zip.GZIPInputStream.readUByte(Unknown Source)
at java.util.zip.GZIPInputStream.readUShort(Unknown Source)
at java.util.zip.GZIPInputStream.readHeader(Unknown Source)
at java.util.zip.GZIPInputStream.<init>(Unknown Source)
at java.util.zip.GZIPInputStream.<init>(Unknown Source)
at as.a(SourceFile:8)
at tq.b(SourceFile:54)
at hi.b(SourceFile:45)
at rq.l(SourceFile:66)
at rq.b(SourceFile:56)
at da.a(SourceFile:95)
at net.minecraft.client.Minecraft.a(SourceFile:540)
at fu.a(SourceFile:101)
at da.a(SourceFile:72)
at da.f(SourceFile:120)
at da.e(SourceFile:108)
at net.minecraft.client.Minecraft.k(SourceFile:1299)
at net.minecraft.client.Minecraft.run(SourceFile:754)
at java.lang.Thread.run(Unknown Source)
java.io.EOFException
at java.util.zip.GZIPInputStream.readUByte(Unknown Source)
at java.util.zip.GZIPInputStream.readUShort(Unknown Source)
at java.util.zip.GZIPInputStream.readHeader(Unknown Source)
at java.util.zip.GZIPInputStream.<init>(Unknown Source)
at java.util.zip.GZIPInputStream.<init>(Unknown Source)
at as.a(SourceFile:8)
at tq.b(SourceFile:65)
at hi.b(SourceFile:45)
at rq.l(SourceFile:66)
at rq.b(SourceFile:56)
at da.a(SourceFile:95)
at net.minecraft.client.Minecraft.a(SourceFile:540)
at fu.a(SourceFile:101)
at da.a(SourceFile:72)
at da.f(SourceFile:120)
at da.e(SourceFile:108)
at net.minecraft.client.Minecraft.k(SourceFile:1299)
at net.minecraft.client.Minecraft.run(SourceFile:754)
at java.lang.Thread.run(Unknown Source)
Commands: 116
EDIT: It was Minecraftforge 1.0.1, i downgraded to 1.0.0 and it worked like a charm
EDIT2: I am currently trying to run:
this is my alternate load order, either way it crashes
EDIT3: i was wrong again
java.io.EOFException
at java.util.zip.GZIPInputStream.readUByte(Unknown Source)
at java.util.zip.GZIPInputStream.readUShort(Unknown Source)
at java.util.zip.GZIPInputStream.readHeader(Unknown Source)
at java.util.zip.GZIPInputStream.<init>(Unknown Source)
at java.util.zip.GZIPInputStream.<init>(Unknown Source)
at as.a(SourceFile:8)
at tq.b(SourceFile:54)
at hi.b(SourceFile:45)
at rq.l(SourceFile:66)
at rq.b(SourceFile:56)
at da.a(SourceFile:95)
at net.minecraft.client.Minecraft.a(SourceFile:540)
at fu.a(SourceFile:101)
at da.a(SourceFile:72)
at da.f(SourceFile:120)
at da.e(SourceFile:108)
at net.minecraft.client.Minecraft.k(SourceFile:1299)
at net.minecraft.client.Minecraft.run(SourceFile:754)
at java.lang.Thread.run(Unknown Source)
java.io.EOFException
at java.util.zip.GZIPInputStream.readUByte(Unknown Source)
at java.util.zip.GZIPInputStream.readUShort(Unknown Source)
at java.util.zip.GZIPInputStream.readHeader(Unknown Source)
at java.util.zip.GZIPInputStream.<init>(Unknown Source)
at java.util.zip.GZIPInputStream.<init>(Unknown Source)
at as.a(SourceFile:8)
at tq.b(SourceFile:65)
at hi.b(SourceFile:45)
at rq.l(SourceFile:66)
at rq.b(SourceFile:56)
at da.a(SourceFile:95)
at net.minecraft.client.Minecraft.a(SourceFile:540)
at fu.a(SourceFile:101)
at da.a(SourceFile:72)
at da.f(SourceFile:120)
at da.e(SourceFile:108)
at net.minecraft.client.Minecraft.k(SourceFile:1299)
at net.minecraft.client.Minecraft.run(SourceFile:754)
at java.lang.Thread.run(Unknown Source)
Commands: 116
EDIT4: sorry for all the edits eh heh... but this happens when im opening a world, works fine if i use a debugging batch file thing tho
EDIT5:My last flippin edit, it was a Radio mod i installed, went 1 by 1 till i found the culprit
I have to voice my support for this project. This is the greatest. Making an overarcing compatibility for these great mods.
I love the circuit mod. As rebuilding time consuming and large redstone cicuits is tedious.
Who doesn't love the Buildcraft pipes.
And nothing, nothing, would make me happier than Better than wolves and Alblaka's work being compatible. The work of these modders are easily the two greatest mods ever made.
Thought it would be good to provide some insight, if this is indeed any form of insight at all, as to how I installed the Forge to use with my MCP.
1) Downloaded the source AND client files (I'm an SSP only modder for now)
2) Placed the client's modified base files and the forge folder directly into my minecraft.jar in the MCP jars/bin folder. Even though I wanted to leave the forge folder out to force the source to reobfuscate with my mod (for convenience!) this was how I did it on my trial run.
3)Ran my update because I was way overdue. Ran my cleanup because I hadn't yet. :tongue.gif:
4) Decompiled the jar with the forge classes.. decompiling was successful, save for the 2 Error Hunks that ModLoader ALWAYS gives you on decompile, which I appropriately ignored.
5) I put the source for forge (minecraft only! left server alone, I'm not a server mod, derp) inside of the src/minecraft directory, so that the only two folders contained within are "net" and "forge". Makes sense! All the source classes use the package "forge" so obviously this is where it needs to be. :happy.gif:
6) import forge.ITextureProvider (or whatever hook you need) within the block/item/etc you intend to use it with.
7) Finally, implement the class below the method declaration.. and then use with love and adoration <3
Guys, I really appreciate your work on this. It's really good to see some talented modders working towards more compatibility across the board, and I wish everyone took a similar stance, with this sort of "GPL Feel". I was always a fan of teamwork.
EDIT: lol just cut about 40 lines of modloader overrides and silly looking constructors out of my mod_ class. AND this doesn't use indices? *joy*
Okay, I'm convinced. I have to touch WorldRenderer again anyway, so I can change things to work this way internally. It doesn't change the public-facing interface anyway, so no biggie.
I just wanted to know the technical reasons behind what you want, so I could form an informed opinion on it.
Thought it would be good to provide some insight, if this is indeed any form of insight at all, as to how I installed the Forge to use with my MCP.
5) I put the source for forge (minecraft only! left server alone, I'm not a server mod, derp) inside of the src/minecraft directory, so that the only two folders contained within are "net" and "forge". Makes sense! All the source classes use the package "forge" so obviously this is where it needs to be. :happy.gif:
Odd, normally they go in src/minecraft/net/src, because "forge" is a subpackage of minecraft/net/src. Well, it's supposed to be, at least. Otherwise I'm glad you got it working!
Hmm.. well, src/minecraft, I failed to imply.. but yes, it's allowing me to use functions straight from forge "package" beside net. So my classes are calling package net.minecraft.src and importing forge.whatever. I'm sure there's more than several ways to do it.
This is an idea I had a while back but there never really seemed a good place to suggest it till Minecraft forge came around so...
Basicly it would be nice if Minecraft forge could take care of all the ID number allocating. Mostly because it would be alot easier for most people on the user side to have all of the mod props in one file that could then be edited to fix conflicts instead of having to search through multiple props files to find out what IDs, if any, are available.
Basicly it would be nice if Minecraft forge could take care of all the ID number allocating. Mostly because it would be alot easier for most people on the user side to have all of the mod props in one file that could then be edited to fix conflicts instead of having to search through multiple props files to find out what IDs, if any, are available.
OK, let's get IC (67 BlockIDs, 109 ItemIDs), BTW (30 BlockIDs, 27 ItemIDs), Buildcraft (19 BlockIDs, 8 ItemIDs) and Aether (113 IDs) together in one file.
Each of these mods (except Buildcraft) already has clusterf**k-config, and you wish to MERGE THEM.
Minecraft Forge is an API providing extra modding capabilities such as:
- infinite terrain and sprite indexes
- custom buckets
- custom armors
- modification of list of mineable objects
- advanced configuration files
- population of custom blocks
- ...
Before you read, please use an open mind and try to understand my points, rather than going in with a negative mind-set and feeling as if I were attempting to destroy this idea. I am not. I am simply trying to state my reasoning behind my thoughts against this idea.
A few comments about these 'extra modding capabilities' that have been implemented:
1: Terrain/item sprite limit fix. While this seems useful, you're using my method (or Space Toad's, or whoever you wish to give original creator to) to create unlimited terrain and item indexes, so this isn't really anything necessary since it will still create greater lag for every mod that uses this fix, and increases as such, especially if I decided 'let's convert NetherCraft to use this!'. No one would be able to even play NetherCraft because of this problem. And, like I said, this is a *really* make-shift fix that I can foresee causing complaints with lag and random crashes. Even PremiumWood causes lag using this method...
2: Modification of list of mineable objects. You do realize there are already two mods that have this implemented (ScotTools and SAPI), right? And they both work together by just installing ScotTools second. Making a third API that alters the tool class file will just cause more incompatibilities and issues. =/
3: What more do you need besides MLProp, except maybe some organization or comments... By now, so many modders already use MLProp that mod users know how to use the config files correctly (except newbie mod users, of course).
4: I'm not really sure what you mean by 'population of custom blocks'... BaseMod's PopulateChunk??? I'm not exactly sure, so please explain.
Lastly, most of these 'API features' aren't really useful enough (custom buckets, custom armors, config files) to even be worth losing the compatibility. Even if this mod turns into the 'ultimate API' of some sort, there would still be many who use the old APIs. I passionately hate the idea of a full-feature API, since that practically forces modders to choose this API. I would not have a problem at all if this was simply a sprite limit API, but this is just turning out to be what is now the most hated API by mod users: ShockAhPI (from what I've heard). It causes a fair amount of incompatibilities. Say someone creates an ore mod, like my Randomite mod, and uses ShockAhPI. Now, anyone who wants to use that mod is going to have to choose between a simple ore mod and MC Extended, which is a mod some people depend on to have increased block IDs and unlimited item and terrain sprites without changes made by modders.
I probably just made myself sound like a hypocrite since I have made ItemSpriteAPI, which is basically this mod, but only with an API for item sprite sheets...
But seriously, if I wanted to create a mod that allows you to collect a new liquid from the Nether, I would have to choose to either A) use this API that can cause other incompatibilities, or :cool.gif: just edit ItemBucket myself, since most mods don't modify this file either way.
Just to warn you, I'm not going to include myself in this API with tons of random hooks/'fixes'. It is a nice idea, but I would never use it. If you plan for this to be a huge API, why not ask Risugami about implementing the features of this API, so anyone making a ModLoader mod will already be using this mod, obviously avoiding mod conflicts (no one likes conflicts with APIs), and allowing the user to download one less required mod.
These are just words of advice that I feel everyone who is a part of this should read, and think about the consequences, and consider how this can be seen as a 'selfish' way to 'force' modders to use this API.
PS: Not exactly sure how much sense I made throughout this post, since I have been awake for about 36hrs straight. XD
My main point is that 'Combination' APIs don't seem right in my opinion. It makes sense with ModLoader, since without ML, you could have maybe 3 mods installed at once. This API is not useful enough IMO (except the sprite fixes) to be combined with a bunch of other nonsense and barely useful hooks that just take up more base class files. I hope you consider what I've said, and maybe just split this up into 'Miscellaneous' and 'Sprite Fixes' (you really shouldn't add another tool fix API. I'm not sure if Shockah has heard of this, but when I created ScotTools, he became offended, just a warning. And I doubt he'll quit making ToolUtils in SAPI, and I'm not gonna stop making ScotTools, even if it makes this API incompatible with my mods. Looks like modding will have two separate realms of compatibility now, ones that use Minecraft Forge, and ones that use standalone APIs). =/
EDIT: Oh! And another thing I forgot to mention was that the terrain sprite fix does not even require an API. Yes, overriding BaseMod.RenderWorldBlock can be expensive, but if used in small amounts (let's say an ore mod or only certain blocks that are not abundant like grass or something), it doesn't really cause issues. I can see a use for having an API that can decrease the time taken to render each block, but even the coding used in Minecraft Forge will still decrease fps because of binding and re-binding the textures, especially, like I said, if you use a block that is found in abundance. The main reason I use the fix is for mods like PremiumWood, that wouldn't even work without MC Extended because of all the new textures. I plan on finally adding a method of creating blocks that use terrain sheets like I've done with ItemSpriteAPI. Sorry if this offends you in any way, but I *did* create ItemSpriteAPI before this was posted, and already planned on creating a fix for terrain sprites, so you have no reason to be angry with me.
EDIT2: Forgot another thing, lol. What about OptiFine, HD Textures? Of course there's a chance that these will be fixed in the future, but how long will it take? How long will it be before I can use any of these fantastic mods that are planning to use Minecraft Forge with OptiFine on my laggy computer? If merged files are made, how often would they be updated? How long could it take to update the merged classes for OptiFine when it makes an update (non-MC version update, added features/bug-fixes update)? Just something to think about. And that is only one example. And why would OptiFine choose to use Minecraft Forge's files as default if the mod wouldn't even use the API at all? OptiFine is just one example of a mod like this. Another good example would be Dynamic Lights. Minecraft Extended would also be an issue for users who want more block IDs. You just seem to be creating so many conflicts with mods that aren't really necessary. Makes me reconsider my idea of updating ItemSpriteAPI to be SpriteAPI (with terrain fix). If I just want a small mod that will allow practically infinite item sprites for my personal use (mostly, obviously I didn't want to just hold it to myself) for my NetherCraft mod, then use my terrain sprite fix (which, btw, does not alter any rendering files for blocks) so that NetherCraft is compatible with almost any mods (until the block ID limit is reached, or a group of mods use too many terrain sprites or item sprites). Now *that* sounds like a great way to fix incompatibility problems without trying to get the entire modding community to just start using an API. =/
And I'm still surprised about the 'mining' and 'bucket' features. Like, wow. Just, why? WHY!?
Thank you for your time!
~Scokeev9
A few comments about these 'extra modding capabilities' that have been implemented:
1: Terrain/item sprite limit fix. While this seems useful, you're using my method (or Space Toad's, or whoever you wish to give original creator to)
I posted about it long before your mod, but it's probably independent reinvention.
Also, the new multi-Tessellator code that I'm rolling into the next version completely eliminates the "lag" that this method cause, without changing the API that we're using.
Lastly, most of these 'API features' aren't really useful enough (custom buckets, custom armors, config files) to even be worth losing the compatibility. Even if this mod turns into the 'ultimate API' of some sort, there would still be many who use the old APIs.
There's also a long list of hooks that I'm using that SpaceToad didn't mention in the OP. I've used them to construct a fully functional multi-part-block/sub-block system. I consider them pretty important.
These are just words of advice that I feel everyone who is a part of this should read, and think about the consequences, and consider how this can be seen as a 'selfish' way to 'force' modders to use this API.
This is an open-source, community-driven, non-profit collaboration to make an API. I fail to see how it's selfish.
EDIT: Oh! And another thing I forgot to mention was that the terrain sprite fix does not even require an API.
You're right there, of course. RedPower has 320 terrain sprites, and still doesn't use the terrain sprite part of this API, and probably won't. It will use the new sorted texture list/multi-tessellator system when I finish writing it, though, since that will bring a sizable rendering speed boost to everything using it, including everything using this API for terrain sprites.
I posted about it long before your mod, but it's probably independent reinvention.
Also, the new multi-Tessellator code that I'm rolling into the next version completely eliminates the "lag" that this method cause, without changing the API that we're using.
There's also a long list of hooks that I'm using that SpaceToad didn't mention in the OP. I've used them to construct a fully functional multi-part-block/sub-block system. I consider them pretty important.
This is an open-source, community-driven, non-profit collaboration to make an API. I fail to see how it's selfish.
You're right there, of course. RedPower has 320 terrain sprites, and still doesn't use the terrain sprite part of this API, and probably won't. It will use the new sorted texture list/multi-tessellator system when I finish writing it, though, since that will bring a sizable rendering speed boost to everything using it, including everything using this API for terrain sprites.
Why can't you guys just release separate APIs? >.<
It just feels as though making this have so many functions and features to use, that most modders will only use a couple of these features, depending on the mod they make. I guess you just don't see the compatibility issues with this...
It's similar to ShockAhPI: It contains a DimensionAPI, but if a modder only wants to use it for ToolUtils, then it will still break things like MC Extended and other extremely useful and commonly used mods when it has no reason to.
Why can't you guys just release separate APIs? >.<
It just feels as though making this have so many functions and features to use, that most modders will only use a couple of these features, depending on the mod they make. I guess you just don't see the compatibility issues with this...
It's similar to ShockAhPI: It contains a DimensionAPI, but if a modder only wants to use it for ToolUtils, then it will still break things like MC Extended and other extremely useful and commonly used mods when it has no reason to.
To my mind, the intent of this API is to increase compatibility by providing a free, open, and common framework for modding to the community so that everyone using it will be virtually guaranteed of compatibility with the other mods that are doing so.
Our door is absolutely open to other participants in this process, which can not be said of many other API's out there. Also, I fail to see how requiring your users to download a collection of separate API's is in any way superior to being able to simply point them here and be done with it.
IMO, it's better for modders in that it frees us from dealing with compatibility issues, and it's better for players in that it frees them from running all over the internet to download various APIs to get their mods working.
Seeing Scokeev9 replied actually made me happy for a while, since I really liked your ScotTools a lot :biggrin.gif: ... It works and I never got any issue with it! I was hoping that you could hop on board, and this API would definitely be something I'm going to have besides ML.
Now I see the difficulty of gathering modders together for a common goal... sigh...
PS: as a player, I would definitely support downloading things from only one place and only once...
I've been a closet linux user, but I've been pushing into some windows dev and long since abandoned my very, very old distros. I don't even dual boot anymore. I'm not familiar with SVN, but I'm sure someone with a little spare time and a willingness to read things can figure it out. Thanks again.
EDIT: Successfully decompiled with modified base classes, the source isn't strictly necessary unless you intend to modify it with your own hooks, then, is it?
All in all, I think calling it difficult to install a bit of a misnomer. ;D
At any rate, will be converting my items to use the new ITexture formats and creating my sprite sheets. I'm excited to see an indices-free Equivalent Exchange. :happy.gif:
For the general mod compatibility it would be better not to include MCForge in the individual mods, only to give a link to this thread. So installing a single older mod can not break the rest of the mods by installing an older version of MCForge.
On a side note, MCForge will have to be very strict about backwards compatibility to avoid breaking somewhat older mods.
Overall I agree with that assessment, but it's not my place to make that policy for everyone. It's a community project.
I don't expect all that much churn on the hooks, the important ones should stay pretty stable throughout the life of the project. The first few versions of any hook may change a couple times, but once it's figured out, it should stay figured out unless there's a really, really compelling reason to change it.
By the way, how is it easier to bind to a static function than an interface? I figured that mods that wanted to be compatible could just include the interface that was being linked against, but if you can explain to me why it's helpful, I can look at the changes you mentioned.
Odd, I'd heard that there were problems decompiling it. It worked for you? Interesting.
And we're glad to have you onboard. :smile.gif:
It'll bring a performance boost to our custom texture support with relatively low impact. I don't think any mods override Tessellator itself, and only a couple rendering mods (like Optifine) touch WorldRenderer, which we override already anyway. Assuming I didn't miss anything, that's worth doing, so I'm on it.
I am looking from the point of view of OptiFine which has to overwrite the base rendering classes and simulate the functions of MinecraftForge in order to be compatible.
Currently OptiFine supports ModLoader and DynamicLights without having to compile against their classes, which is a big plus for me. It would be very nice if a support for MinecraftForge can also be added in this way.
A sample from RenderBlocks:
Calling a static function has several advantages:
- it is simpler and easier to organize with reflection.
- if the implementation changes in the future (for example: who is a MultiPassRenderer and when it should multi-render), the change can be limited to the MinecraftForge classes and no change in WorldRenderer will be needed => no need to make a new OptiFine version. If the number of parameters changes, then a change will be needed but it is much simpler. I can even detect how many parameters are needed and support both the older and the newer version at once.
OptiFine modifies heavily the WorldRenderer, Tessellator and RenderGlobal in order to make the multithreading work. Having as little foreign code in there as possible helps a lot. The static method calls are for me the best way to do it.
Edit: The interfaces are fine, they can just be moved inside the MinecraftForge static method.
EDIT2: I am currently trying to run:
EDIT3: i was wrong again
EDIT5:My last flippin edit, it was a Radio mod i installed, went 1 by 1 till i found the culprit
I love the circuit mod. As rebuilding time consuming and large redstone cicuits is tedious.
Who doesn't love the Buildcraft pipes.
And nothing, nothing, would make me happier than Better than wolves and Alblaka's work being compatible. The work of these modders are easily the two greatest mods ever made.
Wonderful idea guys and keep up the great work
You haven't tried hard enough.
1) Downloaded the source AND client files (I'm an SSP only modder for now)
2) Placed the client's modified base files and the forge folder directly into my minecraft.jar in the MCP jars/bin folder. Even though I wanted to leave the forge folder out to force the source to reobfuscate with my mod (for convenience!) this was how I did it on my trial run.
3)Ran my update because I was way overdue. Ran my cleanup because I hadn't yet. :tongue.gif:
4) Decompiled the jar with the forge classes.. decompiling was successful, save for the 2 Error Hunks that ModLoader ALWAYS gives you on decompile, which I appropriately ignored.
5) I put the source for forge (minecraft only! left server alone, I'm not a server mod, derp) inside of the src/minecraft directory, so that the only two folders contained within are "net" and "forge". Makes sense! All the source classes use the package "forge" so obviously this is where it needs to be. :happy.gif:
6) import forge.ITextureProvider (or whatever hook you need) within the block/item/etc you intend to use it with.
7) Finally, implement the class below the method declaration.. and then use with love and adoration <3
Guys, I really appreciate your work on this. It's really good to see some talented modders working towards more compatibility across the board, and I wish everyone took a similar stance, with this sort of "GPL Feel". I was always a fan of teamwork.
EDIT: lol just cut about 40 lines of modloader overrides and silly looking constructors out of my mod_ class. AND this doesn't use indices? *joy*
Okay, I'm convinced. I have to touch WorldRenderer again anyway, so I can change things to work this way internally. It doesn't change the public-facing interface anyway, so no biggie.
I just wanted to know the technical reasons behind what you want, so I could form an informed opinion on it.
Odd, normally they go in src/minecraft/net/src, because "forge" is a subpackage of minecraft/net/src. Well, it's supposed to be, at least. Otherwise I'm glad you got it working!
Basicly it would be nice if Minecraft forge could take care of all the ID number allocating. Mostly because it would be alot easier for most people on the user side to have all of the mod props in one file that could then be edited to fix conflicts instead of having to search through multiple props files to find out what IDs, if any, are available.
OK, let's get IC (67 BlockIDs, 109 ItemIDs), BTW (30 BlockIDs, 27 ItemIDs), Buildcraft (19 BlockIDs, 8 ItemIDs) and Aether (113 IDs) together in one file.
Each of these mods (except Buildcraft) already has clusterf**k-config, and you wish to MERGE THEM.
Before you read, please use an open mind and try to understand my points, rather than going in with a negative mind-set and feeling as if I were attempting to destroy this idea. I am not. I am simply trying to state my reasoning behind my thoughts against this idea.
A few comments about these 'extra modding capabilities' that have been implemented:
1: Terrain/item sprite limit fix. While this seems useful, you're using my method (or Space Toad's, or whoever you wish to give original creator to) to create unlimited terrain and item indexes, so this isn't really anything necessary since it will still create greater lag for every mod that uses this fix, and increases as such, especially if I decided 'let's convert NetherCraft to use this!'. No one would be able to even play NetherCraft because of this problem. And, like I said, this is a *really* make-shift fix that I can foresee causing complaints with lag and random crashes. Even PremiumWood causes lag using this method...
2: Modification of list of mineable objects. You do realize there are already two mods that have this implemented (ScotTools and SAPI), right? And they both work together by just installing ScotTools second. Making a third API that alters the tool class file will just cause more incompatibilities and issues. =/
3: What more do you need besides MLProp, except maybe some organization or comments... By now, so many modders already use MLProp that mod users know how to use the config files correctly (except newbie mod users, of course).
4: I'm not really sure what you mean by 'population of custom blocks'... BaseMod's PopulateChunk??? I'm not exactly sure, so please explain.
Lastly, most of these 'API features' aren't really useful enough (custom buckets, custom armors, config files) to even be worth losing the compatibility. Even if this mod turns into the 'ultimate API' of some sort, there would still be many who use the old APIs. I passionately hate the idea of a full-feature API, since that practically forces modders to choose this API. I would not have a problem at all if this was simply a sprite limit API, but this is just turning out to be what is now the most hated API by mod users: ShockAhPI (from what I've heard). It causes a fair amount of incompatibilities. Say someone creates an ore mod, like my Randomite mod, and uses ShockAhPI. Now, anyone who wants to use that mod is going to have to choose between a simple ore mod and MC Extended, which is a mod some people depend on to have increased block IDs and unlimited item and terrain sprites without changes made by modders.
I probably just made myself sound like a hypocrite since I have made ItemSpriteAPI, which is basically this mod, but only with an API for item sprite sheets...
But seriously, if I wanted to create a mod that allows you to collect a new liquid from the Nether, I would have to choose to either A) use this API that can cause other incompatibilities, or :cool.gif: just edit ItemBucket myself, since most mods don't modify this file either way.
Just to warn you, I'm not going to include myself in this API with tons of random hooks/'fixes'. It is a nice idea, but I would never use it. If you plan for this to be a huge API, why not ask Risugami about implementing the features of this API, so anyone making a ModLoader mod will already be using this mod, obviously avoiding mod conflicts (no one likes conflicts with APIs), and allowing the user to download one less required mod.
These are just words of advice that I feel everyone who is a part of this should read, and think about the consequences, and consider how this can be seen as a 'selfish' way to 'force' modders to use this API.
PS: Not exactly sure how much sense I made throughout this post, since I have been awake for about 36hrs straight. XD
My main point is that 'Combination' APIs don't seem right in my opinion. It makes sense with ModLoader, since without ML, you could have maybe 3 mods installed at once. This API is not useful enough IMO (except the sprite fixes) to be combined with a bunch of other nonsense and barely useful hooks that just take up more base class files. I hope you consider what I've said, and maybe just split this up into 'Miscellaneous' and 'Sprite Fixes' (you really shouldn't add another tool fix API. I'm not sure if Shockah has heard of this, but when I created ScotTools, he became offended, just a warning. And I doubt he'll quit making ToolUtils in SAPI, and I'm not gonna stop making ScotTools, even if it makes this API incompatible with my mods. Looks like modding will have two separate realms of compatibility now, ones that use Minecraft Forge, and ones that use standalone APIs). =/
EDIT: Oh! And another thing I forgot to mention was that the terrain sprite fix does not even require an API. Yes, overriding BaseMod.RenderWorldBlock can be expensive, but if used in small amounts (let's say an ore mod or only certain blocks that are not abundant like grass or something), it doesn't really cause issues. I can see a use for having an API that can decrease the time taken to render each block, but even the coding used in Minecraft Forge will still decrease fps because of binding and re-binding the textures, especially, like I said, if you use a block that is found in abundance. The main reason I use the fix is for mods like PremiumWood, that wouldn't even work without MC Extended because of all the new textures. I plan on finally adding a method of creating blocks that use terrain sheets like I've done with ItemSpriteAPI. Sorry if this offends you in any way, but I *did* create ItemSpriteAPI before this was posted, and already planned on creating a fix for terrain sprites, so you have no reason to be angry with me.
EDIT2: Forgot another thing, lol. What about OptiFine, HD Textures? Of course there's a chance that these will be fixed in the future, but how long will it take? How long will it be before I can use any of these fantastic mods that are planning to use Minecraft Forge with OptiFine on my laggy computer? If merged files are made, how often would they be updated? How long could it take to update the merged classes for OptiFine when it makes an update (non-MC version update, added features/bug-fixes update)? Just something to think about. And that is only one example. And why would OptiFine choose to use Minecraft Forge's files as default if the mod wouldn't even use the API at all? OptiFine is just one example of a mod like this. Another good example would be Dynamic Lights. Minecraft Extended would also be an issue for users who want more block IDs. You just seem to be creating so many conflicts with mods that aren't really necessary. Makes me reconsider my idea of updating ItemSpriteAPI to be SpriteAPI (with terrain fix). If I just want a small mod that will allow practically infinite item sprites for my personal use (mostly, obviously I didn't want to just hold it to myself) for my NetherCraft mod, then use my terrain sprite fix (which, btw, does not alter any rendering files for blocks) so that NetherCraft is compatible with almost any mods (until the block ID limit is reached, or a group of mods use too many terrain sprites or item sprites). Now *that* sounds like a great way to fix incompatibility problems without trying to get the entire modding community to just start using an API. =/
And I'm still surprised about the 'mining' and 'bucket' features. Like, wow. Just, why? WHY!?
Thank you for your time!
~Scokeev9
I posted about it long before your mod, but it's probably independent reinvention.
Also, the new multi-Tessellator code that I'm rolling into the next version completely eliminates the "lag" that this method cause, without changing the API that we're using.
There's also a long list of hooks that I'm using that SpaceToad didn't mention in the OP. I've used them to construct a fully functional multi-part-block/sub-block system. I consider them pretty important.
This is an open-source, community-driven, non-profit collaboration to make an API. I fail to see how it's selfish.
You're right there, of course. RedPower has 320 terrain sprites, and still doesn't use the terrain sprite part of this API, and probably won't. It will use the new sorted texture list/multi-tessellator system when I finish writing it, though, since that will bring a sizable rendering speed boost to everything using it, including everything using this API for terrain sprites.
Why can't you guys just release separate APIs? >.<
It just feels as though making this have so many functions and features to use, that most modders will only use a couple of these features, depending on the mod they make. I guess you just don't see the compatibility issues with this...
It's similar to ShockAhPI: It contains a DimensionAPI, but if a modder only wants to use it for ToolUtils, then it will still break things like MC Extended and other extremely useful and commonly used mods when it has no reason to.
To my mind, the intent of this API is to increase compatibility by providing a free, open, and common framework for modding to the community so that everyone using it will be virtually guaranteed of compatibility with the other mods that are doing so.
Our door is absolutely open to other participants in this process, which can not be said of many other API's out there. Also, I fail to see how requiring your users to download a collection of separate API's is in any way superior to being able to simply point them here and be done with it.
IMO, it's better for modders in that it frees us from dealing with compatibility issues, and it's better for players in that it frees them from running all over the internet to download various APIs to get their mods working.
Now I see the difficulty of gathering modders together for a common goal... sigh...
PS: as a player, I would definitely support downloading things from only one place and only once...