Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Di]

Maybe ramp tiles are considered longer than flat ones?
If tile sizes are 2:2:3 meters then straight ramp is ~3.6 meters (and corner ramp would be ~4.1? meters).
Sorry I'm really in condition for formulae right now, can't help with the rest.

Another setup:

Code: [Select]

push
track
down
down
down
TS high+
downIn game cart passes Track Stop in a single tick and moves on.
In excel it stops and "friction steps" column says "30".

As for shotgunning speed, I'm sure I've seen carts going off the rails without losing their shit. And the ~70 000 number is the speed at which cart exits accelerator with just enough impulse ramps for shooting.
But, if you replace the track stop in the example above, the cart will crush in the wall and throw everything out on lower speed before falling onto last downward ramp.

[fricy]

Another setup:

Code: [Select]

push
track
down
down
down
TS high+
downIn game cart passes Track Stop in a single tick and moves on.
In excel it stops and "friction steps" column says "30".

Newest unreleased version calculates 64000 speed on entering TS+, exit after one tick at 14000 speed and 15 ticks on the next tile if it's a normal track. Unfortunately something is borked, because if I enter a Down ramp after the TS+ it says that the cart will stop. LOL, I need to crush this bug, value should be 5-8 steps off the top of my head. I'll fix a few things and release it in a day or two, because it's a bit embarrassing that I have not updated it to a better version. I have to test multi tile rollers to confirm that they work the way I think they work, and then implement a few logic checks to represent middle tile behavior properly.

If a cart derails onto a floor tile, it will not spill it's contents, but if you want to change z-levels above 50k speed it will crash, spill and stop. I have not seen any difference between 50 and 70k speed so far, I'll try to design something after I finished dealing with this weird ramp distance thingy. I'm not so sure anymore that the numbers I posted yesterday are valid, the limited testing I did on OSX seems to indicate that it's a read error with the windows version. It would be so great...

Maybe ramp tiles are considered longer than flat ones?
If tile sizes are 2:2:3 meters then straight ramp is ~3.6 meters (and corner ramp would be ~4.1? meters).
Sorry I'm really in condition for formulae right now, can't help with the rest.

...because I already tried +50% longer ramps, and they are really close to the game values, but not quite right, I have ONE extra friction step to deal with on a 20 z high ramp.
Thx for the info you provided.

[silentdeth]

Something I would find interesting is if you could do something like say if I put a pressure plate and hook it to a bridge (or door, or gear assembly) where will the cart be when the bridge opens? When it closes? More advanced form, if I put a bridge (or roller hooked to gear assembly, or door, ect.) at this point in the track, where would I need to put a pressure plate so that it is open (or closed) when the minecart reaches it. Maybe given as a range?

[fricy]

Something I would find interesting is if you could do something like say if I put a pressure plate and hook it to a bridge (or door, or gear assembly) where will the cart be when the bridge opens? When it closes? More advanced form, if I put a bridge (or roller hooked to gear assembly, or door, ect.) at this point in the track, where would I need to put a pressure plate so that it is open (or closed) when the minecart reaches it. Maybe given as a range?

I tested track switching with perpendicular rollers, there was 1 tile between the plate and the roller (gear) and it worked flawlessly with 40-50k speed. I'm pretty certain that it would work without the "safety tile", right next to each other. A door is also a fast switching component, so I'm guessing a plate can be right next to it to activate, although there's one thing to consider: crash/ramp/drop checks are executed in the middle of the previous tile, and I don't know when a plate gets activated, so it may be tricky. I have not tested this, because effective door switching needs >50k speed to derail off a corner, I find rollers to be more easy to handle this way. Another thing to consider: At high speeds, around ~160k the cart starts to skip tiles, sometimes 1, sometimes 2 in a row. I have seen carts fly through highest tracks stops this way without slowing down, I assume they would fly over pressure plates as well.

Bridges: I have 0 experience with them, they cause lag when switching, they throw a cart around if it's on them when they switch, and they are sloooow to activate. You can use the calculator to find how long track you need to reach them until they activate. Regular tracks/features are 100% accurate, the tricky part is handling the ramps and the tiles before/after them, as they change distance units AND friction not on the tile boundaries, but between the middle and the tile boundaries.

NEW VERSION: 2.6

• Distance calculations:
  a: speed
  b: base friction
  c: distance units (length of a tile)
  c_delta: lefover distance units
  n: ticks/tile
  
  n = (sqrt(4a^2+4ab+b^2+8bc)-2a-b)/(2b) -- rounded down
  c_delta=c-na+b((n^2+n)/2)
  
• Ramp distance units are ~1,4 times longer than regular tiles, but then they compensate for the longer distance. (Partly working
• Rollers start a cart from the beginning of the roller tile, a push teleports it to the beginning (not the middle!) of the next tile
• Logic checks: ramps/rollers/drop influence a minecart from the middle of the previous tile. Exiting a ramp teleports a cart to the middle of the next tile.
• Tile skipping
• Multi-tile rollers are calculated correctly
• No more corner column, corners are entered in D
• Only .xlsx (Excel2007) version.

I have determined that ramps are ~1,41 times longer (4890/3457) then regular distance units (the game handles them differently, on ramps the executed speed and friction calculations are ~0,707 shorter, it's the same really), and there is some compensation logic that adds extra (shorter then regular!) steps when travelling on ramps to make up for some lost speed due to the longer distance units and the tiles skipping behavior. More science is needed. Still. Grrr.

Entering a ramp will almost always result in mixed (regular and ramp) friction on a regular tile depending on how much distance units we need until the ramp. Sometimes we gain/lose some speed, other times we just enter. Tile boundaries are not set in stone!
 
When exiting a ramp the cart teleports from the middle of the ramp to the middle of the next regular tile, the friction of this tick is either regular tile friction or up-ramp friction depending on speed: exiting a ramp with max velocity will result in -4900 friction, so on the first regular tile we'll have 265k speed. On the other hand exiting a ramp with ~50k speed onto a track stop will result in -10 friction until we reach the middle point, and track stop friction on the next tick. So it's tricky...

QUIRK:
highest roller, track, UP ramp, UP ramp, track,  --> cannot go up, the cart rolls back
highest roller, track, UP ramp, track, UP ramp, track, --> cart exits with 25k speed leftover because it teleports from the middle of the UPs to the middle of the next tiles.

Rollers: they set the speed of a cart from the middle of the previous tile until the middle of the roller tile. Multi-tile rollers do this along their whole length, so they have a constant speed.

Last words: I hate you Toady! I'm starting to loose some hair trying to figure this out.

[fricy]

@DI: I finally started testing liquids, first test, your scenario:

push
track
down ramp   water 7/7
impuse ramp water 7/7
up ramp       water 7/7
track

Uhmm, you found some really weird sh!t:
First I did a dry run to test how the pit works: No matter how fast/slow the cart enters, it won't loose speed on the up ramp, it just touches the middle point (this registers as a z change in the game), then moves up a level onto the middle of the next tile. Strange, it looks like the quirk I described in my previous post, only this time this is with an impulse ramp and an up ramp. As if an impulse ramp behaves like a ramp and a flat track at the same time, and the cart will just teleport from the middle point to the middle point.
 
Second, 7 water, empty cart: The cart CAN leave the pit, however not where we expect it. It rolls really slowly along the impulse ramp, does not speed up/slow down, collects water on the up ramp, then rolls back onto the impulse ramp and flys out on the invalid end of the imp.ramp. I guess you had a wall there blocking that exit in your test.

Third: 6-7 water, filled cart: The cart exits on the up ramp like it's nobodies business.

Fourth run: 7 water, filled cart: The cart gets stuck between the up ramp and the impulse ramp. Does not stop, it rolls back-and-forth.

I did multiple scenarios with different number of impulse ramps in the pit, it doesn't matter how much imp. ramps I use, the same thing happens. Nice catch.
Thx, now I have something to think about.
again.

[Di]

Is it 6/7 in third test or cart moves through a flow of 6's and 7's?
I've been testing this in aquifer so that probably counts as permanent 7/7.
Anyways, for practical uses I've just resorted to building rollers down there.

[fricy]

It's 6/7, 6/7, 7/7 : 2 units of water is already in the cart. It's not flowing water, I'm experimenting with the dfhack liquids plugin, spawning and deleting water, how much I need for the test.

I just rerun the same test with 7/7 magma with the same result: the cart exits/derails out of the pit on the impulse ramp. I think we have a breakthrough with powerless magma retrieval. Cool.
Accidental second run with empty cart and 6/7,6/7,7/7 magma resulted in the cart exiting on the up ramp filled. Even cooler.
Third run: 6/7,6/7,5/7 level: cart exits empty. So I guess that't the limit.

I'm going to repeat the experiment with the real magma, to make sure there's no different between spawned liquids and the real stuff.

Later:
Did it, and accidentally improved it into a simple powerless magma filler. It does not work with flowing magma, and slow, but it's good for filling up a few minecarts early for a surface forge.

Spoiler (click to show/hide)

z-0

z+1

It's a down ramp, southeast impulse ramp and an up ramp. North of the impulse ramp you build a 2 tile magma-safe raising bridge to the magma source.
The cart is pushed from 4 tiles on the Z level up, enters from the west, and the bridge somehow helps the minecart to escape on the up ramp to the east.

I did several trials, the first run into 7/7 magma will usually pick up 2 magma, the next cart returns empty in 6-7/7 magma, but if you push it for a third time it can successfully collect another 2 units. Then it needs to be refilled to 7/7.
I was not successful with flowing magma, so I guess that's the limit, no use for water magma cannons.
I somehow doubt I can program this behavior into an excel sheet.

edit: improvement idea: build a longer pit with more imp.ramps, and two bridges. one at the last impulse ramp to help the cart escape, another a little bit back to let the magma in. (this does not work with a 3 tile config, when I built another bridge north of the down ramp the cart got stuck.)

[fricy]

And another ramp exploit:

The perpetual motion elevator.

This quirk depends on this observation:

highest roller, track, UP ramp, track, UP ramp, track, --> cart exits with 25k speed leftover because it teleports from the middle of the UPs to the middle of the next tiles.

In this scenario, we have 2 types of friction source:
regular friction: calculated from the middle of the tiles between the ramps till the middle of the ramps, then the cart jumps to the next middle point.
speed penalty: when a cart is going faster then 100k speed every time we jump from a ramp to a regular flat tile there's a 4900 penalty for that tick. Below 100k this penalty is only 10.

So the idea is to choose an entry speed that's lower then 100k, so we don't have to pay this speed penalty, but still generates long enough distance units so we just skip the ramp tile without taking ramp friction. In theory that speed threshold is around 70k, in practice I tried this exploit with 103k speed, 6 down ramps, 7 up ramps.

Spoiler: game log of cart speed (click to show/hide)

Code: [Select]

tile id dist. units speed friction
36,8675 1,0363 1,0363 -0,0001
37,78544 0,91794 1,0362 -0,0001
38,48338 0,69794 0,9871 -0,0491
39,5 1,01662 0,987 -0,0001
40,19781 0,69781 0,9869 -0,0001
41,5 1,30219 0,9868 -0,0001
42,19766 0,69766 0,9867 -0,0001
43,5 1,30234 0,9866 -0,0001
44,19752 0,69752 0,9865 -0,0001
45,5 1,30248 0,9864 -0,0001
46,19738 0,69738 0,9863 -0,0001
47,5 1,30262 0,9862 -0,0001
48,19724 0,69724 0,9861 -0,0001
49,5 1,30276 0,986 -0,0001
50,1971 0,6971 0,9859 -0,0001


This is the log of the minecart after travelling up 7 z levels. The first up ramp penalizes the cart because of the excessive speed, so we go from 103k to 98710 speed. After that every z level only costs 20 friction. Exit speed after the last up ramp is 98590. Then we fly a bit to the edge of the map.

Possibilities? In theory this type of track design is able to raise a cart 1500z levels with an initial impulse of 6 ramps. 

[Di]

Wow.

[fricy]

Re: The perpetual motion elevator

I realized that I made a mistake in my previous post, and this exploit shouldn't be working the way I described it: The minecart teleports to the middle of a track tile, and ~70k speed moves it onto the ramp in the following tick, so it should be losing speed fast on the up ramps...
But it does work somehow, second test confirms it. Even better: there's no upper speed limit, a max speed cart will go through the ramps at almost constant 265k speed spending 2 ticks on every z level. I accelerated a cart with 54 straight down ramps to 270k speed, and after returning to the surface on the exploit up-ramps it flew up 24 z levels until it hit the ceiling. Exit speed was measured to be 261940, ~2000 speed was lost at two corners that I had to use, the up ramps only cost ~1100 friction.
Minimum speed is untested, but should be:
sqrt(2)*50001=70712 + 20*zlevel