Print

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

[Mr Frog]

We are now one tantalizing step closer to having a railgun that fires live badgers.

ACTUALLY RELEVANT:

- Assuming that rideable carts make it in, will units riding carts suffer the same falling damage as others, i.e. do carts cushion falls?

Should prolly take that one to FotF, come to think of it

[Girlinhat]

Mr. Frog, you seem to not clearly understand how impulse works.  So I'm going to quit this argument until I come at you with a working repeater/latch.

That is a question though.  Do riders suffer fall damage from flying carts?  My aerial dragoon squad may have hit a snag...

[Eric Blank]

Well, if it does prove to be a setback, they can be deployed from a ground-level track.

[Talvieno]

Mr. Frog, you seem to not clearly understand how impulse works.  So I'm going to quit this argument until I come at you with a working repeater/latch.

That is a question though.  Do riders suffer fall damage from flying carts?  My aerial dragoon squad may have hit a snag...

If it was realistic, you could land a rider on a slanted track slanting downwards in the direction the minecart is going, and it would turn the landing into forward momentum, decreasing the jolt upon landing. I don't know if Toady will do that, though.   Also, I get the feeling that dwarves won't be invincible. Just seems like a Toady thing to do.

[Mr Frog]

@Girlinhat:

So would you please explain to me how I'm wrong instead of simply assuring me that I am and artificially shutting down the conversation as though that'll get anyone anywhere? Because, at the moment, I think I'm right, you think I'm wrong, and I'm not likely to accept that I'm misinformed just because you said so. That would open up several philosophical cans of worms which I'm very much not intellectually-equipped to deal with.

Spoiler: Mr Frog tries to do math! (TL;DR WARNING) (click to show/hide)

To check... impulse is an application of force over a period of time, expressed in newton-seconds (N*s or kg*m/s), yes? So by dividing the impulse by the object's mass in kilograms, you get the object's change in speed, yes? (How am I doing so far?) (And yes, I am reading this out of my textbook) (But I don't seem to have been wrong so far...) (But I suck at application, so I'm almost certainly flubbing something there)

So my understanding is: if you have a roller that imparts force N on a cart on top of it every tick, and neither the force exerted nor the cart's mass changes, then you can simplify the equation from (Δv = Δs*N / kg) to (Δv = Δs * A), where Δs is the total number of ticks the cart has spent on the roller, A is a constant value equal to the average force exerted divided by the mass of the object, here expressed in units of (N / kg) or ( ( (kg * m) / (s² * kg) ) = m/s²). The equation is now basically just taking a set acceleration value and multiplying it by a time interval to get the total change in speed of an object, which is a situation similar to gravitational acceleration (Δv = Δs * G).

Assuming I haven't already gone horribly wrong somewhere (quite likely, but I'm sure someone will be able to point it out to me), this means that a moving minecart that hits a roller will travel in a parabolic arc along the roller, and that therefore the component of its velocity parallel to the roller's angle of acceleration will be the negative of its parallel velocity upon hitting the roller at the time of it crossing back over the interface between the roller and solid ground, much like how an object launched upward in a gravitational field will travel in a parabolic arc and have accelerated to a vertical velocity exactly negative to its initial vertical velocity by the time it falls back down to its initial elevation, the initial elevation of the object being analogous to the interface between unpowered rail and the roller.

That's my entire understanding of the concepts at play here. Just point to something, tell me how it's wrong, and I'll shut up.

[Girlinhat]

1: Cart is in motion, arriving from the left and moving towards the right.

Code: [Select]

######
0===<#
######2: Cart passes over the roller, robbing it of some momentum before it hits the wall and stops.

Code: [Select]

######
====0#
######3: The roller applies force, sending the cart from the right, to the left.

Code: [Select]

######
==0=<#
######4: This is actually ping-pong.

Code: [Select]

#######
#>0==<#
#######5: You should have already installed a pressure plate.

Code: [Select]

#######
#>=^0<#
#######6: You also need a bridge, which carts can pass over as if they were tracks.

Code: [Select]

#######
#>0^+<#
#######
While active, the cart will hopefully have enough momentum to run back and forth within 100 ticks, and function as a latch as it keeps the pressure plate depressed.  If it takes longer, then it will be a repeater instead.

To deactivate, you retract the bridge, and the cart falls to the level below into whatever track system is set up.

[Mr Frog]

The wall actually makes things worse; you're limiting the amount of momentum that the cart can conserve after hitting a roller. If it hits the roller too fast, it'll strike the wall, stop, and then get pushed back as though it only had enough momentum to just barely make it to the wall before stopping.

The faster the cart hits the roller, the farther along it'll get before stopping (I'm assuming that the cart's position is stored as a floating-point value which is then rounded to determine which space the cart is considered to be 'on' for the purposes of game mechanics). The farther along the cart is on the roller, the longer it'll take for the roller to push the cart off and thus the more speed the cart will have by the time it comes off the roller. Since it'll constantly lose speed due to friction, it'll eventually not get enough speed from the rollers to make it to the other one. I don't know how to explain it more clearly than that.

You could probably just do this:

Code: [Select]

vX<
P |
>X^

P is a pressure plate, X is a floodgate or something that can stop them from spinning around

And have two carts located across from each other flying around pushing the plate. Of course, they'll probably end up spinning faster and faster until they hit the rollers' hardcoded speed limit, but putting walls on the corners should at least prevent them from flying off.

[Girlinhat]

...that makes no sense.

Let's make a small illustration here.  Let's assume that the left is -x and the right is +x.  If you have an object traveling at +20/s then it's traveling from left to right.  If you want it to travel in the opposite direction, you would need to apply -20 speed to bring it to a stop and an additional -20 to bring it up to -20/s traveling from right to left.

If you have an object traveling at +20/s and it hits a wall, it's instantly at 0 and will only take -20 to reverse direction.  Bringing the object to an instant halt will save you half as much energy.  As an extension, if your object is at a dead stop and being rolled, then it will be much easier to get moving than an object that is acting against the direction of movement.

A thought has occurred to me though.  Describe what a roller does.  Just, you tell me exactly how a roller will work.

[Mr Frog]

A roller applies a force to a cart in a specific direction as long as the cart is on the roller. The amount of force applied depends on the time a cart spends on a roller. Also, the cart continues to move while the roller accelerates it. It doesn't just stop on a roller for a bit, store up force, then say "okay, time to go!" and then get the change of speed all at once. It'll continue to move around according to its velocity even as the roller changes its velocity. As such, it'll eventually get pushed off the roller, after which it will no longer be accelerated by the roller's force. The amount of time before the cart leaves the roller is proportional to how far down the roller the cart starts at, which is proportional to how fast the cart hits the roller, because hitting the roller at a greater speed increases the time it takes to slow to a stop and begin rolling in the other direction thus increasing the distance the cart travels before stopping. By putting the wall in, you are limiting how far the cart can go and by extension how much space the cart has to accelerate.

Also: please lose the condescending tone. I'm trying to be civil here, and I would appreciate it if you followed suit. nvm, read something wrong

[Aseaheru]

Mind if i speak? well, type? here is what i want to find out.
if siege weapons aim and fire at enemy mobs and mine carts can carry cages(hopefully still full of trolls), can siege weapons hit a troll, in a cage, on a mine cart? also, can there be a system where mine carts can suck-up drops it comes across, and possibly reload traps, then you don't have to worry about the item dance and just have to worry about urist mc-noble being a arse.

[Girlinhat]

I don't think any of those ideas will apply.  Namely because creatures in cages don't actually exist in the literal sense, and because carts must be manned to function properly.  Also, "aim a siege weapon" doesn't really happen.  Ballistae don't aim, they always fire randomly.

[Mitchewawa]

I do physics and stuff too.

I think in a real world scenario Mr Frogs design might work better due to no loss of momentum from walls, plus the fact that the cart does not have a max velocity. It would, in real life, go around the track (even though it's longer) faster then a cart could switch directions in Girlinhat's design. This being that whenever the cart hits the wall, its acceleration  is zero and the roller has to re-apply the force in the other direction, whereas Frog's design does not have loss of acceleration (barring friction).

However, for the sake of the game Girlinhat's would work better. For one, I assume rollers apply an instant velocity (as acceleration does not appear to exist in this game) and the track is just plain shorter.

[Trif]

Ah, I think I understand Mr Frog's point.
Let's assume that a roller can accelerate a minecart to 20/s in the direction it's built, if the minecart fully traverses the roller.
This happens after the initial wall-slam.

2: Cart passes over the roller, robbing it of some momentum before it hits the wall and stops.

Code: [Select]

######
====0#
######

The cart passes the roller, being decelerated and hitting the wall afterwards.
At this point, v= 0/s.

3: The roller applies force, sending the cart from the right, to the left.

Code: [Select]

######
==0=<#
######

Now it gains momentum. Its mass remains the same (if minecarts don't reach relativistic speeds, which we'll assume for now), so it's sufficient to observe the velocities.
The cart fully traverses the roller and is accelerated to v=20/s.

4: This is actually ping-pong.

Code: [Select]

#######
#>0==<#
#######

It's not quite ping-pong, and the cause is friction.
The minecart loses a bit of its speed, so it arrives at the second roller with less than 20/s, maybe 18/s.
The moment it moves on the roller, it's getting decelerated. Now, if a roller can accelerate a minecart to 20/s, it can also decelerate a minecart with 20/s to 0/s if it fully traverses the roller in the opposite direction. The problem here is: our minecart is slower than 20/s. As a result, it cannot reach the other side of the roller because the roller decelerates it too much. The cart cannot slam into the wall, and it stops somewhere on the roller (2/20 of a tile off the wall, to be exact).
Because it can't fully traverse the roller, it won't get accelerated to -20/s, only to -18/s again.  The trend here is obvious: the cart will lose some of its velocity again, acceleration won't suffice etc.
Long story short, the cart will stop in the middle eventually.

That is, if Mr Frog's conception of a roller is correct (and I think it's likely) (and if I understood it correctly).

_{This post was brought to you by the verb: to traverse.}

[Girlinhat]

Ah, now you make sense.  If that's the case then yes, it would slowly trail down to nothing and stop.  However, something tells me that the physics aren't that strict.  While you suggest a reliable real-world way to handle this, it ultimately boils down to how real the game physics are.  And on that point, we must simply wait.  We don't know how it works now, and we shall simply have to test a prototype to come to a conclusion.

[Mr Frog]

Thanks for the assist, dudes-who-actually-know-what-they're-talking-about-and-how-to-explain-it

@Mitchewawa:

Look back at the devlog quote I posted a few posts back -- Toady specifically mentions rollers as increasing the speed of a cart, which sounds like acceleration to me. Also, his mention of the rollers having a maximum possible point that they can increase a cart's speed to is meaningless unless it's possible for the cart to not be sped up to that point every time.

Should probably learn how not to jump down people's throats whenever they say something I think might be wrong...

@Girlinhat:

Well, that is the Problem, isn't it? Real-life physics don't suffer from rounding errors, or quantum tomfoolery due to a ridiculously long Planck time :p