Print

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

[Arkenstone]

I figured out how to make a randomizer for things like traps or shifting mazes!  It's a bit complex to draw, so I'll just explain it:

Basically it's just a large, square, 1Z-high circular room with a floodgate in the center (and also a hatch in the ceiling that lets you refill it).  The floor is covered in 0-6 pressure plates.  You leave the floodgate closed when filling it, then when you want to activate it you open it, sending seven "water holes" flying around the room randomly.  So you're exploiting the game's randomizer algorithm instead of having to make your own!

[Shoku]

The way water moves around actually has pretty obvious patterns to it. Expect a whole bunch of plats in the same column/row to get triggered together. You can expect them to almost always send their off signal at the predictable 100 step mark after their on signal though, depending on the size of the room.

[Arkenstone]

Really?  Well, I was thinking of having the room like 16 radius; maybe strategicly placed columns can break up the "straight line" effect you speak of -although I haven't seen that happen alot before for more han 3-4 tiles anyways.  Also, I'm utilizing the ABSENCE of water as the trigger, so it might behave differently.

If need be, I can further increase uncertainty be using a specialized pump stack I designed months ago but scrapped because I couldn't find a feasible way of feeding it data that would be consistantly meaningful.  It works like this:

A bunch of 1x1 reservoirs (with pressure plates) are layed out in three dimensions, with pumps linking them.  All the data, therefore, is preserved in discrete quanta, besides for the occasional irregularity that only increases randomness.  Multiple pumps are hooked into each one of at least a dozen imput signals, which my new randomizer can provide.  Only the bottom layer has inf water, the rest must take the "ON" signal from a device on the floor beneath it.  Thus while multiple pumps are activated with each input, it is random which output signals actually work.  The higher floors would be on less often, and there needs to be a regulatory system (like having a hatch that needs a seperate signal from the pump) if they aren't to merely "Pulse" on rare occasion.  Although, the problem might solve itself as the lower levels get increasingly filled; I haven't tested it.

A third circut could be added to solve the "Pulsing" problem: a long series of these "descrete" memory gates that connect and empty directly into an infinite water source.  Machine logic works really well for OR and AND, so the imputs from the last device could be connected to, say, a 3x3 grid of gears to activate/deactivate each one.  The output of that circut would hook directly into the features that are to change -The Cube is now possible to construct. I think I might start a thread for that...

[Zidane]

What about NAND Gates, and inverters?

[thijser]

The way to make this like this would probably be by making a 2 tiles high reservoir and then making pressure plates 2 tiles away. Then using each of the gates as a part of a binary number and you have a random number.

[Wastedlabor]

I'd favour a cat in a sealed pit.

[Kurouma]

Using the absence of 1/7 scooting around is genius. With 4 possible source tiles to take the 1/7 from, I'm pretty sure you'd have something approaching randomness. Just clarify for me? With your 3D arrangement, the feeder pups attached to the inf water source are turned on by the RNG, but how are the pumps on each successive layer randomized? Or does each pressure plate just turn on the four pumps taking from it? Wait, that's cool, I'm getting it now. So how do you propose to plan/set out the geometry of the initial level?

as for the NAND gate... you need two floodgates next to each other in a 2x2 channel (your output), open by default - I'm pretty sure that this can be achieved by first linking up a lever to them and leaving it pulled [[actually if that works, this allows you to swap between a NAND and an AND at will, awesome]]. Link each to pressure plates on your two input channels. They both need to be depressed to fully block your output, which should otherwise flow constantly.
i.e (!output) iff [(!input1) AND (!input2)]
Can floodgates work like that? I have no experience doing this myself

[Sphalerite]

Can floodgates work like that? I have no experience doing this myself

No, sorry.  Floodgates don't toggle when they get a trigger.  Trigger devices (pressure plates and levers) send 'open' and 'close' commands, and floodgates (and everything except for a gear) just respond to the last trigger they received (although devices with activation delays ignore commands received during their delay time).  Gears toggle when they get any message from a trigger, but they are the exception.

[eggrock]

Basically it's just a large, square, 1Z-high circular room

I'll bet that's hard to draw. 

I just ran through some tests recently and found this to work well. This is a side view:

Code: [Select]

~B_
  ppppppXX

~ water source
B bridge (opens <)
_ channel to the corridor below
p pressure plate (7/7)
X floodgate

Link a lever to the bridge and both floodgates. When the lever is in the 'off' position the bridge should be down and both floodgates up. This results in 7/7 water everywhere (which will set the plates to an activated state and leave them there.) Flipping the lever to the 'on' position will raise the bridge and lower the floodgates, leaving seven tiles at 6/7 and one at 7/7. The plates will start toggling stuff randomly but fairly quickly.

For large areas the math winds up requiring too many floodgates so it's easier to flood to 7/7 and remove a bucketful of water.

[Arkenstone]

Um, what I said was to utilize where it's 6 deep instead of seven.  If you leave a single level of water bouncing around like that long enough, then it will dissapear.  I'm hoping that it won't with a single layer missing.  And using a single floodgate like I said is essentially taking 7 bucketfulls of water out.

Also, the key features in the secondary/tertiary systems were that...

• There is no flowing water: all water is added to and removed from 1x1x1 cubes using pumps.
• The pumps are controlled by gears, and therefore do not generate lag when inactive.
• The states in each successive system would change less and less often -but hopefully more randomly as well.

All of these are designed with the purpose of having a more efficient system, and reduce lag.  I always try to do stuff like this; I even use pressurized water channels so that only one tile of water is moving instead of the entire channel.

[Immacolata]

All of these are designed with the purpose of having a more efficient system, and reduce lag.  I always try to do stuff like this; I even use pressurized water channels so that only one tile of water is moving instead of the entire channel.

Would you care to elaborate a bit what that is about? I am new to pumping in general and have been using good old fashioned murky pool / brook / river and well from underground caverns to do watery stuff in my fortress. I am still terrified of messing with pressurized water because of all the woeful tales of dorfen fortress drowning I have been reading.

How does pressurized water stay in channels - and why does this affect lag positively (or negatively if you view "lag" as a number

[Shoku]

All of these are designed with the purpose of having a more efficient system, and reduce lag.  I always try to do stuff like this; I even use pressurized water channels so that only one tile of water is moving instead of the entire channel.

Would you care to elaborate a bit what that is about? I am new to pumping in general and have been using good old fashioned murky pool / brook / river and well from underground caverns to do watery stuff in my fortress. I am still terrified of messing with pressurized water because of all the woeful tales of dorfen fortress drowning I have been reading.

How does pressurized water stay in channels - and why does this affect lag positively (or negatively if you view "lag" as a number

He's talking about some esoteric aspects of water movement. When you're only dealing with 1 z-level the water acts like stacks of disks and the disks can slide around on top of each other. If all of the water in some space in 3/7 deep then all of the disks are taking up all of the space so none of it moves (flows) anywhere. If you add one disk though then there is a single tile of 4/7 and that top disk can easily slide around on all of the 3/7 stacks. And if you were to add exactly 4 all at once you would for a moment have 7/7 next to the 3's but the top would slide off and drop down to 4/7 and pretty quickly they'd all drop down to the 4th level.

Now if you open up a pool of 7/7 deep water into a long tunnel then you end up with basically a bunch of 6/7 in the pool then a length of mainly 5/7, then 4/7 and so on as the parts slide around on top of each other and encounter open space so they can drop. Eventually these would slide around until it was all the same level (excluding evaporation) but this takes quite awhile and thus all of this moving of disks of water eats up a lot of CPU. Worse yet is if your pool doesn't go exactly level, like with half 3s and half 4s. They're slide around forever instead of just sitting still.

Now with pressure it is a little bit different. With several z levels of water a new mechanic comes into play. Any time that water is sitting on top of 7/7 water and there is open space on a lower level it will just vanish from on top of the water and reappear in that open space. If you have many levels of water this can result in a whole lot of water moving very quickly, except it's not really moving because to move the water above would have to push the water below out of it's way and actually nudge the lower space's water further out.
Now pumps also behave very much like this but instead of water looking for open space on a lower level the pump just looks for space on the same level or lower.

Pressurized water has a little flaw though. It only checks for open space in 4 of the 8 directions. If you have a diagonal space space the water will still "flow" through it but it won't teleport through it.


Now as for flooding your fort: there is considerably less risk of this if you just install lots of doors in your halls. Water won't ever force a door open so you only have to worry about it if dwarves walk through it or if they leave items in the doorway (thus keeping the door open.) And then if there is an accident you can just forbid the doors (and perhaps build extra walls in front of them just in case.) Better though is to only play with water at the lower parts of your fort. Pressurized water can't end up higher than it started so if you go off to the side and dig a stairwell down several levels then play with water there any limited source of water won't be able submerge important parts of your fort. For limitless sources though you may want to dig up several layers above them then over and back down to make whatever waterworks you were planning for absolute safety.

Though absolute safety is not really that FUN. If you have aquatic catastrophes you'll have lots of fun stories to share with people and probably some fond memories as you look back on it.

[cog disso]

I'd favour a cat in a sealed pit.

Holy poopsicles, this is a good idea for some mischief.

Cat sealed in a room full of pressure plates, which activate various traps throughout the fortress. Build the cat room in the center of a large cat themed temple complex. Maybe seal a few caged cats up with it so in case it dies of starvation, you can unload a few other cats.

How long until the dwarves start figuring out that their odds of survival are based entirely upon the actions of ALL POWERFUL CAT DEITY, and a cult forms?

FURTHER MISCHIEF:

Seal two cats in the room. Make it so that IF ALL traps are pressed at once, the entire fortress collapses. As the cats will inevitably breed,  you have now built yourself an unknown timer until the inevitable catsplosion, and all dwarven lives are now completely dependent upon this knowledge.

FURTHER FURTHER MISCHIEF:

If you seal a cat in a cage with a small piece of plutonium, and the chances are that the cat could, at any time, die of radiation poisoning, Urist McShrodinger's theory states that the cat is both living and dead according to the rules of logic.

[gtmattz]

Um, what I said was to utilize where it's 6 deep instead of seven.  If you leave a single level of water bouncing around like that long enough, then it will dissapear.

One 7/7 amidst a bunch of 6/7 should not disappear, a single 1/7 dancing around on top of a bunch of 7/7, however will.  Unless you are on a really hot biome and the water is exposed to the open air, water should not evaporate unless it is 1/7.

[Akjosch]

Now as for flooding your fort: there is considerably less risk of this if you just install lots of doors in your halls. Water won't ever force a door open so you only have to worry about it if dwarves walk through it or if they leave items in the doorway (thus keeping the door open.) And then if there is an accident you can just forbid the doors (and perhaps build extra walls in front of them just in case.)

As a side note:

I prefer a system of grates leading to sewers behind every single door to a room, as well as across major walkways. The sewers themselves have outlets to the side of the map (through carved fortifications) as well as to several big (5x5 or bigger) outlet shafts separated from the sewers through fortifications, which go all the way below the lowest level of the fort into a huge cistern, which itself has several overflow tunnels (at least one big on the top level and one behind flood gates on the lowest level) leading to the map edge. The sewers levels themselves are interconnected in groups of two to five, and separated from the fortress by trapped airlock-style maintenance entrances in case there is too much growth in there and some underground trees have to be cut, or some annoying critter has to be killed/rescued.