I've decided to core-dump several ideas here rather than pollute the forum with multiple new threads, especially since I know each of these things has been discussed before (at least a little bit). The text isn't showing up quite the way I want it, but hopefully it's decipherable.
Any links that I missed to previous discussion on the topics would be appreciated, and of course fire away at the merits (technical or Dwarfiness) of the ideas here.
----
Keyshttp://www.bay12forums.com/smf/index.php?topic=115254The idea of keys has come up in multiple threads applied to locking doors. There are two main objections:
1. Door keys would proliferate, causing FPS issues similar to coins ("pocket lint" problem)
2. The pathing code doesn't seem to be able to handle some-Dwarves-can-pass-but-not-others ("pathing" problem)
It is also suggested that putting an access list on the door would be an elegant solution to the pocket lint problem but leave the pathing problem.
Either or both of these could be overcome eventually with Moore's Law, but anyway it is not what I am suggesting.
I am suggesting a container (chest seems the dwarfiest) that can be locked. If adding a lock to an existing container is too complex to code well (and I suspect it is), the alternative is a new container such as a "lockbox."
The lockbox would be either (chest + mechanism) -> (lockbox + key) or (chest + lock&key) -> (lockbox + key). I'm envisioning a lock&key item made at a mechanic's workshop like a mechanism but metal-only.
Placing an item into or removing an item from a lockbox requires the Dwarf to have a key (or lockpicking skill...).
A lockbox would mildly slow down a Kobold thief. Mostly it would provide a dwarfier way of forbidding something.
7777777
7777777
77+++77
77+Æ+77
77+++77
7777777
7777777
╞═╡
----
Hearth/Fireplacehttp://www.bay12forums.com/smf/index.php?topic=46184.msg914907http://www.bay12forums.com/smf/index.php?topic=69453.msg1680410This is another idea that got kicked around a lot a few years ago, and it actually exists in some mods. A hearth or fireplace would be a one-tile building/construction that can start a fire given a unit of wood or fuel.
The hearth should be able to cook Simple Meals, but in Fortress mode it mostly serves to raise the value of a dining room. In Adverturer mode these things should be in residences and give the character access to fire should he/she need it.
In either mode, it'd be nice to have it affect the surrounding temperature. Not recommended inside glaciers.
♥----
Secret Doorswww.bay12forums.com/smf/index.php?topic=27207.msg327671www.bay12forums.com/smf/index.php?topic=121538.msg3942012This is in essence just a regular door, but with the invisibility of a trap.
Option 1: Make it from a boulder for a "rough wall" look and from a block for a "smoothed wall" look.
Option 2: Force the player to plan ahead... secret doors can only be carved out of native stone.
If someone sees a Secret Door in use, he/she knows it is there... similar to how intelligent creatures avoid known traps. ("Speak friend and enter.")
It should not be possible to make a Secret Door that matches soil surroundings. If secret doors can be built (rather than carved in-situ) then an option for a wooden secret door should exist as well.
Here is an example of a poorly-hidden secret door made of the wrong material, mostly so that those of you without TRAPAVOID tags can actually see it:
═════
+++++
═╦═╦═
║+║----
Pit TrapAlthough a pit trap can already be built with a retractible bridge and a pressure plate, this is just a compact one-tile version. Should probably be remote-controllable by a typical trigger as well.
One neat feature would be to deactivate it (and thus not reveal its presence) if there is solid wall below it. This only matters if the area below it is mobile (see below) or you plan to mine out soil tunnels
really fast during a siege.
^----
Mobile Wallshttp://www.bay12forums.com/smf/index.php?topic=23799.msg263225This is an idea that is definitely already on the table, so this more of an idea on how to do it.
I think the simplest method is to just glue blocks together using a Construction menu (choose to connect any combination of N/S/E/W/U/D) and leave them at the mercy of minecart physics. Powered rollers would be the most reliable way to move things around.
This lets the community apply all of the minecart ‼SCIENCE‼ immediately to moving segments. Would love to see the ability to join across z-levels and the ability to carve fortifications into moving segments.
The typical penalty for conflicting/invalid movements (deconstructing the whole damn thing) should keep this Fun. Toady also needs to work out a character's reaction to having the ground move under him/her/it.
Here are two different methods for sliding a segment East and West:
│
╞═■■■■╤╤╤═╡ These rollers set to move EAST when powered
╞═■■■■╤╤╤═╡ These rollers set to move WEST when powered
│
│ │
╞■■╤╤╤╤╡ Western 3 rollers move EAST when powered, Eastern 3 rollers move WEST when powered.
----
Worm GearAnother way to get thing moving would be to use worm gears. Since axles don't rotate in any particular direction right now, the mechanism at the end of the driving axle needs to designate a direction it moves across the worm gear sections.
The mass of the moving section (including its own axels and/or worm gears) figures into the power needed to move it.
This section of wall (with a fortification carved in the middle) will slide north to seal off an entryway. The spin of the North-South axle is ignored by the mobile wall.
╥
║ Tracks
║
■
╬ Mobile wall section
■
│
↕─── Will move the assembly SOUTH when powered
↕
↕─── Will move the assembly NORTH when powered
↕
↕
↕
│
──↔↔↔↔── What an East-West worm gear looks like.
9 What a vertical worm gear looks like.
A particularly Dwarfy use for vertical worm gears would be to lift a mobile section like an elevator.
Top view of the elevator. The mobile section has an implied floor, upon which levers are placed to control which axle is moving the segment. There is no need for these levers to be on the vehicle itself, but it might make the dwarves feel better to have the illusion of control. Engaging both levers are the same time would lead to Fun.
To prevent the whole thing from pancaking on the ceiling when it reaches the top, use a segment of vertical axle at the top so it no longer provides power. Ditto for the bottom segment of the down-driving gear. Or you can put your trust in Urist McOperator's timing skills. The choice is yours.
Z+1
++++++
+++ò9+
++++++
++++++
+9ò+++
++++++ Z+0
■■■■■■
■■■■9■
■■■■■■
■■■■■■
■9■■■■
■■■■■■Conveniently, ↕ nor ↔ nor 9 has any meaning in the game (other than the last showing up in text).
----
DialogI saw
this on Ars Technica and thought that it might be worth looking at for ideas. Of course this appeared
after Toady did all that work on dialog and lying.
The
research paper is a working paper from an Artificial Intelligence lab in Europe. Ignoring the implementation details, the state-space concept is what I think would be useful for pulling dialog completely into game time.
I also think it'd be awe-inspiring if a character could be in more than one conversation simultaneously, such as the audience members of an announcement making snide comments to one another. Or the shopkeeper's daughter running up and asking him for a biscuit. Of course the in-world mothers with multiple children will hate Toady for this upgrade, but you can't please everyone.
----
Fontshttp://www.bay12forums.com/smf/index.php?topic=136332.0Speaking of dialog, I'm also incorporating my previous suggestion on tilesets for text, just to keep everything in one place.
I apologize if this has been suggested before, but the keywords are just too common to search properly.
One of the upcoming features I read about was separating the font from the graphics tilesets, and that is a great idea. I think Toady can go one step further and allow several fonts with very little additional effort.
The planned feature, as I understand it, would have something like text.png and graphics.png as two distinct tilesets. Why not also allow for specific tilesets designated inside language files? Then we could have a runic-looking Dwarf language tileset (font), a frilly Elf language tileset, a serif Human tileset and something ugly for the Goblin tileset (like Comic Sans). Languages from mods can include their own fonts as desired, or pick one of the basic ones. The vanilla version of the game just needs a single tileset to act as a fallback in case specific ones are missing.