Fuels not work?

[MightyPork]

I have a mod extending BaseMod from ModLoader (no, I wont switch to FML), and I add a fuel item using addFuel method.

People who use FML keep complaining that the fuel does not work, but I have tested it and it works - with ModLoader.

Why?, and is there any workaround for this?

[LexManos]

Show your code, I've tested myself and addFule works perfectly fine.

[MightyPork]

Well, I am not 100% sure why it does not work, but all those who complain have FML, and often only one or two other mods, so thats why i think its caused by this.

You can try it, the mod is PowerCraft: http://www.minecraftforum.net/topic/842589-futurecraft-automate-your-world/ and the fuel is PowerDust.

It is a perfectly normal public class mod_PCcore extends PC_Module PC_Module extends BaseMod and adds some things which modloader does not allow, such as managing translation files and automatic texture preloading.

This is how the mod_PCcore adds fuel:

// Add fuels.
@Override
public int addFuel(int id, int meta) {
    return (id == powerDust.shiftedIndex) ? 3200 : 0;
}

[LexManos]

Well I just verified that FML does indeed invoke addFuel properly, and that code works just fine. I also installed your mod with Forge and it works perfectly fine. I think it may be a end-user install issue.

Beyond that, I have to say, no offense to you, but your code layout is atrocious. If you're willing to go open source and work together i'd be willing to help you clean things up and get all your code outside the net,minecraft.src package.

[MightyPork]

Then I don't know why the fuels don't work for them.. but it really doesn't matter.

I would happily move to my own package, but I can not, for I need to override protected methods and use protected fields from GuiScreen, Gui and GuiContainer.

I've tried this several times, but moving PowerCraft code to it's own package simply is not possible - and I do not want to have all code in a separate package and the Guis stuff in net.minecraft.src. That is why we are using the PC prefix for all classes - it makes it easy to maintain even if it is in the default package - and Weasel has it's own package, because for something as complex as Weasel we really needed separate namespace.

If you have a solution for this, how to move guis to separate package, it'll be welcome. Our source is already open - if you checkout this SVN to a src folder in MCP: http://code.google.com/p/powercraft-mc-mod/source/checkout - but i can also zip the mod sources for you if you want.

[LexManos]

Anything is possible if you know how to work it properly. And seriously dude, you have a freakin svn up with all of Minecraft code on it. What made you think this is a good idea? I'll take a look at in in a second but cleaning your code should honestly be no issue.

[MightyPork]

I know this is not a good idea. But is there an alternative, if it is in the same folder? We also tried to sync the folders from within eclipse, but subclipse refused to work, saying that it is an external resource and simply ignored it... So now we sync the whole folder with external svn apps, and it works all right.

Anyway now when 1.3 comes out we will have the opportunity to reorganize this mess in SVN, and possibly implement the protected-stuff workaround you are going to show me :)

[LexManos]

Ya you can ignore files in the SVN, as well as just you know, not putting your stuff in the minecraft package...

[LexManos]

So ya, just took a look at your code, refactored all your classes to a different package, Cleaned up a few things that you're doing in a retarded way like accessing a protected field instead of its public accessor, accessing a protected field instead of it's static version, etc... and low and behold it works in a separate namespace! Took like 10 mins.So ya, start cleaning up your repo and i'll help you out. But there is no reason you should be in the minecraft package.

[MightyPork]

Do you have google talk - gmail chat? If you do, it'd be faster. Try to connect ondra@ondrovo.com

and btw how did you fix these powerCrystal = new PCco_BlockPowerCrystal(cfg().num(pk_idCrystal), 49) .setHardness(0.5F) .setResistance(0.5F) .setBlockName("PCcoPowerCrystal") .setStepSound(Block.soundGlassFootstep) .setLightValue(cfg().num(pk_brightCrystal) * 0.0625F);

nearly all the setters are protected - did you move these calls inside the block class?

[MightyPork]

I have plenty of things that do not seem to be able from outside the package :(

One of these is worldSaveDir = (((SaveHandler) mc.theWorld.saveHandler).getSaveDirectory()).toString();

• getSaveDirectory is protected, and there is no getter

[MightyPork]

No, I do not believe you got it working. There are things that can not be solved without base class editing.

1) in mod_xy - when I register blocks, i need to call setHardness, setResistance etc - only workaround is to move these calls into the block's constructor, it it works 2) (((SaveHandler) worldObj.getSaveHandler()).getSaveDirectory()) is protected and there is no other way how to get the save directory. 3) block.damageDropped(meta); - damage dropped is protected, and i really need it 4) block.createStackedBlock(meta) - is protected 5) entityliving.experienceValue - is protected, so is the getter 6) block.dropBlockAsItem_do(...) is protected

For some of these I could make a local copy of the original code, but what if the block/class overrides it? This is useless.

If you have a solution for these things, I will be really thankful.

[psxlover]

You didn't need to have your source in the same folder as the minecraft source even if it's in the same package. You could put it in another folder somewhere outside /src and include that folder to the eclipse project.

[LexManos]

For the bulk of it, there is either a proper way of doing it, or you can use reflection, or create an accessor. remember, protected allows you to access from a subclass, so ya.. go for it!

[MightyPork]

I think I'll keep it as it is, it works and when i tried to separate it, I got complete mess and had to checkout the old version from SVN.

But the idea of having it outside src folder sounds interesting - if it is possible. I'll try that for 1.3.

[LexManos]

I am just going to say it right now, don't expect any support from me for any mod that is in the minecraft namespace.

[psxlover]

It is, and it makes it easier than trying to find your files among the mc sources. If you want to move the sources you could just have one class in the net.minecraft to be able to access the protected stuff.

[MightyPork]

This sounds like a good alternative, having few "accessor" classes in the mc package. I'll try it. Surely better than playing with reflection, which often stops working after obfuscating.

[LexManos]

Due to MC's setup a accessor class in the default namespace is acceptable. As long as it's easily identifiable as not Minecraft code.

[MightyPork]

It all seemed to work, i fixed all errors, made an accessor - and modloader stopped recognizing my mod_... classes, for they were not in net.minecraft.src. If i now move these to net.minecraft.src, it will complain all the block constructors are protected and not public. I am giving up, restoring all from backup. Thanks for this waste of time, it was really worth it :S

[LexManos]

So its saying that the constructors in YOUR class are not accessible.. oh whatever shall you do....

[MightyPork]

I already spent whole afternoon, and the result was really much worse than the current state. We DO NOT need separate package, because we have all files prefixed, and I see no real advantage in it - despite the possibility to remove these prefixes - yay, what a marvelous idea, we have bloody 200 classes and I will rename then all, great. No, we'll keep it as it is, it works and there's no problem, but this thing with fuels, which i dont know why refuses to work.

[LexManos]

Clean maintainable code isn't a reason to do it? If you would of made your mod properly from the beginning things would be easier. Anyways your issue is resolved as I have personally tested your mod and it works fine. Its user error.