Its just the mod related ones binds. I have a problem with my Smart move binds, but that is related to his mod and I'm not worried about it, that I can work around. But ya, its just your mods control binds that reset. Thanks for the update so quick. Looking forward to the patch.
Fixes keybinds resetting, regardless of forge version. You can change them via in-game config, or editing the config file.
Removed debug keybinds from view. They weren't supposed to be there for release
Also cleaned up some exception handling for not-yet-spawned-on-the-client entities.
No other changes.
I may have found a small issue. When dismounting the catapult from clicking the button on the GUI interface, the catapult glitches into the block level below it, it seemingly moved on block deeper into the world and essentially i am glitches into the ground as well with the catapult, which almost always results in death. Oddly enough there was a 10-15 minute period of time it worked fine, i going to continue testing it on various size areas of flat land to see if something environmental is causing the issue. Aside from that everything else seems to function wonderfully.
Both the ballista and catapult demounting has the same effect, it does not do this on initial placement. It seems to occur after ammo has been added and fired afew times. Any thoughts?
I may have found a small issue. When dismounting the catapult from clicking the button on the GUI interface, the catapult glitches into the block level below it, it seemingly moved on block deeper into the world and essentially i am glitches into the ground as well with the catapult, which almost always results in death. [..............]
Both the ballista and catapult demounting has the same effect, it does not do this on initial placement. It seems to occur after ammo has been added and fired afew times. Any thoughts?
Death sounds like a bad bug...
Thanks for pointing this out. I had kind of noticed it when doing the bukkit port, but didn't think too much of it. I should be able to come up with a fix for it fairly easily...expect to see it posted later today. It will probably involve moving the player away from the vehicle when they dismount by a block or two--as I think on the server it is the player that is forcing the vehicle into the ground.
In 1.3.2 this isn't an issue, as they rewrote the vanilla dismount code to do pretty much that (move player upon dismount)..so I guess I kind of forgot about it in the 1.2.5 branch.
Anyway, sorry about that, and you should see an update in a few hours (4-5 hours...got a few other things to do first).
I may have found a small issue. When dismounting the catapult from clicking the button on the GUI interface, the catapult glitches into the block level below it, it seemingly moved on block deeper into the world and essentially i am glitches into the ground as well with the catapult, which almost always results in death. Oddly enough there was a 10-15 minute period of time it worked fine, i going to continue testing it on various size areas of flat land to see if something environmental is causing the issue. Aside from that everything else seems to function wonderfully.
Both the ballista and catapult demounting has the same effect, it does not do this on initial placement. It seems to occur after ammo has been added and fired afew times. Any thoughts?
Fixes:
Vehicle would occasionally glitch into the floor/ground after dismount. It would also occasionally damage the player who was riding it. Both have been fixed.
Upon dismounting a vehicle, you will be placed up to two blocks away. It will attempt to find an empty area two blocks tall to place the dismounting player in. If none can be found, it will default to the original behavior (meaning there was no empty area to dismount you into)
Thank you for the very quick update. I wasn't expecting a fix tonight! I'll do some more testing tomorrow after Im home from work. Oh one other thing, the catapult when placed seems to "jump" up and down on occasion, like it does on initial placement. How it falls about a block above the placement level.
I have one catapult just sitting there and it would just do a little hop every once in awhile (10-15 seconds), its not a big issue. It doesn't interfere with any usage of the mod.
I have to say the ammo flying through the air is nice and smooth, its great! I did however accidentally burn down afew redwood trees outside the castle i didn't. Great work, and thanks again.
Thank you for the very quick update. I wasn't expecting a fix tonight! I'll do some more testing tomorrow after Im home from work. Oh one other thing, the catapult when placed seems to "jump" up and down on occasion, like it does on initial placement. How it falls about a block above the placement level.
I have one catapult just sitting there and it would just do a little hop every once in awhile (10-15 seconds), its not a big issue. It doesn't interfere with any usage of the mod.
I have to say the ammo flying through the air is nice and smooth, its great! I did however accidentally burn down afew redwood trees outside the castle i didn't. Great work, and thanks again.
I did notice the 'hopping' on the bukkit server, and I think I know the cause. It didn't seem to interfere with anything, so I wasn't in a huge rush to fix it--especially since the fix may require quite a bit of rewriting of movement handling code. I don't remember it doing that on vanilla servers, so it may even be a bukkit-related thing that I'm not handling properly.
I will look into it (as I would like the 1.2.5 branch to be as stable as possible), but might be a few weeks before I get around to doing an update for it.
Got an error report for you, tried heaps of times to run this with the forge modloader with nothing but forge modloader and this mod, here is the error report
Minecraft has crashed!
----------------------
Minecraft has stopped running because it encountered a problem; Failed to start game
This error has been saved to C:\Users\Steve\AppData\Roaming\.minecraft\crash-reports\crash-2012-09-07_22.15.04-client.txt for your convenience. Please include a copy of this file if you report this crash to anyone.
--- BEGIN ERROR REPORT d8de7c41 --------
Generated 7/09/12 10:15 PM
- Minecraft Version: 1.3.2
- Operating System: Windows 7 (x86) version 6.1
- Java Version: 1.6.0_27, Sun Microsystems Inc.
- Java VM Version: Java HotSpot™ Client VM (mixed mode), Sun Microsystems Inc.
- Memory: 939882144 bytes (896 MB) / 1037959168 bytes (989 MB) up to 1037959168 bytes (989 MB)
- JVM Flags: 2 total; -Xmx1024m -Xms1024m
- LWJGL: 2.4.2
- OpenGL: ATI Radeon HD 2400 PRO GL version 2.1.8787, ATI Technologies Inc.
- Is Modded: Definitely; 'forge,fml'
- Type: Client
- Texture Pack: Default
- Profiler Position: N/A (disabled)
java.lang.NullPointerException
at cpw.mods.fml.common.FMLModContainer.getName(FMLModContainer.java:106)
at cpw.mods.fml.common.Loader.sortModList(Loader.java:236)
at cpw.mods.fml.common.Loader.loadMods(Loader.java:416)
at cpw.mods.fml.client.FMLClientHandler.beginMinecraftLoading(FMLClientHandler.java:192)
at net.minecraft.client.Minecraft.a(Minecraft.java:402)
at net.minecraft.client.Minecraft.run(Minecraft.java:734)
at java.lang.Thread.run(Unknown Source)
--- END ERROR REPORT c28fb01e ----------
I am a total idiot, i installed the wrong version of forge, please forgive me for wasting this post space and filling up your thread with useless info
In other words: Sorry
No worries, we've all built with the wrong forge before---one of the main downsides to the whole mine craft modding world. Please let me know if you encounter any other issues though.
Adds battering ram and recipes
Adds recipes for all armors
And few minor fixes regarding packet handling.
Battering ram does not need wheels in order to move, nor does it need ammunition. When it attacks, it will both: destroy the blocks in front of the ram, and damage any entities that are at that height in front of it (more damage the closer the entity is to the ram).
Didn't quite make it in:
Gates!! (_sooo_ close, but the implementation is still buggy, and I don't want to release them as-is).
Kind of like a garage-door for your castle, and can be nearly any-size you want them to. Open/Close on activation (and hopefully redstone + locking ability).
Hopefully I will work out the weirdness and have a second update to add gates in a few days (they might wait until next weekends update though).
OP will be updated shortly with links and recipes.
This looks really interesting ^^ Think you might be up for helping out another mod that needs similar weapons? Not now clearly while your working on this ^^ I think you could do a particularly good tank mod based off what I see here
FIX--remove debug rendering, and (re)disable debugging keybinds
NEW--Added both wooden and Iron gates
-----these function pretty much like a garage door
-----(drawbridges and horizontally extending bridges will be coming in another update)
A wooden gate in the process of lowering (old block based code...looks the same though):
A wooden and an Iron gate (both from the new entity based code):
Gate building items are used by selecting a pair of coordinates--click on two opposite corners of where you want the gate to be built
and it will build itself to fill up those dimensions. If you have selected invalid coordinates, the gate will NOT be built, and you will have to retry. Selecting coordinates works just like placing a block, and will select the coordinate for an area clicked as if you were attempting to place a block there.
After placed, you may right-click on a gate to raise or lower it. Attacking a gate will decrease its health and make it flash red. Attempting to attack a gate with sticks equipped will repair it. Health is currently not displayed, but it is 10 health per-block for wooden gates, and 17-per-block for iron gates (max initial health). Wooden gates can be caught on fire (they will go out after a few seconds), while iron gates are immune to fire/fire damage.
Right clicking a gate will activate it. Gates can be both activated and locked by a redstone signal to any of the four corners of the gate. If the gate is unpowered and provided constant power, it will activate and then lock into its new position once done activating. This is so you can 'lock' a gate from the inside. When powered(locked) you can neither activate the gate by clicking nor by redstone...it must have all power removed before it can be re-activated/toggled. The gate only checks for power at its for corners, so power sources must be placed accordingly.
I will try and release a video on these shortly, as the initial spawning of them might seem a bit weird (I'm looking into alternative methods that would work as reliably). Once spawned, they work pretty much like a door.
There are a few known issues:
maximum size is unknown -- I have tried up to about 15x15 without issues(aside from interaction when open)--and that is one huge door. I believe I have it hard-coded to fail if any dimension is larger than 20 blocks though, so should not be too much of an issue.
vehicles will try and drive 'over' a closed gate
battering ram has no special interaction with gates yet (aside from the regular damage they would do to any entity)
extremely large gates can be hard to activate when open (too tall to click on the top)
any open gate can be difficult to activate (you need to click on where the very top of the gate would be, usually while standing directly underneath it)
entities can see you through the gate, and will try and attack you through it. creepers may detonate on the other side of a closed gate while you cannot see them (iron gates recommended for visibility)
attack and interaction ranges seem a bit large
---they are not perfect, but _much_ more reliable than the original block/tile entity based implementation I had originally written, and I think I can sort out most of the remaining issues one way or another.
OP will be updated shortly with link and recipes, video might come in the next few days (but please post if you have problems with the gates...or anything for that matter).
Defenitely looks like a fun concept. I'm still in the process of reading through the posts in my downtime, but should be caught up in a day or two.
I'de definitely be willing to lend a hand when I get this project to a well fleshed-out point (which actually might not take to long at that rate I've been going).
I can send you further contact info to discuss it more if you would like (skype/email/whatever), as I'de love to take a look at what you guys have going so far, and find out more about what you are looking for precisely (I might even be able to come up with some stuff in my spare'ish time).
Anyhow, let me know either way (message would be fine)
Defenitely looks like a fun concept. I'm still in the process of reading through the posts in my downtime, but should be caught up in a day or two.
I'de definitely be willing to lend a hand when I get this project to a well fleshed-out point (which actually might not take to long at that rate I've been going).
I can send you further contact info to discuss it more if you would like (skype/email/whatever), as I'de love to take a look at what you guys have going so far, and find out more about what you are looking for precisely (I might even be able to come up with some stuff in my spare'ish time).
Anyhow, let me know either way (message would be fine)
Thanks again for your interest
Alternatelives would be happy to hear from you, I'm the texture guy for him until somebody better comes along. I also answer most of the questions since he isn't online often enough to keep everybody happy, I can keep an eye over here too if you want ^^ Im pretty good with coming up with ideas if you need them..
http://dl.dropbox.co...-108--alpha.zip
Link is also in the OP in the normal spot.
Fixes keybinds resetting, regardless of forge version. You can change them via in-game config, or editing the config file.
Removed debug keybinds from view. They weren't supposed to be there for release
Also cleaned up some exception handling for not-yet-spawned-on-the-client entities.
No other changes.
----Armor is still coming soon!----
Both the ballista and catapult demounting has the same effect, it does not do this on initial placement. It seems to occur after ammo has been added and fired afew times. Any thoughts?
Death sounds like a bad bug...
Thanks for pointing this out. I had kind of noticed it when doing the bukkit port, but didn't think too much of it. I should be able to come up with a fix for it fairly easily...expect to see it posted later today. It will probably involve moving the player away from the vehicle when they dismount by a block or two--as I think on the server it is the player that is forcing the vehicle into the ground.
In 1.3.2 this isn't an issue, as they rewrote the vanilla dismount code to do pretty much that (move player upon dismount)..so I guess I kind of forgot about it in the 1.2.5 branch.
Anyway, sorry about that, and you should see an update in a few hours (4-5 hours...got a few other things to do first).
Update for 1.2.5 has been pushed.
Links:
http://dl.dropbox.com/u/95935735/Cat_Mod_Releases/Catapult_Mod-0.9.7-beta--Client.zip
http://dl.dropbox.com/u/95935735/Cat_Mod_Releases/Catapult_Mod-0.9.7-beta--CraftBukkit.zip
http://dl.dropbox.com/u/95935735/Cat_Mod_Releases/Catapult_Mod-0.9.7-beta--Server.zip
Fixes:
Vehicle would occasionally glitch into the floor/ground after dismount. It would also occasionally damage the player who was riding it. Both have been fixed.
Upon dismounting a vehicle, you will be placed up to two blocks away. It will attempt to find an empty area two blocks tall to place the dismounting player in. If none can be found, it will default to the original behavior (meaning there was no empty area to dismount you into)
OP will be updated shortly.
I've been thinking about an avatar...but..perhaps I'll think a bit longer yet.
I have one catapult just sitting there and it would just do a little hop every once in awhile (10-15 seconds), its not a big issue. It doesn't interfere with any usage of the mod.
I have to say the ammo flying through the air is nice and smooth, its great! I did however accidentally burn down afew redwood trees outside the castle i didn't. Great work, and thanks again.
I did notice the 'hopping' on the bukkit server, and I think I know the cause. It didn't seem to interfere with anything, so I wasn't in a huge rush to fix it--especially since the fix may require quite a bit of rewriting of movement handling code. I don't remember it doing that on vanilla servers, so it may even be a bukkit-related thing that I'm not handling properly.
I will look into it (as I would like the 1.2.5 branch to be as stable as possible), but might be a few weeks before I get around to doing an update for it.
Got an error report for you, tried heaps of times to run this with the forge modloader with nothing but forge modloader and this mod, here is the error report
Minecraft has crashed!
----------------------
Minecraft has stopped running because it encountered a problem; Failed to start game
This error has been saved to C:\Users\Steve\AppData\Roaming\.minecraft\crash-reports\crash-2012-09-07_22.15.04-client.txt for your convenience. Please include a copy of this file if you report this crash to anyone.
--- BEGIN ERROR REPORT d8de7c41 --------
Generated 7/09/12 10:15 PM
- Minecraft Version: 1.3.2
- Operating System: Windows 7 (x86) version 6.1
- Java Version: 1.6.0_27, Sun Microsystems Inc.
- Java VM Version: Java HotSpot™ Client VM (mixed mode), Sun Microsystems Inc.
- Memory: 939882144 bytes (896 MB) / 1037959168 bytes (989 MB) up to 1037959168 bytes (989 MB)
- JVM Flags: 2 total; -Xmx1024m -Xms1024m
- LWJGL: 2.4.2
- OpenGL: ATI Radeon HD 2400 PRO GL version 2.1.8787, ATI Technologies Inc.
- Is Modded: Definitely; 'forge,fml'
- Type: Client
- Texture Pack: Default
- Profiler Position: N/A (disabled)
java.lang.NullPointerException
at cpw.mods.fml.common.FMLModContainer.getName(FMLModContainer.java:106)
at cpw.mods.fml.common.Loader.sortModList(Loader.java:236)
at cpw.mods.fml.common.Loader.loadMods(Loader.java:416)
at cpw.mods.fml.client.FMLClientHandler.beginMinecraftLoading(FMLClientHandler.java:192)
at net.minecraft.client.Minecraft.a(Minecraft.java:402)
at net.minecraft.client.Minecraft.run(Minecraft.java:734)
at java.lang.Thread.run(Unknown Source)
--- END ERROR REPORT c28fb01e ----------
I am a total idiot, i installed the wrong version of forge, please forgive me for wasting this post space and filling up your thread with useless info
In other words: Sorry
0.5.2.109-alpha is available for DL.
Catapult_Mod-0.5.2.109-alpha.zip
Adds battering ram and recipes
Adds recipes for all armors
And few minor fixes regarding packet handling.
Battering ram does not need wheels in order to move, nor does it need ammunition. When it attacks, it will both: destroy the blocks in front of the ram, and damage any entities that are at that height in front of it (more damage the closer the entity is to the ram).
Didn't quite make it in:
Gates!! (_sooo_ close, but the implementation is still buggy, and I don't want to release them as-is).
Kind of like a garage-door for your castle, and can be nearly any-size you want them to. Open/Close on activation (and hopefully redstone + locking ability).
Hopefully I will work out the weirdness and have a second update to add gates in a few days (they might wait until next weekends update though).
OP will be updated shortly with links and recipes.
http://dl.dropbox.com/u/95935735/Cat_Mod_Releases/Catapult_Mod-0.5.2.110-alpha.zip
release highlights:
FIX--remove debug rendering, and (re)disable debugging keybinds
NEW--Added both wooden and Iron gates
-----these function pretty much like a garage door
-----(drawbridges and horizontally extending bridges will be coming in another update)
A wooden gate in the process of lowering (old block based code...looks the same though):
A wooden and an Iron gate (both from the new entity based code):
Gate building items are used by selecting a pair of coordinates--click on two opposite corners of where you want the gate to be built
and it will build itself to fill up those dimensions. If you have selected invalid coordinates, the gate will NOT be built, and you will have to retry. Selecting coordinates works just like placing a block, and will select the coordinate for an area clicked as if you were attempting to place a block there.
After placed, you may right-click on a gate to raise or lower it. Attacking a gate will decrease its health and make it flash red. Attempting to attack a gate with sticks equipped will repair it. Health is currently not displayed, but it is 10 health per-block for wooden gates, and 17-per-block for iron gates (max initial health). Wooden gates can be caught on fire (they will go out after a few seconds), while iron gates are immune to fire/fire damage.
Right clicking a gate will activate it. Gates can be both activated and locked by a redstone signal to any of the four corners of the gate. If the gate is unpowered and provided constant power, it will activate and then lock into its new position once done activating. This is so you can 'lock' a gate from the inside. When powered(locked) you can neither activate the gate by clicking nor by redstone...it must have all power removed before it can be re-activated/toggled. The gate only checks for power at its for corners, so power sources must be placed accordingly.
I will try and release a video on these shortly, as the initial spawning of them might seem a bit weird (I'm looking into alternative methods that would work as reliably). Once spawned, they work pretty much like a door.
There are a few known issues:
maximum size is unknown -- I have tried up to about 15x15 without issues(aside from interaction when open)--and that is one huge door. I believe I have it hard-coded to fail if any dimension is larger than 20 blocks though, so should not be too much of an issue.
vehicles will try and drive 'over' a closed gate
battering ram has no special interaction with gates yet (aside from the regular damage they would do to any entity)
extremely large gates can be hard to activate when open (too tall to click on the top)
any open gate can be difficult to activate (you need to click on where the very top of the gate would be, usually while standing directly underneath it)
entities can see you through the gate, and will try and attack you through it. creepers may detonate on the other side of a closed gate while you cannot see them (iron gates recommended for visibility)
attack and interaction ranges seem a bit large
---they are not perfect, but _much_ more reliable than the original block/tile entity based implementation I had originally written, and I think I can sort out most of the remaining issues one way or another.
OP will be updated shortly with link and recipes, video might come in the next few days (but please post if you have problems with the gates...or anything for that matter).
Absolutely
Defenitely looks like a fun concept. I'm still in the process of reading through the posts in my downtime, but should be caught up in a day or two.
I'de definitely be willing to lend a hand when I get this project to a well fleshed-out point (which actually might not take to long at that rate I've been going).
I can send you further contact info to discuss it more if you would like (skype/email/whatever), as I'de love to take a look at what you guys have going so far, and find out more about what you are looking for precisely (I might even be able to come up with some stuff in my spare'ish time).
Anyhow, let me know either way (message would be fine)
Thanks again for your interest
Kudos to Shadow for all the awesome work!
Thanks!
EDIT: LOL. Forgot I'm not the only shadow here. Woops, that's embarrassing. Sorry