Forge - question for FC

[Kinniken]

Hi FC,

I don't know if you remember, but I'm the maker of Millénaire. I had contacted you some time back about joining Forge. At the time you had recommended it heavily. I hadn't gone ahead though because the need was not very pressing and I was worried about some Forge aspects (in particular, delays in upgrade time after new MC releases).

I recently started thinking about it again, as the lack of sprites for new items and blocks is becoming a major deal for me. I discovered during it that you had dropped out of Forge, something I had missed when it happened. I've read a bit on the topic, from various angles, and listened to your interview with Battosay52. Your concerns with Forge resonate with me. I'm interested in a simple, compatible way to get new item and block sprites, not to be dependent on a huge rewrite of Minecraft that will make my mod incompatible with many others such as yours (which my survey says is played by about 10% of my users BTW).

I would thus like to know whether you are aware of any solution right now that provides new block or item sprites without clashing with either Forge or BTW, or whether there's any chance of one emerging. I'm afraid the answer is no, but it's worth a try.

Thanks

K.

PS: I'd send this as a PM but you don't seem to accept them either here or on the MC forums.

[Stormweaver]

I know I can't talk for FC, but the modified (and deobfuscated) forge class files that deal with the infinite sprites are included in the BTW downloads, as per the forge's licence. Which means you can use them yourself, so long as you also provide the source :)

That's all I know though, till FC get on. Hope I helped :)

[Kinniken]

I didn't know that, interesting. But I suspect using those would break compatibility with Forge, no?

[Stormweaver]

I didn't know that, interesting. But I suspect using those would break compatibility with Forge, no?

I'm not sure; you'd have to wait on FC for that. In the meantime I do know that those same classes are ones overwritten by optifine though, and that optifine is compatible with both BTW and the Forge. Which strongly implies that what you want is possible.

[FlowerChild]

Hey dude!

Glad you stopped by man. I've always had a great deal of respect for what you've done with Millenaire :)

Honestly, my impression of the whole thing is that if at all possible, you should probably hold off for the official API. If Jeb's statements on the matter are at all accurate, it seems like we're looking at only another month or two before it is released, at which point, everything about modding Minecraft is likely to change so much that whether the Forge will exist at all afterwards is a big question mark. To me, it therefore wouldn't make much sense right now to port your code-base over to an API that may or may not exist within a month or two.

However, if you're in need of something immediately, what I'd probably recommend is taking a look at the Forge source and consider stripping out the functionality that you need for infinite texture indices. The licensing agreement for the Forge is extremely flexible in terms of allowing redistribution of Forge files along with your mod as long as you provide the source code for it. This is effectively what I'm doing with BTW.

BTW is not incompatible with the Forge for that reason. It's incompatible with it due to my own base-class mods that I make to other files that conflict with those found in the Forge (mostly world.java). If all you're using from it are the infinite textures though, I doubt you'd run into the same kind of problems, with either being incompatible with the Forge, or with BTW.

Anyways, hope that was of some help. If you have any additional questions, feel free.

[Kinniken]

Hi FC,

Thanks for the quick reply, and the kind words on Millénaire. While I admit I've never tried yours (the only major mod I've ever played was Aether actually), I like the way you've tried to build on MC without overpowering things. I did not know the API was supposedly only a month or two away, I thought it was one of these things that Mojang had been speaking of for months but which had no real target date.

Yes, I need only that infinite textures code, which will only impact a very small part of my mod - the rest is fully ML-compatible and will remain that way. I'll have a look at the Forge code as you suggest. So you feel that if I take just that part, my mod will work fine even with Forge or BTW installed on top of it (and vice-versa, if people install my mod on top of Forge or BTW)? The classes concerned are separate enough? That would be great.

[FlowerChild]

Well, I've admittedly never played Millenaire either, but I've seen a lot about it over time :)

And yes, I feel that should work fine as long as you're careful not to modify any of the function or class names (or any of their parameters) and just strip out the functionality that you don't want. That way, if someone installs Forge on top of what you've done (install order will become important though), they'll just get the additional functionality that Forge provides, and all your stuff should still work just fine.

Same thing with BTW, if you're not modifying any of the same non-Forge base-classes I do, there shouldn't be any issue at all between our two mods running together.

Anyways, let me know if you run into any issues. I was with the Forge from very early on its creation (I think I was the third person to sign up right after Space Toad and Eloraam), so I'm pretty familiar with its inner-workings. Obviously, I'm also pretty familiar with hacking it apart at this stage ;)

[Kinniken]

I don't doubt that ;)

Actually, stupid question, but aren't your modified Forge classes exactly what I need? If I package the Forge classes you mention in your readme without modifying them (forge/BlockTextureParticles.java, forge/ICustomItemRenderer.java, forge/IMultipassRender.java, forge/IRenderContextHandler.java, forge/ISidedInventory.java, forge/ITextureProvider.java) plus your two modified Forge classes, won't that provide me with sprite extensions without breaking compatibility with either your mod (of course) and Forge itself, as long as Forge users install Forge after my mod?

[FlowerChild]

I don't doubt that ;)

Actually, stupid question, but aren't your modified Forge classes exactly what I need? If I package the Forge classes you mention in your readme without modifying them (forge/BlockTextureParticles.java, forge/ICustomItemRenderer.java, forge/IMultipassRender.java, forge/IRenderContextHandler.java, forge/ISidedInventory.java, forge/ITextureProvider.java) plus your two modified Forge classes, won't that provide me with sprite extensions without breaking compatibility with either your mod (of course) and Forge itself, as long as Forge users install Forge after my mod?

Well, yes, but you won't need forge/ISidedInvetory.java (that's just in there for BuildCraft support with Better Then BuildCraft), and you'll also need a few of the modified vanilla classes that the Forge provides, and which to my understanding you're not obliged to distribute the source for as per the Forge licensing agreement (I think it would actually violate Mojang's licensing to do so).

Let me do a quick search in the code as to what you'd need...

EffectRenderer.java
ItemRenderer.java
RenderBlocks.java
RenderEngine.java
RenderGlobal.java
RenderItem.java
Tesselator.java
TileEntityRendererPiston.java

and lastly:

WorldRenderer.java

The last one will require a minor modification to get it to compile without some of the other Forge hooks present. You should be able to figure it out rather quickly due to the compile error that it generates, but here's my modified code from it to help you track it down:

Code: Select all

                        // FCMOD: Switched this back to vanilla version
                        if (i2 == 0 && Block.isBlockContainer[i3])
                    	// END FCMOD

That should do it :)

[Kinniken]

Great! I'll try it out. In fact if this works so simply it should probably be publicised as way for modders to be compatible with as many mods as possible.

[Kinniken]

I've tried it and I'm getting compile errors. Just to be sure I've followed the right procedure, here is what I've done:

- made a copy of an MCP env, installed forge in it (that part works, or at least it compiles)
- in an other MCP env, I copied the Forge classes listed in your readme as unmodified (except ISidedInventory), your two modified Forge classes, and the vanilla classes modified by Forge you listed

A few seemed like simple MCP mapping mismatch due to Forge using slightly outdate mappings compared to the latest update of MCP. Those I fixed easily enough. However there are a few more which looks like they are due to the Forge-modified classes you told me to copy being dependent on other Forge code. Specifically:

ignoreFrustumCheck() is missing in the Entity class (needed in RenderGlobal)
canBlockCatchFire() is called with an extra int argument in Forge's RenderBlocks than it has in the vanilla Block class
hasTileEntity(int) doesn't exist in the Block class (needed by RenderBlocks)
stepSoundDir() doesn't exist in the StepSound class (needed by RenderGlobal)

How did you deal with that? I suppose I should compare the vanilla and the Forge classes and try and remove those added dependencies, hopefully without breaking anything.

[Zhil]

It looks like it might be handy for modders if you commit this lightweight version to Forge when you're done. That way, other modders can use the infinite sprites too, while being compatible with Forge, sounds like it'd be helpful.

[Kinniken]

I've sent a PM to SpaceToad about it, let's see what he says.

[FlowerChild]

Sorry, just woke up so I'm still a bit out of it, but I suspect what is happening is that you're using the 1.3.1 version of Forge, while I'm using the 1.3 version.

I've noticed a certain tendency towards making the files more dependent on each other over the last couple of versions. It's something you might want to keep aware of, as it looks like this is getting more difficult to do with time.

[FlowerChild]

As for the RenderBlocks "CanBlockCatchFire()", just checked, and you're right, that was in the old version. Here's the code I use there:

Code: Select all

        // FCMOD: got rid of direction
        if (!blockAccess.isBlockNormalCube(i, j - 1, k) && !Block.fire.canBlockCatchFire(blockAccess, i, j - 1, k))
        // END FCMOD

You can safely ditch the last parameter that they have to that function as it just specifies the direction (yay for cover-plates catching fire on different sides depending on material!).

[Kinniken]

Sorry, just woke up so I'm still a bit out of it, but I suspect what is happening is that you're using the 1.3.1 version of Forge, while I'm using the 1.3 version.

I've noticed a certain tendency towards making the files more dependent on each other over the last couple of versions. It's something you might want to keep aware of, as it looks like this is getting more difficult to do with time.

I'm indeed using 1.3.1, I just got the latest from the Forge thread. Anywhere I can download 1.3? And it's not great news, if Forge is really trending toward more and more integration...

[FlowerChild]

I'm indeed using 1.3.1, I just got the latest from the Forge thread. Anywhere I can download 1.3? And it's not great news, if Forge is really trending toward more and more integration...

Yeah, I have no idea if it's intentional, but while SpaceToad and me are on very good terms, there are definitely other elements of the Forge team with whom that is not the case ;)

As for 1.3.0, all version of the Forge can be found here:

Sourceforge link

[Kinniken]

Yeah, I know you have your differences with some team members ;)

Anyway, I'm download 1.3, I'll try again with that one, thanks.

[Kinniken]

1.3 is not working, I'm getting errors when decompiling it. Was it for MC 1.0 or 1.1?

[Aduis1210]

its minecraft 1.1 :)

[whynocheese]

Aduis they are talking about Forge 1.3 not Minecraft 1.1.0
-EDIT- Damn me and my speed reading sorry Aduis you're right! :)

[FlowerChild]

1.3 is not working, I'm getting errors when decompiling it. Was it for MC 1.0 or 1.1?

Yeah, 1.3 is for MC 1.1. Are you just running into MCP renaming problems or what?

[Kinniken]

It seems to be an issue during recompilation:


== Post decompiling operations ==
> Recompiling
> Recompiling client...
> Done in 6.78 seconds
> Recompiling server...
!! Can not find server sources !!
> Generating the md5 (client)
> Generating the md5 (server)
sed: 1: "./minecraft/net/minecra ...": invalid command code .
sed: 1: "./minecraft/net/minecra ...": invalid command code .
sed: 1: "./minecraft/net/minecra ...": invalid command code .

(and it goes on with similar lines for some time)

No fore code is produced, there is no forge directory in minecraft/src

[FlowerChild]

It seems to be an issue during recompilation:


== Post decompiling operations ==
> Recompiling
> Recompiling client...
> Done in 6.78 seconds
> Recompiling server...
!! Can not find server sources !!
> Generating the md5 (client)
> Generating the md5 (server)
sed: 1: "./minecraft/net/minecra ...": invalid command code .
sed: 1: "./minecraft/net/minecra ...": invalid command code .
sed: 1: "./minecraft/net/minecra ...": invalid command code .

(and it goes on with similar lines for some time)

No fore code is produced, there is no forge directory in minecraft/src

Wait, are you trying to decompile the client version of the Forge, or are you installing the 1.3 source version?

[Kinniken]

I downloaded the source version of Forge, and like they instruct placed it in an already-decompiled MCP environment. I then ran forge/install.sh. With Forge 1.3.1, it works, with 1.3, it fails with the errors I posted.