[Mod] Carts [carts]

loremed
New member
Posts: 4
Joined: Fri Mar 07, 2014 14:06

by loremed » Post

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

User avatar
Krock
Developer
Posts: 4649
Joined: Thu Oct 03, 2013 07:48
GitHub: SmallJoker
Location: Switzerland
Contact:

by Krock » Post

loremed wrote:when i open world it says "failed to load and run /usr/share/.../minetest_game/mods/PilzAdam-carts-70cc4f4"
I have linux
viewtopic.php?id=1379

The example in the wiki is EXACTLY your problem. Wow.
Look, I programmed a bug for you. >> Mod Search Engine << - Mods by Krock - DuckDuckGo mod search bang: !mtmod <keyword here>

User avatar
PilzAdam
Member
Posts: 4026
Joined: Fri Jul 20, 2012 16:19
GitHub: PilzAdam
IRC: PilzAdam
Location: Germany

by PilzAdam » Post

Krock wrote:
loremed wrote:when i open world it says "failed to load and run /usr/share/.../minetest_game/mods/PilzAdam-carts-70cc4f4"
I have linux
viewtopic.php?id=1379

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

4aiman
Member
Posts: 1208
Joined: Mon Jul 30, 2012 05:47

by 4aiman » Post

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

dgm5555
Member
Posts: 245
Joined: Tue Apr 08, 2014 19:45

by dgm5555 » Post

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

User avatar
Kilarin
Member
Posts: 894
Joined: Mon Mar 10, 2014 00:36
GitHub: Kilarin

by Kilarin » Post

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

User avatar
Evergreen
Member
Posts: 2135
Joined: Sun Jan 06, 2013 01:22
GitHub: 4Evergreen4
IRC: EvergreenTree
In-game: Evergreen
Location: A forest in the midwest
Contact:

by Evergreen » Post

Kilarin wrote: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.
Back from the dead!

User avatar
Kilarin
Member
Posts: 894
Joined: Mon Mar 10, 2014 00:36
GitHub: Kilarin

by Kilarin » Post

Evergreen wrote:]Blame the minetest engine, not his mod.
Since the behavior changed when I upgraded the engine, that is sure what it looks like.

spillz
Member
Posts: 138
Joined: Thu Feb 13, 2014 05:11

by spillz » Post

dgm5555 wrote: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:

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.

User avatar
Kilarin
Member
Posts: 894
Joined: Mon Mar 10, 2014 00:36
GitHub: Kilarin

Re: [Mod] Carts [carts]

by Kilarin » Post

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.
Last edited by Kilarin on Fri Apr 25, 2014 12:07, edited 1 time in total.

User avatar
PilzAdam
Member
Posts: 4026
Joined: Fri Jul 20, 2012 16:19
GitHub: PilzAdam
IRC: PilzAdam
Location: Germany

Re: [Mod] Carts [carts]

by PilzAdam » Post

Kilarin wrote: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
New member
Posts: 8
Joined: Sat Apr 12, 2014 15:08

Re: [Mod] Carts [carts]

by jacobwellz » Post

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

User avatar
Kilarin
Member
Posts: 894
Joined: Mon Mar 10, 2014 00:36
GitHub: Kilarin

Re: [Mod] Carts [carts]

by Kilarin » Post

PilzAdam wrote: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
New member
Posts: 8
Joined: Sat Apr 12, 2014 15:08

Re: [Mod] Carts [carts]

by jacobwellz » Post

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

User avatar
PilzAdam
Member
Posts: 4026
Joined: Fri Jul 20, 2012 16:19
GitHub: PilzAdam
IRC: PilzAdam
Location: Germany

Re: [Mod] Carts [carts]

by PilzAdam » Post

Kilarin wrote:
PilzAdam wrote: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).

User avatar
Kilarin
Member
Posts: 894
Joined: Mon Mar 10, 2014 00:36
GitHub: Kilarin

Re: [Mod] Carts [carts]

by Kilarin » Post

PilzAdam wrote: 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.
PilzAdam wrote: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.

User avatar
Kilarin
Member
Posts: 894
Joined: Mon Mar 10, 2014 00:36
GitHub: Kilarin

Re: [Mod] Carts [carts]

by Kilarin » Post

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!
Last edited by Kilarin on Wed May 07, 2014 03:02, edited 1 time in total.

User avatar
Inocudom
Member
Posts: 3121
Joined: Sat Sep 29, 2012 01:14
IRC: Inocudom
In-game: Inocudom

Re: [Mod] Carts [carts]

by Inocudom » Post

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.

User avatar
Kilarin
Member
Posts: 894
Joined: Mon Mar 10, 2014 00:36
GitHub: Kilarin

Re: [Mod] Carts [carts]

by Kilarin » Post

Inocudom wrote: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
Member
Posts: 245
Joined: Tue Apr 08, 2014 19:45

Re: [Mod] Carts [carts]

by dgm5555 » Post

@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.
Last edited by dgm5555 on Tue May 06, 2014 22:43, edited 1 time in total.

User avatar
Kilarin
Member
Posts: 894
Joined: Mon Mar 10, 2014 00:36
GitHub: Kilarin

Re: [Mod] Carts [carts]

by Kilarin » Post

dgm5555 wrote: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.
dgm5555 wrote: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
Member
Posts: 245
Joined: Tue Apr 08, 2014 19:45

Re: [Mod] Carts [carts]

by dgm5555 » Post

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)

User avatar
hoodedice
Member
Posts: 1374
Joined: Sat Jul 06, 2013 06:33
GitHub: hoodedice
IRC: hoodedice
In-game: hoodedice
Location: world
Contact:

Re: [Mod] Carts [carts]

by hoodedice » Post

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.
7:42 PM - Bauglio: I think if you go to staples you could steal firmware from a fax machine that would run better than win10 does on any platform
7:42 PM - Bauglio: so fudge the stable build
7:43 PM - Bauglio: get the staple build

User avatar
Kilarin
Member
Posts: 894
Joined: Mon Mar 10, 2014 00:36
GitHub: Kilarin

Re: [Mod] Carts [carts]

by Kilarin » Post

dgm5555 wrote: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.
dgm5555 wrote: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:
dgm5555 wrote: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.
hoodedice wrote: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.

User avatar
Calinou
Moderator
Posts: 3169
Joined: Mon Aug 01, 2011 14:26
GitHub: Calinou
IRC: Calinou
In-game: Calinou
Location: Troyes, France
Contact:

Re: [Mod] Carts [carts]

by Calinou » Post

Nice, I may add this in Carbone.

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

Post Reply

Who is online

Users browsing this forum: No registered users and 19 guests