I assume this is due to the fact the hitbox is set for a ONE-FITS-ALL block, and that block can change shape so it has to be completely square to fit all possible rotations/versions.
Yeah i hadn't thought of that. If the hitbox was changed to allow for selection of neighboring blocks, it would probably make the code really complicated.
I'm having difficulty visualizing what you're saying regarding the slopes on the ground. I'm close to releasing a new version, and if it does not add what you need, let me know.
I excluded Ice as a cover because I couldn't use the built-in render methods to make it alpha transparent - it was easier to disable it instead. I can make it work, but it's not a big priority at the moment.
Regarding textures - many mods rely on reading the block tile entity to determine what texture to grab (like this mod). If I allowed them to be a cover, the texture could be incorrect, invisible, or possibly crash the game.
I can't check out the new version because I can't update to 1.5.2 yet. I'll try to explain better.
= slopes
= walls
= stone path
= grass
= proposed new block location
This is the front of my fort, the slopes make the diagonal walls look nice and flat. The block I was explaining would go in the orange spots IN the ground so only the top of the block is exposed. The purpose of this block is to continue the straight line made by the slopes on the walls while not making a triangular hole in the ground. The block would be 2 halves, each the same size as the carpenters slope and each side would be able to have textures applied to match the neighboring textures to make the transition from one surface to another smooth. Orientation would work exactly like the normal slope so it could also be used in other directions. A concern is will the code allow for having a texture on each half of the block?
Another application for this block would be to allow for diamond shapes in the ground / ceiling.
It's cool that ice sounds like a future possibility. (then i can replace the snow i'm using instead of ice on the slopes)
Ok, I think I get it now with the texture application. So it basically depends on how the block applies its texture and determines if it will work with carpenter slope.
-----------------------
So any previews of what new things you plan to add? I like the hammer, will see that being useful for slopes in odd locations that you can't align properly because of tight spaces.
Rollback Post to RevisionRollBack
Spoiler tags are your friends when posting errors. USE THEM!
I can't check out the new version because I can't update to 1.5.2 yet. I'll try to explain better.
So any previews of what new things you plan to add? I like the hammer, will see that being useful for slopes in odd locations that you can't align properly because of tight spaces.
Ok. I see what you're saying now. I have envisioned this before, but because textures usually use metadata, and because the slope block only contains one cover's metadata, having two is not possible with my implementation.
At the moment.. I have nothing new to add. I'm taking a break for now - it's exhausting after a while. I will probably look into ways to make slope selection easier.
Ok. I see what you're saying now. I have envisioned this before, but because textures usually use metadata, and because the slope block only contains one cover's metadata, having two is not possible with my implementation.
At the moment.. I have nothing new to add. I'm taking a break for now - it's exhausting after a while. I will probably look into ways to make slope selection easier.
Yeah I thought that might be the case with 2 textures. I'll have to think up something creative to make it work with what i got, maybe raising / lowering the entrance.
Breaks are good, can't work too hard then you don't want to do anymore on it. Good job on what you got so far, a much more efficient implementation (from the user point of view) then having hundreds of individual blocks and orientations.
A suggestion for after your break: Slab slopes. They match up with slab block thickness. I don't think "normal" slopes would work with this and only horizontal slopes would probably look good. (like what i'm using to make my walls flat) Applications for this could be to make stairs on diagonal direction, or a different way to make decorative half block sections (maybe fountains, short walls, ect)
A thing i noticed with the block ID reassign (in version 1.1) it changes the block IDs every time the game is launched. (for example mine changes it from default to something like 512 and 513) this is fine, but what happens if another mod is installed and takes those 512 and 513 IDs? Won't this break the save game because the slopes IDs were changed from the save game? I've seen this implemented where once it changes the IDs it turns off auto assign and changes the IDs in the config file to match the change.
Have a good break.
Rollback Post to RevisionRollBack
Spoiler tags are your friends when posting errors. USE THEM!
A thing i noticed with the block ID reassign (in version 1.1) it changes the block IDs every time the game is launched. (for example mine changes it from default to something like 512 and 513) this is fine, but what happens if another mod is installed and takes those 512 and 513 IDs? Won't this break the save game because the slopes IDs were changed from the save game? I've seen this implemented where once it changes the IDs it turns off auto assign and changes the IDs in the config file to match the change.
That sounds like a better idea. My implementation of auto-assign is fairly new. The only problem is... if the Slopes have determined a safe Block ID, but you load up a new mod that loads before Slopes and uses the same IDs, Slopes will end up throwing the error. I can change the error message to indicate it is not Slopes truly causing the error, but I'm not sure if the average user would notice. But as you said, it would break saves - hopefully people would think before changing it in the scenario I pointed out.
I'm going to update the 1.5.1 version today (maybe later) and will put a hotfix into 1.21 for 1.5.2 with new auto-assign code.
As for suggestions on more slopes: yikes. Unless I start using another ID for different type slopes, I don't know how I can intuitively put together a slope selection method. The original idea wasn't to make everything diagonal, but was to make roofs look like actual roofs, plus the inverted versions.
That sounds like a better idea. My implementation of auto-assign is fairly new. The only problem is... if the Slopes have determined a safe Block ID, but you load up a new mod that loads before Slopes and uses the same IDs, Slopes will end up throwing the error. I can change the error message to indicate it is not Slopes truly causing the error, but I'm not sure if the average user would notice. But as you said, it would break saves - hopefully people would think before changing it in the scenario I pointed out.
I'm going to update the 1.5.1 version today (maybe later) and will put a hotfix into 1.21 for 1.5.2 with new auto-assign code.
As for suggestions on more slopes: yikes. Unless I start using another ID for different type slopes, I don't know how I can intuitively put together a slope selection method. The original idea wasn't to make everything diagonal, but was to make roofs look like actual roofs, plus the inverted versions.
Hmmm, damned if you do, damned if you don't with auto assign. Broken saves or crash on startup... I'd think the lesser of 2 evils would be crashing. I mean the error message DOES say "hey you got 2 mods trying to use the same ID" and most people could catch that. Kinda wish it would say that more directly when it happens.
Haha don't worry about a new slope, was just thinking about it when i was playing with half slabs earlier. I had a 5 gallon bucket of Legos when i was a kid, now Minecraft is my Legos and was thinking of new pieces i could play with
Rollback Post to RevisionRollBack
Spoiler tags are your friends when posting errors. USE THEM!
Hi guys. It's been another hard working night and day, but I've got a new update ready.
Changes:
- Slope now inherits hardness, explosion resistance, flammability and fire spread speed from cover block.
- Hammer logic improved (will update picture in op soon with new click-behavior)
- Ambient occlusion for exterior oblique corners tweaked.
- Slope now renders as a slope in the inventory and player hand.
- Auto-assign ID feature removed. Better safe than sorry if problems occur.
- Ice added as a valid cover.
- Block breaking animation fixed.
- Full solid faces of slopes now support torches, redstone wire, etc (but not vine).
And, I also released this update for 1.5.1 using the last released version of Forge for 1.5.1, build 682. Hopefully that works out for some of you.
Because I removed the ID auto-assign feature, be sure not to click "yes" if loading a world indicates IDs have changed - you may lose your slopes. You need to determine what block ID the game is currently using for the slope before the update, and manually set that ID in the config before updating. This only applies if the mod has actively been reassigning the block ID to avoid a conflict.
No extensive testing was done on this update. One bug I am aware of is when slope lighting is changed by a client besides you in multiplayer (when covering a slope with glowstone, for instance), it may not update the lighting in your game until a set time passes or until you reconnect. It's random, and I'm not sure how to fix it.
The new hammer logic is fairly simple:
Right click a slope to change between slope types (side slope, regular slope, regular corner slope, oblique corner slope, pyramid slope).
Left + Shift click a corner to cycle between all possible corners of that style (regular or oblique).
Left click a corner to switch between oblique and normal facing.
Left click any other slope type to cycle between the same type and same positive/negative orientation.
If you want to avoid manually back-porting and maintaining multiple versions of your mod, consider using Forge's new runtime deobfuscation script, srgnames. It's also supposed to eventually future-proof your mod, but it's still being developed and is changing. But if you use the current iteration of it for Forge 1.5.2, your mod will also be compatible with 1.5.1 (And hopefully 1.6)
If you want to avoid manually back-porting and maintaining multiple versions of your mod, consider using Forge's new runtime deobfuscation script, srgnames. It's also supposed to eventually future-proof your mod, but it's still being developed and is changing. But if you use the current iteration of it for Forge 1.5.2, your mod will also be compatible with 1.5.1 (And hopefully 1.6)
I had seen this used for some mods but honestly had no idea how it was done. I'll read up on it, thanks.
EDIT: Hmm, that was easy. I changed v1.22 download to a single 1.5+ version. It works with 1.5.1 now. Thanks for suggesting that.
java.lang.ArrayIndexOutOfBoundsException: 5657
at CarpentersSlope.BlockCarpentersSlope.func_71903_a(BlockCarpentersSlope.java:517)
at net.minecraft.client.multiplayer.PlayerControllerMP.func_78760_a(PlayerControllerMP.java:366)
at net.minecraft.client.Minecraft.func_71402_c(Minecraft.java:1315)
at net.minecraft.client.Minecraft.func_71407_l(Minecraft.java:1799)
at net.minecraft.client.Minecraft.func_71411_J(Minecraft.java:834)
at net.minecraft.client.Minecraft.run(Minecraft.java:759)
at java.lang.Thread.run(Unknown Source)
Client crash only.
Further testing it seems to happen on any right click on any slope for me with the hammer.
java.lang.ArrayIndexOutOfBoundsException: 5657
at CarpentersSlope.BlockCarpentersSlope.func_71903_a(BlockCarpentersSlope.java:517)
at net.minecraft.client.multiplayer.PlayerControllerMP.func_78760_a(PlayerControllerMP.java:366)
at net.minecraft.client.Minecraft.func_71402_c(Minecraft.java:1315)
at net.minecraft.client.Minecraft.func_71407_l(Minecraft.java:1799)
at net.minecraft.client.Minecraft.func_71411_J(Minecraft.java:834)
at net.minecraft.client.Minecraft.run(Minecraft.java:759)
at java.lang.Thread.run(Unknown Source)
Client crash only.
Just pushed a new zipped package to fix it - same version.
Also corrected hammer picture in op to reflect that "LEFT CLICK" has "SHIFT CLICK" behavior, not "RIGHT CLICK."
I wish I discovered this earlier very tempted to remake my tang palace project haha.
I was wondering is it possible to lay down the slopes with world edit at specific orientation? I tried with the block id but only got a line of square blocks.
I wish I discovered this earlier very tempted to remake my tang palace project haha.
I was wondering is it possible to lay down the slopes with world edit at specific orientation? I tried with the block id but only got a line of square blocks.
Slope type is determined when the block is placed by a player. I'm not sure what happens when worldedit does it, but it sounds like it doesn't work too well.
I want to say I stand behind what I said when I first saw this mod.
AWESOME.
And the work you put into it and the speed.
Really fantastic.
Thanks
If I could I would one up your OP again.
Thanks for this.
Thank you good sir.
After bug-fixing my other mod, I decided to throw a couple fixes in for this one as well. Version v1.23 is now live.
Slope lighting bug when players on server covered a slope with glowstone (or other light emitting block) is now fixed.
Slope recipe changed and alternates included... just because it's slope shaped now by default.
After watching a lot of videos it was clear the auto-cornering code was a little too aggressive, so if a slope being placed faces opposite the slope it's up against, auto-cornering code will not override. It seems to behave better after limited testing.
Okay, so you say you had to create the 'mods' folder - a Forge environment will create this folder for you, so you're not using a correct server jar. Use either MCPC or minecraft_server.jar patched with Forge.
I don't understand the Hammer Logic, i could only right click in Creative Mode and than I could only switch between 4 different types. All other types seems to be impossible in Creative Mode. So this Mod is in Creative Mode now not really usable.
And sometimes, when I go onto my map, the Slopes are not render right, must reconnect to my map to fix this:
I'll have to brainstorm a bit on how to address the issues with creative. Maybe I'll make shift right-click in creative cycle through similar slopes types... like shift left-click.
As for the rendering glitches: not good. I think I ran into that problem before, but I'm not able to reproduce this now.
Can you give me an idea of how this started happening, what version, etc.. any additional information could help me narrow it down.
EDIT: Also check your Forge logs to see if any type of error is occurring.
Yeah i hadn't thought of that. If the hitbox was changed to allow for selection of neighboring blocks, it would probably make the code really complicated.
I can't check out the new version because I can't update to 1.5.2 yet. I'll try to explain better.
= slopes
= walls
= stone path
= grass
= proposed new block location
This is the front of my fort, the slopes make the diagonal walls look nice and flat. The block I was explaining would go in the orange spots IN the ground so only the top of the block is exposed. The purpose of this block is to continue the straight line made by the slopes on the walls while not making a triangular hole in the ground. The block would be 2 halves, each the same size as the carpenters slope and each side would be able to have textures applied to match the neighboring textures to make the transition from one surface to another smooth. Orientation would work exactly like the normal slope so it could also be used in other directions. A concern is will the code allow for having a texture on each half of the block?
Another application for this block would be to allow for diamond shapes in the ground / ceiling.
It's cool that ice sounds like a future possibility. (then i can replace the snow i'm using instead of ice on the slopes)
Ok, I think I get it now with the texture application. So it basically depends on how the block applies its texture and determines if it will work with carpenter slope.
-----------------------
So any previews of what new things you plan to add? I like the hammer, will see that being useful for slopes in odd locations that you can't align properly because of tight spaces.
Ok. I see what you're saying now. I have envisioned this before, but because textures usually use metadata, and because the slope block only contains one cover's metadata, having two is not possible with my implementation.
At the moment.. I have nothing new to add. I'm taking a break for now - it's exhausting after a while. I will probably look into ways to make slope selection easier.
Yeah I thought that might be the case with 2 textures. I'll have to think up something creative to make it work with what i got, maybe raising / lowering the entrance.
Breaks are good, can't work too hard then you don't want to do anymore on it. Good job on what you got so far, a much more efficient implementation (from the user point of view) then having hundreds of individual blocks and orientations.
A suggestion for after your break: Slab slopes. They match up with slab block thickness. I don't think "normal" slopes would work with this and only horizontal slopes would probably look good. (like what i'm using to make my walls flat) Applications for this could be to make stairs on diagonal direction, or a different way to make decorative half block sections (maybe fountains, short walls, ect)
A thing i noticed with the block ID reassign (in version 1.1) it changes the block IDs every time the game is launched. (for example mine changes it from default to something like 512 and 513) this is fine, but what happens if another mod is installed and takes those 512 and 513 IDs? Won't this break the save game because the slopes IDs were changed from the save game? I've seen this implemented where once it changes the IDs it turns off auto assign and changes the IDs in the config file to match the change.
Have a good break.
That sounds like a better idea. My implementation of auto-assign is fairly new. The only problem is... if the Slopes have determined a safe Block ID, but you load up a new mod that loads before Slopes and uses the same IDs, Slopes will end up throwing the error. I can change the error message to indicate it is not Slopes truly causing the error, but I'm not sure if the average user would notice. But as you said, it would break saves - hopefully people would think before changing it in the scenario I pointed out.
I'm going to update the 1.5.1 version today (maybe later) and will put a hotfix into 1.21 for 1.5.2 with new auto-assign code.
As for suggestions on more slopes: yikes. Unless I start using another ID for different type slopes, I don't know how I can intuitively put together a slope selection method. The original idea wasn't to make everything diagonal, but was to make roofs look like actual roofs, plus the inverted versions.
Hmmm, damned if you do, damned if you don't with auto assign. Broken saves or crash on startup... I'd think the lesser of 2 evils would be crashing. I mean the error message DOES say "hey you got 2 mods trying to use the same ID" and most people could catch that. Kinda wish it would say that more directly when it happens.
Haha don't worry about a new slope, was just thinking about it when i was playing with half slabs earlier. I had a 5 gallon bucket of Legos when i was a kid, now Minecraft is my Legos and was thinking of new pieces i could play with
Changes:
- Slope now inherits hardness, explosion resistance, flammability and fire spread speed from cover block.
- Hammer logic improved (will update picture in op soon with new click-behavior)
- Ambient occlusion for exterior oblique corners tweaked.
- Slope now renders as a slope in the inventory and player hand.
- Auto-assign ID feature removed. Better safe than sorry if problems occur.
- Ice added as a valid cover.
- Block breaking animation fixed.
- Full solid faces of slopes now support torches, redstone wire, etc (but not vine).
And, I also released this update for 1.5.1 using the last released version of Forge for 1.5.1, build 682. Hopefully that works out for some of you.
Because I removed the ID auto-assign feature, be sure not to click "yes" if loading a world indicates IDs have changed - you may lose your slopes. You need to determine what block ID the game is currently using for the slope before the update, and manually set that ID in the config before updating. This only applies if the mod has actively been reassigning the block ID to avoid a conflict.
No extensive testing was done on this update. One bug I am aware of is when slope lighting is changed by a client besides you in multiplayer (when covering a slope with glowstone, for instance), it may not update the lighting in your game until a set time passes or until you reconnect. It's random, and I'm not sure how to fix it.
The new hammer logic is fairly simple:
Added. Thanks!
I had seen this used for some mods but honestly had no idea how it was done. I'll read up on it, thanks.
EDIT: Hmm, that was easy. I changed v1.22 download to a single 1.5+ version. It works with 1.5.1 now. Thanks for suggesting that.
This..... is..... awesome!
Don't burn yourself out.
Now take your well deserved break...... right now!
*edit*
Doh crashed using the hammer right clicking on an inside corner
---- Minecraft Crash Report ----
// Why did you do that?
Time: 5/10/13 10:29 PM
Description: Unexpected error
java.lang.ArrayIndexOutOfBoundsException: 5657
at CarpentersSlope.BlockCarpentersSlope.func_71903_a(BlockCarpentersSlope.java:517)
at net.minecraft.client.multiplayer.PlayerControllerMP.func_78760_a(PlayerControllerMP.java:366)
at net.minecraft.client.Minecraft.func_71402_c(Minecraft.java:1315)
at net.minecraft.client.Minecraft.func_71407_l(Minecraft.java:1799)
at net.minecraft.client.Minecraft.func_71411_J(Minecraft.java:834)
at net.minecraft.client.Minecraft.run(Minecraft.java:759)
at java.lang.Thread.run(Unknown Source)
Client crash only.
Further testing it seems to happen on any right click on any slope for me with the hammer.
Just pushed a new zipped package to fix it - same version.
Also corrected hammer picture in op to reflect that "LEFT CLICK" has "SHIFT CLICK" behavior, not "RIGHT CLICK."
Looks good. I will refrain from posting more problems for a couple days so you can chill.
I was wondering is it possible to lay down the slopes with world edit at specific orientation? I tried with the block id but only got a line of square blocks.
Slope type is determined when the block is placed by a player. I'm not sure what happens when worldedit does it, but it sounds like it doesn't work too well.
Thank you good sir.
After bug-fixing my other mod, I decided to throw a couple fixes in for this one as well. Version v1.23 is now live.
Slope lighting bug when players on server covered a slope with glowstone (or other light emitting block) is now fixed.
Slope recipe changed and alternates included... just because it's slope shaped now by default.
After watching a lot of videos it was clear the auto-cornering code was a little too aggressive, so if a slope being placed faces opposite the slope it's up against, auto-cornering code will not override. It seems to behave better after limited testing.
I'm not really sure what would cause that. I don't use bukkit or MCPC so I can't offer much support, unfortunately.
Okay, so you say you had to create the 'mods' folder - a Forge environment will create this folder for you, so you're not using a correct server jar. Use either MCPC or minecraft_server.jar patched with Forge.
I'll have to brainstorm a bit on how to address the issues with creative. Maybe I'll make shift right-click in creative cycle through similar slopes types... like shift left-click.
As for the rendering glitches: not good. I think I ran into that problem before, but I'm not able to reproduce this now.
Can you give me an idea of how this started happening, what version, etc.. any additional information could help me narrow it down.
EDIT: Also check your Forge logs to see if any type of error is occurring.