OvermindDL1

And do note that canUpdate is only called when the TE is added to the world, so it is only ever called once per TE, hence why it always only ticks, or always never ticks.

Ah, I see what happened there. Good catch petsquirrel!

I am hoping that based on this post of his that he is trying it without mcpatcher, we hope anyway. EDIT: And as he just said, he is. So, can anyone else replicate this issue? Need a testcase to be able to fix it.

Never seen the issue here yet, but not really been looking. Can anyone else confirm this?

You can also drop invisible light emitting blocks at your entity *IF* it does not move and update often perhaps?

I might suggest to do something that I do. I have a TE block, does not tick, holds coordinates of its 'controlling' block. It passes all events to the controlling block (interface). It is invisible, and all bounds checks and so forth are passed to the parent. It is a very useful little block.

ModLoaderMP is broken, it will not work with Forge. Tell any author of any mod that uses MLMP to switch to Forge instead. Forge's is faster, more efficient, more logical, etc... No reason to not switch.

On block placed they just place the top part of the door above it. The item I think it was is what does the check for if it can be placed in the 2x1x1 space.

4096 is likely not updated yet.

A block bounds must *NOT* extend past its own cube (unless you use a bit of a hack like in my mod ) or you *will* get oddities like that. You must have multiple blocks.

No such way, you either always tick, or never tick.

Spout supports texture urls, but all it does is just download it, cache it, and used the cache version, as you should. Easy for any mod to support it itself if it wants to. Personally I do not see the point of requiring an Internet connection if they play SP though.

Forge has both ModLoader and ModLoaderMP's functionality, you do not need either of them if you use the latest Forge.

Yeah, Archive Manager does not always pull directories for whatever retarded reason. I use Ark, it works fine. Well, I used to use Ark, now I have a script that full mods up a client and server for me based on mods in a directory tree using the zip/unzip cli commands.

Optifine just updated yes, it works fine with forge now. Huh?

And you want to remove single player, why? You mean like how MC already is becoming in 1.3? Have you not seen the snapshots? It is already like that.

What would be more useful is a generic entity-added-to-world hook, then you could add it there, and do many other useful things too.

MCPatcher is known to break things right now, do not use it until they fix it.

We are up to .108 now you know, *quite* a bit newer than .75.

Just a basic tree mod would probably work, have new ones grow and use your api properly. I cannot speak for Lex but vanilla hooks seem to be well accepted if they have a useful purpose, are minimized in code (keep about all the code you can 'elsewhere', like in ForgeHooks.java, with just a single line or two in the vanilla class), and cannot already be done via some other method, like reflection (which your API here fills something that reflection cannot fix). Forge actually already has a script to do that. You want to get Forge from github, not the source distribution. The github version has a development set up for working on forge itself. When set up, make your change, and there is a script that will auto generate patches and so forth. Just run it, then push back to github as a pull request. Lex has done an amazing job at keeping it very simple, and as such he can still explain it better. This would be a very useful little hook, and one that *requires* vanilla changes, which is useful to have in Forge instead of 'other' mods editing base files. It would also be useful if the API could be used to disallow blocks that trees overwrite. Some mods have rather costly blocks that are often run in tree farm (think RedPower or BuildCraft), and being non-solid a growing tree can grow into and destroy the block, it would be nice to be able to mark a custom mod block as preventing tree growth as well.

DW20 is also using a much older version of Forge and the 4046 fix. I am quite sure that mDiyo has not updated it in many Forge versions now.

If you use Forge 109+ then you do not need ModLoader as well. Forge includes ModLoaders functionality directly in it starting at 109.

If you do not know github well then we can help with that as well. I am curious to get this in as too.

Hence why the client needs to be a dumb client only sent rendering and interpolation data to it from the server, which handles everything.

I also *randomly* get that same error when MC is loaded using a non-standard classloader (in my case, Eclipse). At which point just reloading it another 1 or 5 times gets it working, has to do with the order that the classes are loaded. If you are using a non-standard launcher then that could be the reason.