Bay 12 Games Forum

Please login or register.

Login with username, password and session length
Advanced search  

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - gchristopher

Pages: 1 ... 38 39 [40] 41 42 ... 53
586
few questions about this. How exactly does the water drain from the firing range? How pressurized does the water have to be (and how to build up water pressure, but that's not exactly on this topic and something for my own research), and how feasible is this trap. I mean, for real. Why should someone do this versus just the old dodge-me trap+ballistas.
The level above the firing range has pumps pulling up through floor grates. Water is pulled up off the range continually by the pumps, then flows out and down to an aquifer.

You need enough water pressure to keep up with the firing rate and keep the trench full. A four barrel cannon running at maximum speed will (possibly depending on the flow pattern) outpace a single pump pulling up from an aquifer. (This one, using modded "magmatankers," runs slower than optimal.) The easiest way to keep the trench pressurized is to have a large amount of water one level below, continually refilled by an aquifer, then pulled up into the trench with 2-4 pumps.

Minecart/water traps are a lot of work to build, but far more effective than siege engine traps, work against flying enemies that don't fall in pits, never jam and require no dwarves to operate or ammunition to be constructed. Even with normal minecarts, you can laugh off sieges without risking a single dwarf. Even most megabeasts don't have much of a chance. It's pretty game-breaking in that sense, though worth building for the fun of making a giant preposterous defense monstrosity. If you download the savegame, unpause, and watch the carnage, the point comes across.

I built one using a single dwarf in a Hermit game. It took him about 20 years by himself to finish the project, but he also had to do everything else in the fortress, too.

The biggest feasibility issues I run into for these traps are space and complexity. My example here is 20-30 tiles long for the cannon barrels and another 40-50 for the firing range, plus whatever bridges/cage traps/etc you want to have. Also, you only have to misplace one ramp or drop one minecart at the wrong place during construction and suddenly instead of a cannon, you have a meat grinder that can murder half your fortress while you try to fix it. Once built correctly, you can lock it away and never have to touch it again, but especially if you have to fix a mistake after putting some carts in the system, it's dangerous.

I'm working on a magma version.
Bwahahaha! Can't wait to see it.

How long does it take water to freeze if it has been launched this way?

Does it just freeze the second it leaves a subterranean tile, after it hits something and coats the ground, or does ice form in mid-air?
I don't know how fast water freezes. While flying, it's not "water," but it's actually a generic projectile "glob" that happens to be made of water. When the glob hits something, it turns back into 2/7 water (7/7 for the silly modded globs) at the point of impact. At that point, it's water again and freezing physics probably start being applied at that point for any transition to ice.


587
Trees grow in the hallway to that control room. You might have to cut some down to reach the levers.

588
Hey, Kurik Amudnil over in the dfhack thread found what I missed with the script to fix caravan guards that are converted using makeown!

http://www.bay12forums.com/smf/index.php?topic=91166.msg4329026#msg4329026

The fix lets them be assigned noble positions and there's a separate script to completely fix dwarves that have already been partially fixed last year.

As far as I can tell, it should be possible to get fully functional dwarves out of caravan guards now!

589
Utilities and 3rd Party Applications / Re: DFHack 0.34.11 r3
« on: June 20, 2013, 05:42:02 pm »
Kurik, thanks. That looks like a script I can just run, I don't have to hunt down the unit I used the command on?

Also..how do I know to make it a .rb or .lua script? Does it matter?

that script does use getSelectedUnit so you will have to select the unit in one of its supported methods.  I haven't played around with makeown myself so I don't know how feasible it would be to make the script look for any incomplete citizens with which to add historical figure data. 

A thought off the top of my head about why these units can't be placed into a noble position might have to do with a lack of recorded events such as arriving at the fort, birth, or some such.  I might look into that later if no one else does.

The events are probably unimportant, but for completeness we could add a history_event_add_hf_entity_linkst and a history_event_change_hf_statest. 

To get the noble positions working I found that the unit needs a nemesis entry.
Spoiler: fixmakeown.lua (click to show/hide)

changes:
  • new_hist_fig.appeared_year = df.global.cur_year.  Probably irrelevant but this field is usually the year they arrived or created not birth year.
  • new_hist_fig.died_seconds = -1. Also likely to be irrelevant, but = 1 was probably a typo.
  • create and insert nemesis entries.
  • searches for all relevant units instead of only the currently selected unit
still missing and perhaps not needed:
  • history_event_add_hf_entity_linkst and history_event_change_hf_statest events.
  • historical_figure.info, historical_figure.info.skills, historical_figure.info.unk_14.
script to add nemesis to units that have already had historical figures added with the previous version of the fixmakeown or fixhistfig script:
Spoiler: fixnemesis.lua (click to show/hide)
Whoa, that's great Kurik! Thanks for the fix!

590
This looks really interesting! What's the peak speed, ticks per cart sent through?

Minecart momentum has some weird quirks.
Hahahahaa aaa aahh augh. Just reading that sentence gave me failed cart layout flashbacks.

Of course the absolute easiest method, if you don't mind doing most of it manually, is to just drop 2 minecarts into a trench of magma, then dump water on it from the floor above, then dig out the obsidian.  2 carts worth of magma is enough for a magma forge (4/7 magma).
I think QuantumMenace(?) demonstrated one that looked easier to me, and reusable, in his Wave Cannon save game. Set the carts to fill on a magma-safe floor grate, below which is a drain or smasher or whatever. Build a pump that pulls magma onto the carts and grate, and pump until the carts are full. Then just carry them away.

591
Okay, there's three new control levers:



The rightmost one controls a bridge that stops the magma cart launcher. If you disengage that lever, then that bridge will extend and the magma flow will stop. Since the magma forge area is already well-supplied, this shouldn't mess anything up, other than the magma river drying up.

The other two control the five silly cart grinders across a couple of the entrances.

The center lever extends/retracts the bridge that covers over the cart grinders. If it's disengaged, the bridges extend and anyone can walk anywhere safely, because the grinders are covered over.

The left lever controls a bridge that turns the cart grinders off completely by halting the minecart. If you want to retrieve goblinite, disengage this lever, while leaving the center lever enganged. This will cause a 1-tile bridge to cover an impulse ramp and the minecart will halt on that tile. But it's not 100% bug-free to use this lever, because when you re-start the grinder by retracting the bridge, it will toss the minecart around and it might fly out of the grinder area and have to be re-placed by a dwarf.

As far as FPS goes, I'm pretty sure the river is still the biggest offender. When I raised the two bridges Spish built to block the waterfall and let the river (very slowly) empty out, my FPS eventually went from 135 to 175.

592
I AM SORRY I PROMISE I DIDN'T FORGET ABOUT THIS FORT

I'll unleash the hounds upon him if he doesn't make some sort of announcement of what's going on soon.
Um, yeah, unleash away(?). I probably won't have any time to do anything for about another week, so either settle in for more inactivity or move on to the next person.

Mad One, have you made any progress to speak of?
I tried, but the FPS lag is craziness. Is there any way to shut off the minecart magma thingy that doesn't involve death or levers labelled "VERY DANGEROUS DO NOT PULL"?
The magma carts probably aren't the biggest FPS problem, but yes, it can be safely turned off. I'll go check the save later for the right lever. Guess I didn't label them well enough.

I think the big FPS problem is the river modification, actually. The upper river is partially blocked, so the lower river isn't full anymore. I noticed that a large part of the lower river is only partially full and all of it is flowing water now.

So, maybe turn off the ridiculously dangerous entrance minecart traps, turn off the magma cannon and raise the bridge to let the river empty?

I got pretty high FPS with everything running , but I'll try that tonight and post an essay on levers.

593
If a minecart hits another minecart that is travelling in a perpendicular direction, what happens to the component velocities? Is the behaviour different if the carts collide while in midair? Call it the T-bone aiming system if it works.
Okay, tried it, with two perpendicular 10-tile impulse ramp accelerators that converge on a NSEW flat track. Both carts start with 0 offset on the exact same tick.

Prior to colliding, both carts have the same speed, 112,470, in their respective directions.

On the tick where collision occurs, one cart enters the point of convergence of the tracks. The other comes to a halt one tile before that point. The cart that enters the point of convergence does retain the full velocity of both carts, in addition to an extra 5000 from the other cart, so it has slightly more speed in the direction of the non-continuing cart. That cart is now traveling at a 45 degree angle.

That's the good news. The bad news is what happens to the contents of the carts. Both eject their contents on the tick where collision occurs. Both ejected contents appear to have their velocities based just on the speed of each cart before the collision, so both are still traveling orthogonally.

The tick after collision, the stopped cart moves into the tile at the point of convergence and stays there. The other cart moves away at 45 degrees and all the ejected contents fly along orthogonal trajectories, not showing any effect of the collision.

Summary, you can get a cart going in a non-orthogonal direction with a collision, but this test didn't reveal a way to fire non-cart projectiles at an angle.

594
If a minecart hits another minecart that is travelling in a perpendicular direction, what happens to the component velocities? Is the behaviour different if the carts collide while in midair? Call it the T-bone aiming system if it works.
I don't care if it works or explodes all over itself. That idea is beautiful and I love it.

595
YES. I wondered about something like this but decided it couldn't be even remotely possible. Stacking "drift" with multiple such ramps could be the key to a 360 degree firing arc from only 4 barrels.
Well, don't get too excited yet? All I managed to do with it is break otherwise good cannons. But there might be something useful there.

596
I just thought of a derailment behavior that might somehow be useful for aiming cannons. A curved track on an up ramp has different physics than a curved track on flat. The up-ramp curved track will still turn a high-speed cart as it goes up one level, but the cart will retain a small amount of its previous velocity component. This can break cannons, (since the cart ends up going in a non-orthogonal direction) so you have to avoid curved tracks on ramps for cannon barrels, but maybe it'd help get a little more velocity mix?

Here's a bit of imaginary cannon barrel that goes up one level:
Code: [Select]
z: 0   z: +1
 ↓
░║░    ░░░░░░
░╚░    ░▼╚╚╚╚
░░░    ░░....
       ░░░░░░
All the curved tracks are ramps. If a high-speed cart enters from above, at the arrow, it will appear to turn the corner correctly and keep accelerating along the upper row of impulse ramps. However, it will retain 5,000 south velocity after going up the level and eventually fly off to the south, even striking the south wall and ejecting its contents. Maybe being continuously derailed lets it keep that small south velocity?

Maybe there are some tricks to be discovered with curving track up-ramps that can build diagonal velocity?


597
A weird effect of carts moving on a non-orthogonal vector is that they appear to ignore tracks: a cart moving at a SE to NW heading and meeting a straight E<->W track will just cross it and keep its heading, even when only propelled by 'low' speed rollers, which means a speed far below derail velocity. Seems you need to completely stop the cart before you can again propel it along a track.
Yeah, there's a lot of confusing derailment behavior. Maybe once a cart is derailed by entering a tile without an associated entrance track, it's treated as skidding? I wonder if there's something in the vehicle entry in lua that stores an "on-track" state? I know there's velocity, offset and a "stopped" counter.

Instead of aiming a single cannon sideways, why not make an impulse ramp cyclotron with 4 exits triggered with pressure plates placed at the targeted area? Put a few such gun emplacements in the field and watch the invaders get minced.
I think the biggest reason many people aren't playing with cyclotrons is rate of fire. If you have to wait for a cart (or set of carts) to speed up to firing velocity, then the cannon barrel isn't firing for that many ticks. That'd be okay for carts loaded with bins full of weapons/trap components, but for a squirt gun, it doesn't fire fast enough.

598
I was thinking the same thing with perpendicular rollers at the end of the barrel. Good to know that they only affect velocity in the roller direction.

Though, I don't see how multiple rollers would achieve much more deflection than just one, since the roller just imparts a fixed velocity.

599
Argh, I don't have my notes for exact numbers.

The rate-limiting factor for minecart autocannons is probably the amount of time it takes a minecart to begin falling down a shaft after striking an obstacle, coming to a halt, and firing its contents. It's something in the range of 8-11 ticks.

If you go faster than that, the next cart in line will run into the back of the first cart and prevent it from falling, and a multi-cart jam will form at the firing point.

So one nice property of a cart collecting (vertical stack) and dispensing system is for it to be exactly that rate or slightly slower. At that point I think you're at the theoretical maximum output for a single barrel.

All these ideas look neat!

edit, oh, also, if you use a vertical cart stack for collection and dispensing, there will be a timing glitch with the last cart in the system being released too quickly, causing the jam mentioned above. A workaround is to fill the system with one more cart than it can keep moving at a time, so there's always one cart backed up in the cart stack.

600
DF Dwarf Mode Discussion / Re: A simple question about magma and cart
« on: June 04, 2013, 03:06:26 pm »
One 7/7 tile of magma will always fill a stationary minecart. I haven't seen exactly what the criteria for filling a moving minecart might be. Others have guessed that it has to be moving slow enough.

I know that dropping a minecart straight down with no horizontal velocity or offset, onto a ramp with 7/7 magma will always fill the cart before it finishes rolling off the ramp.

What is your roller speed? Try it again with the first rollers set on lowest, then increase the speed once you've verified that the cart fills?

Pages: 1 ... 38 39 [40] 41 42 ... 53