gotyaoi

No, it's ok. You just have to make a choice whether to be compatible with forge or not. Here's the basic breakdown. Since the forge code in there does nothing at the moment, you could leave it out(just edit the vanilla class) and be compatible with both. However, if/when a future forge build adds an actual call there, you have to choose whether to edit the vanilla class, or edit the class after forge made it's changes. Edit the vanilla class, be compatible with vanilla only, edit the forge-edited class, be compatible with forge only.

It's possible, take a peek at the dispenseItem method in BlockDispenser. However, to change dispenser behavior would involve a base class edit. Not too bad, ordinarily, for something like BlockDispenser, but forge does stick something in there, so if you wanted to be compatible with forge mods, a little bit trickier.

The posts here are about making mods, not installing them. You came to this forum, read apparently none of the rules or stickies, and asked for help after breaking your install. You're lucky all you got was "smart remarks". Go read the rules, post in the right location with the proper info and format, stop digging your hole any deeper and maybe you might get some pity-help.

There's actually a slight difference between the required-before/after and simple before/after. The required version should make modloader spit out errors if the mod listed isn't there while at the same time making sure you load before or after it. The simple before/after version makes no such check, only ensuring ordering if the listed mod is there, but not complaining if it's not. An example of a place to use the required version is if one of your crafting recipes uses an item from another mod. You need that mod to be there for it's item to exist, so you require it. An example of a place to use the simple ordering is if you know your mod conflicts with another in some way, and one of them has to have the final say on something, you can use after to make sure it loads after the other mod. If the other mod isn't there though, there's no conflict and things can proceed as normal.

That's cool especially the sort of indented bit in the GUI. Just a note, it doesn't have to stick to close to the original textures, as I was just using those as placeholders. It's pretty much a furnace with part of a piston stuck to the top right now. Also, if it includes the top vent, it could also have a additional lit up texture there, as I could code that in pretty simply.

So, first, you appear to adding the same two hooks over and over again, so that's probably not helping you. Second, there's a much cleaner way to add items to the creative inventory. Simply override the addCreativeItems method in your Block classes. Like so: public void addCreativeItems( ArrayList itemList ) { itemList.add( new ItemStack(this, 1, 0)); } At a guess, since you were modifying the creative list every tick in the gui, it wasn't so happy. Edit: Or it could be that you registered BlockMarble 3 times, and never registered BlockMarbleG or BlockMarbleY.

Thank you very much. And yeah, leave the HD stuff for HD texture packs. For reference in that terrain.png, on the second line, it's the side of glass panes and then the rest is for the machine: bottom, top, front-off, front-on, sides.

People of the Scribble Parlor, I come from the Modder's Metropolis bearing a humble request. I have recently made a mod, but unfortunately, I am not the most artistically talented individual in the world. Thus I come to you, head in hands, with this small request: Please help me make my mod not look like shit. The glass is mostly fine, but the furnace-thing and the gui could really use some help. All I can offer is a spot in the credits, but I would greatly appreciate the help. A link to my mod: http://forums.technicpack.net/threads/stained-glass-mod.8384/ Current look:

A new release. Now with SMP support. Not bukkit yet though, sorry. And a machine with which to smelt glass. Is that how glass-making works? I have no idea! It's how Minecraft glass-making works, so there!

I got it. It's slightly stupid and hackish, but it works and it only uses the one block id. I had to override Block.getLightValue() for my block (made it conditional rather than array lookup) and then manually call worldObj.updateAllLightTypes(x,y,z) from my tileEntity when I needed it (since updating metadata doesn't normally call that while updating the block does) and it worked. I'm going to test a bit more, but I'll probably post something soon.

I'm not sure why you did that with the jar. Looking at your code, you're using the api correctly, though don't forget the static methods in ElectricItem. Is there something that prompted you to throw the jar in there, cause it seems like a pretty odd course of action.

No worries. I'm going to either try and puzzle out how the redstone dust works, or I might take a look at the latest forestry, to see if he found a way to do this with his new candle block.

As near as I can tell, all blocks in the world are sort of a reference to the one declared in Block.java, with things like metadata and such being stored separately, so changing the light level for one block sort of does it to all of them.

Ok, so I've got my glass furnace pretty much working, which means a release is probably soon. I'm just having trouble finding if there's a way to have my block conditionally emit light without using 2 block ids. All the notch blocks that do this use two (furnace, redstone lamp/repeater/torch) except, apparently, redstone wire. Odd...

Why does no one read? You don't ask for mods to be added to the pack here. There are other threads in other forums for that. Here, you ask for mods to be created. And not even here in this thread. This is the meta thread.

My god. That page was so long it broke the tiled background. Couldn't tell what the actual content was due to what I can only assume/hope is English as a second language.

Heh, documentation. That might be nice, but eh. It's more of a thing where you hang around the forums long enough and things just start making sense. Anyway, to answer a few of your other questions: The site is sort of all over the place because a lot of it hasn't been changed since the switch to the launcher was made. There used to be a technic installer, but now it's all launcher, which is much nicer. The version selector is basically a measure of how many bugs or differences you're willing to put up with. If you use the recommended version, that's generally stable and good, though it's quite a bit behind the times in terms of version numbers. 7.0.1 is also generally stable, or so I've heard, and more up to date, but it doesn't have all the mods you might want. It's still a development version. Versions above that are very development, and probably shouldn't be played, but they're available if you feel like being a guinea pig. If you have questions about a specific version of technic or tekkit, the forums are pretty informative. Check the stickys, use the search bar.

Yes, and? That's the snapshot. If the OP is still using the rec build, they'll be on 1.1. Even if they're on the dev build, it's 1.2.5 and they'll still have this problem.

As I remember, there's a bug in the mac version of minecraft where the "open texture pack folder" button is broken. That where you're having trouble? If not, how exactly is it not working.

I'm not entirely sure you can for the overworld, at least not without modifying some base classes.

I am back! from a week in the mountains! It was quite refreshing. Anyway, the next release will at least support vanilla server. I've no idea at the moment how to make it a bukkit mod, but the thought is in my head.

Ah Christwire, The Onion of religion, except sadly more believable.

I would not want to see the type of mood that would cause a dwarf to make something like that.

Or spawned a nasty next to them.

Any mod built with a requirement for ModLoader will run with forge installed. ModLoaderMP is right out, ask the author to rewrite using FML.