Jump to content

sequituri

Forge Modder
  • Posts

    669
  • Joined

  • Last visited

Everything posted by sequituri

  1. As Draco18s has told you, don't put anything in the crafting strings that you don't explain except spaces ' ' or " ". They are the only things that provide empty ness, not "_" or any other wierd character. If the grid has "A A" " B " and " C ", then you must have the characters 'A', 'B', and 'C' after the string and before an Item. If you use '#' in the grid, then you must use that before an Item, same with '_'. The craftingManager cannot read your mind! You still have this? GameRegistry.addRecipe(new ItemStack(ARepo.ICobalt_door, 1), "_##", "_ ##", "_ ##", Character.valueOf('#'), CMStuff.cobaltwood); GameRegistry.addRecipe(new ItemStack(ARepo.ICobalt_door, 1), "##_", "##_", "##_ ", Character.valueOf('#'), CMStuff.cobaltwood); GameRegistry.addRecipe(new ItemStack(ARepo.IIronCobalt_door, 1), "_ ##", "_##", "_##", Character.valueOf('#'), CMStuff.cobaltingot); GameRegistry.addRecipe(new ItemStack(ARepo.IIronCobalt_door, 1),"##_", "##_", "##_", Character.valueOf('#'), CMStuff.cobaltingot); Change the underscores to spaces. Or, get rid of the entirely. You don't need them.
  2. In regards to my second point: Your hashmap requires unique keys. Classes and interfaces tend not to be unique, where instances usually are. Therefore, you could never create more than one instance of any class or interface in your map and successfully register the new one. Your best hope would be for a HashMap(Class<?>,Set<Object>) to represent such a mapping. Another thing, your idea represents breaking an object (Like a TE) into sides. But a TE normally requires and assumes all six sides belong to it. You'd get farther along by creating MicroTEs where each gets an isosceles pyramid shaped area of the block. Then you could make aggregates of these to fill a block. TileEntiry myWierdBlock = new AggregateTE(MicroTE ob_up, MicroTE ob_down, MicroTE ob_north, MicroTE ob_south, MicroTE ob_east, MicroTE ob_west); That would at least be a start.
  3. There are random walk maze generator algorithm might might just make great vein generators. The idea is: [*]pick a spot (x,y,z) in chunk [*]push location on stack [*]then pick a random direction from spot (of 6 or 5) [*]if that location is stone: place block, decrement count If all blocks are placed: return select that new location goto step 2 [*]if there are open directions (where there is stone): goto step 3 [*]pop a location off stack. [*]If stack is empty then you've probably filled the whole chunk: abort [*]goto step 3 This would work best if the direction selection were weighted based on twistiness of veins desired. Less twisty mazes weight last direction as 60%, and 10% for each side direction.
  4. Several things to note: [*]Your example getBehavior method never uses the side argument. It is therefore useless as an example of anything except a spiffy class cast. [*]Your map would not work in most situations as many instances of a class exist, duplicate keys will abound. [*]Your second code snippet might as well be static as it makes no reference to this at all. What's it's purpose again? [*]Your third snippet boils down to, try {ISomeBehavior b = (ISomeBehavior)tileEntity;} catch(Exception e) {b = null; } [*]What's the advantage to your method? I still see none. Am I missing the obvious?
  5. You'll not get much help without posting complete crash report. People here may have some good hunches, but their aren't clairvoyant.
  6. shouldSideBeRendered() is only useful for solid blocks. You'll have to use your own rendering code for stairs and slabs.
  7. ItemStack itemStack = RecipeInfusionTable.getRecipe(this.infuserItemStacks[1], this.infuserItemStacks[2], this.infuserItemStacks[3]).getOutput(); Yep, it does indeed seem like the call to getOutput() is being made on a null recipe reference. [line 40-RecipeInfusionTable.java] if (recipe == null) { return null; } I think you should call your map's "containsKey(Arrays.asList ...)" function before assuming anything. My first problem is the way your recipeMap is implemented (as a HashMap with a key of "List<ItemStack>". That key is not likely ever to compare equally with another set of List<ItemStack> because the references are not the same. This is especially true when every ItemStack is freshly "new"ed each time. You might want to create a hash map ItemStackList with a HashCode and equals override. So as the check for equivalent ItemStacks in the list.
  8. Pretty good, except for CFP and CT, again you specified an initializing declaration (NOT AN ASSIGNMENT). You want to only do assignment if you want your data to persist as long as the mod does. And, you still need to register all of your blocks, items, handlers, etc. I'll leave that as an exercise for you. As to your question about visibility, you chose to specify that your fields are only visible to the package it is in. To do otherwise you must include a visibility modifier before the type specifier. Public or Private 0are the ones you want to look at. There is also Protected (which is like private, except subclasses can see them, too.)
  9. I don't really see the benefit of this rewrite. Besides the fact that refactoring the modder's code is a modder responsibility. Theirs, not ours. Also, if you just want a pipe that handles liquids, just implement the more limited set of interfaces in your class. Then use your class wherever a liquid pipe is needed. That's the beauty of interfaces. Your class can adhere to only the contracts it needs to perform its job. A backhoe might have interfaces for wheeledVehicle, contructionEquipment, diggerMachine, HydrolicsUser, and others. While a car might implement wheeledVehicle, roadWorthy, comfortProvider, etc. why make a car into a backhoe when that is not its job?
  10. Also note that the Item.onCreated() method is called when a new Item of that class is crafted. I would add achievement stuff there for new subclasses of items.
  11. Yes, that style is workable for your purposes. However, you are again declaring local Blocks in your Initialization method. Stop doing that! Do not start the instruction with a type declarator (like "Block ..."). That only creates a new and separate variable that no other method has access to. However, be aware that most of the time, the scope of the IDs you get from a config file should last as long as the mod container. That is why the IDs are usually declared in the class (outside any method). If you need to refer to the IDs from another of your classes, you cannot do it easily with the method you've chosen. My suggestion, is learn to use class fields. Do not redeclare local variables with the same names. That is very confusing. But, if you must do it, use "this.variable" for the class field and just "variable" for the local variable (most often a parameter). Example: @Mod( ... ) public class Modone { private static final String CATEGORY_BLOCK = "block"; int myOreBlockID; Block myOreBlock; @SubscribeEvent public static void Preinit(FMLPreinitializationEvent ev) { Configuration config = new Configuration(event.getSuggestedConfigurationFile()); config.load(); myOreBlockID = config.get(CATEGORY_BLOCK, "Titanium Ore ID", 501).getInt(); myOreBlock = new MyOre(myOreBlockID,Material.rock); . : config.save(); GameRegistry.registerBlock(myOreBlock, .... yadda yadda yadda ); } Notice how the IDs and Blocks are uninitialized fields of the class. I did not use a 'type ID' before any of the setting instructions, so the instructions referred to the fields already declared. That is what I am attempting to teach you.
  12. @Moritz, That is server-side code. The OP needs the client-side code.
  13. It's not just the misspellings that have you stymied. You are not referring to the ID you have set up previously to hold the ID: config.load(); int titaniumOreID = config.getBlock(Configuration.CATEGORY_BLOCK, "Titanium Ore ID", 501).getInt(); Here you are assigning the ID to a completely separate variable. Not the class variable you set up here: public static CreativeTabs tabSupernova = new CreativeTabs("supernova") { @SideOnly(Side.CLIENT) public int getTabIconItemIndex() { return SuperNova.oxidizerIdle.blockID; } }; public static int titaniumOreID; The first variable above is a method local variable. It is not visible and doesn't even exist outside the Preinit method. The second variable above is a class variable. It exists forever. It was never used or initialized in your code. Two separate variable with the same name, but different scopes. It might help you to learn java programming before delving too deeply into modding.
  14. I should have been clearer, I guess. By "persistent store" I meant, any file system outside of the inner minecraft communication system of world storage. Now I repeat the important part: Never hard-code IDs in the newer version of minecraft.
  15. I'm sure glad we god rid of those damned IDs. Now, if people will learn that when you jam a bunch of mods developed by different people together in one installation, there will be conflicts and learn to resolve them.
  16. The point to be made here is, never hard-code any IDs from now on. PERIOD. Ever. If you get an ID temporarily (from a call to the registry for example), expect it to be fine for this session only. Do not ever store it persistently or load it from persistent store and expect it to mean anything.
  17. You misspelled your denseCoreOreID in 2 different places. You got no compile errors because you redeclared the IDs as local variables. Newly declared variable of type int always get a value of 0. And the int value of Block is also 0. You are declaring an entirely new variable every you put a type before a variable name at the beginning of an instruction: int denseCoalID; static int denseCoalOre; int denseCoalOreID = blahBlahBlah; All of the above represent completely separate and unassociated variables.
  18. Java is funny about all the different scopes and such, huh. There are variables: local, nonlocal, and even other. vis-a-vis:
  19. You do not need JProfiler to tell you that the BufferedReader stays active forever. That function never returns until the user has entered a line of code. And when they do, it goes right back into it for another line. That's called allowing user input. The only time a thread will not be waiting there, is when the server closes.
  20. Have a look at net.minecraftforge.client.event.sound.PlayStreamingEvent which is worth some study. By the way, there is a class SoundPoolEntry that you can use, and the method to override is func_148648_d() and return 'true' for a streaming sound source. Look in the net.minecraft.client.audio.SoundManager class and study the method 'playSound(ISound ...)'.
  21. Your InventoryCrafting classes are nice, but you did not create overrides for certain required things to access your new private fields (your fields shadow the superclass's stackList and Inventory width.) The superclass cannot access your shadows fields. So, methods like getStackInRowAndColumn() which is used by checkMatch cannot get at your data. They will fetch the superclass data (which is invalid.) You have to override methods that must access your shadowed fields. Implement getStackInRowAndColumn() and getStackInSlot() and you should be fine.
  22. You're generating minables (stuff below the surface) with coordinates that are up in the air (up to 4 blocks above the terrain). Why would you expect to find some stone to replace with an ore up there? The generate function of WorldGenMinable checks for stone to replace, otherwise it doesn't place anything.
  23. net.minecraft.network.PacketBuffer has methods; void writeStringToBuffer(String) and String readStringFromBuffer(int decodedLength) It extends ByteBuffer, so you can do: myBuf = new PacketBuffer(myByteBuffer); myBuf.writeStringToBuffer(myString); // or myString = myBuf.readStringFromBuffer(100);
  24. I suspect you should put something like this in your main class: @EventHandler public static void init(FMLPreinitializationEvent event) { your code ... // It looks like you expect your class "main" (with lower case 'm') to be called magically } In 1.6, you would use FMLInitializationEvent. But for 1.7 blocks and items start out as above.
×
×
  • Create New...

Important Information

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