1) Railcraft 4.3 is for 1.2.4 not for 1.2.5
2) You no longer need ModloaderMP with Forge build 75
3) Wait patiently for CoverJaguar to actually do the port to 1.2.5 - forge only stabilized what like 12h ago?
Point still stands, people claiming that it's 1.2.5 functional didn't test properly. I got the same error without MLMP as well.
*edit*
To clarify things, I am waiting patiently for it be 1.2.5 compliant. I just get really sick and tired of people spreading crap about how it works when they didn't even do basic testing...
Sorry guys, took a bit of a break while things settled down with Forge/MC/etc...
I'll try and post one final version for 1.2.4 before making the transition to 1.2.5. Mainly because its basically done aside from SMP testing. And will say right now that I'd be very surprised if you get 1.2.5 to work with the current releases. At the very least several Forge functions changed their signature.
Getting a strange problem, and Modloader txt isn't reporting any errors, nor can I get a crash dump because it's not actually crashing. On my server I run 2 mods, IndustrialCraft2, and RailCraft. The sever is running ModLoaderMP and Forge (this is all 1.2.4 btw) and my client is running ModLoader, ModLoaderMP, Forge, IC2 and RailCraft. It all works fine in SSP, but when I place a block from RailCraft, it's invisible and I'f I attempt to click the spot, the game goes to the dirt screen for a few seconds before a black screen.
I've tried everything, including resetting up the server by getting a fresh jar and reinstalling MLMP, Forge, IC2 and RC and it still happens. I've followed the instructions for installing, to the letter and this continues to happen. What am I doing wrong?
Make sure both client and server are running identical config files. By default they do not.
*flags CJ down* Yo. Wanna talk to you. The change done to High Speed rails (not sure what version) put them just a bit faster than the speed of normal rails (by default).
Yet when I ran over a section that didn't have a track, BOOM. Can you please... please have an option to disable explosions for high speed rails? I know that's not realistic in anyway, but...
1. They are very ...... sensitive, as I said several pages ago when Railcraft was for 1.1.0.
2. I feel like eventually they will give me a heart attack (seriously) of the sudden "BOOM" sound. Yeah, I get scared quite easily.
Everytime I get on one, I cringe fearing explosions.
Please put the option to disable the BOOM (or at least remove the sound). It's an option. Not everyone will use it, I'm sure. But it's there just incase. Say for testing purposes.
You might be able to delete the explosion sounds from ".minecraft\resources\newsound\random", that or replace them with empty sound files. It would be somewhat tricky for me remove the sound via code.
As for them being only slightly faster, I did lower the default to 2.5x faster than normal carts at one point (1.0 tiles per tick). But the max is only 1.2 tiles per tick.
I am however disinclined to disable the explosion unless I can come up with an alternative penalty that would encourage people to at least enable the explosion for normal play. Perhaps something like removing the crafting recipe while explosions are disabled.
Hmm. This definitely needs your attention, Covert. I was browsing the Twilight Forest thread and saw this;
Don't know if you already know this or not. Just, since your mod requires ModLoaderMp, I wanted to tell you. Think you mentioned before of Forge intergrading ModLoaderMp in a later version?
I already made the transition a while back. But I need to double check and make sure I'm not actually still calling any ModloaderMp functions though, like log() for example. Once I can remove ModloaderMp from my dev environment safely, I'll remove the install requirement.
Covert doesn't support nor suggest using the technic pack. You should ask them for support.
Also, Covert. I know you're on Spring Break or something. But when you get back, I've been looking over the OP again and I have to say, there comes a time where a cart has to say; "Get the **** out of my way!!" and runs over animals on your tracks.
Will you be the one that "bans" griefing animals by insta-killing them in a Minecart, without losing momentum? Ends the need for disgusting barriers and glass tunnels over your tracks to keep them off? Removes the need of having to change the Grass between tracks to Gravel to stop animals from spawning?
If you accept and do this challenge, you will be a Minecraft God in my book (and my best friend).
Hmm....well that's a tricky one. Since I do want carts to be able to be used to automate mob farming I can't really be killing off mobs every time a cart runs into one. Best I can probably do is make a cart that kills/throws mobs on contact. Though if I ever make electric rails, one feature they will probably have is that they shock anything on the track.
Hmm....well that's a tricky one. Since I do want carts to be able to be used to automate mob farming I can't really be killing off mobs every time a cart runs into one. Best I can probably do is make a cart that kills/throws mobs on contact. Though if I ever make electric rails, one feature they will probably have is that they shock anything on the track.
Well, Minecart Mania I believe tried to do this too but with little success. It pushed the mob off the track but didn't always work, and went full speed backwards. These electric rails sound awesome, but I assume they require IC2? My transit system already requires four mods (including yours) to operate. I hate to force another.
Energy loader turning to item loader: Only tried SMP. Although I really push things, this happened after 8-10 remove and replace in 2 minutes, trying to find the best position. Looked really interesting, after removing the original energy loader it kept the original graphics, but lost (became empty, but still a gray floating thing) the alt (floating title) and when placing again it was now an item loader, with proper alt (that is item loader) when removed later.
It's a little hazy but I seem to remember running into this if I used a wrench to try and remove it instead of a pick - try and see if that's a factor (that was also an smp world)
It's a little hazy but I seem to remember running into this if I used a wrench to try and remove it instead of a pick - try and see if that's a factor (that was also an smp world)
I could see this happening if we were talking about rails, but it should not happen with utility blocks. They are more robust and rely on metadata for item drops. Nor do I see anything that might cause wrenches to be more susceptible to causing this, other than the fact that the wrench is faster at removing the block. But even still the client should receive the metadata in the same packet as the block id, leaving no possibility of lag being the cause. So as I said before, very odd.
I'm using railcraft to build a self sorting warehouse, I'm having a slight issue though. Here's my layout:
Those are holding rails over item unloaders next to chests with filters. Fair enough. However I am having an issue with the central unloaders - some of them, rather than unloading the chests next to them, will instead unload to the chest across the tracks from them. Any idea on how to prevent this? I assume if i had a one block gap between the rails it would work fine, but I'm hoping there's a way that doesn't involve tearing apart half of my warehouse to shunt it over a block...
I'm using railcraft to build a self sorting warehouse, I'm having a slight issue though. Here's my layout:
Those are holding rails over item unloaders next to chests with filters. Fair enough. However I am having an issue with the central unloaders - some of them, rather than unloading the chests next to them, will instead unload to the chest across the tracks from them. Any idea on how to prevent this? I assume if i had a one block gap between the rails it would work fine, but I'm hoping there's a way that doesn't involve tearing apart half of my warehouse to shunt it over a block...
The reason this is happening is that the Unloader sees the neighboring Unloaders as a viable destination for items. I'll change it in the next patch so that can't happen.
Also, I lied. I'm going to skip that last 1.2.4 patch and go straight to 1.2.5. I got a little carried away while reworking some of the recipes and the result was more than enough changes to require a major version increment. However this also means I probably won't get the update out until sometime this weekend.
Somehow, I think we can all live with that. I'd rather have a version that works in 1.2.5 so I can get rid of the stock crap we had to use for the server railway we're setting up. Gah, I hate the stock rail setup.
so......
*shoo**shoo*
looks like my train is leaving the station now!
thanks to this mod,so i can have a train between my mine and my house!
better grab my diamond pickaxe before its too late to catch!
The reason this is happening is that the Unloader sees the neighboring Unloaders as a viable destination for items. I'll change it in the next patch so that can't happen.
Also, I lied. I'm going to skip that last 1.2.4 patch and go straight to 1.2.5. I got a little carried away while reworking some of the recipes and the result was more than enough changes to require a major version increment. However this also means I probably won't get the update out until sometime this weekend.
This weekend!!!! OH THANK YOU THANK YOU THANK YOU!
I haven't updated my server or client pc's because I'm waiting for Railcraft Hopefully the last of the ModloaderMP stuff will be out of the build this time. (pretty please with sugar on it)
Take the time and do it right, I'll wait....
*I bow down before the modding gods... >;>
We're not worthy, we're not worthy!*
I could see this happening if we were talking about rails, but it should not happen with utility blocks. They are more robust and rely on metadata for item drops. Nor do I see anything that might cause wrenches to be more susceptible to causing this, other than the fact that the wrench is faster at removing the block. But even still the client should receive the metadata in the same packet as the block id, leaving no possibility of lag being the cause. So as I said before, very odd.
it's an IC2 mechanism - whenever you use the wrench or the powered wrench in energy concervation mode it has a chance of breaking the block device down. For example if you use a wrench on an MFE it has a chance of becoming machine block. You need to change the mode on the electric wrench to avoid this problem (and you'll be rechanging that wrench practically every 2nd use). So it might be an interaction between what ever code does that in IC2 and your block. I do remember running into the problem though at least once. Ever since then I've made sure to always use a pick axe on the energy loaders/unloaders. Usually the unloader as my primary use for it was a mining operation using the IC2 miner (this was back when all the mods were in sync). But like I said my memory might be a bit hazy since it's been a while since I've used IC2 with Railcraft.
it's an IC2 mechanism - whenever you use the wrench or the powered wrench in energy concervation mode it has a chance of breaking the block device down. For example if you use a wrench on an MFE it has a chance of becoming machine block. You need to change the mode on the electric wrench to avoid this problem (and you'll be rechanging that wrench practically every 2nd use). So it might be an interaction between what ever code does that in IC2 and your block. I do remember running into the problem though at least once. Ever since then I've made sure to always use a pick axe on the energy loaders/unloaders. Usually the unloader as my primary use for it was a mining operation using the IC2 miner (this was back when all the mods were in sync). But like I said my memory might be a bit hazy since it's been a while since I've used IC2 with Railcraft.
I doubt that is the case. I have it setup so that getWrenchDropRate() returns zero, always. Meaning that it never drops successfully and always falls back to whatever getBlockDropped() returns. And getBlockDropped() should always return the correct item. Unless of course IC2 is doing something weird when passed a 0% chance to successfully drop the block, you know like actually dropping the block successfully.
The IWrenchable API is severely lacking when it comes to controlling which blocks get dropped. It assumes that a successful drop is created via (new ItemStack(blockid, metadata)), which is not the case with Utility, Structure, or Rail blocks in Railcraft at all. Attempting to do so is buggy at best. It would also be nice if you could drop more than one item when it breaks but you can't do that either because anything beyond one item will drop whether or not the drop was successful.
Does anyone know if the dropped item has no name? If it doesn't then the ItemBlock item is being dropped instead of the ItemUtility item. In which case it would have to be something interfering with the drop code rather than the metadata.
Just when critical mods are about to update to 1.2.5 Mojang goes and starts to release yet another new version...
Can you excuse me...
Well, anyway. I got news about BuildCraft. Looks like there is activity in the coding department and there "might" be an update one of these days/weeks. http://www.mod-build...ate/#post-18073
Just when critical mods are about to update to 1.2.5 Mojang goes and starts to release yet another new version...
Yeah leave it to them to throw one hell of a monkey wrench into the works. What really sucks is that "@dinnerbone requested to keep the changelog secret, so blame him for this:" on the update. So now the modders don't have a clue what has been changed in the latest build.
Not going to start ranting here this is not the thread for that...
But all the same I'm not going to update anything until I find out what they have changed this time..
Laters.
I just want to get off 1.1 already. Finally got Railcraft added to my mod soup, then realized some of the features I wanted to use aren't in the older version I'm stuck with. heh
Point still stands, people claiming that it's 1.2.5 functional didn't test properly. I got the same error without MLMP as well.
*edit*
To clarify things, I am waiting patiently for it be 1.2.5 compliant. I just get really sick and tired of people spreading crap about how it works when they didn't even do basic testing...
I'll try and post one final version for 1.2.4 before making the transition to 1.2.5. Mainly because its basically done aside from SMP testing. And will say right now that I'd be very surprised if you get 1.2.5 to work with the current releases. At the very least several Forge functions changed their signature.
Make sure both client and server are running identical config files. By default they do not.
You might be able to delete the explosion sounds from ".minecraft\resources\newsound\random", that or replace them with empty sound files. It would be somewhat tricky for me remove the sound via code.
As for them being only slightly faster, I did lower the default to 2.5x faster than normal carts at one point (1.0 tiles per tick). But the max is only 1.2 tiles per tick.
I am however disinclined to disable the explosion unless I can come up with an alternative penalty that would encourage people to at least enable the explosion for normal play. Perhaps something like removing the crafting recipe while explosions are disabled.
The Bore was bugged in early 4.0 versions of Railcraft.
I already made the transition a while back. But I need to double check and make sure I'm not actually still calling any ModloaderMp functions though, like log() for example. Once I can remove ModloaderMp from my dev environment safely, I'll remove the install requirement.
Odd....is this SMP or SSP?
Impossible. You are either confused or lying. The function in question (getGUIElement) didn't exist until build 70, a 1.2.5 version.
Hmm....well that's a tricky one. Since I do want carts to be able to be used to automate mob farming I can't really be killing off mobs every time a cart runs into one. Best I can probably do is make a cart that kills/throws mobs on contact. Though if I ever make electric rails, one feature they will probably have is that they shock anything on the track.
Well, Minecart Mania I believe tried to do this too but with little success. It pushed the mob off the track but didn't always work, and went full speed backwards. These electric rails sound awesome, but I assume they require IC2? My transit system already requires four mods (including yours) to operate. I hate to force another.
It's a little hazy but I seem to remember running into this if I used a wrench to try and remove it instead of a pick - try and see if that's a factor (that was also an smp world)
I could see this happening if we were talking about rails, but it should not happen with utility blocks. They are more robust and rely on metadata for item drops. Nor do I see anything that might cause wrenches to be more susceptible to causing this, other than the fact that the wrench is faster at removing the block. But even still the client should receive the metadata in the same packet as the block id, leaving no possibility of lag being the cause. So as I said before, very odd.
Those are holding rails over item unloaders next to chests with filters. Fair enough. However I am having an issue with the central unloaders - some of them, rather than unloading the chests next to them, will instead unload to the chest across the tracks from them. Any idea on how to prevent this? I assume if i had a one block gap between the rails it would work fine, but I'm hoping there's a way that doesn't involve tearing apart half of my warehouse to shunt it over a block...
The reason this is happening is that the Unloader sees the neighboring Unloaders as a viable destination for items. I'll change it in the next patch so that can't happen.
Also, I lied. I'm going to skip that last 1.2.4 patch and go straight to 1.2.5. I got a little carried away while reworking some of the recipes and the result was more than enough changes to require a major version increment. However this also means I probably won't get the update out until sometime this weekend.
*shoo**shoo*
looks like my train is leaving the station now!
thanks to this mod,so i can have a train between my mine and my house!
better grab my diamond pickaxe before its too late to catch!
This weekend!!!! OH THANK YOU THANK YOU THANK YOU!
I haven't updated my server or client pc's because I'm waiting for Railcraft Hopefully the last of the ModloaderMP stuff will be out of the build this time. (pretty please with sugar on it)
Take the time and do it right, I'll wait....
*I bow down before the modding gods... >;>
We're not worthy, we're not worthy!*
it's an IC2 mechanism - whenever you use the wrench or the powered wrench in energy concervation mode it has a chance of breaking the block device down. For example if you use a wrench on an MFE it has a chance of becoming machine block. You need to change the mode on the electric wrench to avoid this problem (and you'll be rechanging that wrench practically every 2nd use). So it might be an interaction between what ever code does that in IC2 and your block. I do remember running into the problem though at least once. Ever since then I've made sure to always use a pick axe on the energy loaders/unloaders. Usually the unloader as my primary use for it was a mining operation using the IC2 miner (this was back when all the mods were in sync). But like I said my memory might be a bit hazy since it's been a while since I've used IC2 with Railcraft.
I doubt that is the case. I have it setup so that getWrenchDropRate() returns zero, always. Meaning that it never drops successfully and always falls back to whatever getBlockDropped() returns. And getBlockDropped() should always return the correct item. Unless of course IC2 is doing something weird when passed a 0% chance to successfully drop the block, you know like actually dropping the block successfully.
The IWrenchable API is severely lacking when it comes to controlling which blocks get dropped. It assumes that a successful drop is created via (new ItemStack(blockid, metadata)), which is not the case with Utility, Structure, or Rail blocks in Railcraft at all. Attempting to do so is buggy at best. It would also be nice if you could drop more than one item when it breaks but you can't do that either because anything beyond one item will drop whether or not the drop was successful.
Does anyone know if the dropped item has no name? If it doesn't then the ItemBlock item is being dropped instead of the ItemUtility item. In which case it would have to be something interfering with the drop code rather than the metadata.
Good to hear. Hopefully BuildCraft and RedPower 2 get updated at the same time.
Very much agreed
Pure Vanilla Minecraft | 24/7 | Mature Active Community
Just when critical mods are about to update to 1.2.5 Mojang goes and starts to release yet another new version...
Can you excuse me...
Well, anyway. I got news about BuildCraft. Looks like there is activity in the coding department and there "might" be an update one of these days/weeks.
http://www.mod-build...ate/#post-18073
Yeah leave it to them to throw one hell of a monkey wrench into the works. What really sucks is that "@dinnerbone requested to keep the changelog secret, so blame him for this:" on the update. So now the modders don't have a clue what has been changed in the latest build.
Not going to start ranting here this is not the thread for that...
But all the same I'm not going to update anything until I find out what they have changed this time..
Laters.
http://www.mod-buildcraft.com/
Oops, wrong thread. Sorry guys.