[Mod] Carts [carts]

[loremed]

when i open world it says "failed to load and run /usr/share/.../minetest_game/mods/PilzAdam-carts-70cc4f4"
I have linux

[Krock]

when i open world it says "failed to load and run /usr/share/.../minetest_game/mods/PilzAdam-carts-70cc4f4"
I have linux

https://forum.minetest.net/viewtopic.php?id=1379

The example in the wiki is EXACTLY your problem. Wow.

[PilzAdam]

when i open world it says "failed to load and run /usr/share/.../minetest_game/mods/PilzAdam-carts-70cc4f4"
I have linux

https://forum.minetest.net/viewtopic.php?id=1379

The example in the wiki is EXACTLY your problem. Wow.

lol

[4aiman]

Kilarin, PM me your version of carts, please. Some of my users experienced the same.
Also, logs would be nice.

[dgm5555]

I'm using minetest 0.4.9, carts 0.4.
I'd like to put my vote behind a fix for the bug where carts randomly turn around. I haven't read all 450 posts, but it has been mentioned before, so is obviously a frustration. This seems to happen both if they are being ridden or if they are being watched. The location isn't consistent. I'm not sure, but I think you might be able to decrease the probably by watching where you're going, so it might be something to do with the engine.
Also was thinking about the carts never returning if they are sent away from the player on a long track. Would there be any way of creating autospawn/autodestruct rails which create carts at set intervals, and destroy them if they don't have anyone riding, or arrive too close together (which would likely be a whole bunch which had hit the player influence boundary coming back to life again), thus there would always be a steady supply.
Alternatively is there any way of marking a cart as something which the engine needs to process irrespective of distance from the player (this might solve both of the above issues).
Finally, would it be possible to have carts start up a bit more slowly when they're created (equivalent to inertia). Its sometimes a bit tricky to create a cart then catch it as it moves out of range very quickly. All my rails are powered, but I found it was even worse when trying to punch it then leap on, and a bit much for my 7year old to coordinate.
Thanks, David

[Kilarin]

I updated to the latest version of minetest minetest_201404130050-0~2687~ubuntu12.04.1_i386
And I have been using carts a LOT since then. Building a huge track. I have not had a single case of my cart dropping through the rail since I upgraded minetest. I HAVE had a very few mysterious stops. Not many considering the hundreds of tracks I've had the cart going over and the number of times I've tested it. I did have ONE mysterious reversal

[Evergreen]

I updated to the latest version of minetest minetest_201404130050-0~2687~ubuntu12.04.1_i386
And I have been using carts a LOT since then. Building a huge track. I have not had a single case of my cart dropping through the rail since I upgraded minetest. I HAVE had a very few mysterious stops. Not many considering the hundreds of tracks I've had the cart going over and the number of times I've tested it. I did have ONE mysterious reversal

Blame the minetest engine, not his mod. I don't think there is any way of fixing that atm.

[Kilarin]

]Blame the minetest engine, not his mod.

Since the behavior changed when I upgraded the engine, that is sure what it looks like.

[spillz]

I'm using minetest 0.4.9, carts 0.4.
Finally, would it be possible to have carts start up a bit more slowly when they're created (equivalent to inertia). Its sometimes a bit tricky to create a cart then catch it as it moves out of range very quickly. All my rails are powered, but I found it was even worse when trying to punch it then leap on, and a bit much for my 7year old to coordinate.
Thanks, David

Good luck getting the author to change anything. For what it's worth I posted a patch here that let's you click while riding, which is much better for young'ens:

https://forum.minetest.net/viewtopic.php?pid=133378#p133378

If you don't know how to apply a patch, just open up the carts/init.lua in your mods folder with a text editor and remove the lines marked with - and add the ones marked with + in the patch file.

[Kilarin]

I just noticed an interesting and slightly confusing thing about carts.

I've got this great big humongous track I've build going around a bunch of pretty scenery in my world. If you start at sunrise, it will be sunset by the time you get back to the end of the track. And it WAS working just fine. Occasionally hit the sudden stop bug, and once in a great while the reversal bug, but most of the time I could ride the whole track without any problems. And, most importantly of all, my power rails were distributed so that the cart never stopped if you didn't hit a bug.

However, I was having lag problems, in certain regions my drawtime would shoot up to around 200 and everything became very jittery. Other regions it was fine. SO, I decided to turn off shaders. And boy did that fix my drawtime problems! Much better.

BUT, a side effect of turning off the shaders is that now my power rails are not distributed close enough. My cart now runs out of power between rails in multiple locations. Note, I am NOT talking about the sudden stop bug, I mean that the cart gradually slows down and stops because the next power rail is too far away.

Now, I would have assumed that with a lot of lag, you would be on the power rails for less time, and get less boost out of them. But what I'm seeing is the opposite of that. Because I've got less lag, I am going to have to reposition my power rails closer across the entire line.

I'm guessing that while with less lag you get more boost out of each power rail (because you hit the cart logic to accelerate more times while still on the power rail), with less lag you must also get more deceleration out of each normal rail.

Anyway, I've got way to many rails to fix. I may have to build me a cheating machine to lay down those tracks for me.

[PilzAdam]

However, I was having lag problems, in certain regions my drawtime would shoot up to around 200 and everything became very jittery. Other regions it was fine. SO, I decided to turn of shaders. And boy did that fix my drawtime problems! Much better.

Wait, did you experince lag or performance issues?

[jacobwellz]

I don't know what but when I placed rail it went up in the sky it wasn't lagging

[Kilarin]

Wait, did you experince lag or performance issues?

Sorry, careless vocabulary on my part. It was single player so not lag, performance issues. In certain regions on the surface of my world my drawtime would skyrocket up to around 200 and the screen would update slowly and jerkily. But the cart had enough umph from the power rails to make it to the next one. Then I turned shaders off and my performance issues greatly improved, and now my cart can't make it between the power rails in many spots.

NOT a bug, just an interesting (and unexpected, for me) side effect of how the cart mod handles acceleration and deceleration.

[jacobwellz]

How do you turn shaders off I'm on android tablet by the way no I didn't have lag or porfomance issues

[PilzAdam]

Wait, did you experince lag or performance issues?

Sorry, careless vocabulary on my part. It was single player so not lag, performance issues. In certain regions on the surface of my world my drawtime would skyrocket up to around 200 and the screen would update slowly and jerkily. But the cart had enough umph from the power rails to make it to the next one. Then I turned shaders off and my performance issues greatly improved, and now my cart can't make it between the power rails in many spots.

NOT a bug, just an interesting (and unexpected, for me) side effect of how the cart mod handles acceleration and deceleration.

It seems like the acceleration handling has some issues.
It only handles acceleration rails that the cart is on when the on_step() function is called, not the acceleration rails that it passed since the last step. I would expect it to be the other way round, though (i.e. you don't get enough speed when the server gets slow).

[Kilarin]

I would expect it to be the other way round, though (i.e. you don't get enough speed when the server gets slow).

That was what I expected as well. But I just ran a test to confirm what I had seen last night.
I turned shaders on, then ran through my track. My fps got as low as 5, and had one brief burst up to 20, but was usually somewhere between 9 and 12. Drawtime varied between 40 and 160. But I made it all around the track without a single slowdown.

I turned shaders off, ran the track again, and my fps shoots up to 33-40! drawtime is down between 19 and 30. BUT, now my cart has a hard time making it to the next power rail and frequently doesn't.

It only handles acceleration rails that the cart is on when the on_step() function is called,

My guess is that the issue is that DECELERATION is handled exactly the same way. Because on_step() is being called more frequently per rail, and since there are more plain rails on my track than power rails, my cart is slowing down more. I'll just have to redistribute the power rails.

I suppose it would be possible to keep track of the "previous rail" and only apply acceleration or deceleration once per rail (when the rail changes), but that would change the behavior of the cart pretty radically, and would, I assume, result in much more jerky acceleration/deceleration.

I'm not certain this is a problem, it just means carts will move differently depending on your frame rate. Or at least differently when your frame rate is ridiculously low.

[Kilarin]

First thing I want to do here is complement PilzAdam on his WONDERFUL cart mod. The more I have been exploring and playing with the code the more I've begun to understand how complicated making a cart work actually is.

I've been playing with the mod and I've created a version with some changes:
https://github.com/Kilarin/carts

It includes spillz code to allow the rider to punch a stopped or very slow moving cart to get it going. I'm just not dexterous enough to left click to start the cart then right click to ride before it gets more than 3 nodes away. And minermoder27's patch to do a get_voxel whenever minetest returns an "ignore" when checking for the next rail. This should reduce some of the mysterious stops.

The rest of these are my changes:

While riding, pressing and holding LEFT or RIGHT arrows will cause the cart to switch tracks in that direction when it comes to a junction. Note that these work as left and right relative to the direction the CART is facing. Once you release the arrow key, the cart will go back to searching for new rails in it's regular forward first mode.

While riding, pressing the down arrow acts as a hand break and will slow the cart. (Not a very important change, but a slightly more dignified way of stopping than SNEAK-Left clicking to destroy the cart you are currently riding)

While riding, pressing JUMP will lock the users view to the view of the cart, so that when the cart turns, the users view will turn along with it. Note that it ONLY moves the user's view when the cart turns. The user can still freely control the camera with the mouse even when the view is locked, and pressing SNEAK will unlock the view. The turning rate is controlled by YAW_STEP. I've got it set to pi/12 right now, which is a bit jerky. Setting a smaller step should, theoretically, give you a smoother turn rate, but it also makes the turn a lot slower and the view has a harder time keeping up with fast turns. pi/12 seemed the best compromise to me. Certainly beats my initial attempt of just setting the view to the new direction in one step. Talk about disorienting! :) But someone with a faster (or slower) computer than mine might want to play with that value. Right now the cart defaults to unlocked view, but anyone who wanted carts to start with lockview on could just change lockyaw=false to lockyaw=true at the top of the init.lua file.

I've added "Touring Rails". Power rails attempt to get you up to top speed and keep you there, but Touring Rails offer a more leisurely journey along the rails so that you can enjoy the scenery. Touring Rails have a target velocity set by TARGET_TOUR_V, I've got it set to 4.5 right now. When you are going slower than the target velocity, a touring rail will attempt to speed you up. BUT, when you are going FASTER than the target velocity, the touring rail will attempt to slow you down. This makes it easy to put touring rails along a track on both up and down slopes, and still have your cart maintain a fairly steady velocity no matter which direction it is traveling. A velocity that is slow enough to allow you time to enjoy looking at the beautiful minetest world the tracks are passing through. Power rails have to be placed about every 12 tracks (11 plain tracks, 1 power track) to maintain speed. Due to their lower top speed, Touring rails have to be placed about every 4 tracks (3 plain, 1 touring), along flat tracks, and work better at one every 3 tracks on extended slopes. So it takes about 3 or 4 Touring Rails to power the same length of track as 1 power rail. You get two power rails at a time, so I made the Touring Rails recipe give you 7 Touring Rails at a time, which I think should be about in balance. Of course, cart performance changes depending on your frame rate, so your mileage may vary.
The recipe is:
steel_ingot, coal_lump, steel_ingot
steel_ingot, stick, steel_ingot
steel_ingot, mese_crystal_fragment, steel_ingot
I also added a recipe to allow people to turn already existing stacks of power rails into touring rails if the wanted to:
default:coal_lump
carts:powerrail
carts:powerrail

With these changes there are a lot of keystrokes to remember, so I added a chat message that appears every time a cart is placed that tells the users what clicks and keystrokes do what with the cart.

And one last little easter egg. With this code carts keep track of how many rails they pass over between the time they are placed and picked back up. The count is placed into debug.txt so you can use it to count how long a rail line is if you want.
cart: begin pos=(80,9,129)
cart: end pos=(89,9,124) railcount=686
I'm not certain the count is 100% accurate, because of the way the cart has to back up when it overshoots some rails, but it should be pretty close.

This code could use some more testing, and some cleaning up. I'm putting it here in this thread first because before I go any further with it, I'd like to know if PilzAdam would like to incorporate any of these changes directly into his cart mod, or if he would prefer me to place them in a separate mod? (I presume I could make a mod named carts-plus that was dependent upon carts and just overrode the carts function I've modified?)

For anyone who would like to test the changes, you can download the zip file here:
https://github.com/Kilarin/carts/archive/master.zip
Change the folder name to carts and place it in your mod folder instead of the original carts mod. License CC0 on all my changes.

Critique and advice all very welcome. And again, a huge thank you to PilzAdam for a really awesome mod!

[Inocudom]

Kilarin, even if PilzAdam does not accept the changes, I would recommend that your present your work to the developers of Freeminer, a fork of Minetest. The reason I am saying this is because that fork appears to have PilzAdam's carts mod in it's base game.

[Kilarin]

Kilarin, even if PilzAdam does not accept the changes, I would recommend that your present your work to the developers of Freeminer, a fork of Minetest. The reason I am saying this is because that fork appears to have PilzAdam's carts mod in it's base game.

I'd be happy to have them use it. Once we've decided the final form, I'll go over to their forums and post it.

The thing I would want to check very carefully is how freeminer implements get_look_yaw() and player:set_look_yaw() . Because in Minetest they are offset from each other in a way that seems very odd and counter-intuitive to me. If Freeminer corrected that, we'll need to modify the mod for them or the view lock will behave very strangely.

[dgm5555]

@Kilarin:Awesome upgrade. It seems to sort out all the glitches (eg suddenly reversing), and I love your controls!

However I'm curious why you didn't use your original fork of the carts mod for your files. Copying it into a new master, changing it's name, then forcing users to change the name back isn't very intuitive (in retrospect probably worth it, but probably not regularly ie for further upgrades). My initial trial at installing it caused an error (ERROR[main]: Error loading mod "minetest-mod-carts-plus": modname does not follow naming conventions: Only chararacters [a-z0-9_] are allowed.), and I had to re-read your post twice and eventually open the init.lua to check the actual expected mod name. Also by changing it's name it makes it yet another step if you want to use gitsync or similar to keep it up to date. It also probably guarantees adam won't accept it as a replacement for his version, as yours is different and can't make use of git version control, so you might as well have called it something different too (and perhaps aliased the old names to maintain compatibility)...

Final question. How do you get rid of the carts. Punch doesn't seem to work.

[Kilarin]

Awesome upgrade. It seems to sort out all the glitches (eg suddenly reversing), and I love your controls!

Glitches are NOT gone, I still get them from time to time. I think engine fixes have reduced the number of times they happen.

However I'm just curious why you didn't fork the original carts mod.

I wasn't certain what was going to be the best approach if PilzAdam didn't want to include these changes in his mod. Is it a good idea to have two versions of the same mod (with the same name) floating around? But I certainly see your point on the confusion of renaming.

Right now I'm looking at 4 possible approaches:

1:If PilzAdam likes the changes he can just include them in carts, problem solved.

2:I could just fork the Carts mod and we would have two different mods both named carts, but with slightly different functionality.

3:I could try to modify this to run as cartsplus and in cartsplus, make it depend on carts, and override the carts functions I've changed. But so far I haven't had any luck making that work.

4:I could create this as cartsplus with a slightly different recipe for my version of the cart. The rails would still be compatible with carts, but any carts build using the old recipe would not have the new controls, and old carts would treat the new touring rails as ordinary power rails. Carts built using the new recipe would have all of the new functionality, of course.

I'm leaning towards options 2 or 4. What would you recommend?

[dgm5555]

I'd go for option 2, but if you wanted to go for option 4, cant you make the old carts an alias of your new carts, then you could disable the old mod, but carts/rails/etc would still be recognised and wouldn't have problems with compatibility. I thought that's what minetest.register_alias was for?
I would maintain option 1 won't happen if it's not a fork (I'm guessing PilzAdam is too busy to keep up with merging forked versions, let alone trying to do it without version control)

[hoodedice]

While riding, pressing JUMP will lock the users view to the view of the cart, so that when the cart turns, the users view will turn along with it.

I was working on this fix_camera to viewpoint issue a while back. I had this problem that since the "look for direction cart is heading" part of the code would run every dtime, which made the player's cam fixed to the cart all the time. I tried looking for a solution, but gave up after a week.

Your solution is the most simple, and effective one I have found. For this, I applaud you from the bottom of my heart.

[Kilarin]

I'd go for option 2,

I've made it just a plain old fork, (links changed in original message), thank you very much for the advice.

if you wanted to go for option 4, cant you make the old carts an alias of your new carts, then you could disable the old mod, but carts/rails/etc would still be recognised and wouldn't have problems with compatibility. I thought that's what minetest.register_alias was for?

Aha! Looks like that is what I needed to know! I didn't know minetest.register_alias existed. I'm new to this. I'll see if I can look up some documentation and examples on how to use that.

Oh, also, I forgot to answer your question:

How do you get rid of the carts. Punch doesn't seem to work.

same as with the original carts, SNEAK-left click to put back in inventory. Whenever you place a cart, there should be a chat message that appears listing the controls.

Your solution is the most simple, and effective one I have found.

Thank you! But when thinking up how to code a steam cart the other day, I realized I had coded the "Touring Rails" in a stupid and inelegant way. I wrote special code to make the touring rail acceleration account for the acceleration that was going to happen because of gravity/friction instead of taking the much simpler and more elegant route of calculating the touring rail acceleration AFTER the regular gravity/friction acceleration was added. Grrr. I mean, it works fine this way, but it was ugly the way I did it. Gonna have to go back and fix that. So, anyway, not real thrilled with my coding skills right now. :)

Biggest problem I had working on that view lock is that the values returned from get_look_yaw are offset by +1/2 pi from the values put in to set_look_yaw. VERY strange.

[Calinou]

Nice, I may add this in Carbone.

Does this fix the infinite loop bug? https://github.com/PilzAdam/carts/issues/14

[dgm5555]

the values returned from get_look_yaw are offset by +1/2 pi from the values put in to set_look_yaw. VERY strange.

Oh that's what is wrong, I noticed apparent errors in yaw but concluded 'a glitch' and didn't look any harder (I only needed to read it with my mapit mod). I also thought there were also sometimes incorrect yaw values returned, but this didn't seem to be consistent.

@Kilarin: By the way, would it be difficult to be able to R click on a piece of track and have a cart automatically generated and you in it and similarly destroyed when you get off it. Really just for convenience, sometimes it's a pain to track down a cart in the inventory or it's at the other end of the track just when you want it. Maybe a 'creative mode only' option.
david

[Kilarin]

I may add this in Carbone.

I'd be honored!

Does this fix the infinite loop bug? https://github.com/PilzAdam/carts/issues/14

Wow, that is interesting. When I tried this with my code, it didn't just lock up, the cart went plunging down through the ground without stopping (or rendering the ground around it) and couldn't be stopped. Just kept going deeper. Trying to exit to the menu caused minetest to lock up.

The cart goes through this configuration just fine when there is a forward rail at the end, so I don't think it is the "find the next rail" part of the code that is causing the crash. I suspect it is the "stop the cart when velocity close to zero and place exactly on the rails" part of the code. I'll have to do some debugging when I get time...

[Kilarin]

problem was that the calc_rail_direction has code that fires when the cart stops that checks to see if the cart has moved above or below the rail and places it back on the rail. it does this by checking for a rail above or below the current position, and if it finds it, calling calc_rail_direction recursively on the new position. In the scenario you built above, there is a rail directly above the rail that the cart stops on. So the recursion moves up to the top rail, then finds the bottom rail and calls itself recursively again there, then finds the top rail again, and the process repeats until you run out of memory.

Did a simple fix over lunch. Solution is:
in function cart:calc_rail_direction(pos, vel)
change the following line from:

Your phone or window isn't wide enough to display the code box. If it's a phone, try rotating it to landscape mode.

Code: Select all

if cart_func.v3:equal(velocity, {x=0, y=0, z=0}) then

to:

Your phone or window isn't wide enough to display the code box. If it's a phone, try rotating it to landscape mode.

Code: Select all

if cart_func.v3:equal(velocity, {x=0, y=0, z=0}) and not cart_func:is_rail(p) then

Now none of the recursive "Move the cart on the rail if above or under it" logic ever fires if the cart is currently ON a rail. And even if the cart is not on the rail, the recursion ceases as soon as a rail is found.

The cart does reverse now, but I tested with the original code and apparently the cart always reverses if it hits a dead end rail that is a power rail.

This has been updated in my fork of carts https://github.com/Kilarin/carts/archive/master.zip, so download the latest version and the infinite loop will not happen again.

[Kilarin]

By the way, would it be difficult to be able to R click on a piece of track and have a cart automatically generated and you in it and similarly destroyed when you get off it. Really just for convenience, sometimes it's a pain to track down a cart in the inventory or it's at the other end of the track just when you want it. Maybe a 'creative mode only' option.

I'll have to think about that. it would require modifying all tracks to respond to a right click. Do you want the cart pulled out of inventory or just created on the spot? (which would CERTAINLY be a creative mode only option)
I'm not certain how widely this would actually be used.

[PilzAdam]

problem was that the calc_rail_direction has code that fires when the cart stops that checks to see if the cart has moved above or below the rail and places it back on the rail. it does this by checking for a rail above or below the current position, and if it finds it, calling calc_rail_direction recursively on the new position. In the scenario you built above, there is a rail directly above the rail that the cart stops on. So the recursion moves up to the top rail, then finds the bottom rail and calls itself recursively again there, then finds the top rail again, and the process repeats until you run out of memory.

Did a simple fix over lunch. Solution is:
in function cart:calc_rail_direction(pos, vel)
change the following line from:

Your phone or window isn't wide enough to display the code box. If it's a phone, try rotating it to landscape mode.

Code: Select all

if cart_func.v3:equal(velocity, {x=0, y=0, z=0}) then

to:

Your phone or window isn't wide enough to display the code box. If it's a phone, try rotating it to landscape mode.

Code: Select all

if cart_func.v3:equal(velocity, {x=0, y=0, z=0}) and not cart_func:is_rail(p) then

Now none of the recursive "Move the cart on the rail if above or under it" logic ever fires if the cart is currently ON a rail. And even if the cart is not on the rail, the recursion ceases as soon as a rail is found.

The cart does reverse now, but I tested with the original code and apparently the cart always reverses if it hits a dead end rail that is a power rail.

This has been updated in my fork of carts https://github.com/Kilarin/carts/archive/master.zip, so download the latest version and the infinite loop will not happen again.

https://github.com/PilzAdam/carts/commit/10c455793d430e9177b9d5226a76f8525faef007