Print

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

[Fossaman]

I was reading through the superweapons thread in the Fortress Mode discussion forum, and came across orbital cannons. What struck me was (no, not a cave in projectile) that the controls for such a device would take up a huge amount of space. So what I'd like to see is a lever type that can be assigned multiple toggle states; more like a control panel with multiple levers on it. It should probably be a 3x3 workshop sized thingamajig for realism.

This workshop would have several tasks available. "Add Control Lever" to add another toggle option, "Pull lever x" for any of the installed controls, "Link lever x" for any of the installed controls, and a "Remove Control Lever" option. Maybe even an "Unlink Lever x" option that lets you undo stuff, that would be nice for normal levers too.

Now, this might seem like it would make big sets of levers useless. But I propose requiring a mechanic to do that actual lever pulling. It's a room with lots and lots of levers; you want to make dead sure you've got the right one. Mechanic skill would determine the speed it takes for the dwarf to find the correct lever. The more levers in a workshop, the slower the action. Add in a chance of getting the wrong lever for real 'fun' times.

Essentially, this is a space saving contrivance. Build one of these instead of a field of fifty levers. Add in a function to name each control lever and you've got an organizational tool too.

[Warlord255]

While there might be some compunctions about the dwarfiness/era-appropriateness of such a control panel, it's worth noting that right now, mechanisms are borderline magical (or, rather, just gamey) in their operation.

Something like this might be better forestalled for if/when we get a more advanced handling of mechanisms, such as requiring power to be supplied to lever-toggleable devices.

[Variance]

You could use a 2-bit system (explained more below), where one set of levers determines what group of tiles will contain the tile to be released, and the second set of levers determines which tile within that group will be released. You would only need 480 levers on a 57600-tile map (5x5 on embark), rather than one for every tile.

You would need to create a mechanical computer to do this, ideally using mechanics rather than fluids for the gates. Assuming you have a normal-ish map of about 5x5 region tiles, then a true orbital cannon would need to be able to drop any one of 57600 projectiles. A binary readout board of activated/deactivated gear assemblies would only need 16 gear assemblies to express any number from 1 to 57600 (They could go up to 65535), and then you could integrate everything back into gear assemblies that dictate which axles will be rotated, which dictate what pumps will pump water onto what pressure plate to release what bridge to send which wall to come crashing down.

Normally, of course, you would then need a pressure plate for every link that would need to be severed to drop a wall. However, there is a far more ingenious way. You use a bi-level routing code system (with two connections that hold the projectiles in place and two determinant switches), where when the activated/deactivated gear assembly display is programmed with what tile to drop (you would have to assign every tile a number) and it activates the correct pumps to spring the pressure plates, there are only two sets of 240 pressure plates that need to be pressed. The first set of pressure plates that need to be pressed are ones that decide which zone of the map will be selected. Out of one of 240 divisions of the map (any one set of 15x16 tiles), each division will contain 240 floor tiles. The first pressure plate from the first set of 240 plates will sever the first connection holding the projectile in place for all the tiles in that division, but none will fall due to the second connection. The other pressure plate activated in the other set of 240 plates will sever every secondary connection for an individual tile in each of the 240 divisions. However, only one division will already have its first connection severed, so only one projectile will have both connections severed and be able to fall.

Wall of text summary: You can use a 2-bit system instead of a one-bit system to determine which tiles will fall, reducing the number of switches needed 240-fold.

You could also make the system higher-bit yet, with multiple tiers of zones and divisions, until you only need 16 switches for a binary system. Of course, that's impossible, because you can't connect more than 6 connections to a given tile, but even a 6-bit system could greatly ease the number of things used. It would just require a little more planning and a lot more connections between pressure plates and supports or bridges.

[Pilsu]

I don't really see how this would be useful

[flabort]

you could use a device in one tile to "decide" weather it opens floodgates at A, B, or C, or raises the bridge at point D. all from the comfort of point E. provided you can place enough mechanisms with enough power to do all that, you'd only need the one "lever"/control panel. that's how this is usefull, is that you don't need to use as much space. you DO need to use more matierial, but you save space, and thus have room to do even more stuff.

[Variance]

I don't really see how this would be useful

I don't know if you were talking to flabort, but I'm going to flesh out my ideas a little more.

Using a 2-bit system for such a large project does look daunting, but it makes you only need twice as many as the square root of the number of levers otherwise, where every lever is linked to one drop. So in a system with 16 things to drop, you would only need 8; in a system with 64 things, you only need 16. The larger the number of things to be triggered is, the smaller the fraction you need is.

Imagine a normal set of 16 walls to be dropped. with 16 levers. You want to employ a 2-bit system and only need 8 levers. Each wall has 2 supports or bridges holding it instead of one.

2 is a wall with 2 supports connected, 1 is a wall with only 1 support left, and 0 is a wall falling;
= is a bridge;

A and B are levers in different states. 1 is off, 2 is on, and on raises the bridges/cuts supports.

Spoiler (click to show/hide)

Group 1 determines which zone of 4 blocks will have 1 support released, and Group 2 determines which wall in each set will be released.

=2= =2= =2= =2= =2= =2= =2= =2= =2= =2= =2= =2= =2= =2= =2= =2=

Group 1        Group 2
A A A A        A A A A

You want to drop the 2nd wall in the 3rd zone, the 10th wall from the left. You first select the third group by flipping the third switch in group 1, the zone determinant. This disengages one support for all walls in zone 3, walls 9-12

=2= =2= =2= =2= =2= =2= =2= =2=  1=  1=  1=  1= =2= =2= =2= =2=

Group 1        Group 2
A A B A        A A A A

Then you select the 2nd wall in a zone, by flipping lever 2 in group 2. This disengages every 2nd wall in each zone, but only the one in zone 3 falls, because that zone is the only one with the first support also gone. That's how the zone is "selected". Now the 10th wall drops like you wanted it to, but with only 8 levers instead of 16.

=2= =2= =2= =2= =2= =2= =2= =2=  1=  0  1=  1= =2= =2= =2= =2=

Group 1        Group 2
A A B A        A B A A

Although it seems more complicated, remember that it requires only twice the square root of the total number of levers it would otherwise. 8 levers in 16 isn't a big difference, but it's a huge difference to only need 480 levers instead of 57600 levers where you need to be able to trigger 57600 different events. You only need to set up things ahead of time, like using rows and columns. A 4x4 version of the example system would pick, say, row 3, column 2.

In summary, having a lever with multiple settings is equivalent to having a higher-base system, like having options 1, 2, 3, and 4 instead of just options 1 and 2. A higher bit system acts as multiple digits, options 11, 12, 21, and 22. A high-base system works well for smaller numbers of options, like when you want to be able to trigger one of 4 different things; a high-bit system works better when you want to be able to trigger one of 400 different things. Flabort's would be a useful addition to normal gameplay; my idea can already be done, but is limited to megaprojects.