Hmm, after playing around with this a bit, I've come to notice that if you have a Saving Stone in your inventory and you die by falling into the void, your game simply crashes. I'm using not enough items and code chicken core as my only two other mods.
Edit: Forgot to note that I am using the 1.7.10 version of the mod. Not sure if you are still interested in fixing anything there.
Can I get a log? And honestly this probably won't end up being a high priority fix due to the fact that this mod is intended for use in survival and there is no possible way to die to the void in survival as far as I know
When wearing armor, how do I create a second row of hearts(or more)?
I actually can't say I know the answer to that. I know Tinkers Construct adds something like that and is open source so you may want to check that out.
Hi, is there a way to make this work for Terrafirmacraft which doesn't allow weapons and armour to be stored in chests? I would rather have this option than use keepInventory command. Because of the grindy nature of the mod, losing armour and weapons really sucks.
I can't say I've tried it myself because I don't play with that mod. Considering that is a mechanic of the mod, chances are I would have to disable it using ASM, which isn't something that will be pleasant. There is a slim chance that since technically the server places the items in the chest as opposed to a player it might work, but no promises.
Based on the post above, I have to ask. Does this mod have an option to save items that were in the hotbar, and armor slots, *first*?
Well, here is the thing about that. This class is where the magic happens in this mod. It works by getting all the items dropped by the player, however the list I get from Forge about the items is not grouped. Therefore, I don't have a way to determine what was in the players hotbar.
I write medium to small mods so take this as you will:
Overall, 1.8 has been one of the biggest changes to Minecraft modding since 1.3 and the migration over to Forge that followed. 1.8 is kind of like an awkward growth phase for Minecraft, there are some good ideas, but a lot of them are poorly implemented.
1. The Block Model System - Or alternatively, "The worst thing to happen to Minecraft modding in recent memory." In the past, for custom blocks, modders would make a model, use something like ISimpleBlockRenderer for the rendering and that would be it(Plus or minus a few things like renderering IDs), the block would be ready to render. For standard model blocks, all you would do is specify the texture and that was it. In 1.8 that all changed. Now for all blocks we HAVE to use JSON files for modelling our blocks which isn't very pretty, custom model or not, which is pretty difficult because AFAIK no tools like Techne exists to help create those models. This also becomes a problem for modders who have massive model possibilities(Like Buildcraft) because they now need a file for every single one of those models. Forge has created an alternative for those stuck in that situation however in my opinion its still pretty funky. This is required for all blocks, which eats up more hard drive space for users and creates a ton more work for modders as we try to adopt our models and understand the new system. For perspective, old render code is still there for vanilla liquids and fire takes roughly 48 JSON files according to the Builldcraft developer. As an alternative, blocks can use TileEntitySpecialRenderer for blocks however this kills performance if used in large quantities.
2. Blockstates - I don't really work with metadata so take this as you will too. In previous MC versions, we would use numbers to specify item or block metadata. So for example, if I have a block of stone with the ID of 295, a new variant of that would have an ID of 295:1. However, that no longer applies. Block states now exist which instead of using numbers uses an "object"(If you aren't very fluent with programming, think of an object as something that isn't a letter or a number, but like an idea. For example, the number 1 is an integer, and a Creeper is an object. An object alone can be anything really and so usually values are cast onto it.) This creates two new objects IBlockState and BlockState, both of which have access to different things and all have fun obfuscated methods, making them sometimes tricky to understand. Blockstates are a good idea but are currently poorly implemented. Blockstates also require modders to define them all in JSON too, yay JSON! In 1.7, we would reference a block by calling Blocks.stone for stone and the idea follows for the rest. This was great because no longer did we have to worry about ID conflicts and it was just a little less code for us to write. Then 1.8 came along and killed all of that because now everything is referenced through Blockstates! Granted ID conflicts still don't exist, but it is annoying trying to reference a block because you have to call Blocks.stone.getDefaultState() which is the equivalent to getting a block of stone with a metadata value of zero. Not really hard, just feels kind of redundant because referencing the block and nothing more should just return it's default state and should not need it specified.
3. BlockPos - Up next in pointless junk that didn't need to be added. In the past, you would simply pass along the x, y, and z coordinate of an area if a method required it(I.E world.getBlock(0, 0, 0)). Then 1.8 came along and killed that too. Now, to get a block at a specific coordinate, you would create a new instance of BlockPos and pass that to the method. So
[/p]
[p]world.getBlock(x, y, z);[/p]
[p]
becomes
[/p]
[p]//Can't forget those fun block states![/p]
[p]world.getBlockState(new BlockPos(x, y, z));[/p]
[p]
This is another thing that really isn't difficult but really annoying because it is not needed. I weep for those who wrote massive world gen mods.
4. The Great Package Renaming - Forge has always been big on naming. For example, around 1.3 or 1.4(I can't really remember) Forge split the Minecraft package from being "net.minecraft.src" into a large array of packages that were much more specific, which was pretty nice. In 1.8 though, Forge changed all FML packages from cpw.mods.fml to net.minecraftforge.cpw.fml, which required everyone to update their package namings. Not really a big deal though. But accidentally leaving a cpw.mods.fml package in your mod would crash your game.
5. Various changes - In every Minecraft version things change. Methods get renamed or go away entirely. This is common with modding and also takes some time to adjust to. These can range from being small changes to huge deletions. All these eat up modders time every update.
If there are any concepts that need more explaining or if I screwed up somewhere please let me know so I can fix it.
0
Can I get a log? And honestly this probably won't end up being a high priority fix due to the fact that this mod is intended for use in survival and there is no possible way to die to the void in survival as far as I know
0
As requested by some(And wanted by myself) this mod is now running on version 1.7! Get it while it's hot!
0
Learn Java before you start to mod
0
Added 1.7 info
0
I actually can't say I know the answer to that. I know Tinkers Construct adds something like that and is open source so you may want to check that out.
0
Use for() loops to iterate through the inventory. If you don't know how to use them, I recommend you lookup a tutorial.
0
You will need to search through the inventory to to find the items you want...
0
Use player.inventory. Although I'm not sure of the index where hop bar items appear.
0
0
Sorry for the long wait, I've been out of town for a while. On the upside..... New update out!
0
I can't say I've tried it myself because I don't play with that mod. Considering that is a mechanic of the mod, chances are I would have to disable it using ASM, which isn't something that will be pleasant. There is a slim chance that since technically the server places the items in the chest as opposed to a player it might work, but no promises.
0
Well, here is the thing about that. This class is where the magic happens in this mod. It works by getting all the items dropped by the player, however the list I get from Forge about the items is not grouped. Therefore, I don't have a way to determine what was in the players hotbar.
0
I really wish I could bring this down to 1.7.10 so I could play it with the new FTB packs but it would be a ton of work on stall the 1.8 project
0
No problem! Kind of funny, I feel pretty comfortable with Java but fall apart when I look at Lua.
4
I write medium to small mods so take this as you will:
Overall, 1.8 has been one of the biggest changes to Minecraft modding since 1.3 and the migration over to Forge that followed. 1.8 is kind of like an awkward growth phase for Minecraft, there are some good ideas, but a lot of them are poorly implemented.
1. The Block Model System - Or alternatively, "The worst thing to happen to Minecraft modding in recent memory." In the past, for custom blocks, modders would make a model, use something like ISimpleBlockRenderer for the rendering and that would be it(Plus or minus a few things like renderering IDs), the block would be ready to render. For standard model blocks, all you would do is specify the texture and that was it. In 1.8 that all changed. Now for all blocks we HAVE to use JSON files for modelling our blocks which isn't very pretty, custom model or not, which is pretty difficult because AFAIK no tools like Techne exists to help create those models. This also becomes a problem for modders who have massive model possibilities(Like Buildcraft) because they now need a file for every single one of those models. Forge has created an alternative for those stuck in that situation however in my opinion its still pretty funky. This is required for all blocks, which eats up more hard drive space for users and creates a ton more work for modders as we try to adopt our models and understand the new system. For perspective, old render code is still there for vanilla liquids and fire takes roughly 48 JSON files according to the Builldcraft developer. As an alternative, blocks can use TileEntitySpecialRenderer for blocks however this kills performance if used in large quantities.
2. Blockstates - I don't really work with metadata so take this as you will too. In previous MC versions, we would use numbers to specify item or block metadata. So for example, if I have a block of stone with the ID of 295, a new variant of that would have an ID of 295:1. However, that no longer applies. Block states now exist which instead of using numbers uses an "object"(If you aren't very fluent with programming, think of an object as something that isn't a letter or a number, but like an idea. For example, the number 1 is an integer, and a Creeper is an object. An object alone can be anything really and so usually values are cast onto it.) This creates two new objects IBlockState and BlockState, both of which have access to different things and all have fun obfuscated methods, making them sometimes tricky to understand. Blockstates are a good idea but are currently poorly implemented. Blockstates also require modders to define them all in JSON too, yay JSON! In 1.7, we would reference a block by calling Blocks.stone for stone and the idea follows for the rest. This was great because no longer did we have to worry about ID conflicts and it was just a little less code for us to write. Then 1.8 came along and killed all of that because now everything is referenced through Blockstates! Granted ID conflicts still don't exist, but it is annoying trying to reference a block because you have to call Blocks.stone.getDefaultState() which is the equivalent to getting a block of stone with a metadata value of zero. Not really hard, just feels kind of redundant because referencing the block and nothing more should just return it's default state and should not need it specified.
3. BlockPos - Up next in pointless junk that didn't need to be added. In the past, you would simply pass along the x, y, and z coordinate of an area if a method required it(I.E world.getBlock(0, 0, 0)). Then 1.8 came along and killed that too. Now, to get a block at a specific coordinate, you would create a new instance of BlockPos and pass that to the method. So
becomes
This is another thing that really isn't difficult but really annoying because it is not needed. I weep for those who wrote massive world gen mods.
4. The Great Package Renaming - Forge has always been big on naming. For example, around 1.3 or 1.4(I can't really remember) Forge split the Minecraft package from being "net.minecraft.src" into a large array of packages that were much more specific, which was pretty nice. In 1.8 though, Forge changed all FML packages from cpw.mods.fml to net.minecraftforge.cpw.fml, which required everyone to update their package namings. Not really a big deal though. But accidentally leaving a cpw.mods.fml package in your mod would crash your game.
5. Various changes - In every Minecraft version things change. Methods get renamed or go away entirely. This is common with modding and also takes some time to adjust to. These can range from being small changes to huge deletions. All these eat up modders time every update.
If there are any concepts that need more explaining or if I screwed up somewhere please let me know so I can fix it.