Jump to content

voidzm

Members
  • Posts

    32
  • Joined

  • Last visited

Converted

  • Gender
    Undisclosed
  • Personal Text
    I am new!

voidzm's Achievements

Tree Puncher

Tree Puncher (2/8)

4

Reputation

  1. Did you name it "mc.modinfo" or "mcmod.info"? It's supposed to be "mcmod.info". Even if you did name it right, you've got two syntax issues: your modid should be in quotes, and you don't have a comma after it.
  2. The way that you're opening the GUI is really not optimal. I tried doing that when I first started doing GUIs, and it always ended in horrible server/client desyncing. The way you have it set now, like Draco said, shouldn't even be working. You're telling the server to open a GUI, and I bet that would crash instantly on a real server. Look up stuff concerning IGuiHandler. That is the way that you are "supposed" to do it in Forge. It takes care of making sure that both the server and the client know what the player is doing, and that you can get the relevant code running for both sides.
  3. A couple things: 1. You don't need to create a whole new ItemStack just to switch the ID on the original. Just go with "par1ItemStack.itemID = Items.shikaifire.itemID;", it will make your code a bit more concise. 2. You probably shouldn't use a direct comparison between the ItemStack's Item object and your singleton sword Item. In theory it should work, but there are all sorts of little reasons a straight-up comparison like that might not behave as expected. Try pulling the item ID straight off the held ItemStack and compare that against the sword's item ID instead. Comparing IDs is always a better idea than comparing the Item itself.
  4. I'm pretty sure onBlockAdded doesn't fire when the world is generating. I might be wrong, though.
  5. Yes, you would need to set up a tick handler for the server side to manage all of those conditions. There are plenty of tutorials on doing TickHandlers, just make sure it runs on the server (otherwise you get client/server de-syncing and other nasty things). You should probably do something similar to the Beacon, where a small internal timer runs in the TileEntity (except you would be doing it in the TickHandler). This timer would count up once per tick, and once it reaches some arbitrary value (say 40, for a 2 second update cycle), reset it and calculate all of your stuff. That way you don't have to run potentially expensive calculations that you don't need to every single tick. Basically, each time that update fires, you need to: 1. Iterate over every player. 2. Discover if they have the armor set, and if so, do nothing. 3. If not, use some kind of iteration to search the nearby blocks in the world for the Air Filter, and if you find it, do nothing. 4. If both of those last conditions were false, (i.e., the player is not safe) add the Radiation effect for 600 ticks (30 seconds) or reset it to 600 if it already is on the player. Since the two "safe" conditions only prevent the radiation from being renewed to 30 seconds, that will give you the 30 second cool-down you want. That's how I would implement that, at least.
  6. Theoretically you could create a biome decorator (similar to one that you might create for a custom tree or structure, or a custom ore) that simply grabs all the stone and changes it to your custom block type. I don't know how the default biome decorators would deal with that, but you might have to overwrite the dirt, gravel, and vanilla ores too (unless you want those). I also have no idea how expensive that would be in terms of chunk decoration time. Without doing wild hacks to the default ChunkProviders, a decorator will probably be your best shot.
  7. Generally you just package your compiled source and your resources together into a jar package (using the jar creator built into JVM). At least when you are creating a coremod, you need a META-INF folder and a MANIFEST.MF file to designate the main mod file. I assume that you are working with a regular mod, in which case I don't know how that step differs. You should be able to look that up without much trouble.
  8. I have a coremod that needs to load some image assets and draw them on the screen in a GUI. I'm using the OpenGL drawing functions, so I need to get a ResourceLocation for the images before I can bind the textures and draw them. However, upon trying to bind the texture, an error occurs: I'm using this code to create the ResourceLocation: And this code to bind it for drawing: "image.png" is located at "/assets/mymodid/textures/gui/image.png". I did read that having an uppercase modid in the file path would cause this error to occur, but the modid is lowercase, so that can't be the problem. Any ideas? I can't seem to make this ResourceLocation stuff work properly, and I don't know if the fact that I don't have a regular @Mod file has anything to do with it. If it does, then this is a really stupid way to have the texture system set up (requiring a @Mod file with a registered modid before the resource engine will find any of your textures.)
  9. Coremods won't load by default in the Eclipse environment. You have to specify them as an argument in the run configuration. Go to Run > Run Configurations..., select your main configuration (probably Client if you use the default setup), and select the Arguments tab. Insert "-Dfml.coreMods.load=com.example.mod.CoremodPlugin" into the VM Arguments box, just remove the quotes and insert the package/name of your IFMLLoadingPlugin class.
  10. That's exactly what I was looking for. Thanks!
  11. To clarify: Blocks go from ID 0 to ID 4095. (4096 distinct IDs.) Items go from ID 0 to ID 32767 (32768 distinct IDs.) Items can have IDs < 4096, but it's not recommended so as to prevent conflicts with blocks. (The vanilla items, for instance, are in the 256+ area). The game will add 256 to whatever item ID you specify in the config to get the real value for the in-game item. In the config: Blocks - (0-4095). Items - (3840-32511). Going outside these ranges will do very strange things.
  12. A quick, hopefully simple question: What is the best way to develop more than one mod at a time with Forge? Obviously I could install two copies/workspaces of Forge/MCP and work from those, but that seems redundant and not ideal. How could I make two different mods refer to the same base code installation without affecting each other or interacting with each other in any way? Also, is there a better way to update Forge then to just throw out the folder and reinstall it? I have my mod source outside of the "forge" folder, so I have to rebuild the class path each time I reinstall and also reconfigure the workspace to my ideal settings. I just wondered if there was a better/more efficient way to update than what I'm already doing.
  13. Since tool classes have to subclass ItemPickaxe, ItemSword, etc, it's really not feasible to pack all five tool types into one class. For my mod, I made one base class for each type of tool, (pick, shovel, sword, axe, and hoe) and had them take a EnumToolMaterial in its constructor (passing it up to the respective superclass.) Anything else that is material-specific gets handled in the base classes with an if/else block.
  14. Two things. 1. You shouldn't be using ModLoader methods. They aren't guaranteed to work perfectly with current Forge stuff and are pretty much deprecated. 2. You should be subclassing through the BlockFluid inheritance tree instead of trying to roll your own solution for creating a fluid. I think the base Minecraft code treats BlockFluid and its subclasses (BlockFlowing and BlockStationary, + your subclasses of those two) differently than other blocks, so you should go that route. That's how I implemented my custom liquid, and it works fine.
  15. Well, for one, you are using ModLoader functions (A really bad idea.) Whatever tutorial you used is either hopelessly out of date or doesn't have any idea how to properly do a Forge GUI. Look up IGuiHandler and go from there. You also need a Container to correspond with your GUI, there are plenty of tutorials on how to set one of those up.
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.