Railcraft

Railcraft

34M Downloads

Redstone Flux cart are frustrating and useless

Malien opened this issue · 8 comments

commented

Redstone flux carts are prone to drag, as all battery carts do. Which makes sense from that stand point, but it is also makes using them in a single cart scenario impractical to say the least. I know battery drag was introduced to encourage the use of electric rails instead of EU batteries to power electric locomotive, and I do like the idea of using powered rails. The solutions to introduce additional battery drag for trains seems reasonable, but since RF can't be used to power locomotives anyways, RF carts can only be used as means of RF transportation, and whole drag makes them frustrating to use for such purposes at least.

Problem mostly begins when you try to combine regular carts (item, fluid, etc.) with RF carts as speeds of them vary dramatically. So maybe removing drag from single-cart use would be appreciated. Or maybe lessening it for RF ones, since they can't be used to power locomotives

As @CovertJaguar said, batteries suppose to be heavy, yet heavier object are harder to accelerate to desired speed, not that their max speed is lower. It makes some sense in terms of friction, but to make whole system more practical, it's better to at least lessen friction. As 'ol trusty formula F=ma says that the same force applied (in my case it's booster tracks) results in lesser acceleration for heavier objects, not speed. Additionally speed of heavier objects accelerated with gravity should be the same as for lighter ones (aka acceleration speed for falling, in our case sliding at 45º angle, objects is constant and equals g). This would eliminate the problem of speed inconsistency in booster-powered simple track design (without tracks for faster carts to drive past slower ones).

Also the pitiful max speed makes RF carts look like they are broken, and their physics looks really weird to the eye.

It would make a world of difference to RF transportations at mid-range distances where it is far enough to not to lay down pipes/wires everywhere, but close enough to use booster tracks instead of locomotives. But as for now, RF cart are ranging from impractical or useless, to even harmful to your existing fluid/item/etc. infrastructure.

Also RF carts rendering cause client lag for some reason, but that's not the core of the issue

P.S. I'm not familiar with Railcraft codebase so no pull request here :(

commented

Minecarts move via an inertia based system. They either have enough inertia to move at max speed or they don't move at all. As they move they consume inertia until there is not enough remaining to move. Boost tracks and locomotives work by adding more inertia to the pool. Drag applied by tracks, such as it is, is the rate at which inertia is consumed.

There is no concept of acceleration.

commented

I understand that Minecraft/Railcraft uses a different movement system to the one I've described, but that's only the real-world example of it. (Imagine using realism to justify Minecraft physics 😅). Just in this system, I don't see a use for RF batteries on carts. Maybe I'm not creative enough to come up with a reasonable solution, but all of the other designs I've come up with using RF carts are rediculous. I was just hoping a bit of a consistency buff for a cart to let it be used alongside other ones.

I don't mean this in any hateful way. I love your work here.

Thx.

commented

I've used the battery carts to great effect on local circuits. For example, I had a lot of IC2 advanced miners in a large mine connected by rail. I had one central power source / power storage. I put multiple trains in the rail circuit with a battery cart to charge MFE/MFSU's at each advanced miner. This worked very well.

If you want to use battery carts on regional rail networks, I'd just add bypass loops that would occasionally pull the slower battery cart trains and let the faster cargo trains go by.

commented

I'm just explaining the limitations of the system we have to work with. Any solution has to exist within that system.

I like that the slower trains adds an additional engineering challenge. That said, I'm willing to revisit just how dramatic the effect on the energy type carts is. Currently they calculate a max speed based on the number of locomotives in the train.

commented

private float calculateMaxSpeed() {
double locoBoost = Math.max(0.0, getNumRunningLocomotives() - 1.0) * 0.075;
return (float) (double) stream()
.mapToDouble(c -> Math.min(c.getMaxCartSpeedOnRail(), softMaxSpeed(c) + locoBoost)).min().orElse(1.2F);
}
private float softMaxSpeed(EntityMinecart cart) {
if (cart instanceof IWeightedCart)
return ((IWeightedCart) cart).softMaxSpeed();
return Capabilities.get(cart, CapabilitiesCharge.CART_BATTERY, null)
.filter(bat -> bat.getType() != IBatteryCart.Type.USER)
.map(bat -> 0.03F).orElse(cart.getMaxCartSpeedOnRail());
}

public final float softMaxSpeed() {
return 0.18F - 0.05F * getTier();
}

public final float softMaxSpeed() {
return 0.08F;
}

commented

Iron track has a max speed of 0.4, Reinforced 0.6 (I think) and HS 1.2.

Six locomotives could pull a train of as many energy carts as you want at somewhere around 0.5.

I would not be opposed to reworking a lot of this. For example, we could instead assign speed penalties for each energy cart and speed bonuses for each locomotive and rework the numbers.

commented

Sure. Guess that's taking it as an engineering challenge is a healthier mindset. I'll try to approach it this way. Just didn't expect it to appear there. Not that intuitive.

I guess that makes this issue closed

commented

Yeah, not being able to have electric carts without Industrialcraft is pretty disappointing.