You fucked up, clean mcp and get clean jars and try again

 

You're right. I redid everything and now it works better now. However, there are still a bunch of problems that makes it impossible to mod. Everything works fine except the variable names in Minecraft are all messed up... They are all named like: field_71969_a and such. In addition to that, when I install, it still tells me there are a bunch of errors but Eclipse works with it no problem though. Thanks Lex.

You probably screwed soemthing up again.

And things being named func_/field_ is normal, what is this, your first time modding?

will the release be modloaderMP compatible?

edit: the current version isnt compatible with the latest optifine version

Optfine has to add in the hooks when forge is updated enough for it to do that.

Maybe I'm missing something but I can't see any recent build on Jenkins, the last one is #171 from the 3rd of August?

 

Instead I tried using the "fml.zip" from GitHub, it works in that it decompiles and recompiles but it doesn't seem to include all the Forge classes.

You probably screwed soemthing up again.

And things being named func_/field_ is normal, what is this, your first time modding?

 

No it's not just one or two things being named like that, ALL VARIABLES are being named like that. In 1.2.5, there are some variables named like that but most of them are correctly named.

 

Anyway, i will one again try nuking MCP and re-doing it again. I saw your new build so I'm testing it out right now...

 

Edit: Installation failed: MCMerger failed.

 

Edit 1: Redownloading all jar files and testing it out again.

Something IS wrong with build #178.  I get an error every time I try to decompile.  Also, as of build #176, the only files in (server)net.minecraft.src are the ModLoader classes and a few others.  This has already probably been discussed, just wondering what the time quota was until this issue is fixed.

Server side only having a few files is not an issue, its a feature

And saying 'i have errors dur dur dur' is like saying 'The sky.. exists...'

tells us nothing.

Server side only having a few files is not an issue, its a feature

And saying 'i have errors dur dur dur' is like saying 'The sky.. exists...'

tells us nothing.

Haha, you're right.  Log files are below.  Also, what do you mean by the few server files being a 'feature?'  Sounds...important.

 

Console log: http://pastebin.com/XSq98FMX

mcp.log: http://dl.dropbox.com/u/90411166/mcp.log

mcperr.log was zero bytes full.

 

Thanks

humm im gunna have to figure out why some people don't take the patches until the 2nd time around.

its reallly stupid and shouldnt happen.

And as for the server files...

Check the src folder... notice anything.. new..?

humm im gunna have to figure out why some people don't take the patches until the 2nd time around.

its reallly stupid and shouldnt happen.

And as for the server files...

Check the src folder... notice anything.. new..?

Well, the problem is that neither the client OR server is decompiling, it just gives that error as soon as I run the install script.  Is there a workaround?  Should I not run updatemcp before I install Forge?

 

Thanks for your help.

 

By the way, checked the server folder in the forge directory, found an empty 'PLACEHOLDER' file.  Guessing that means something

What Jenkins are you people referring to? Isn't it http://lexmanos.no-ip.org:8080/? Because I'm not seeing the new releases there 

What Jenkins are you people referring to? Isn't it http://lexmanos.no-ip.org:8080/? Because I'm not seeing the new releases there 

 

Here is a secret-Forge-modder-exclusive Jenkins: http://jenkins.minecraftforge.net:7070/

 

Or: http://www.minecraftforge.net/forum/index.php/topic,1200.0.html

 

Also, I noticed the new "common" folder. If I write place sources from my mod into the "common" folder, would it be compiled into both client and server?

 

Also, can anyone please give me an example of how the IGUIHandler now works?

Thanks, I had completely missed that thread!

I dislike the new enum "Orientation"... Why not just use 0-5? It was so much easier to loop over those numbers rather than dealing with these enums.

 

For example:

 

@Override
    public int getStartInventorySide(Orientation side)
    {
        if(side == side.DOWN || side == side.UP)
        {
            return side;
        }

        return 2;
    }

 

I can't return "side" because it's an enum and not an int... How would I convert that enum back into an orientation int without checking it manually?

 

EDIT: I tried using side.ordinal(). Not sure if this will work...

I dislike the new enum "Orientation"... Why not just use 0-5? It was so much easier to loop over those numbers rather than dealing with these enums.

Certainly Java has a way to loop over enumerations...  Every other language certainly does...

 

I usually use those with switch/case or just math manipulation.  I actually already made my own enumeration (well, actually static final int's) of those anyway so that is something that I can remove from my code. 

 

As for that code case, seems like something they missed...

I didnt 'miss' anything.

You're just lazy and expect side to directly correlate to your index.

You can always use .ordinal() to get the same exact values as what they used to be.

But you're better of doing it properly, and returning a valid index directly, not returning the side.

 

Certainly Java has a way to loop over enumerations...  Every other language certainly does...

 

I usually use those with switch/case or just math manipulation.  I actually already made my own enumeration (well, actually static final int's) of those anyway so that is something that I can remove from my code. 

 

As for that code case, seems like something they missed...

 

Switches? those things are rank..

Ah, so it is his code, not MC code, yep.

 

Switches are convenient, here is the copy/paste part scaffold for areas that use my enums (to be changed to the above on the 1.3.1 port):

                case Helpers.direction_y_minus:
                        break;
                case Helpers.direction_y_plus:
                        break;
                case Helpers.direction_z_minus:
                        break;
                case Helpers.direction_z_plus:
                        break;
                case Helpers.direction_x_minus:
                        break;
                case Helpers.direction_x_plus:
                        break;

 

Cleaner than an if/then/elseif/else tree for sure.

Ah, so it is his code, not MC code, yep.

 

Switches are convenient, here is the copy/paste part scaffold for areas that use my enums (to be changed to the above on the 1.3.1 port):

 

Cleaner than an if/then/elseif/else tree for sure.

 

Sure. I like the concept, I just don't like the stupid way it assumes you want to carry on through the other cases. Like seriously, does anybody ever use them without breaks inbetween cases? I think they would just be way more elegant without that little annoyance.

 

Call me OCD.

 

 

edit; but since you have it nicely copy/pasted like that I'll probably use it anyway!

Actually I have *MANY* cases where I fallthrough, such as:

                case Helpers.direction_y_minus:
                case Helpers.direction_y_plus:
                        break;
                case Helpers.direction_z_minus:
                case Helpers.direction_z_plus:
                        break;
                case Helpers.direction_x_minus:
                case Helpers.direction_x_plus:
                        break;

 

It would be stupid-ugly to have to specify a 'fallthrough;' keyword or something each time, it would not 'fit'.

 

 

It would be stupid-ugly to have to specify a 'fallthrough;' keyword or something each time, it would not 'fit'.

 

I see, thats interesting. I have to admit that I haven't used the things much They always just seemed a bit contrived.

I didnt 'miss' anything.

You're just lazy and expect side to directly correlate to your index.

You can always use .ordinal() to get the same exact values as what they used to be.

But you're better of doing it properly, and returning a valid index directly, not returning the side.

Ahh yes thanks. Ordinal() was what I was looking for.

I see, thats interesting. I have to admit that I haven't used the things much They always just seemed a bit contrived.

it depends both on taste and on situation

 

for example, if you want something to happen in case of any 2+ unique situations, it might be easier to use them because you can define each situation seperately without needing massive amounts of OR's in your if/else-if

I see, thats interesting. I have to admit that I haven't used the things much They always just seemed a bit contrived.

it depends both on taste and on situation

 

for example, if you want something to happen in case of any 2+ unique situations, it might be easier to use them because you can define each situation seperately without needing massive amounts of OR's in your if/else-if

 

A switch can be more efficient code as well, especially on larger sets, since a jump table is more efficient then repeated boolean tests after a small size.