Print

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

[Urist Da Vinci]

Has anyone tried shotgunning magma-filled minecarts yet?

Yes, earlier in this very thread: http://www.bay12forums.com/smf/index.php?topic=109460.msg3296000#msg3296000
Not all of the useful information will be in the first post or last page.

Not yet into minecart, question though: is there a way to get enemies into/ to ride carts? Can you load cages into carts? What happens when an enemy (or dwarf) is dropped onto a stopped (or moving) cart?

Enemies into carts: no, not like you are thinking.
Cages into carts: yes.
Creature dropped onto moving/stopped cart: the creature collides with the cart and is injured. Yes, falling 1z onto a stationary cart apparently can hurt, when falling 1z onto the floor would only stun you.

[Martin]

I've pretty effectively weaponized the cyclotron. It's slightly fussy, however, in that you have to work hard to make sure your dwarves don't go running through it. The design is like this:

X Wall
= Track
^v Rollers moving north/south
P Power source
. open pit
G Gear assembly

Code: [Select]

XXXXX XXXXXXX
X=====.=====X
X=XXXXX XXX=X
X^GPX   XPFvX
X=XXX XXXXX=X
X=====.=====X
XXXXXXX XXXXX
The cart goes clockwise. The cart gets added from a spur 1z level up moving south and drops onto the righthand roller which speeds it further along. The cart can jump the pits just fine. Invaders approach from the south entrance and are forced by the pit to go around the east section of track counterclockwise, through the crossover, and along the west section clockwise before emerging from the opening to the north. Cage traps in the corners would work best if the cart can only stun a MB, with traps along the track and probably in the crossover for sieges.

The gear assembly bridges the power source to the rollers and is hooked to a lever so you can unpower the whole thing. The cart will roll and eventually fall into the pit, all of which are connected and accessible from within the fort so you can retrieve the minecart and whatever casualties fall in there.

Its very effective. It's so far killed 2 kobolds, 3 children, and a number of pets. The kids and pets have a habit of pathing in there trying to follow their parents/owners. It will also obliterate every trade representative unless you give them an alternate, safer route. I have the trade depot outside of the cyclotron, airlocked via bridges. I'll probably add a pressure plate/hatch deal on the approach from the interior of the fort to stop any dwarves from wandering in there accidentally.



I'm pretty sure that a much longer track would allow for an infinite path entrance. Basically you use the switching/track jumping ability of the cart, along with pressure plates and drawbridges/floodgates to continually route the cart in a figure eight (imagine two crossovers to my design above). Each half circuit flips the path from the outside to the inside of the fortress to a different route. It's constantly pathable, but the path changes every 100-200 ticks as the cart hits new pressure plates. Basically, there's always a path, but you can never reach the end of it - and there's a minecart whizzing toward you the entire time.

[osmo]

1) Toady intended the max cart speed to be 1 tile per tick, but there's a bug causing the cart to exceed this value. I've done some programming along these lines, and dealing with cases where objects travel farther than your sample rate is a lot harder than when objects are limited to your sample rate. I suspect this will be changed, and cart max speed lowered in a future update because of 2) below.

Well, I built a circular track for testing purposes and for future use as a repeater. It is exactly 50 tiles in circumference and has a 10-tile roller on one side. I intended for this to reach the maximum minecart speed possible. This ought to work, as the minecart will be accelerated on each pass-through until the maximum is reached, unless the acceleration provided by the rollers is insufficient to compensate for the friction loss of a single pass, in which case the cart should become progressively slower and eventually grind to a halt. It seems to work as intended, and equilibrates at a remarkably constant 103-104 ticks per full turn. I've measured this by dotting manually but have got very good control over this, as I also have a pressure plate tied to both a bridge and a spike for testing purposes. As expected, the bridge changes state just before the minecart passes the pressure plate.
From this I concluded that the maximum reciprocal speed for minecarts is likely 2 ticks per tile. I attribute the extra ticks through losses during a single turn, as acceleration is only provided by rollers on one side of the loop. It might be that carts can gain greater speeds when descending ramps than through rollers, the latter ceasing to have an effect at lower levels. It could also be a case of 'Dwarven Physics'. But I've got pretty good confidence in that 2 tick/tile number.

What kind of script did you use for your 100 steps, by the way? I've been trying similar things with the in-game macro system, using D_ONESTEP, and couldn't get it to work with any degree of reliability. If I use the standard 15 ms value for macro steps in the init file, it just eats a large proportion of the intended steps - my framerate is terrible in my present fort that I've been trying things in, and presumably one would need at least 67FPS for that 15 ms to work, as it doesn't look like the game is queuing the step commands up. If I increase it to a bigger value, the game puts extra ticks in after each step while the script is running, so it really runs for much longer than intended. I also tried putting a pause in after each tick, to no avail. Is there some kind of trick or did you use an external tool?

[Martin]

I wrote an AppleScript to send the key press 100 times with a 1/10 sec pause in between.


Another possibility here is an obliterator coil. A loop with two lengths 100 tiles long that invaders need to navigate and a pressure plate on each pass lowers ten 10-wide drawbridges onto the opposite track. FBs would still need to be dealt with by the cart, but everything else would be destroyed, no cleanup needed.


I think I'll try the infinite entrance.

[Nyotor Lizardhammers]

Finally figured some important track-related nonsense out, decided to add what I figured out the the wiki earlier today. Stuff I would have thught would have been in there earlier =V

Oh well

[Burmalay]

This is about minecart teleportation.

I used jumpers as compensator of speed attenuation of the minecart but not tracks.

_ - ground without track
\ - ramp
[] - channel (without ramp in it)
W - wall
Ш - minecart
! - disappearance

9-z high ramp    !       !           !
                   \  F___13   F___16   F_  ---> no more teleportations at all.
                    []          []          []

The minecart was teleported through 13 and 16 tile at this scheme. !NOTICE! Its not 13 an 16 tile from ramp (start of the experiment), its 13 ground tile next behind the first fortification and the 16 tile next behind the second fortification! After the third jumper/fortification was not teleportations at all.

1)

9-z high ramp
                   \  WШ_
                    []

The minecart teleported trough the wall and stops at the next tile.

2)

9-z high ramp    !         !            !
                   \  F___Ш13   F___16   F_
                    []            []          []

When I built the wall at the 13 tile (spot of the minecart missing), the minecart just hit the wall and stops.

3)

9-z high ramp    !          !            !
                   \  F___   13Ш___   16_
                    []       []           []

This construction helps me to teleport the minecart through the 13 tile (13 tile is the wall) and stops at the next tile as it happens at the 1st example.

4)

9-z high ramp    !          !          !
                   \  F___   13___   16Ш_
                    []       []       []

13 tile are fortification and the 16 are wall. Result are the same. Minecart was teleported through the wall and stops.

[IpunchFaces]

Holy shit.

Toady adds Minecarts, and the community uses them not to transport ore, but to invent Dwarven quantum teleportation, railguns and cyclotrons.

Never change, you mad dwarves.

[crazysheep]

Holy shit.

Toady adds Minecarts, and the community uses them not to transport ore, but to invent Dwarven quantum teleportation, railguns and cyclotrons.

Never change, you mad dwarves.

That's how we roll, always finding new ways to kill things.

[SmileyMan]

That's how we roll, always finding new ways to kill ourselves.

Fixxored

[Martin]

The minecart was teleported through 13 and 16 tile at this scheme. !NOTICE! Its not 13 an 16 tile from ramp (start of the experiment), its 13 ground tile next behind the first fortification and the 16 tile next behind the second fortification! After the third jumper/fortification was not teleportations at all.

Yeah, this is what I was describing in my post above. When the cart is moving > 1 tile per tick, it 'skips' over some tiles, with the game never appearing to reconcile what would happen if the cart was at that coordinate. Toady can fix that, but it's tricky. The alternative is to cap the cart speed at 1 tile per tick, which the current cap appears to be close to, and which I suspect was his intention, so the behavior may go away. The reason you see no teleportations at all after the 3rd jump is the speed of the cart came down to 1/1, so the cart never travels more than a tile each tick.


If Toady doesn't fix it, it has some useful implications as in my testing, the tunneling effect is pretty reliable in terms of where it happens over repeated runs. At a minimum, it solves the railgun pathing issue. If you don't want anything to path back up your railgun line, simply put a wall at the end at precisely the right location. The gun will still work and nobody can path in. It could also eliminate some of your collision damage by putting the high-speed line in a completely sealed run relying on tunneling to have it emerge through the wall of the workshop. Because it can't tunnel through more than one tile, if you time it out right, just put the stop immediately next to the wall and it should catch it every time.


It may also work as a switching mechanism. If you want a given cart to skip over a track stop, accelerate it at just the right point so it tunnels over the stop. Unaccelerated carts would stop.


And the implications aren't just for carts but for everything else. In my testing, several of those struck by the cart tunneled through a wall and were found at the map edge. I even increased the height of the wall to make sure that it wasn't due to them flying over it and periodically they would still tunnel through. I don't know how to utilize this for anything productive as it's completely unpredictable, but I suspect Toady will need to fix it - it's going to be intolerable if stuff keeps tunneling through walls, flying across the map, or getting embedded in walls and such. So, I'm not counting on keeping this, but it's fun for now.

[SmileyMan]

Anyone fancy doing the maths for the amount of energy required for a minecart-sized particle to quantum tunnel through a 2m barrier with a probability of 1/13?

I'd imagine it's somewhere in the region of 'more energy than exists in the observable universe'

[Burmalay]

Test with 15-z high ramp and track on the ground:

\
 \_2_5_8_ and so on...
The numbers are tile numbers from the rump (except the ramp) where minecart has been disappeared.

I think with the higher ramp we can teleport the minecart trough the 2 or more tiles =)

[snoopychicken]

Doctor Urist McBrown: If my calculations are correct, when this minecart hits 88 tiles per hour... you're gonna see some serious shit.

[Sadrice]

Anyone tried tunneling a cart through the map edge?

[Burmalay]

Can we move a minecart through the floor?
Is there a vertical teleportation effect?