Brockenflabel wrote:Are the carts designed to go up and down slopes and stairs? When I go up stairsI always end up flying, sometimes several blocks in the air and my cart floats there.I have fall to the ground then build up blocks to get it back.

What is still missing:not tested with meseconssometimes cart just stops with no reason, but much less than in original moduser controls may be improved, now they work only on low speedcart just stops if at 0 speed on uphill/downhill

sometimes cart just stops with no reason-----thats the Reason why i dont implement this Mod in my Game. But i missed this Mod. :(***Add player controls to switch direction---This can make the Stoppbug tolerable

I just tested it in version 4.10 on my server and i was able to ride 1200 blocks long railway without stops or other issues(on version 4.9 there was stops and freezes).So i think that cart mod is pretty usable now.

The stops in 0.4.9 were due to get_node(p).name returning "ignore" erroneously at chunk boundaries. You still see lighting glitches from time to time at the chunk bounds, so I don't know that the issue won't continue to come up in some other use cases.

The change I was thinking of, which perhaps you guys would be interested in implementing was this:

It seems like there are several different ideas for rails, and even some different ideas for carts (I still want to make a powered steam cart!). But under the current cart mod structure, to add a new type of rail or a new cart requires forking the mod. What if we rewrote the Cart mod as a cart api. All of the basic functionality for movement on the rails, and acceleration due to gravity, would be built into the cart mod. But actual carts and rails would be done separately, and would call a carts_register_cart(mycart.mycartfunction) or carts_register_rail(myrail.myrailfunction)

When the cart mod is moving a cart along on the rails, each turn it would calculate the rail direction, deal with controls, and calculate acceleration due to gravity. BUT, then it would call the registered function for that particular cart to allow that cart to add any acceleration unique to that cart. And then it would call the registered function for the rail it is currently on and add any acceleration for that particular rail.

That way, if someone wanted to add low power rails, or reverse power rails, or mesecon conductive but non-power rails, or my touring rails, or whatever kind of rails they wanted, they could do so without having to fork and rewrite the cart mod. And if someone wanted to add a steam cart, they could do so without having to fork and rewrite the cart mod.

Kilarin wrote:Interesting. I was considering rewriting Carts again myself.

The change I was thinking of, which perhaps you guys would be interested in implementing was this:

It seems like there are several different ideas for rails, and even some different ideas for carts (I still want to make a powered steam cart!). But under the current cart mod structure, to add a new type of rail or a new cart requires forking the mod. What if we rewrote the Cart mod as a cart api. All of the basic functionality for movement on the rails, and acceleration due to gravity, would be built into the cart mod. But actual carts and rails would be done separately, and would call a carts_register_cart(mycart.mycartfunction) or carts_register_rail(myrail.myrailfunction)

When the cart mod is moving a cart along on the rails, each turn it would calculate the rail direction, deal with controls, and calculate acceleration due to gravity. BUT, then it would call the registered function for that particular cart to allow that cart to add any acceleration unique to that cart. And then it would call the registered function for the rail it is currently on and add any acceleration for that particular rail.

That way, if someone wanted to add low power rails, or reverse power rails, or mesecon conductive but non-power rails, or my touring rails, or whatever kind of rails they wanted, they could do so without having to fork and rewrite the cart mod. And if someone wanted to add a steam cart, they could do so without having to fork and rewrite the cart mod.

Just an idea for consideration.

+100, a marvelous idea. I know of someone who has had to fork it and add his own rails, I'm sure a lot of people would benefit from this...

Nam ex spatio, omnes res venire possunt.Why let the ground limit you when you can reach for the sky?Back to college now, yay for sophomore year schedules. :P

There are always problems with carts on a server to some degree due to lag. I think the only way to do it properly would be to teach the client about rails in general so that the client can predict the movement of objects attached to rails. Handling rail switches would still require updates from the server, but most movements could be done by the client. "Rails" ought to be a very general concept so that things like tubes from pipeworks and the items shooting through them are handled by the same code.

I'm a bit disappointed that carts are unmovable when you're inside of them. I'd rather see a cart be slow (e.g. max speed while manually pushing 4) than the current situation, since carts are just no fun unless you start building all sorts of mese-powered contraptions. Please consider making carts player-powered when attached (e.g. punching them while in one should just work)