Mod Feedback [By Request] RotaryCraft Suggestions
- Thread starter Reika
- Start date
-
FTB will be shutting down this forum by the end of July. To participate in our community discussions, please join our Discord! https://ftb.team/discord
Though, I do hear that there's development going on to bring it to 1.7. At least, that's what some of the last posts on its forum have indicated, and for all intents and purposes, they were somewhat recent.PowerCraft revisited.
However, mine could potentially be better...I just don't know what kind of cap to put on it. 16 m/s? 24? 8? That'd be the default, of course; you'd be able to configure it to your taste (or -1 for no upper limit), or what you think your machine and/or Minecraft can handle.
Talk about some extra-zippy transport!
Also, I was thinking about something like this for the rules of conveyor belts:
- Two endpoints are defined by conveyor motors, and conveyor belts can only travel in a straight line. However, you can have one conveyor lead to another to get around curves.
- Power must be supplied to both conveyor motors for the belt train to function.
- A given amount of torque can only move a belt train of a certain length, given by this formula: y = x / 8; y is the length of belt train, including the motors, that can be supported, and x is the amount of torque supplied.
- Divide your speed by 512 (truncating the decimal) to get the speed (in m/s) the belt train goes.
- If you don't meet the torque requirements, again on both motors, the belt train will only move at a fixed rate of 1 m/s.
- Special smart conveyors can be crafted that can intelligently filter items in any direction on any plane, provided that you have another kind of special belt made for vertical transport, the sticky belt.
- The sticky belt will firmly hold on to anything it catches, and anything other than players (real or fake, or Thaumcraft golems and the like) can't escape. Their sticky properties also allow them to transport items vertically, as opposed to the strictly horizontal normal belts.
- If a belt leads to an inventory (like a chest), it'll attempt to insert the item into the first available, valid slot in the inventory, while interfacing find with sided inventories. This can, unfortunately, be a bit problematic with certain machines, but this can be solved with...
- Smart insertion belts! With them, you can tell them which side to insert items into a machine, or even just a given slot number, similar to Factorization routers.
Well, the "not technically failing, but still failing" thing would also likely be configurable, and speed may or may not be a floating-point variable...floating-point would allow more precision, and a smoother performance curve. I may not truncate the decimal at all, thinking on it. Also, the MFR conveyors are the most uselessly, painfully slow things I have EVER used. I really don't care about being marginally faster than they are. I have never had a situation where I've wanted to use them for anything. At least, this way, even when they're uselessly underpowered, my conveyors could still do something for someone. Its like meeting the absolute minimum requirements for a RoC grinder. It may be almost painfully slow, but its still useful.
I know, but "The Full Conversion" fits just as well.
Hey, I made a mystcraft age last night with no natural ores (dirt world), and iron tendrils. Absolutely massive (think the cave system generator, plopping down iron instead of air). Minor instability, but well worth it for RoC.Reika said:Now I want to try vein-generated ores. It completely eliminates the random of mining.
Xcw is going to give the instability another tweak. I've discovered how to go from "A little too nasty" to "Very, very easy".
Not true. No need for prospecting. You explore caves/ravines to find the veins. You know that if you go down deep, you are no longer in the iron zone. Etc.
You don't find these by digging randomly. You dig them out once you find them.
Custom Ore Generation, First Revival
http://www.minecraftforum.net/topic/1935710-172forge-custom-ore-generation-first-revival/unread/
As long as you make the little bastards take less time to break. Every time I think I want to use MFR conveyor belts, eventually I realize how much I didn't actually want to use MFR conveyor belts, and it takes me 15 minutes to clean them all back up, just so I can inevitably make the same mistake again later.
Oh hell no, I'm not pulling that kinda crap. I think a good, happy medium would be for them to break at about a similar speed to BuildCraft pipes: quickly, but not so quickly that a mis-click or bit of lag can screw you over and accidentally break more than you'd wanted.
You're mostly right, from my perspective, although you left a tiny bit out which I imagine you already know.
I play a GT 1.7 pack these days using similar generation and while I probably find 40% of the veins via caves/ravines as you mentioned. I find 40% via mountainsides, for high-elevation ores. This one feels particularly cool and realistic.
The remainder, good old fashioned mining. Although I call it exploratory mining now, since I don't do the standard 2-block-thick-wall branch-mining anymore. Veins can be huge, so a grid will generally be at least 30-40 blocks on a side.
Found a redstone/cinnabar/ruby vein last night just in time.
fwiw I think Reika would rock a custom ore generation mod, but its been done, so I can't imagine he'd have much interest.
Clusters. That's what TE calls them, and it works.
No (intentional) claims here, just things I've heard. I have precisely 0 experience with FC. Just heard a lot of warnings and drama history. Mostly as a fair warning so anyone that goes there is guarded and polite.
Erm, @Reika, I'm having an issue here. I've got a crash report from IntelliJ when I try to launch from the IDE, and its pointing me to something in RotaryCraft regarding armour. I've got both DragonAPI and RotaryCraft linked up properly, and I can include things from them just fine, though IntelliJ seems a tad anal about using full qualification for imports, and they're in the output's mods folder as my mod won't work without them...which I believe is how its supposed to be since its an addon and thus depends on both of them. Got any hints as to what might be going wrong here? The only thing my mod has in it, currently, its really really basic item (no interactions with anything, just kinda there) called a Spanner, soooooo...I'm sorta leaning away from it being a problem there. Only thing in my mod currently that I think may be an issue is my ItemRegistrar class, but all that does is act as a place to encapsulate all my item loading so the loading methods in my main mod class look pretty.
No...I copied the blast glass code...
I only noticed because we removed compressed cobble and everyone's anxious to find blast resistant blocks. I was trying Railcraft Strengthened Glass (not creeper or TNT proof), and spotted the tank. Turned out it was though I didn't expect it to be as none of the other tanks are. Most of us just progress to obsidian.
It looks like you have a Forge version issue, because the missing method is in the parent Item class.
Aah, so I just need a quick Forge update, eh? Good to know!
Oh, and have a visual representation of how conveyor trains will function:
[ETA]
Wait a tick...I'm using version 10.13.0.1208 of Forge, the latest one available. What version would I need to work with v1c of DragonAPI and RotaryCraft?
That is the version I use. What did you do?Aah, so I just need a quick Forge update, eh? Good to know!
Oh, and have a visual representation of how conveyor trains will function:
[ETA]
Wait a tick...I'm using version 10.13.0.1208 of Forge, the latest one available. What version would I need to work with v1c of DragonAPI and RotaryCraft?
I might have the dependency order wrong...I'm still kinda figuring out IntelliJ, lol.