On the subject of low-friction wheels, the small tank has a diameter of 3 and a friction of 4. They are really long though, so you've have to make the carts wider to fit them.
My bad, I experimented with mesh blocks replaced only on the 45° turn and it seemed pretty well, didn't thought that entire rail made out of it would cause such effect of not really accelerating. I should've described it more. Thanks for trying this out. Nonetheless, there are some blocks in between mesh (2) and concrete (6) in terms of friction, which I will test and share my observations. Also I've thought of adding back axis (the carts don't ever reverse, right?) so they can maneuver passively during turning. Testing this out too.
Axis: So making back axis turn doesn't work. Dependently nor independently. Wheels turn randomly, bc they slip anyways. Carts still bump out of the track, and wheels oscillate left and right even at straight parts of rails. Also doesn't look good. Changing the position of the rollers more forward (to center force more in center) doesn't help also. I thought this would work like a trailer follows path of the car hauling it. It doesn't. Friction: 2 and 3 makes cart slip a lot, 4,5,6- from my tests on 45° turns, all had one derailment per 20 minutes, with 4 carts on each loop. Even tho my experiments bring no proof, I guess that lower friction equals to smaller sideways force while turning. I'm going to repeat this test with slighter curves later on
A tip for lane following systems, you want to put the sensors onto a piston that is slightly angled (based on preference) and when the sensor detects the line (when it wasn't to turn) in your case you want it to push out, as a buffer (that's my trick to it).
Yeah, I will try this if I have to resort to line followers, but honestly I do think it would be more fun if a real mechanical rail could work. Thanks for the suggestion though, if I do ever need a line follower I will think of this!
I just sumbled across your video and have no idea if you said something about it in the past but you seem to have painted parts of the road a darker grey, it is possible for it to cause issues at the start and exit of the turns. In the save files for blueprints if a surface has different colors it is counted as a seperate "object". Blocks are counted always as cubes with 3 dimensions, coloring a part devides it into 2 "objects", the more complex a blueprint is, the longer the text file and physics calculations. if you have the will, maybe try changing all the blocks to one color and test. Remember that every little glitch adds up to the possibility of failure. Good luck with your endeavours.
What u say only applies to blocks. The game tries to merge blocks into bigger shapes that are always cubic. But parts, like pipes are never merged. They are always separate shapes. "Shape" is the term describing a single object in a body. A "body" is a collection of shapes. Bodies can be connected by joints. "Joints" are bearings, pistons and suspenses. Connected bodies make up a "creation". This is the termology that Scrap Mechanic uses behind the scenes.
So, what you say is true, but removing the paint causes even more glitches. If the long rails were all one solid color and the same block material, SM would optimize that into one large shape. This is good for lag optimization, however, for some reason the collision detection gets wonky on these large shapes. So we have to strike a balance between making many small shapes to improve the collision math accuracy, and avoiding splitting up the shapes too much and causing glitches that way. The collision math being wonky starts to become a problem around 64 blocks, so my MiniCart system has these gray pain strips at a 32 or 64 block interval (I forgot which one). Maybe I could try to not put the paint near corners, but the wedges also split up the block shapes, so even without paint the blocks can have glitchy gaps.
You could try to use low friction blocks/parts as the guide rod. But this probably only applies to the mesh blocks. They won't just fit. A solution is to make the channel wider. With the new wedges, you actually have great control over the width of the cannel, but on the strait sections, you're still bound to full blocks. If widening the channel is not an option, you could build a second channel under the first, that is wider and have a rod through the first without touching it. Or use a piston to bridge the first layer and get rid of the channel in that layer entirely. But in this case you could also have the second channel made out of low friction blocks again and a normal rod.
Yeah, the second channel option is what I showed at the end of the video 16:25. Low friction wedges were not needed to make it reliable, and it could even go through the corners faster than before.
If you make a version using the mesh block, I suggest making it two layered so that you have concrete on top and mesh block on bottom, thus the wheels don't slip.
Yeah, good point, but if I am using two layers anyway, the mesh seemed to not be needed as I showed at the end of the video. But if that turns out not to work I will try this, so thanks for the comment!
I noticed at 6:24 the problem seemed to occur at the sharp transition between the curve and the straight segment, so maybe try adding just 1 or 2 more wedges and that might fix it.
Hmm, I think that will just postpone the problem. My latest theory on the "smart" physics glitchyness is that it doesn't have anything to do with joints. My theory goes that the "smart" physics will dynamically decide to not calculate collisions between some shapes (= parts or merged blocks) for some time, and this system is oversensitive, causing it to forget to calculate the collision sometimes. For MiniCart this means that the peg will refuse to calculate collisions between one of the shapes in the track, causing it to clip inside that shape, until the collision calculation is resumed some time later. This is especially visible at 14:28, where the stick is clearly ignoring the collision of the unpainted concrete, but is calculating the collision of the darker grey painted concrete. If both shapes had been calculating collision correctly, the stick and the cart would have been violently ejected upward, but instead the game seems to not really care.
If you set the physics of the world to "advanced" instead of "smart" it fixes the physics issues. Make the blocks on the sides of the groves low friction and use the crane roller/wheels as an alternative.
Yeah I tested the differences between the physics engines in my last video. For a new version of MiniCart, I would like it to work with the default physics engine, which is the "smart" one. The crane wheel is a part I totally forgot about, I will try that. Thanks!
Just a bit of knowledge that isn't widely known. 1. the more mass is on a bearing the more stable it is so that might be something to look into as you currently only have one small pipe on the bearings. 2. You could also lower the physics Settings as guides like these are a lot more forgiving in those. 3. Using bigger guide wheels than tiny pipes will prevent the physics engine from thinking the pipe is inside the wedge and If it still happens a bigger percentage of the guide is still outside the wedge and it will stay in place.
1. Yes 2. I would like MiniCart to work on the default physics engine, I want this to "just work" and be compatible with other stuff. 3. Yeah, this is true, probably the reason the thing I showed last that I developed during a livestream works so well. It has a larger wheel hidden underground.
@CodeMaker4 actually how about you try that on a bigger scale with just using the hidden wheel below as a guide instead of the pipes. kinda like the San Francisco cablecars with hidden mechanisms below.
why not let the pipe turn the wheels so the engine helps the minicart take the corners better instead of just trying to push the pipes into the walls. this will also take a lot of energy away from the initial impact as the pipe is allowed to swing side to side.
Yeah this would probably work, but I tried this back in 2021 and the mechanism was much larger and too laggy for the form factor I wanted for the minicart project, so I probably won't be trying this now. Thanks for the suggestion though.
@CodeMaker4I'm sure it wouldn't lag anymore. This is one thing about the new engine, if one creation doesn't cause frame drops, multiple copies won't either and the engine should be able to handle that mechanism well these days. But it would make the creation way more ugly. It will be hard to keep the current, sleek design.
Instead of 1 rod per set of wheels, could you put 2 rods per set about 3 blocks apart and allow the 2-wheel/2-rod assembly to pivot in the center? That way the as the 2 rods rotate to be tangent to the track, the wheel assembly would rotate and be aligned in the direction of travel instead of fixed forward.
Out of curiosity, regarding the thinner part of the wedge allowing errors, I wonder if glitch-welding would allow for better impacting on the corners. You could inset the wedges into the next section so that there will always be at least a block of thickness where it impacts. Fair enough if you don't want glitch wielding, I don't particularly like z-fighting and iirc, it does impact GPU performance.
Yeah, I totally think that using glitchwelding to kind of bridge the gap between two wedges would be very effective at reducing the glitchyness, but I am not a fan of doing things that cannot be constructed in the vanilla game. As far as I know glitchwelding doesn't work in the current version, so that's a no I am afraid. But thanks for commenting!
@CodeMaker4 Glitch welding is theoretically always possible through direct blueprint editing. The Glitch welder mod for example is only a tool to make things easier.
I think new physics is more optimized,cuz when I tried making train before the update I played with 15-20 FPS, and after update its stable 60 FPS with vertical sync.
interesting results, glad my thought seemed somewhat helpful! though I can imagine it not working for your intersection setup as that needs to be compact. humm only other theory i really have that might not work but would require a redesign to the carts would be to split the wheels and control pins from the main body so it works like a train's bogeys. allowing the pin to guide the wheels around, rather then dragging them around the corners?
I think the smooth corners will work fine with corners, maybe even better than before, as the wedges generally give me more freedom in how the intersection should be shaped. About the bogeys, when I made MiniCart originally I tried out bogeys, but rejected the idea as they did not fit with the small people-mover form-factor I had in mind. This is partially because of lag concerns, but it was also an artistic choice I don't regret.
What about connected minicarts? It can work on small friction wheels (I tested it). And i found one rule ,,in two connected minicarts one must be powered. For three two must be powered and four two too. In four, the first an third carts as powered works the best." English is not my national language so sorry for my mistakes.
Hi Inay, I actually have an unreleased blueprint of a train of 3 MiniCarts. I never released it, because the entire rail system was made under the assumption that only single carts will ever come over the intersections and stuff, so making that actually work would be a lot of effort. Also at the time I was afraid about lag, and some turns got weird at 45 degree angles would cause the back cart to forcefully push the others through the turn at a higher speed. I might try actual trains with the new smoother turns though, so stay tuned!
Usually, line followers are either binary or multi-sensor types. Basically you have your turn left and turn right, but a finer or coarser set on the outside/inside of the other two This can sometimes be achieved with sensors on bearings tuned to your desires As to address what I meant by some of that in the previous video, the wheels (as you have found) cause skipping and hopping. They are bouncy and resistant to perpendicular forces Go play Space Engineers to see what I mean , getting a fully functional, script less maus to work with neutral steering or even handbrake turning was nearly impossible, they also bounce (but have far more mass to resist it) The pin can bounce too far out of the slot, which is your real issue (and you solved this by literally clamping it to the track) Having two objects inside each other, they will naturally repel each other, until the center of mass is completely inside of the larger mass, at which point, there is no normal to calculate a force upon, and any remaining normals are actually ADDING forces into the larger mass
Thanks for the suggestion. Making suspension that can go in two directions while still being compact is hard though, so I will try the other promising methods first. But this is a decent idea I haven't seen before!
Would be a big change but can you have 2 pipes connected to the ends of a rotating rod that the wheels are connected to? Think train wheels but guided by a peg instead of the wheels themselves
I am surprised my suggestion seemed to make it worse. Scrap Mechanic jank, as weird as it always has been. I have been doing some testing and found that my 2 roller approach does not work, the 2 rollers ping pong off the sides and glitch out. If you use an electric engine on the free bearing, it stops the ping ponging but causes other issues. I have figured something else out though. If you extend the wedge on the outside of the curve 1 block father than the track, it seems to help with reliability. As for the carts, I have nothing. A deeper groove would help, but in my testing that can still glitch out.
You mean like this? ###_...-+`` _...-+`` ###_...-+``##### ^ ^ one large wedge of like 2x8 \- over here there is a gap I had this idea too, I'll try this if other stuff doesn't work.
I really quite like it, But you should really give creator credit for the music (Sven Papoz), Even if it's from the game. (It's the elevator music from warehouse's). I kust don't want your video to be taken down.
Yeah I should have credited them, good point. Though I am pretty sure video game music is usually fine, as the studios have made deals with YT for obvious reasons.
What if you try using low friction mesh blocks and wedges only for inner side where metal pipe collides, and use concrete on the outer perimeter for better tire grip. ⬛🟧⬆🟧⬛ ⬛🟧⚪🟧⬛ ⚪ - pipe ; ⬛- concrete ; 🟧 - mesh ⬛🟧 🟧⬛ (like scheme or smth) This technique would've been imosible previously but now that we can combine different wedges on their wedged sides, i believe it might work 8:00
In theory this would work, however, due to the wonkiness of the wedges, the smaller the wedge, the higher likelihood they will be clipped through. Having larger wedges seems to help but would detract from the look and potentially functionality of the wheels.
@Goldfish_Vender think I'd try it myself, I wasn't interested in such things before, but now that I have suggested possible solution, there's a need of trying this out
Good point, but I'll first experiment further with reducing the bearings in the follower sticks, as that not only seemed to improve reliability, but would also reduce lag a little, and I don't like the look of mixing materials for the turns. Though I will keep this suggestion in my head in case the simpler following mechanism doesn't work.
One thing, some of the wedges used are really large and cannot be made smaller due to the ratios, so this won't prevent the two wheels being on a slippery surface at the same time. (Unless I use a second layer that has the actual roller, but as demonstrated at the very end of the video that doesn't need low friction to be more reliable)
@CodeMaker4 yeah, I thought about using only 1 and 2 blocks thick wedges for this to work because of that. As always, everything needs to be proven, so I'll reinstall the game and check if it works myself
On the subject of low-friction wheels, the small tank has a diameter of 3 and a friction of 4. They are really long though, so you've have to make the carts wider to fit them.
Yeah, or make a flintstones-themed minicart...
The more I think about it the more I want to do it lol...
@CodeMaker4 Oh my god yes.
My bad, I experimented with mesh blocks replaced only on the 45° turn and it seemed pretty well, didn't thought that entire rail made out of it would cause such effect of not really accelerating. I should've described it more. Thanks for trying this out. Nonetheless, there are some blocks in between mesh (2) and concrete (6) in terms of friction, which I will test and share my observations. Also I've thought of adding back axis (the carts don't ever reverse, right?) so they can maneuver passively during turning. Testing this out too.
Axis: So making back axis turn doesn't work. Dependently nor independently. Wheels turn randomly, bc they slip anyways. Carts still bump out of the track, and wheels oscillate left and right even at straight parts of rails. Also doesn't look good. Changing the position of the rollers more forward (to center force more in center) doesn't help also. I thought this would work like a trailer follows path of the car hauling it. It doesn't.
Friction: 2 and 3 makes cart slip a lot, 4,5,6- from my tests on 45° turns, all had one derailment per 20 minutes, with 4 carts on each loop.
Even tho my experiments bring no proof, I guess that lower friction equals to smaller sideways force while turning. I'm going to repeat this test with slighter curves later on
Yeah, makes sense. Thanks for the clarification and further testing.
A tip for lane following systems, you want to put the sensors onto a piston that is slightly angled (based on preference) and when the sensor detects the line (when it wasn't to turn) in your case you want it to push out, as a buffer (that's my trick to it).
Yeah, I will try this if I have to resort to line followers, but honestly I do think it would be more fun if a real mechanical rail could work. Thanks for the suggestion though, if I do ever need a line follower I will think of this!
I just sumbled across your video and have no idea if you said something about it in the past but you seem to have painted parts of the road a darker grey, it is possible for it to cause issues at the start and exit of the turns. In the save files for blueprints if a surface has different colors it is counted as a seperate "object". Blocks are counted always as cubes with 3 dimensions, coloring a part devides it into 2 "objects", the more complex a blueprint is, the longer the text file and physics calculations. if you have the will, maybe try changing all the blocks to one color and test. Remember that every little glitch adds up to the possibility of failure. Good luck with your endeavours.
What u say only applies to blocks. The game tries to merge blocks into bigger shapes that are always cubic. But parts, like pipes are never merged. They are always separate shapes.
"Shape" is the term describing a single object in a body. A "body" is a collection of shapes. Bodies can be connected by joints. "Joints" are bearings, pistons and suspenses. Connected bodies make up a "creation". This is the termology that Scrap Mechanic uses behind the scenes.
So, what you say is true, but removing the paint causes even more glitches. If the long rails were all one solid color and the same block material, SM would optimize that into one large shape. This is good for lag optimization, however, for some reason the collision detection gets wonky on these large shapes. So we have to strike a balance between making many small shapes to improve the collision math accuracy, and avoiding splitting up the shapes too much and causing glitches that way. The collision math being wonky starts to become a problem around 64 blocks, so my MiniCart system has these gray pain strips at a 32 or 64 block interval (I forgot which one). Maybe I could try to not put the paint near corners, but the wedges also split up the block shapes, so even without paint the blocks can have glitchy gaps.
3:41 perfectly comedic moment of silence 😂
You could try to use low friction blocks/parts as the guide rod. But this probably only applies to the mesh blocks. They won't just fit. A solution is to make the channel wider. With the new wedges, you actually have great control over the width of the cannel, but on the strait sections, you're still bound to full blocks.
If widening the channel is not an option, you could build a second channel under the first, that is wider and have a rod through the first without touching it. Or use a piston to bridge the first layer and get rid of the channel in that layer entirely. But in this case you could also have the second channel made out of low friction blocks again and a normal rod.
Yeah, the second channel option is what I showed at the end of the video 16:25. Low friction wedges were not needed to make it reliable, and it could even go through the corners faster than before.
If you make a version using the mesh block, I suggest making it two layered so that you have concrete on top and mesh block on bottom, thus the wheels don't slip.
Yeah, good point, but if I am using two layers anyway, the mesh seemed to not be needed as I showed at the end of the video. But if that turns out not to work I will try this, so thanks for the comment!
I noticed at 6:24 the problem seemed to occur at the sharp transition between the curve and the straight segment, so maybe try adding just 1 or 2 more wedges and that might fix it.
Hmm, I think that will just postpone the problem. My latest theory on the "smart" physics glitchyness is that it doesn't have anything to do with joints. My theory goes that the "smart" physics will dynamically decide to not calculate collisions between some shapes (= parts or merged blocks) for some time, and this system is oversensitive, causing it to forget to calculate the collision sometimes. For MiniCart this means that the peg will refuse to calculate collisions between one of the shapes in the track, causing it to clip inside that shape, until the collision calculation is resumed some time later. This is especially visible at 14:28, where the stick is clearly ignoring the collision of the unpainted concrete, but is calculating the collision of the darker grey painted concrete. If both shapes had been calculating collision correctly, the stick and the cart would have been violently ejected upward, but instead the game seems to not really care.
you should try to only put mesh blocks on outside of the corner. So that just the outside wheel slips.(kinda like a Differential)
Yeah, good point. I'll revisit the low friction rails if the other more promising methods shown turn out not to work, so thanks for the suggestion.
If you set the physics of the world to "advanced" instead of "smart" it fixes the physics issues. Make the blocks on the sides of the groves low friction and use the crane roller/wheels as an alternative.
Yeah I tested the differences between the physics engines in my last video. For a new version of MiniCart, I would like it to work with the default physics engine, which is the "smart" one.
The crane wheel is a part I totally forgot about, I will try that. Thanks!
Just a bit of knowledge that isn't widely known.
1. the more mass is on a bearing the more stable it is so that might be something to look into as you currently only have one small pipe on the bearings.
2. You could also lower the physics Settings as guides like these are a lot more forgiving in those.
3. Using bigger guide wheels than tiny pipes will prevent the physics engine from thinking the pipe is inside the wedge and If it still happens a bigger percentage of the guide is still outside the wedge and it will stay in place.
1. Yes
2. I would like MiniCart to work on the default physics engine, I want this to "just work" and be compatible with other stuff.
3. Yeah, this is true, probably the reason the thing I showed last that I developed during a livestream works so well. It has a larger wheel hidden underground.
@CodeMaker4 actually how about you try that on a bigger scale with just using the hidden wheel below as a guide instead of the pipes. kinda like the San Francisco cablecars with hidden mechanisms below.
why not let the pipe turn the wheels so the engine helps the minicart take the corners better instead of just trying to push the pipes into the walls. this will also take a lot of energy away from the initial impact as the pipe is allowed to swing side to side.
Yeah this would probably work, but I tried this back in 2021 and the mechanism was much larger and too laggy for the form factor I wanted for the minicart project, so I probably won't be trying this now. Thanks for the suggestion though.
@CodeMaker4I'm sure it wouldn't lag anymore. This is one thing about the new engine, if one creation doesn't cause frame drops, multiple copies won't either and the engine should be able to handle that mechanism well these days. But it would make the creation way more ugly. It will be hard to keep the current, sleek design.
Off Topic. The idea of using those low friction wheels was great! I'm able to push my cart speed faster then it could before.
Great to hear someone else was able to replicate my results! I might try pushing the speed of the low friction wheels.
@ I’ve done a mixture of low friction and high friction wheels. Driving feels realistic in some capacity.
ive noticed some of my monorails have started bugging after the update
The SM Technical Community knows a lot about the physics engine, you should ask them.
Yeah I should have, I will send it there if the new solutions don't turn out to work. Thanks.
Instead of 1 rod per set of wheels, could you put 2 rods per set about 3 blocks apart and allow the 2-wheel/2-rod assembly to pivot in the center? That way the as the 2 rods rotate to be tangent to the track, the wheel assembly would rotate and be aligned in the direction of travel instead of fixed forward.
Yeah, this could work, but it is a relatively big mechanism, so it is not quite right for the minicart project. Thanks for the suggestion though.
Out of curiosity, regarding the thinner part of the wedge allowing errors, I wonder if glitch-welding would allow for better impacting on the corners. You could inset the wedges into the next section so that there will always be at least a block of thickness where it impacts.
Fair enough if you don't want glitch wielding, I don't particularly like z-fighting and iirc, it does impact GPU performance.
Yeah, I totally think that using glitchwelding to kind of bridge the gap between two wedges would be very effective at reducing the glitchyness, but I am not a fan of doing things that cannot be constructed in the vanilla game. As far as I know glitchwelding doesn't work in the current version, so that's a no I am afraid. But thanks for commenting!
@CodeMaker4 Glitch welding is theoretically always possible through direct blueprint editing. The Glitch welder mod for example is only a tool to make things easier.
@@dampfwatze Yeah but I mean like through in-game vanilla methods. This is a bit of a challenge from me for myself to keep my stuff vanilla.
I think new physics is more optimized,cuz when I tried making train before the update I played with 15-20 FPS, and after update its stable 60 FPS with vertical sync.
Maybe try making low friction blocks touching the floor with the basic wheels
I know that works for some random problem like this
What do you mean? I was already using the basic wheels when experimenting with the low-friction rails.
@CodeMaker4 I meant having low friction blocks on the car touching the ground
interesting results, glad my thought seemed somewhat helpful! though I can imagine it not working for your intersection setup as that needs to be compact. humm
only other theory i really have that might not work but would require a redesign to the carts would be to split the wheels and control pins from the main body so it works like a train's bogeys. allowing the pin to guide the wheels around, rather then dragging them around the corners?
I think the smooth corners will work fine with corners, maybe even better than before, as the wedges generally give me more freedom in how the intersection should be shaped.
About the bogeys, when I made MiniCart originally I tried out bogeys, but rejected the idea as they did not fit with the small people-mover form-factor I had in mind. This is partially because of lag concerns, but it was also an artistic choice I don't regret.
What about connected minicarts? It can work on small friction wheels (I tested it). And i found one rule ,,in two connected minicarts one must be powered. For three two must be powered and four two too. In four, the first an third carts as powered works the best." English is not my national language so sorry for my mistakes.
Hi Inay,
I actually have an unreleased blueprint of a train of 3 MiniCarts. I never released it, because the entire rail system was made under the assumption that only single carts will ever come over the intersections and stuff, so making that actually work would be a lot of effort. Also at the time I was afraid about lag, and some turns got weird at 45 degree angles would cause the back cart to forcefully push the others through the turn at a higher speed. I might try actual trains with the new smoother turns though, so stay tuned!
Usually, line followers are either binary or multi-sensor types.
Basically you have your turn left and turn right, but a finer or coarser set on the outside/inside of the other two
This can sometimes be achieved with sensors on bearings tuned to your desires
As to address what I meant by some of that in the previous video, the wheels (as you have found) cause skipping and hopping. They are bouncy and resistant to perpendicular forces
Go play Space Engineers to see what I mean , getting a fully functional, script less maus to work with neutral steering or even handbrake turning was nearly impossible, they also bounce (but have far more mass to resist it)
The pin can bounce too far out of the slot, which is your real issue (and you solved this by literally clamping it to the track)
Having two objects inside each other, they will naturally repel each other, until the center of mass is completely inside of the larger mass, at which point, there is no normal to calculate a force upon, and any remaining normals are actually ADDING forces into the larger mass
Suggestion 2:
Make the pins use suspension so it can move left and right compared to the wheels
Add strength to keep it better centered.
Thanks for the suggestion. Making suspension that can go in two directions while still being compact is hard though, so I will try the other promising methods first. But this is a decent idea I haven't seen before!
3:06 omg thats me 😂
Would be a big change but can you have 2 pipes connected to the ends of a rotating rod that the wheels are connected to? Think train wheels but guided by a peg instead of the wheels themselves
I am surprised my suggestion seemed to make it worse. Scrap Mechanic jank, as weird as it always has been. I have been doing some testing and found that my 2 roller approach does not work, the 2 rollers ping pong off the sides and glitch out. If you use an electric engine on the free bearing, it stops the ping ponging but causes other issues. I have figured something else out though. If you extend the wedge on the outside of the curve 1 block father than the track, it seems to help with reliability. As for the carts, I have nothing. A deeper groove would help, but in my testing that can still glitch out.
You mean like this?
###_...-+``
_...-+``
###_...-+``#####
^ ^ one large wedge of like 2x8
\- over here there is a gap
I had this idea too, I'll try this if other stuff doesn't work.
you could convert the creation to be odd (7 or 9) might look bad but it will work better
I'm gay but there's too many comments so no one will ever know
This commenter says "I'm gay but theres too many comments so no one will ever know"
In case he ever edits it.
You appeared at the top of the comments for me btw bruh
We know, but its okay. We accept you bro
Be your gay ass self my dude, we support you!
Sorry that the timelapse music is a bit loud, will do better next time.
it still was nice.
I really quite like it, But you should really give creator credit for the music (Sven Papoz), Even if it's from the game. (It's the elevator music from warehouse's). I kust don't want your video to be taken down.
Yeah I should have credited them, good point. Though I am pretty sure video game music is usually fine, as the studios have made deals with YT for obvious reasons.
suspention
What if you try using low friction mesh blocks and wedges only for inner side where metal pipe collides, and use concrete on the outer perimeter for better tire grip.
⬛🟧⬆🟧⬛
⬛🟧⚪🟧⬛ ⚪ - pipe ; ⬛- concrete ; 🟧 - mesh
⬛🟧 🟧⬛ (like scheme or smth)
This technique would've been imosible previously but now that we can combine different wedges on their wedged sides, i believe it might work 8:00
In theory this would work, however, due to the wonkiness of the wedges, the smaller the wedge, the higher likelihood they will be clipped through. Having larger wedges seems to help but would detract from the look and potentially functionality of the wheels.
@Goldfish_Vender think I'd try it myself, I wasn't interested in such things before, but now that I have suggested possible solution, there's a need of trying this out
Good point, but I'll first experiment further with reducing the bearings in the follower sticks, as that not only seemed to improve reliability, but would also reduce lag a little, and I don't like the look of mixing materials for the turns. Though I will keep this suggestion in my head in case the simpler following mechanism doesn't work.
One thing, some of the wedges used are really large and cannot be made smaller due to the ratios, so this won't prevent the two wheels being on a slippery surface at the same time. (Unless I use a second layer that has the actual roller, but as demonstrated at the very end of the video that doesn't need low friction to be more reliable)
@CodeMaker4 yeah, I thought about using only 1 and 2 blocks thick wedges for this to work because of that. As always, everything needs to be proven, so I'll reinstall the game and check if it works myself