My games crashes every time I try to put liquid into the tank car using the tank block. I'm using Simple Fluid Tanks with the tank block and as soon as I put some kind of liquid into the valve, the game crashes.
My games crashes every time I try to put liquid into the tank car using the tank block. I'm using Simple Fluid Tanks with the tank block and as soon as I put some kind of liquid into the valve, the game crashes.
Odd... I can't seem to re-create that crash. The fact that it's erroring on the getFluid() method is particularly troubling, as the only thing that does is gets a fluid's ID. Could you tell me exactly what you do to make it crash, e.g. which blocks you place first and where?
Also, 3.0 is getting released a day early (or on-time for you eastern folks). If you didn't know already, this update allows you to use the station block to load and unload entities, like villagers, cows, sheep and the like, into your trains. The GUI should be pretty self-explanatory. Get it here.
Do you have any signals? Like,when a train comes, it's lights green or something?
No signals, but the detector block can be used to create one. Just put it's redstone output into a green light or something and you're good. You could also use the signal to trigger an oscillating redstone torch configuration in the shape of a railroad crossing signal.
Odd... I can't seem to re-create that crash. The fact that it's erroring on the getFluid() method is particularly troubling, as the only thing that does is gets a fluid's ID. Could you tell me exactly what you do to make it crash, e.g. which blocks you place first and where?
Okay, here is what I did. I first set the track down then put the tank block next to it and have it set where the tank car is loaded with the liquid. I then set down a valve block next to the tank block and created a tank filled with water. I set down the tank car next to the tank block and that is when the game crashes.
Okay, here is what I did. I first set the track down then put the tank block next to it and have it set where the tank car is loaded with the liquid. I then set down a valve block next to the tank block and created a tank filled with water. I set down the tank car next to the tank block and that is when the game crashes.
Ah! Just figured it out. Forge is to blame. I use 1291, and ROW uses 1272, but I see you're using 1403. Take a look in here:
That FluidIdTransformer feller comes from the net.minecraftforge.classloading.FluidIdTransformer class, which I don't have in my version and explains why the getFluid() method is erroring out. It looks like Forge broke the fluid ID method in 1355, so you'll have to downgrade past that number until I can release a patch.
Testing your version, though, was interesting. Now there's a GUI for mod loading? Makes you almost forget about the META-INF era of pre-1.6. OptiForge, anyone?
That FluidIdTransformer feller comes from the net.minecraftforge.classloading.FluidIdTransformer class, which I don't have in my version and explains why the getFluid() method is erroring out. It looks like Forge broke the fluid ID method in 1355, so you'll have to downgrade past that number until I can release a patch.
Testing your version, though, was interesting. Now there's a GUI for mod loading? Makes you almost forget about the META-INF era of pre-1.6. OptiForge, anyone?
Downgrading did the trick. I look forward to the patch and other upcoming versions of this mod!
How can you make a mod that interacts with another mod? Is that legal?
It is, but you have to be careful how you do it. As an example, Naiten specifically states that people may not decompile or deobfusicate his mod. I haven't done that, but that doesn't mean I can't code something to work with ROW anyways. Since all moving things in Minecraft, be it a testificate or a train, are entities, they share the same set of base code. It's the entity properties, and a few custom NBT tags, that ROWAM works with. The hardest part is putting it into a user-usable format.
Quick Question, in the station block GUI, is left/right for loading/unloading in reference to the train car of the block itself?
Quick answer:
That's in reference to the train car.
Long answer:
I think a little explanation is in order with regards to the loading/unloading system:
First off, when a train arrives at a station the block checks within a 25 block radius for all stopped train cars. Any stopped car that matches the stock selector and contains an entity that matches the entity selector will be unloaded. The unloaded entity is placed on either the right of left side of the car, the side being determined by the direction the locomotive is facing. In addition to keeping your entities from dropping on the tracks like they normally do, the station block ejects them lower, thereby eliminating fall damage. Note that it still ejects them high enough to get them over any trackside fences, which makes automated cattle drives a very real possibility.
When a train departs, the station block again checks for stopped cars within a 25 block radius. It then checks to see if any of them match the cart selector in the GUI. If they do, the block looks for matching entities to the right and/or left sides of the cart to be loaded, again determined by the direction the locomotive is facing. This way you can make it so testificates only get loaded when on the station platform. One thing to remember, though, is that each cart only checks within a roughly 4x4 area for entities. If all your cows are clustered to one side of the pen, the only one or two might get loaded.
Finally, keep in mind that due to limitations the station block is not able to tell what train a cart is part of. This means that nearby, stopped carts from another train may be loaded or unloaded by a triggered station block. Use your selectors wisely!
Is there any chance that you can make a block or something that fixes the memory leaking issue on servers with ROW?
The memory leak is caused by ROWs packet handling methods, and the only way to fix that is to change the ROW code. Safe to say, I'm not doing that anytime soon.
What you can expect, though, is some sort of form of chunkloader in the next update.
sir, a chunk loader that loads when a player is within a certain range or accepts a red stone signal. "something so that the chunk is not always loaded" would be amazing. It would solve a major issue with the ABS system i'm working on. I may even give you a copy of the red stone. By the way your detector blocks made making signalling practical with row!
Another question I had that may or may not be possible. Would there be any way to have detectors that are linked or watch selected track sections? It would make it incredibly easy when making the logic for block occupancy and direction of travel for signals.
Thanks for what you have done so far I look forward to more!
sir, a chunk loader that loads when a player is within a certain range or accepts a red stone signal. "something so that the chunk is not always loaded" would be amazing. It would solve a major issue with the ABS system i'm working on. I may even give you a copy of the red stone. By the way your detector blocks made making signalling practical with row!
Another question I had that may or may not be possible. Would there be any way to have detectors that are linked or watch selected track sections? It would make it incredibly easy when making the logic for block occupancy and direction of travel for signals.
Thanks for what you have done so far I look forward to more!
Not sure what you mean about chunkloading. As it stands that's looking to be entity-based. Forge gives you your chunkloading tickets back at world-load, but for reasons I can't fathom it doesn't store what chunks are loaded. It's like giving me a blank railway ticket and asking me if I want to keep it. Either way, I've got it down now where each stock loads it's own chunk, which should substantially reduce server load for you long-haulers. The only question is how many chunks to load. Right now I have each stock only loading the chunk it's in. This is great for memory, but you end up missing signals if you place the blocks too far away. I can increase the number of chunks, but that'll mean 2 extra chunks per stock, or 3 for the stock at the ends of the train. With memory as scarce as it is with the leak, I'm leaning towards the former.
As far as signaling goes, making an occupancy lane is a bit tricky. Railcraft gets away with it by making occupancy lanes straight, something that chafes with the ROW model, in my opinion. The hardest part with working with the trains is direction. Is the loco going forward, backwards, backwards but forwards on the line, double-heading with another loco, cut off because it ran out of fuel? You get my drift. Linking detectors shouldn't be hard, but figuring out when a train has entered/left the block is. I'm not saying it isn't doable, I'm just saying don't hold your breath. In the meantime, you can use the redstone mechanism I demonstrated in the video.
Your idea about the spring-switch, however, will make it into the next update at this rate, along with a little bonus for the folks who like the ride the rails instead of use them for freight. Basically, it's going to be a bogie block update.
The linking detector blocks I was thinking would let you make the detection area that is normally 10x10 diameter? and stretch it out to be say 10 x 60. something that would let you get a output if a train was sitting on a passing track so that a red stone circuit would automatically line the switches and signals for the other track. right now the only way you could get a constant detection in a siding or straight main would be to have a detector every 10 blocks. for mainlines I have a circuit that defines occupancy and direction based on the order in which you pass the detectors witch throw a S-R latch. similar to the logic of a actual ABS system the final detectors on each block simply reset the system to clear but only if all detectors have been passed in the correct order of the direction set by the occupying train when the first detector was passed.
I'm pretty novice at coding with minecraft so if its not feasible or more difficult than the gains don't worry about it. Im a welder and electrician so I can design electrical systems or logic in gates "relays, diodes, etc".
The linking detector blocks I was thinking would let you make the detection area that is normally 10x10 diameter? and stretch it out to be say 10 x 60. something that would let you get a output if a train was sitting on a passing track so that a red stone circuit would automatically line the switches and signals for the other track. right now the only way you could get a constant detection in a siding or straight main would be to have a detector every 10 blocks. for mainlines I have a circuit that defines occupancy and direction based on the order in which you pass the detectors witch throw a S-R latch. similar to the logic of a actual ABS system the final detectors on each block simply reset the system to clear but only if all detectors have been passed in the correct order of the direction set by the occupying train when the first detector was passed.
I'm pretty novice at coding with minecraft so if its not feasible or more difficult than the gains don't worry about it. Im a welder and electrician so I can design electrical systems or logic in gates "relays, diodes, etc".
EDIT: By the way, an electrician like you might be interested in the Electrical Age mod. It's by far the most realistic representation of electricity I've seen in Minecraft.
New awesomeness, AKA ROWAM 4.0 is out. Get it here.
Basically this is a bogie block update. The most significant part is that the bogie block now loads chunks for ROW stock! A loaded bogie block will dynamically load chunks in a 3x3 radius around all stock.
Other updates:
Bogie blocks now have multiple modes. Right-clicking on the block cycles the mode.
High-speed is the default, which load chunks, fixes stock deaths, and re-positions mods riding in stock so they won't be stuck in the floor. You should have only one of these, and it needs to be in world spawn to work properly.
Low-speed is for slower computers/servers. It disables chunkloading, runs only once every 10 ticks, but still fixes rider deaths. Block restrictions are same as above.
Passive mode removes loco functionality, but adds a few more interesting bits. Any player that has a passive bogie block loaded (i.e. in their render distance), will automatically turn their body with the locomotive! Note that having a ton of these out may impact performance, so be warned.
Download now and I'll throw in an updated pointer block free of charge.
New pointer blocks have a spring mode that makes nearby switches spring-operated, in that they have one position. This position is kept, even if a locomotive runs over the switch from the 'wrong' direction. You can thank Mr. MeatBall_Sub for that suggestion.
1st page of post, lol...
My games crashes every time I try to put liquid into the tank car using the tank block. I'm using Simple Fluid Tanks with the tank block and as soon as I put some kind of liquid into the valve, the game crashes.
Crash log: http://pastebin.com/Syuc0eZq
Odd... I can't seem to re-create that crash. The fact that it's erroring on the getFluid() method is particularly troubling, as the only thing that does is gets a fluid's ID. Could you tell me exactly what you do to make it crash, e.g. which blocks you place first and where?
Also, 3.0 is getting released a day early (or on-time for you eastern folks). If you didn't know already, this update allows you to use the station block to load and unload entities, like villagers, cows, sheep and the like, into your trains. The GUI should be pretty self-explanatory. Get it here.
Do you have any signals? Like,when a train comes, it's lights green or something?
No signals, but the detector block can be used to create one. Just put it's redstone output into a green light or something and you're good. You could also use the signal to trigger an oscillating redstone torch configuration in the shape of a railroad crossing signal.
Okay, here is what I did. I first set the track down then put the tank block next to it and have it set where the tank car is loaded with the liquid. I then set down a valve block next to the tank block and created a tank filled with water. I set down the tank car next to the tank block and that is when the game crashes.
Ah! Just figured it out. Forge is to blame. I use 1291, and ROW uses 1272, but I see you're using 1403. Take a look in here:
LaunchWrapper: 24 active transformer(s)
- Transformer: cpw.mods.fml.common.asm.transformers.PatchingTransformer
- Transformer: cpw.mods.fml.common.asm.transformers.MarkerTransformer
- Transformer: cpw.mods.fml.common.asm.transformers.SideTransformer
- Transformer: cpw.mods.fml.common.asm.transformers.EventSubscriptionTransformer
- Transformer: net.minecraftforge.classloading.FluidIdTransformer
- Transformer: codechicken.lib.asm.ClassHeirachyManager
- Transformer: codechicken.core.asm.InterfaceDependancyTransformer
- Transformer: codechicken.core.asm.TweakTransformer
- Transformer: codechicken.core.asm.DelegatedTransformer
- Transformer: codechicken.core.asm.DefaultImplementationTransformer
- Transformer: com.mumfrey.liteloader.transformers.event.EventProxyTransformer
- Transformer: com.mumfrey.liteloader.launch.LiteLoaderTransformer
- Transformer: com.mumfrey.liteloader.client.transformers.CrashReportTransformer
- Transformer: cpw.mods.fml.common.asm.transformers.DeobfuscationTransformer
- Transformer: cpw.mods.fml.common.asm.transformers.AccessTransformer
- Transformer: net.minecraftforge.transformers.ForgeAccessTransformer
- Transformer: codechicken.core.asm.CodeChickenAccessTransformer
- Transformer: cpw.mods.fml.common.asm.transformers.ModAccessTransformer
- Transformer: cpw.mods.fml.common.asm.transformers.ItemStackTransformer
- Transformer: cpw.mods.fml.common.asm.transformers.TerminalTransformer
- Transformer: com.mumfrey.liteloader.client.transformers.LiteLoaderEventInjectionTransformer
- Transformer: com.mumfrey.liteloader.client.transformers.MinecraftOverlayTransformer
- Transformer: com.mumfrey.liteloader.common.transformers.LiteLoaderPacketTransformer
- Transformer: cpw.mods.fml.common.asm.transformers.ModAPITransformer
That FluidIdTransformer feller comes from the net.minecraftforge.classloading.FluidIdTransformer class, which I don't have in my version and explains why the getFluid() method is erroring out. It looks like Forge broke the fluid ID method in 1355, so you'll have to downgrade past that number until I can release a patch.
Testing your version, though, was interesting. Now there's a GUI for mod loading? Makes you almost forget about the META-INF era of pre-1.6. OptiForge, anyone?
Downgrading did the trick. I look forward to the patch and other upcoming versions of this mod!
I am hopfully going to get this! Keep making the good stuff!
How can you make a mod that interacts with another mod? Is that legal?
It is, but you have to be careful how you do it. As an example, Naiten specifically states that people may not decompile or deobfusicate his mod. I haven't done that, but that doesn't mean I can't code something to work with ROW anyways. Since all moving things in Minecraft, be it a testificate or a train, are entities, they share the same set of base code. It's the entity properties, and a few custom NBT tags, that ROWAM works with. The hardest part is putting it into a user-usable format.
Quick Question, in the station block GUI, is left/right for loading/unloading in reference to the train car of the block itself?
Quick answer:
That's in reference to the train car.
Long answer:
I think a little explanation is in order with regards to the loading/unloading system:
First off, when a train arrives at a station the block checks within a 25 block radius for all stopped train cars. Any stopped car that matches the stock selector and contains an entity that matches the entity selector will be unloaded. The unloaded entity is placed on either the right of left side of the car, the side being determined by the direction the locomotive is facing. In addition to keeping your entities from dropping on the tracks like they normally do, the station block ejects them lower, thereby eliminating fall damage. Note that it still ejects them high enough to get them over any trackside fences, which makes automated cattle drives a very real possibility.
When a train departs, the station block again checks for stopped cars within a 25 block radius. It then checks to see if any of them match the cart selector in the GUI. If they do, the block looks for matching entities to the right and/or left sides of the cart to be loaded, again determined by the direction the locomotive is facing. This way you can make it so testificates only get loaded when on the station platform. One thing to remember, though, is that each cart only checks within a roughly 4x4 area for entities. If all your cows are clustered to one side of the pen, the only one or two might get loaded.
Finally, keep in mind that due to limitations the station block is not able to tell what train a cart is part of. This means that nearby, stopped carts from another train may be loaded or unloaded by a triggered station block. Use your selectors wisely!
The memory leak is caused by ROWs packet handling methods, and the only way to fix that is to change the ROW code. Safe to say, I'm not doing that anytime soon.
What you can expect, though, is some sort of form of chunkloader in the next update.
sir, a chunk loader that loads when a player is within a certain range or accepts a red stone signal. "something so that the chunk is not always loaded" would be amazing. It would solve a major issue with the ABS system i'm working on. I may even give you a copy of the red stone. By the way your detector blocks made making signalling practical with row!
Another question I had that may or may not be possible. Would there be any way to have detectors that are linked or watch selected track sections? It would make it incredibly easy when making the logic for block occupancy and direction of travel for signals.
Thanks for what you have done so far I look forward to more!
Not sure what you mean about chunkloading. As it stands that's looking to be entity-based. Forge gives you your chunkloading tickets back at world-load, but for reasons I can't fathom it doesn't store what chunks are loaded. It's like giving me a blank railway ticket and asking me if I want to keep it. Either way, I've got it down now where each stock loads it's own chunk, which should substantially reduce server load for you long-haulers. The only question is how many chunks to load. Right now I have each stock only loading the chunk it's in. This is great for memory, but you end up missing signals if you place the blocks too far away. I can increase the number of chunks, but that'll mean 2 extra chunks per stock, or 3 for the stock at the ends of the train. With memory as scarce as it is with the leak, I'm leaning towards the former.
As far as signaling goes, making an occupancy lane is a bit tricky. Railcraft gets away with it by making occupancy lanes straight, something that chafes with the ROW model, in my opinion. The hardest part with working with the trains is direction. Is the loco going forward, backwards, backwards but forwards on the line, double-heading with another loco, cut off because it ran out of fuel? You get my drift. Linking detectors shouldn't be hard, but figuring out when a train has entered/left the block is. I'm not saying it isn't doable, I'm just saying don't hold your breath. In the meantime, you can use the redstone mechanism I demonstrated in the video.
Your idea about the spring-switch, however, will make it into the next update at this rate, along with a little bonus for the folks who like the ride the rails instead of use them for freight. Basically, it's going to be a bogie block update.
The linking detector blocks I was thinking would let you make the detection area that is normally 10x10 diameter? and stretch it out to be say 10 x 60. something that would let you get a output if a train was sitting on a passing track so that a red stone circuit would automatically line the switches and signals for the other track. right now the only way you could get a constant detection in a siding or straight main would be to have a detector every 10 blocks. for mainlines I have a circuit that defines occupancy and direction based on the order in which you pass the detectors witch throw a S-R latch. similar to the logic of a actual ABS system the final detectors on each block simply reset the system to clear but only if all detectors have been passed in the correct order of the direction set by the occupying train when the first detector was passed.
I'm pretty novice at coding with minecraft so if its not feasible or more difficult than the gains don't worry about it. Im a welder and electrician so I can design electrical systems or logic in gates "relays, diodes, etc".
EDIT: By the way, an electrician like you might be interested in the Electrical Age mod. It's by far the most realistic representation of electricity I've seen in Minecraft.
New awesomeness, AKA ROWAM 4.0 is out. Get it here.
Basically this is a bogie block update. The most significant part is that the bogie block now loads chunks for ROW stock! A loaded bogie block will dynamically load chunks in a 3x3 radius around all stock.
Other updates:
Bogie blocks now have multiple modes. Right-clicking on the block cycles the mode.
Download now and I'll throw in an updated pointer block free of charge.
Now I just have to get the railroad on my new map out to the first passing siding...