Dwarf Fortress Wiki - User contributions [en]

Difficulty

2025-02-13T03:56:08Z

CobaltNinja: /* Custom settings */ Nuked stray parenthesis

{{Quality|Fine}}
{{av}}
{{merge|Settings}}

While previous versions of ''Dwarf Fortress'' allowed you to toggle [[Invader|invaders]] on or off, v50 added more granular difficulty settings to fine-tune one's experience. Difficulty settings will affect whether your fortress can be attacked by outside forces, how frequent said attacks are, how big invading armies are, and [[noble]] neediness. You can modify these settings before and after embarking at any time.

== Default settings ==
'''Enemies''' has 3 options:
* '''Off''' will disable [[Ambush|ambushes]], [[Siege|sieges]], [[Megabeast|uninvited]] [[Forgotten beast|guests]], [[Werebeast|werebeasts]], and agitated wildlife attacks, but not [[intrigue]], [[HFS]], or misbehaving dwarves, so it is still recommended to train a military.
* '''Normal''' is the standard ''Dwarf Fortress'' experience.
* '''Hard''' ensures a never-ending stream of [[Fun]], causing invaders to show up earlier, more often, and with more bodies to throw at the gates.
'''Economy''' has 2 options:
* '''Normal''' is the standard ''Dwarf Fortress'' economy.
* '''Hard''' requires you to produce more wealth in order to receive higher-ranking nobles, requires [[Temple|temples]] and [[Guildhall|guildhalls]] to be more valuable before satisfying petitions, and causes [[Noble|nobles]] to make more [[Mandate|mandates]] and [[Demand|demands]].

== Custom settings ==
If you wish, you can also fine-tune individual settings - maybe you only want megabeasts to assault your fortress, and would prefer the elves to leave well enough alone. The following options are available for enemy settings:
{| class="wikitable"
|-
! Setting !! Possible values !! Description !! Default values (Off, Normal, Hard)
|-
| Civilizations can attack || Yes/No || Controls whether [[Ambush|ambushes]] and [[Siege|sieges]] can occur. || No, Yes, Yes
|-
| Megabeasts can attack || Yes/No || Controls whether [[Megabeast|megabeasts]] and [[Forgotten beast|forgotten beasts]] can attack. || No, Yes, Yes
|-
| Werebeasts can attack || Yes/No || Controls whether [[Werebeast|werebeasts]] can attack. || No, Yes, Yes
|-
| Curious wilderness creatures can come to cause trouble || Yes/No || Controls whether agitated animals can assault your fortress, and whether animals will spawn with the intent to steal items. || No, Yes, Yes
|-
| Enemy population triggers || 1 to 300 || Likely affects when invasions occur, and how difficult they are. Met when you have this many citizens.{{verify}} || 0/0/0/0/0, 20/50/80/110/140, 15/30/40/55/70
|-
| Enemy production triggers || 0 to 100,000,000 || Likely affects when invasions occur, and how difficult they are. Met when you've created this much wealth.{{verify}} || 0/0/0/0/0, 5000/25000/100000/200000/300000, 2500/12500/50000/100000/150000
|-
| Enemy trade triggers || 0 to 100,000,000 || Likely affects when invasions occur, and how difficult they are. Met when you've exported this much wealth.{{verify}} || 0/0/0/0/0, 500/2500/10000/20000/30000, 250/1250/5000/10000/15000
|-
| Megabeast attack period (seasons) || 0 to 100 || How many seasons must pass before a megabeast may attack your fortress.{{verify}} || 10, 10, 8
|-
| Forgotten beast sensitivity || 1 to 100,000 || Performing nature-disrupting actions within the caverns will agitate forgotten beasts and may cause them to attack. [[Noise]] will also increase agitation. A smaller value will require less actions before the maximum attack chance is reached. || 10000, 10000, 10000
|-
| Forgotten beast irritation minimum || 1 to 100,000 || If the hidden agitation counter is at this value or below, no forgotten beasts will attack. || 5000, 5000, 2000
|-
| Forgotten beast wealth divisor || 1 to 100,000 || Your current fortress wealth is divided by this number - the result is added to effective irritation to determine forgotten beast attacks. A smaller number will cause forgotten beasts to attack sooner. || 40, 40, 40
|-
| Wilderness sensitivity || 1 to 100,000 || Performing nature-disrupting actions such as cutting down trees will agitate wildlife and may cause them to attack. A smaller value will require less actions before the maximum attack chance is reached. || 10000, 10000, 10000
|-
| Wilderness irritation minimum || 1 to 100,000 || If the hidden agitation counter is at this value or below, no agitated wildlife will spawn. || 2000, 2000, 0
|-
| Wilderness irritation decay || 0 to 100,000 || Causes wildlife to be less irritated after every year. A higher value will make them less irritated faster. Normal default values are 500 on '''Normal''' and 100 on '''Hard'''. Currently broken - changing this setting instead modifies the Minimum value above.{{bug|12181}} || 2000, 2000, 0
|-
| Werebeast attack period (seasons) || 0 to 100 || How many seasons must pass before a werebeast may attack your fortress.{{verify}} || 10, 10, 8
|-
| Vampire migrant fraction || 1 to 1,000 || Affects what percentage of new migrants will be [[Vampire|vampires]]. A value of 0 will disable vampiric migrants. (Only on '''Off''' difficulty) || 0, 100, 75
|-
| Invasion caps (regulars) || 0 to 500 || The maximum amount of humanoid enemies that can be thrown at you when a civilization sieges you.{{verify}} || 0/0/0, 10/40/120, 20/60/120
|-
| Invasion caps (monsters) || 0 to 500 || The maximum amount of mounts and other tamed creatures that can be thrown at you when a civilization sieges you.{{verify}} || 0/0/0, 0/5/40, 1/10/40
|-
| Minimum raids before first siege (per civ) || 0 to 500 || Affects how many [[Ambush|ambushes]] must be performed before a civilization can try a proper siege for the first time. || 0, 2, 2
|-
| Minimum raids between sieges (per civ) || 0 to 500 || Affects how many ambushes must be performed before a civilization can try a proper siege from the second time onwards. || 0, 3, 1
|-
| Siege frequency (percentage, otherwise raid) || 0 to 100 || Percentage chance to receive a siege instead of an ambush. || 0, 25, 50
|-
| Cavern dweller scale (increase per attack) || 0 to 100 || Every time cavern-dwellers attack your fortress, the maximum number of attackers increases by this number. || 0, 10, 20
|-
| Cavern dweller maximum attackers || 0 to 500 || The maximum amount of enemies that can be thrown at you when cavern dwellers attack. || 0, 50, 75
|-
| Diplomacy tree-fell count || 1 to 1000 || Affects the default amount of trees [[Elf|elven]] diplomats will request you limit your felling to. Your negotiator will still try and increase the tree limit. || 25, 25, 10
|-
| Diplomacy tree-fell count (untamed wilds) || 1 to 1000 || Affects the default amount of trees elven diplomats will request you limit your felling to if you've settled in a [[savage]] area instead. Your negotiator will still try and increase the tree limit. || 5, 5, 1
|}
The following options are available for economy settings:
{| class="wikitable"
|-
! Setting !! Possible values !! Description !! Default values (Normal, Hard)
|-
| Economy population triggers || 1 to 300 || Affects how many citizens you need to increase the rank of your fortress. Must meet population and one of production or trade. Triggers 1 through 5 correspond to Hamlet, Village, Town, City, and Metropolis. || 20/50/80/110/140, 20/50/80/110/140
|-
| Economy production triggers || 1 to 100,000,000 || Affects how much created wealth you need to increase the rank of your fortress. Must meet population and one of production or trade. Triggers 1 through 5 correspond to Hamlet, Village, Town, City, and Metropolis. Setting this trigger to 0 causes it to be met immediately. || 5000/25000/100000/200000/300000, 25000/125000/500000/1000000/1500000
|-
| Economy trade triggers || 1 to 100,000,000 || Affects how much exported wealth you need to increase the rank of your fortress. Must meet population and one of production or trade. Triggers 1 through 5 correspond to Hamlet, Village, Town, City, and Metropolis. Setting a trigger to 0 causes it to be met immediately. || 500/2500/10000/20000/30000, 2500/12500/50000/100000/150000
|-
| Land holder population triggers || 1 to 300 || Likely affects how [[Baron|barons]] and upwards are achieved.{{verify}} Values 4 through 10 are not used in the base game. || 20/20/20, 20/20/20
|-
| Land holder production triggers || 1 to 100,000,000 || Likely affects how barons and upwards are achieved.{{verify}} Values 4 through 10 are not used in the base game. || 10000/200000/300000, 500000/1000000/1500000
|-
| Land holder trade triggers || 1 to 100,000,000 || Likely affects how barons and upwards are achieved.{{verify}} Values 4 through 10 are not used in the base game. || 10000/20000/30000, 50000/100000/150000
|-
| Value of temple || 1 to 100,000,000 || Affects how valuable a designated [[temple]] zone must be before it satisfies a petition to create it. || 2000, 6000
|-
| Value of temple complex || 1 to 100,000,000 || Affects how valuable a designated temple zone must be before it satisfies a petition to upgrade it. || 10000, 30000
|-
| Priesthood unit count || 1 to 300 || Affects how many members of a religion must be citizens in your fortress before a petition for a temple is made. || 10, 10
|-
| High priesthood unit count || 1 to 300 || Affects how many members of a religion must be citizens in your fortress before a petition to upgrade an existing temple is made. || 25, 25
|-
| Value of guildhall || 1 to 100,000,000 || Affects how valuable a designated [[guildhall]] zone must be before it satisfies a petition to create it. || 2000, 6000
|-
| Value of grand guildhall || 1 to 100,000,000 || Affects how valuable a designated guildhall zone must be before it satisfies a petition to upgrade it. || 10000, 30000
|-
| Guild unit count || 1 to 300 || Affects how many members of a profession must be citizens in your fortress before a petition for a guildhall is made. || 10, 10
|-
| Grand guild unit count || 1 to 300 || Affects how many members of a profession must be citizens in your fortress before a petition to upgrade an existing guildhall is made. || 25, 25
|-
| Mandate period (more = fewer) || 1 to 10,000 || Affects how long nobles must wait before making new mandates. A higher value forces them to wait longer before mandating something.|| 1000, 500
|-
| Demand period (more = fewer) || 1 to 10,000 || Affects how long nobles must wait before making new demands. A higher value forces them to wait longer before making a demand.|| 500, 250
|}

Noise

2024-06-08T03:43:28Z

CobaltNinja: Added information about noise affecting forgotten beast attacks (see https://tinyurl.com/yu5m4ybn DFHack docs for more information)

{{migrated article}}
{{av}}
{{Quality|Unrated}}
:''"Sound" redirects here. For the game's soundtrack, see [[Soundtrack]].''
Certain jobs generate '''noise''' which may disturb [[dwarves]] sleeping nearby. Depending on a job's noise level and proximity, your dwarves could sleep "uneasily due to noise", "very uneasily due to noise", or be woken up by noise. These events will produce unhappy [[thought]]s in varying degrees.

Noise in [[cavern]] layers will also agitate [[Forgotten beast|forgotten beasts]], which may cause them to attack sooner. Don't worry about this too much, because your fortress' [[wealth]] has a much greater impact on how soon they attack.

Neither [[wall]]s nor [[door]]s will insulate dwarves from noise - distance and how loud a job is are the only factors determining whether a dwarf's sleep will be disturbed. Noise is produced when a noisy job is completed, but thoughts about noise do not appear until the sleeping dwarf has woken up.

Also, dwarves walking through a sleeping dwarf's room (even over their heads) will not cause noise, which is important for [[bedroom design]].

'''Note''': Contrary to common belief based on [[23a:Noise|earlier versions]], [[workshop]]s do ''not'' currently produce any noise.

==Noisiness of various jobs==
Only 5 jobs are known to cause noise. These include the following:

* [[Digging]] - 8 tiles
* [[Wood cutting]] - 8 tiles
* [[Engraving]] - 4 tiles
* [[Fortification]] carving - 4 tiles
* Removing [[construction]]s - 8 tiles

====Visualization====

Noise radiates across [[z-level]]s in the shape of a cube, in all 6 directions (north/south, east/west, ''and'' up/down), so noise that travels 4 tiles will generate noise in a 9x9 pattern on 9 successive floors. The noise radiates from the center of the noise-producing things.

{{diagram|spaces=yes|
█ Level 0 Level ± 1 Level ± 2 Level ± 3 Level ± 4 Level ± 5

........... ........... ........... ........... ........... ...........
.*********. .*********. .*********. .*********. .*********. ...........
.*********. .*********. .*********. .*********. .*********. ...........
.*********. .*********. .*********. .*********. .*********. ...........
.*********. .*********. .*********. .*********. .*********. ...........
.****[#000][#808000]N****. .*********. .*********. .*********. .*********. ...........
.*********. .*********. .*********. .*********. .*********. ...........
.*********. .*********. .*********. .*********. .*********. ...........
.*********. .*********. .*********. .*********. .*********. ...........
.*********. .*********. .*********. .*********. .*********. ...........
........... ........... ........... ........... ........... ...........}}

'''N''' = Origin of noise
* = Noise
. = No noise

== Avoiding unhappy thoughts caused by noise ==
* Don't dig near bedrooms when there are dwarves sleeping in them.
* Smooth your bedrooms before placing the actual furniture.

== Designing in anticipation of noise ==
* Putting all your bedrooms 8 levels or lower below ground eliminates noise from wood cutting (''and all other relevant noise related concerns, that being beside the point'').
* Remember that [[jail]]s, [[hospital]]s, and sleeping [[barracks]] should also ideally be kept away from noise, in addition to standard and noble bedrooms.

Facilities that ''can'' be safely built around or above/below bedrooms and other sleeping facilities, to separate the area set aside for the "quiet zone", include anything that does ''not'' make noise.

== In adventurer mode ==
In [[adventurer mode]], various noises that can be heard in unseen areas will be represented by exclamation marks of different colors. Double exclamation marks denote louder noises.

* {{Raw Tile|!|3:0:1}} {{Raw Tile|!|3:0:0}} {{Raw Tile|‼|3:0:1}} {{Raw Tile|‼|3:0:0}}: Talking.
* {{Raw Tile|!|6:0:1}} {{Raw Tile|!|6:0:0}} {{Raw Tile|‼|6:0:1}} {{Raw Tile|‼|6:0:0}}: Movement, such as walking or running.
* {{Raw Tile|!|4:0:1}} {{Raw Tile|!|4:0:0}} {{Raw Tile|‼|4:0:1}} {{Raw Tile|‼|4:0:0}}: [[Combat]].
* {{Raw Tile|!|2:0:1}} {{Raw Tile|!|2:0:0}} {{Raw Tile|‼|2:0:1}} {{Raw Tile|‼|2:0:0}}: Mechanical noises, such as from a [[lever]]-operated [[door]].

Most wildlife doesn't make any noise in adventurer mode, with a few exceptions such as [[capybara]]s and [[kakapo]]s.

<references />
{{Category|Fortress mode}}
{{Category|Physics}}
[[ru:Noise]]

Difficulty

2024-03-15T11:17:38Z

CobaltNinja: Adjusted article rating.

{{Quality|Fine}}
{{av}}
{{stub}}

While previous versions of ''Dwarf Fortress'' allowed you to toggle [[Invader|invaders]] on or off, v50 added more granular difficulty settings to fine-tune one's experience. Difficulty settings will affect whether your fortress can be attacked by outside forces, how frequent said attacks are, how big invading armies are, and [[noble]] neediness. You can modify these settings before and after embarking at any time.

== Default settings ==
'''Enemies''' has 3 options:
* '''Off''' will disable [[Ambush|ambushes]], [[Siege|sieges]], [[Megabeast|uninvited]] [[Forgotten beast|guests]], [[Werebeast|werebeasts]], and agitated wildlife attacks. It will not disable [[intrigue]], [[HFS]], or misbehaving dwarves, so it is still recommended to train a military.
* '''Normal''' is the standard ''Dwarf Fortress'' experience.
* '''Hard''' ensures a never-ending stream of [[Fun]], causing invaders to show up earlier, more often, and with more bodies to throw at the gates.
'''Economy''' has 2 options:
* '''Normal''' is the standard ''Dwarf Fortress'' economy.
* '''Hard''' requires you to produce more wealth in order to receive higher-ranking nobles, requires [[Temple|temples]] and [[Guildhall|guildhalls]] to be more valuable before satisfying petitions, and causes [[Noble|nobles]] to make more [[Mandate|mandates]] and [[Demand|demands]].

== Custom settings ==
If you wish, you can also fine-tune individual settings - maybe you only want megabeasts to assault your fortress, and would prefer the elves to leave well enough alone. The following options are available for enemy settings:
{| class="wikitable"
|-
! Setting !! Possible values !! Description !! Default values (Off, Normal, Hard)
|-
| Civilizations can attack || Yes/No || Controls whether [[Ambush|ambushes]] and [[Siege|sieges]] can occur. || No, Yes, Yes
|-
| Megabeasts can attack || Yes/No || Controls whether [[Megabeast|megabeasts]] and [[Forgotten beast|forgotten beasts]] can attack. || No, Yes, Yes
|-
| Werebeasts can attack || Yes/No || Controls whether [[Werebeast|werebeasts]] can attack. || No, Yes, Yes
|-
| Curious wilderness creatures can come to cause trouble || Yes/No || Controls whether agitated animals can assault your fortress, and whether animals will spawn with the intent to steal items. || No, Yes, Yes
|-
| Enemy population triggers || 1 to 300 || Likely affects when invasions occur, and how difficult they are. Met when you have this many citizens.{{verify}} || 0/0/0/0/0, 20/50/80/110/140, 15/30/40/55/70
|-
| Enemy production triggers || 0 to 100,000,000 || Likely affects when invasions occur, and how difficult they are. Met when you've created this much wealth.{{verify}} || 0/0/0/0/0, 5000/25000/100000/200000/300000, 2500/12500/50000/100000/150000
|-
| Enemy trade triggers || 0 to 100,000,000 || Likely affects when invasions occur, and how difficult they are. Met when you've exported this much wealth.{{verify}} || 0/0/0/0/0, 500/2500/10000/20000/30000, 250/1250/5000/10000/15000
|-
| Megabeast attack period (seasons) || 0 to 100 || How many seasons must pass before a megabeast may attack your fortress.{{verify}} || 10, 10, 8
|-
| Forgotten beast sensitivity || 1 to 100,000 || Performing nature-disrupting actions within the caverns will agitate forgotten beasts and may cause them to attack. [[Noise]] will also increase agitation. A smaller value will require less actions before the maximum attack chance is reached. || 10000, 10000, 10000
|-
| Forgotten beast irritation minimum || 1 to 100,000 || If the hidden agitation counter is at this value or below, no forgotten beasts will attack. || 5000, 5000, 2000
|-
| Forgotten beast wealth divisor || 1 to 100,000 || Your current fortress wealth is divided by this number - the result is added to effective irritation to determine forgotten beast attacks. A smaller number will cause forgotten beasts to attack sooner. || 40, 40, 40
|-
| Wilderness sensitivity || 1 to 100,000 || Performing nature-disrupting actions such as cutting down trees will agitate wildlife and may cause them to attack. A smaller value will require less actions before the maximum attack chance is reached. || 10000, 10000, 10000
|-
| Wilderness irritation minimum || 1 to 100,000 || If the hidden agitation counter is at this value or below, no agitated wildlife will spawn. || 2000, 2000, 0
|-
| Wilderness irritation decay || 0 to 100,000 || Causes wildlife to be less irritated after every year. A higher value will make them less irritated faster. Normal default values are 500 on '''Normal''' and 100 on '''Hard'''. Currently broken - changing this setting instead modifies the Minimum value above.{{bug|12181}} || 2000, 2000, 0
|-
| Werebeast attack period (seasons) || 0 to 100 || How many seasons must pass before a werebeast may attack your fortress.{{verify}} || 10, 10, 8
|-
| Vampire migrant fraction || 1 to 1,000 || Affects what percentage of new migrants will be [[Vampire|vampires]]. A value of 0 will disable vampiric migrants. (Only on '''Off''' difficulty) || 0, 100, 75
|-
| Invasion caps (regulars) || 0 to 500 || The maximum amount of humanoid enemies that can be thrown at you when a civilization sieges you.{{verify}} || 0/0/0, 10/40/120, 20/60/120
|-
| Invasion caps (monsters) || 0 to 500) || The maximum amount of mounts and other tamed creatures that can be thrown at you when a civilization sieges you.{{verify}} || 0/0/0, 0/5/40, 1/10/40
|-
| Minimum raids before first siege (per civ) || 0 to 500 || Affects how many [[Ambush|ambushes]] must be performed before a civilization can try a proper siege for the first time. || 0, 2, 2
|-
| Minimum raids between sieges (per civ) || 0 to 500 || Affects how many ambushes must be performed before a civilization can try a proper siege from the second time onwards. || 0, 3, 1
|-
| Siege frequency (percentage, otherwise raid) || 0 to 100 || Percentage chance to receive a siege instead of an ambush. || 0, 25, 50
|-
| Cavern dweller scale (increase per attack) || 0 to 100 || Every time cavern-dwellers attack your fortress, the maximum number of attackers increases by this number. || 0, 10, 20
|-
| Cavern dweller maximum attackers || 0 to 500 || The maximum amount of enemies that can be thrown at you when cavern dwellers attack. || 0, 50, 75
|-
| Diplomacy tree-fell count || 1 to 1000 || Affects the default amount of trees [[Elf|elven]] diplomats will request you limit your felling to. Your negotiator will still try and increase the tree limit. || 25, 25, 10
|-
| Diplomacy tree-fell count (untamed wilds) || 1 to 1000 || Affects the default amount of trees elven diplomats will request you limit your felling to if you've settled in a [[savage]] area instead. Your negotiator will still try and increase the tree limit. || 5, 5, 1
|}
The following options are available for economy settings:
{| class="wikitable"
|-
! Setting !! Possible values !! Description !! Default values (Normal, Hard)
|-
| Economy population triggers || 1 to 300 || Affects how many citizens you need to increase the rank of your fortress. Must meet population and one of production or trade. Triggers 1 through 5 correspond to Hamlet, Village, Town, City, and Metropolis. || 20/50/80/110/140, 20/50/80/110/140
|-
| Economy production triggers || 1 to 100,000,000 || Affects how much created wealth you need to increase the rank of your fortress. Must meet population and one of production or trade. Triggers 1 through 5 correspond to Hamlet, Village, Town, City, and Metropolis. Setting this trigger to 0 causes it to be met immediately. || 5000/25000/100000/200000/300000, 25000/125000/500000/1000000/1500000
|-
| Economy trade triggers || 1 to 100,000,000 || Affects how much exported wealth you need to increase the rank of your fortress. Must meet population and one of production or trade. Triggers 1 through 5 correspond to Hamlet, Village, Town, City, and Metropolis. Setting a trigger to 0 causes it to be met immediately. || 500/2500/10000/20000/30000, 2500/12500/50000/100000/150000
|-
| Land holder population triggers || 1 to 300 || Likely affects how [[Baron|barons]] and upwards are achieved.{{verify}} Values 4 through 10 are not used in the base game. || 20/20/20, 20/20/20
|-
| Land holder production triggers || 1 to 100,000,000 || Likely affects how barons and upwards are achieved.{{verify}} Values 4 through 10 are not used in the base game. || 10000/200000/300000, 500000/1000000/1500000
|-
| Land holder trade triggers || 1 to 100,000,000 || Likely affects how barons and upwards are achieved.{{verify}} Values 4 through 10 are not used in the base game. || 10000/20000/30000, 50000/100000/150000
|-
| Value of temple || 1 to 100,000,000 || Affects how valuable a designated [[temple]] zone must be before it satisfies a petition to create it. || 2000, 6000
|-
| Value of temple complex || 1 to 100,000,000 || Affects how valuable a designated temple zone must be before it satisfies a petition to upgrade it. || 10000, 30000
|-
| Priesthood unit count || 1 to 300 || Affects how many members of a religion must be citizens in your fortress before a petition for a temple is made. || 10, 10
|-
| High priesthood unit count || 1 to 300 || Affects how many members of a religion must be citizens in your fortress before a petition to upgrade an existing temple is made. || 25, 25
|-
| Value of guildhall || 1 to 100,000,000 || Affects how valuable a designated [[guildhall]] zone must be before it satisfies a petition to create it. || 2000, 6000
|-
| Value of grand guildhall || 1 to 100,000,000 || Affects how valuable a designated guildhall zone must be before it satisfies a petition to upgrade it. || 10000, 30000
|-
| Guild unit count || 1 to 300 || Affects how many members of a profession must be citizens in your fortress before a petition for a guildhall is made. || 10, 10
|-
| Grand guild unit count || 1 to 300 || Affects how many members of a profession must be citizens in your fortress before a petition to upgrade an existing guildhall is made. || 25, 25
|-
| Mandate period (more = fewer) || 1 to 10,000 || Affects how long nobles must wait before making new mandates. A higher value forces them to wait longer before mandating something.|| 1000, 500
|-
| Demand period (more = fewer) || 1 to 10,000 || Affects how long nobles must wait before making new demands. A higher value forces them to wait longer before making a demand.|| 500, 250
|}

Difficulty

2024-03-13T07:59:59Z

CobaltNinja: Link to noise page

{{Quality|Unknown}}
{{av}}
{{stub}}

While previous versions of ''Dwarf Fortress'' allowed you to toggle [[Invader|invaders]] on or off, v50 added more granular difficulty settings to fine-tune one's experience. Difficulty settings will affect whether your fortress can be attacked by outside forces, how frequent said attacks are, how big invading armies are, and [[noble]] neediness. You can modify these settings before and after embarking at any time.

== Default settings ==
'''Enemies''' has 3 options:
* '''Off''' will disable [[Ambush|ambushes]], [[Siege|sieges]], [[Megabeast|uninvited]] [[Forgotten beast|guests]], [[Werebeast|werebeasts]], and agitated wildlife attacks. It will not disable [[intrigue]], [[HFS]], or misbehaving dwarves, so it is still recommended to train a military.
* '''Normal''' is the standard ''Dwarf Fortress'' experience.
* '''Hard''' ensures a never-ending stream of [[Fun]], causing invaders to show up earlier, more often, and with more bodies to throw at the gates.
'''Economy''' has 2 options:
* '''Normal''' is the standard ''Dwarf Fortress'' economy.
* '''Hard''' requires you to produce more wealth in order to receive higher-ranking nobles, requires [[Temple|temples]] and [[Guildhall|guildhalls]] to be more valuable before satisfying petitions, and causes [[Noble|nobles]] to make more [[Mandate|mandates]] and [[Demand|demands]].

== Custom settings ==
If you wish, you can also fine-tune individual settings - maybe you only want megabeasts to assault your fortress, and would prefer the elves to leave well enough alone. The following options are available for enemy settings:
{| class="wikitable"
|-
! Setting !! Possible values !! Description !! Default values (Off, Normal, Hard)
|-
| Civilizations can attack || Yes/No || Controls whether [[Ambush|ambushes]] and [[Siege|sieges]] can occur. || No, Yes, Yes
|-
| Megabeasts can attack || Yes/No || Controls whether [[Megabeast|megabeasts]] and [[Forgotten beast|forgotten beasts]] can attack. || No, Yes, Yes
|-
| Werebeasts can attack || Yes/No || Controls whether [[Werebeast|werebeasts]] can attack. || No, Yes, Yes
|-
| Curious wilderness creatures can come to cause trouble || Yes/No || Controls whether agitated animals can assault your fortress, and whether animals will spawn with the intent to steal items. || No, Yes, Yes
|-
| Enemy population triggers || 1 to 300 || Likely affects when invasions occur, and how difficult they are. Met when you have this many citizens.{{verify}} || 0/0/0/0/0, 20/50/80/110/140, 15/30/40/55/70
|-
| Enemy production triggers || 0 to 100,000,000 || Likely affects when invasions occur, and how difficult they are. Met when you've created this much wealth.{{verify}} || 0/0/0/0/0, 5000/25000/100000/200000/300000, 2500/12500/50000/100000/150000
|-
| Enemy trade triggers || 0 to 100,000,000 || Likely affects when invasions occur, and how difficult they are. Met when you've exported this much wealth.{{verify}} || 0/0/0/0/0, 500/2500/10000/20000/30000, 250/1250/5000/10000/15000
|-
| Megabeast attack period (seasons) || 0 to 100 || How many seasons must pass before a megabeast may attack your fortress.{{verify}} || 10, 10, 8
|-
| Forgotten beast sensitivity || 1 to 100,000 || Performing nature-disrupting actions within the caverns will agitate forgotten beasts and may cause them to attack. [[Noise]] will also increase agitation. A smaller value will require less actions before the maximum attack chance is reached. || 10000, 10000, 10000
|-
| Forgotten beast irritation minimum || 1 to 100,000 || If the hidden agitation counter is at this value or below, no forgotten beasts will attack. || 5000, 5000, 2000
|-
| Forgotten beast wealth divisor || 1 to 100,000 || Your current fortress wealth is divided by this number - the result is added to effective irritation to determine forgotten beast attacks. A smaller number will cause forgotten beasts to attack sooner. || 40, 40, 40
|-
| Wilderness sensitivity || 1 to 100,000 || Performing nature-disrupting actions such as cutting down trees will agitate wildlife and may cause them to attack. A smaller value will require less actions before the maximum attack chance is reached. || 10000, 10000, 10000
|-
| Wilderness irritation minimum || 1 to 100,000 || If the hidden agitation counter is at this value or below, no agitated wildlife will spawn. || 2000, 2000, 0
|-
| Wilderness irritation decay || 0 to 100,000 || Causes wildlife to be less irritated after every year. A higher value will make them less irritated faster. Normal default values are 500 on '''Normal''' and 100 on '''Hard'''. Currently broken - changing this setting instead modifies the Minimum value above.{{bug|12181}} || 2000, 2000, 0
|-
| Werebeast attack period (seasons) || 0 to 100 || How many seasons must pass before a werebeast may attack your fortress.{{verify}} || 10, 10, 8
|-
| Vampire migrant fraction || 1 to 1,000 || Affects what percentage of new migrants will be [[Vampire|vampires]]. A value of 0 will disable vampiric migrants. (Only on '''Off''' difficulty) || 0, 100, 75
|-
| Invasion caps (regulars) || 0 to 500 || The maximum amount of humanoid enemies that can be thrown at you when a civilization sieges you.{{verify}} || 0/0/0, 10/40/120, 20/60/120
|-
| Invasion caps (monsters) || 0 to 500) || The maximum amount of mounts and other tamed creatures that can be thrown at you when a civilization sieges you.{{verify}} || 0/0/0, 0/5/40, 1/10/40
|-
| Minimum raids before first siege (per civ) || 0 to 500 || Affects how many [[Ambush|ambushes]] must be performed before a civilization can try a proper siege for the first time. || 0, 2, 2
|-
| Minimum raids between sieges (per civ) || 0 to 500 || Affects how many ambushes must be performed before a civilization can try a proper siege from the second time onwards. || 0, 3, 1
|-
| Siege frequency (percentage, otherwise raid) || 0 to 100 || Percentage chance to receive a siege instead of an ambush. || 0, 25, 50
|-
| Cavern dweller scale (increase per attack) || 0 to 100 || Every time cavern-dwellers attack your fortress, the maximum number of attackers increases by this number. || 0, 10, 20
|-
| Cavern dweller maximum attackers || 0 to 500 || The maximum amount of enemies that can be thrown at you when cavern dwellers attack. || 0, 50, 75
|-
| Diplomacy tree-fell count || 1 to 1000 || Affects the default amount of trees [[Elf|elven]] diplomats will request you limit your felling to. Your negotiator will still try and increase the tree limit. || 25, 25, 10
|-
| Diplomacy tree-fell count (untamed wilds) || 1 to 1000 || Affects the default amount of trees elven diplomats will request you limit your felling to if you've settled in a [[savage]] area instead. Your negotiator will still try and increase the tree limit. || 5, 5, 1
|}
The following options are available for economy settings:
{| class="wikitable"
|-
! Setting !! Possible values !! Description !! Default values (Normal, Hard)
|-
| Economy population triggers || 1 to 300 || Affects how many citizens you need to increase the rank of your fortress. Must meet population and one of production or trade. Triggers 1 through 5 correspond to Hamlet, Village, Town, City, and Metropolis. || 20/50/80/110/140, 20/50/80/110/140
|-
| Economy production triggers || 1 to 100,000,000 || Affects how much created wealth you need to increase the rank of your fortress. Must meet population and one of production or trade. Triggers 1 through 5 correspond to Hamlet, Village, Town, City, and Metropolis. Setting this trigger to 0 causes it to be met immediately. || 5000/25000/100000/200000/300000, 25000/125000/500000/1000000/1500000
|-
| Economy trade triggers || 1 to 100,000,000 || Affects how much exported wealth you need to increase the rank of your fortress. Must meet population and one of production or trade. Triggers 1 through 5 correspond to Hamlet, Village, Town, City, and Metropolis. Setting a trigger to 0 causes it to be met immediately. || 500/2500/10000/20000/30000, 2500/12500/50000/100000/150000
|-
| Land holder population triggers || 1 to 300 || Likely affects how [[Baron|barons]] and upwards are achieved.{{verify}} Values 4 through 10 are not used in the base game. || 20/20/20, 20/20/20
|-
| Land holder production triggers || 1 to 100,000,000 || Likely affects how barons and upwards are achieved.{{verify}} Values 4 through 10 are not used in the base game. || 10000/200000/300000, 500000/1000000/1500000
|-
| Land holder trade triggers || 1 to 100,000,000 || Likely affects how barons and upwards are achieved.{{verify}} Values 4 through 10 are not used in the base game. || 10000/20000/30000, 50000/100000/150000
|-
| Value of temple || 1 to 100,000,000 || Affects how valuable a designated [[temple]] zone must be before it satisfies a petition to create it. || 2000, 6000
|-
| Value of temple complex || 1 to 100,000,000 || Affects how valuable a designated temple zone must be before it satisfies a petition to upgrade it. || 10000, 30000
|-
| Priesthood unit count || 1 to 300 || Affects how many members of a religion must be citizens in your fortress before a petition for a temple is made. || 10, 10
|-
| High priesthood unit count || 1 to 300 || Affects how many members of a religion must be citizens in your fortress before a petition to upgrade an existing temple is made. || 25, 25
|-
| Value of guildhall || 1 to 100,000,000 || Affects how valuable a designated [[guildhall]] zone must be before it satisfies a petition to create it. || 2000, 6000
|-
| Value of grand guildhall || 1 to 100,000,000 || Affects how valuable a designated guildhall zone must be before it satisfies a petition to upgrade it. || 10000, 30000
|-
| Guild unit count || 1 to 300 || Affects how many members of a profession must be citizens in your fortress before a petition for a guildhall is made. || 10, 10
|-
| Grand guild unit count || 1 to 300 || Affects how many members of a profession must be citizens in your fortress before a petition to upgrade an existing guildhall is made. || 25, 25
|-
| Mandate period (more = fewer) || 1 to 10,000 || Affects how long nobles must wait before making new mandates. A higher value forces them to wait longer before mandating something.|| 1000, 500
|-
| Demand period (more = fewer) || 1 to 10,000 || Affects how long nobles must wait before making new demands. A higher value forces them to wait longer before making a demand.|| 500, 250
|}

Difficulty

2024-03-13T06:35:06Z

CobaltNinja: /* Custom settings */ Corrections regarding forgotten beast difficulty variables - they do not affect cavern-dwellers.

{{Quality|Unknown}}
{{av}}
{{stub}}

While previous versions of ''Dwarf Fortress'' allowed you to toggle [[Invader|invaders]] on or off, v50 added more granular difficulty settings to fine-tune one's experience. Difficulty settings will affect whether your fortress can be attacked by outside forces, how frequent said attacks are, how big invading armies are, and [[noble]] neediness. You can modify these settings before and after embarking at any time.

== Default settings ==
'''Enemies''' has 3 options:
* '''Off''' will disable [[Ambush|ambushes]], [[Siege|sieges]], [[Megabeast|uninvited]] [[Forgotten beast|guests]], [[Werebeast|werebeasts]], and agitated wildlife attacks. It will not disable [[intrigue]], [[HFS]], or misbehaving dwarves, so it is still recommended to train a military.
* '''Normal''' is the standard ''Dwarf Fortress'' experience.
* '''Hard''' ensures a never-ending stream of [[Fun]], causing invaders to show up earlier, more often, and with more bodies to throw at the gates.
'''Economy''' has 2 options:
* '''Normal''' is the standard ''Dwarf Fortress'' economy.
* '''Hard''' requires you to produce more wealth in order to receive higher-ranking nobles, requires [[Temple|temples]] and [[Guildhall|guildhalls]] to be more valuable before satisfying petitions, and causes [[Noble|nobles]] to make more [[Mandate|mandates]] and [[Demand|demands]].

== Custom settings ==
If you wish, you can also fine-tune individual settings - maybe you only want megabeasts to assault your fortress, and would prefer the elves to leave well enough alone. The following options are available for enemy settings:
{| class="wikitable"
|-
! Setting !! Possible values !! Description !! Default values (Off, Normal, Hard)
|-
| Civilizations can attack || Yes/No || Controls whether [[Ambush|ambushes]] and [[Siege|sieges]] can occur. || No, Yes, Yes
|-
| Megabeasts can attack || Yes/No || Controls whether [[Megabeast|megabeasts]] and [[Forgotten beast|forgotten beasts]] can attack. || No, Yes, Yes
|-
| Werebeasts can attack || Yes/No || Controls whether [[Werebeast|werebeasts]] can attack. || No, Yes, Yes
|-
| Curious wilderness creatures can come to cause trouble || Yes/No || Controls whether agitated animals can assault your fortress, and whether animals will spawn with the intent to steal items. || No, Yes, Yes
|-
| Enemy population triggers || 1 to 300 || Likely affects when invasions occur, and how difficult they are. Met when you have this many citizens.{{verify}} || 0/0/0/0/0, 20/50/80/110/140, 15/30/40/55/70
|-
| Enemy production triggers || 0 to 100,000,000 || Likely affects when invasions occur, and how difficult they are. Met when you've created this much wealth.{{verify}} || 0/0/0/0/0, 5000/25000/100000/200000/300000, 2500/12500/50000/100000/150000
|-
| Enemy trade triggers || 0 to 100,000,000 || Likely affects when invasions occur, and how difficult they are. Met when you've exported this much wealth.{{verify}} || 0/0/0/0/0, 500/2500/10000/20000/30000, 250/1250/5000/10000/15000
|-
| Megabeast attack period (seasons) || 0 to 100 || How many seasons must pass before a megabeast may attack your fortress.{{verify}} || 10, 10, 8
|-
| Forgotten beast sensitivity || 1 to 100,000 || Performing nature-disrupting actions within the caverns will agitate forgotten beasts and may cause them to attack. Noise will also increase agitation. A smaller value will require less actions before the maximum attack chance is reached. || 10000, 10000, 10000
|-
| Forgotten beast irritation minimum || 1 to 100,000 || If the hidden agitation counter is at this value or below, no forgotten beasts will attack. || 5000, 5000, 2000
|-
| Forgotten beast wealth divisor || 1 to 100,000 || Your current fortress wealth is divided by this number - the result is added to effective irritation to determine forgotten beast attacks. A smaller number will cause forgotten beasts to attack sooner. || 40, 40, 40
|-
| Wilderness sensitivity || 1 to 100,000 || Performing nature-disrupting actions such as cutting down trees will agitate wildlife and may cause them to attack. A smaller value will require less actions before the maximum attack chance is reached. || 10000, 10000, 10000
|-
| Wilderness irritation minimum || 1 to 100,000 || If the hidden agitation counter is at this value or below, no agitated wildlife will spawn. || 2000, 2000, 0
|-
| Wilderness irritation decay || 0 to 100,000 || Causes wildlife to be less irritated after every year. A higher value will make them less irritated faster. Normal default values are 500 on '''Normal''' and 100 on '''Hard'''. Currently broken - changing this setting instead modifies the Minimum value above.{{bug|12181}} || 2000, 2000, 0
|-
| Werebeast attack period (seasons) || 0 to 100 || How many seasons must pass before a werebeast may attack your fortress.{{verify}} || 10, 10, 8
|-
| Vampire migrant fraction || 1 to 1,000 || Affects what percentage of new migrants will be [[Vampire|vampires]]. A value of 0 will disable vampiric migrants. (Only on '''Off''' difficulty) || 0, 100, 75
|-
| Invasion caps (regulars) || 0 to 500 || The maximum amount of humanoid enemies that can be thrown at you when a civilization sieges you.{{verify}} || 0/0/0, 10/40/120, 20/60/120
|-
| Invasion caps (monsters) || 0 to 500) || The maximum amount of mounts and other tamed creatures that can be thrown at you when a civilization sieges you.{{verify}} || 0/0/0, 0/5/40, 1/10/40
|-
| Minimum raids before first siege (per civ) || 0 to 500 || Affects how many [[Ambush|ambushes]] must be performed before a civilization can try a proper siege for the first time. || 0, 2, 2
|-
| Minimum raids between sieges (per civ) || 0 to 500 || Affects how many ambushes must be performed before a civilization can try a proper siege from the second time onwards. || 0, 3, 1
|-
| Siege frequency (percentage, otherwise raid) || 0 to 100 || Percentage chance to receive a siege instead of an ambush. || 0, 25, 50
|-
| Cavern dweller scale (increase per attack) || 0 to 100 || Every time cavern-dwellers attack your fortress, the maximum number of attackers increases by this number. || 0, 10, 20
|-
| Cavern dweller maximum attackers || 0 to 500 || The maximum amount of enemies that can be thrown at you when cavern dwellers attack. || 0, 50, 75
|-
| Diplomacy tree-fell count || 1 to 1000 || Affects the default amount of trees [[Elf|elven]] diplomats will request you limit your felling to. Your negotiator will still try and increase the tree limit. || 25, 25, 10
|-
| Diplomacy tree-fell count (untamed wilds) || 1 to 1000 || Affects the default amount of trees elven diplomats will request you limit your felling to if you've settled in a [[savage]] area instead. Your negotiator will still try and increase the tree limit. || 5, 5, 1
|}
The following options are available for economy settings:
{| class="wikitable"
|-
! Setting !! Possible values !! Description !! Default values (Normal, Hard)
|-
| Economy population triggers || 1 to 300 || Affects how many citizens you need to increase the rank of your fortress. Must meet population and one of production or trade. Triggers 1 through 5 correspond to Hamlet, Village, Town, City, and Metropolis. || 20/50/80/110/140, 20/50/80/110/140
|-
| Economy production triggers || 1 to 100,000,000 || Affects how much created wealth you need to increase the rank of your fortress. Must meet population and one of production or trade. Triggers 1 through 5 correspond to Hamlet, Village, Town, City, and Metropolis. Setting this trigger to 0 causes it to be met immediately. || 5000/25000/100000/200000/300000, 25000/125000/500000/1000000/1500000
|-
| Economy trade triggers || 1 to 100,000,000 || Affects how much exported wealth you need to increase the rank of your fortress. Must meet population and one of production or trade. Triggers 1 through 5 correspond to Hamlet, Village, Town, City, and Metropolis. Setting a trigger to 0 causes it to be met immediately. || 500/2500/10000/20000/30000, 2500/12500/50000/100000/150000
|-
| Land holder population triggers || 1 to 300 || Likely affects how [[Baron|barons]] and upwards are achieved.{{verify}} Values 4 through 10 are not used in the base game. || 20/20/20, 20/20/20
|-
| Land holder production triggers || 1 to 100,000,000 || Likely affects how barons and upwards are achieved.{{verify}} Values 4 through 10 are not used in the base game. || 10000/200000/300000, 500000/1000000/1500000
|-
| Land holder trade triggers || 1 to 100,000,000 || Likely affects how barons and upwards are achieved.{{verify}} Values 4 through 10 are not used in the base game. || 10000/20000/30000, 50000/100000/150000
|-
| Value of temple || 1 to 100,000,000 || Affects how valuable a designated [[temple]] zone must be before it satisfies a petition to create it. || 2000, 6000
|-
| Value of temple complex || 1 to 100,000,000 || Affects how valuable a designated temple zone must be before it satisfies a petition to upgrade it. || 10000, 30000
|-
| Priesthood unit count || 1 to 300 || Affects how many members of a religion must be citizens in your fortress before a petition for a temple is made. || 10, 10
|-
| High priesthood unit count || 1 to 300 || Affects how many members of a religion must be citizens in your fortress before a petition to upgrade an existing temple is made. || 25, 25
|-
| Value of guildhall || 1 to 100,000,000 || Affects how valuable a designated [[guildhall]] zone must be before it satisfies a petition to create it. || 2000, 6000
|-
| Value of grand guildhall || 1 to 100,000,000 || Affects how valuable a designated guildhall zone must be before it satisfies a petition to upgrade it. || 10000, 30000
|-
| Guild unit count || 1 to 300 || Affects how many members of a profession must be citizens in your fortress before a petition for a guildhall is made. || 10, 10
|-
| Grand guild unit count || 1 to 300 || Affects how many members of a profession must be citizens in your fortress before a petition to upgrade an existing guildhall is made. || 25, 25
|-
| Mandate period (more = fewer) || 1 to 10,000 || Affects how long nobles must wait before making new mandates. A higher value forces them to wait longer before mandating something.|| 1000, 500
|-
| Demand period (more = fewer) || 1 to 10,000 || Affects how long nobles must wait before making new demands. A higher value forces them to wait longer before making a demand.|| 500, 250
|}

Difficulty

2024-03-12T12:29:30Z

CobaltNinja: Updated information for wilderness agitation and cavern attacks due to information release by the DFHack team (see https://docs.dfhack.org/en/latest/docs/tools/agitation-rebalance.html#how-the-df-agitation-system-works)

{{Quality|Unknown}}
{{av}}
{{stub}}

While previous versions of ''Dwarf Fortress'' allowed you to toggle [[Invader|invaders]] on or off, v50 added more granular difficulty settings to fine-tune one's experience. Difficulty settings will affect whether your fortress can be attacked by outside forces, how frequent said attacks are, how big invading armies are, and [[noble]] neediness. You can modify these settings before and after embarking at any time.

== Default settings ==
'''Enemies''' has 3 options:
* '''Off''' will disable [[Ambush|ambushes]], [[Siege|sieges]], [[Megabeast|uninvited]] [[Forgotten beast|guests]], [[Werebeast|werebeasts]], and agitated wildlife attacks. It will not disable [[intrigue]], [[HFS]], or misbehaving dwarves, so it is still recommended to train a military.
* '''Normal''' is the standard ''Dwarf Fortress'' experience.
* '''Hard''' ensures a never-ending stream of [[Fun]], causing invaders to show up earlier, more often, and with more bodies to throw at the gates.
'''Economy''' has 2 options:
* '''Normal''' is the standard ''Dwarf Fortress'' economy.
* '''Hard''' requires you to produce more wealth in order to receive higher-ranking nobles, requires [[Temple|temples]] and [[Guildhall|guildhalls]] to be more valuable before satisfying petitions, and causes [[Noble|nobles]] to make more [[Mandate|mandates]] and [[Demand|demands]].

== Custom settings ==
If you wish, you can also fine-tune individual settings - maybe you only want megabeasts to assault your fortress, and would prefer the elves to leave well enough alone. The following options are available for enemy settings:
{| class="wikitable"
|-
! Setting !! Possible values !! Description !! Default values (Off, Normal, Hard)
|-
| Civilizations can attack || Yes/No || Controls whether [[Ambush|ambushes]] and [[Siege|sieges]] can occur. || No, Yes, Yes
|-
| Megabeasts can attack || Yes/No || Controls whether [[Megabeast|megabeasts]] and [[Forgotten beast|forgotten beasts]] can attack. || No, Yes, Yes
|-
| Werebeasts can attack || Yes/No || Controls whether [[Werebeast|werebeasts]] can attack. || No, Yes, Yes
|-
| Curious wilderness creatures can come to cause trouble || Yes/No || Controls whether agitated animals can assault your fortress, and whether animals will spawn with the intent to steal items. || No, Yes, Yes
|-
| Enemy population triggers || 1 to 300 || Likely affects when invasions occur, and how difficult they are. Met when you have this many citizens.{{verify}} || 0/0/0/0/0, 20/50/80/110/140, 15/30/40/55/70
|-
| Enemy production triggers || 0 to 100,000,000 || Likely affects when invasions occur, and how difficult they are. Met when you've created this much wealth.{{verify}} || 0/0/0/0/0, 5000/25000/100000/200000/300000, 2500/12500/50000/100000/150000
|-
| Enemy trade triggers || 0 to 100,000,000 || Likely affects when invasions occur, and how difficult they are. Met when you've exported this much wealth.{{verify}} || 0/0/0/0/0, 500/2500/10000/20000/30000, 250/1250/5000/10000/15000
|-
| Megabeast attack period (seasons) || 0 to 100 || How many seasons must pass before a megabeast may attack your fortress.{{verify}} || 10, 10, 8
|-
| Forgotten beast sensitivity || 1 to 100,000 || Performing nature-disrupting actions within the caverns will agitate cavern-dwellers and may cause them to attack. Despite the name, this value controls both cavern-dweller invasions '''and''' forgotten beasts. A smaller value will require less actions before the maximum attack chance is reached. || 10000, 10000, 10000
|-
| Forgotten beast irritation minimum || 1 to 100,000 || If the hidden agitation counter is at this value or below, no cavern-dwellers or forgotten beasts will attack. || 5000, 5000, 2000
|-
| Forgotten beast wealth divisor || 1 to 100,000 || Your current fortress wealth is divided by this number - the result is added to effective irritation to determine cavern-dweller and forgotten beast attacks. A smaller number will cause cavern-dwellers and forgotten beasts to attack sooner. || 40, 40, 40
|-
| Wilderness sensitivity || 1 to 100,000 || Performing nature-disrupting actions such as cutting down trees will agitate wildlife and may cause them to attack. A smaller value will require less actions before the maximum attack chance is reached. || 10000, 10000, 10000
|-
| Wilderness irritation minimum || 1 to 100,000 || If the hidden agitation counter is at this value or below, no agitated wildlife will spawn. || 2000, 2000, 0
|-
| Wilderness irritation decay || 0 to 100,000 || Causes wildlife to be less irritated after every year. A higher value will make them less irritated faster. Normal default values are 500 on '''Normal''' and 100 on '''Hard'''. However, the setting actually controls irritation minimum due to a bug. || 2000, 2000, 0
|-
| Werebeast attack period (seasons) || 0 to 100 || How many seasons must pass before a werebeast may attack your fortress.{{verify}} || 10, 10, 8
|-
| Vampire migrant fraction || 1 to 1,000 || Affects what percentage of new migrants will be [[Vampire|vampires]]. A value of 0 will disable vampiric migrants. (Only on '''Off''' difficulty) || 0, 100, 75
|-
| Invasion caps (regulars) || 0 to 500 || The maximum amount of humanoid enemies that can be thrown at you when a civilization sieges you.{{verify}} || 0/0/0, 10/40/120, 20/60/120
|-
| Invasion caps (monsters) || 0 to 500) || The maximum amount of mounts and other tamed creatures that can be thrown at you when a civilization sieges you.{{verify}} || 0/0/0, 0/5/40, 1/10/40
|-
| Minimum raids before first siege (per civ) || 0 to 500 || Affects how many [[Ambush|ambushes]] must be performed before a civilization can try a proper siege for the first time. || 0, 2, 2
|-
| Minimum raids between sieges (per civ) || 0 to 500 || Affects how many ambushes must be performed before a civilization can try a proper siege from the second time onwards. || 0, 3, 1
|-
| Siege frequency (percentage, otherwise raid) || 0 to 100 || Percentage chance to receive a siege instead of an ambush. || 0, 25, 50
|-
| Cavern dweller scale (increase per attack) || 0 to 100 || Every time cavern-dwellers attack your fortress, the maximum number of attackers increases by this number. || 0, 10, 20
|-
| Cavern dweller maximum attackers || 0 to 500 || The maximum amount of enemies that can be thrown at you when cavern dwellers attack. || 0, 50, 75
|-
| Diplomacy tree-fell count || 1 to 1000 || Affects the default amount of trees [[Elf|elven]] diplomats will request you limit your felling to. Your negotiator will still try and increase the tree limit. || 25, 25, 10
|-
| Diplomacy tree-fell count (untamed wilds) || 1 to 1000 || Affects the default amount of trees elven diplomats will request you limit your felling to if you've settled in a [[savage]] area instead. Your negotiator will still try and increase the tree limit. || 5, 5, 1
|}
The following options are available for economy settings:
{| class="wikitable"
|-
! Setting !! Possible values !! Description !! Default values (Normal, Hard)
|-
| Economy population triggers || 1 to 300 || Affects how many citizens you need to increase the rank of your fortress. Must meet population and one of production or trade. Triggers 1 through 5 correspond to Hamlet, Village, Town, City, and Metropolis. || 20/50/80/110/140, 20/50/80/110/140
|-
| Economy production triggers || 1 to 100,000,000 || Affects how much created wealth you need to increase the rank of your fortress. Must meet population and one of production or trade. Triggers 1 through 5 correspond to Hamlet, Village, Town, City, and Metropolis. Setting this trigger to 0 causes it to be met immediately. || 5000/25000/100000/200000/300000, 25000/125000/500000/1000000/1500000
|-
| Economy trade triggers || 1 to 100,000,000 || Affects how much exported wealth you need to increase the rank of your fortress. Must meet population and one of production or trade. Triggers 1 through 5 correspond to Hamlet, Village, Town, City, and Metropolis. Setting a trigger to 0 causes it to be met immediately. || 500/2500/10000/20000/30000, 2500/12500/50000/100000/150000
|-
| Land holder population triggers || 1 to 300 || Likely affects how [[Baron|barons]] and upwards are achieved.{{verify}} Values 4 through 10 are not used in the base game. || 20/20/20, 20/20/20
|-
| Land holder production triggers || 1 to 100,000,000 || Likely affects how barons and upwards are achieved.{{verify}} Values 4 through 10 are not used in the base game. || 10000/200000/300000, 500000/1000000/1500000
|-
| Land holder trade triggers || 1 to 100,000,000 || Likely affects how barons and upwards are achieved.{{verify}} Values 4 through 10 are not used in the base game. || 10000/20000/30000, 50000/100000/150000
|-
| Value of temple || 1 to 100,000,000 || Affects how valuable a designated [[temple]] zone must be before it satisfies a petition to create it. || 2000, 6000
|-
| Value of temple complex || 1 to 100,000,000 || Affects how valuable a designated temple zone must be before it satisfies a petition to upgrade it. || 10000, 30000
|-
| Priesthood unit count || 1 to 300 || Affects how many members of a religion must be citizens in your fortress before a petition for a temple is made. || 10, 10
|-
| High priesthood unit count || 1 to 300 || Affects how many members of a religion must be citizens in your fortress before a petition to upgrade an existing temple is made. || 25, 25
|-
| Value of guildhall || 1 to 100,000,000 || Affects how valuable a designated [[guildhall]] zone must be before it satisfies a petition to create it. || 2000, 6000
|-
| Value of grand guildhall || 1 to 100,000,000 || Affects how valuable a designated guildhall zone must be before it satisfies a petition to upgrade it. || 10000, 30000
|-
| Guild unit count || 1 to 300 || Affects how many members of a profession must be citizens in your fortress before a petition for a guildhall is made. || 10, 10
|-
| Grand guild unit count || 1 to 300 || Affects how many members of a profession must be citizens in your fortress before a petition to upgrade an existing guildhall is made. || 25, 25
|-
| Mandate period (more = fewer) || 1 to 10,000 || Affects how long nobles must wait before making new mandates. A higher value forces them to wait longer before mandating something.|| 1000, 500
|-
| Demand period (more = fewer) || 1 to 10,000 || Affects how long nobles must wait before making new demands. A higher value forces them to wait longer before making a demand.|| 500, 250
|}

Advanced entity position mechanics

2023-12-25T12:07:54Z

CobaltNinja: /* Position levels (Site/Civ) and their interaction */ Fixed grammatical error

{{Quality|Fine}}
{{Modding}}

= Introduction =

[http://www.bay12forums.com/smf/index.php?topic=182239.0 Discussion thread on the forum]

This article is the result of an investigation into the mechanisms involved in entity positions. It can be useful for modders or advanced players to understand how this part of ''Dwarf Fortress'' works.

==What is an entity?==
An entity is an organizational structure. It can have relationships with other entities. An entity is usually known as a [[civilization]] or a "site government", but merchant guilds, religious organizations, and bandit groups are also entities. An entity can have positions. In most cases these are hardcoded and generated by the game, but with civilizations and sites they can be customized with the raw entities.

==What is a position?==
A position is a special relationship between a unit and an entity. The unit holding a position has a larger influence over that entity as other citizens. Positions are mostly known as [[nobles]], but in this article the technical term is used.

=Position levels (Site/Civ) and their interaction=
There are two basic types of positions that are customizable: '''civ(ilization)''' level and '''site level'''. Positions with the tag [SITE] are at site level, positions without the tag [SITE] are at 'civ level'. These two types of nobles can be considered '''loosely related systems'''. There are a few places where they can interact with each other.

Civ-level positions are in charge of the civilization as a whole, managing national trade, laws, and wars. These are, for example, the vanilla [[monarch]], [[princes]], [[diplomat]] and [[general]].

'''LAND_HOLDERS''' nobles are also positions at civ-level. These units are members of the national government, but have gained hold over some land or site. Once they do, they move to that place, but their position is still regarded as a civ-level position.

Site-level position holders are members of a site government (subsidiary to the civilization), and manage local affairs in that location. These are, for example, the [[mayor]], the [[sheriff]] and the [[broker]].
==Table of interaction between different position-levels==
In this table, the possible interactions between different position levels are summarized.
The header row shows the positions defining the tokens.

The left column shows the position type that is referred.
Example:
{| {{prettytable}}
|- bgcolor="#ddd"
! referred position-type
! LAND_HOLDER
|-
| civilization
| (baron is) APPOINTED_BY:MONARCH
|}
color coding: 
* Exists in vanilla
* Possible in mods
* Not possible
* possible to some extend.
* not yet fully investigated.
{| {{prettytable}}
|- bgcolor="#ddd"
! referred position-type
! Civilization
! SITE
! LAND_HOLDER
! CONQUERED_SITE

|-
| civilization
| APPOINTED_BY COMMANDER REPLACED_BY SUCCESSION
| APPOINTED_BY COMMANDER REPLACED_BY SUCCESSION '''(1)'''
| APPOINTED_BY COMMANDER REPLACED_BY SUCCESSION
| APPOINTED_BY COMMANDER REPLACED_BY SUCCESSION

|-
| SITE
| APPOINTED_BY COMMANDER REPLACED_BY SUCCESSION '''(2)'''
| APPOINTED_BY COMMANDER REPLACED_BY SUCCESSION
| APPOINTED_BY '''(3)''' COMMANDER REPLACED_BY SUCCESSION '''(4)'''
| APPOINTED_BY COMMANDER REPLACED_BY SUCCESSION

|-
| LAND_HOLDER
| APPOINTED_BY COMMANDER REPLACED_BY '''(6)''' SUCCESSION
| APPOINTED_BY COMMANDER REPLACED_BY SUCCESSION '''(5)'''
| APPOINTED_BY COMMANDER REPLACED_BY '''(7)''' SUCCESSION '''(8)'''
| APPOINTED_BY COMMANDER REPLACED_BY SUCCESSION

|-
| CONQUERED_SITE
| APPOINTED_BY COMMANDER REPLACED_BY SUCCESSION
| APPOINTED_BY COMMANDER REPLACED_BY SUCCESSION
| APPOINTED_BY COMMANDER REPLACED_BY SUCCESSION
| APPOINTED_BY COMMANDER REPLACED_BY SUCCESSION
|}

Remarks:
# Works only in world-gen, if an unit with that civ-position is present at the site.
# Works only in world-gen, the site-position holding unit will then move to the capital.
# is completely ignored
# Works only in world-gen.
# Works only in world-gen.
# wont appear at all
# This is neccesary for the landholder-chain to work property. It doensn't work otherwise.
# This works only outsite of the landholder-chain, so when landholders are simply regarded as civ-level nobles. might also work in world-gen
#

==Civ-level nobles living at your site==
Nobles from your civilization can come to live at your fortress. This happens in vanilla with landholders such as [[Baron]], [[Count]] and [[Duke]], with the Monarch, but sometimes also with non-landed LAND_HOLDERS.

When a civ-level noble becomes a citizen at your location, his position is shown among the site-level positions in your [[nobles screen]]. They appear to function as a site-level noble. They may have demands, mandates, squads and the like. They can appoint nobles at the site-level.

If they have certain RESPONSIBILITY's, they do the tasks that go with them.

=General=
==Fortress-mode, world-gen and their differences==
Their are a few differences in how positions function, between fortress-mode (normal play-mode) and the world generation (world-gen).

In '''fortress-mode''', the player has some control over the appointment of nobles, limited by elections, automatic filled-in positions and succession rules. Pre-fortress mode, which is refered to as '''world-gen''', the game will always attempt to assign nobles whenever possible. It is subjected to the same rules as in fortress-mode, but there are some exceptions. In '''World Automation''', which is the thing that happens in the world while you play fortress mode, it seems as if the same rules are applied as fortress mode.

A difference between Player-fortress-mode and world-gen, is causes by visibility (see below). Positions that are not visible by the player and thus not available for assignment, will be available in world-gen and will thus be automatically assigned.

In fortress mode, a position that is both ELECTED and APPOINTED_BY, cannot be appointed by the player and is also not elected, and can thus not be filled. But in world-gen sites however, these positions are automatically filled.

Positions with AS_NEEDED are almost never created and filled in world-gen (depending on its RESPONSIBILITY's), but can always be used in player mode.

A positions can in fortress mode be filled by the same unit. A unit can gain multiple positions in fortess-mode, for example because of [[elections]]. This will not happen in world-gen mode: a unit can only have one position. See also remarks on 'embark' and 'Loosing a position'.

In world-gen, SUCCESSION between civ-levels en SITE-levels may happen. This will not happen in fortress-mode, or even off-site in World Automation.

In fortress-mode, premature SUCCESSION may happen. This will not happen in world-gen-mode.

==Units holding multiple positions (in multiple entities)==
A unit can hold multiple positions in its civilisation OR site-entity, however this does not happen in world-gen. Only at player-managed sites units can be holding multiple positions at once. (It is probably not possible for a unit to hold a position in two different civilisations or two different sites. )

In world-gen, if there are too many positions to be filled, they simply stay empty until more units are available.

In world-gen, a unit at a site might inherit a civ-level position and still remains a member of the local government. When this happens however, they move to the capital.

In world-gen, if a unit gains a new position, either inherited or otherwise, it drops the previous one. If a unit assumes a civ-position in fortress mode, it leaves the current position.

If a unit holds the same (site-)position multiple times, it has no additional effect.

If a unit holds multiple different positions of the same entity, he has all those positions responsibilities and properties stacked up. It is presumable that the demands for those combined positions are determined by the highest.

A unit holding a position with a succession-token CAN be assigned another position with a (different) succession-token.

A unit holding a position with a squad-position cannot hold another squad-position. It is dropped from the first, when it gets its second assigned.
A unit holding a position with a succession-token cannot be assigned to a squad-position. The unit is simply not available. It works the other way around, though.

=RESPONSIBILITY=
If a civ-noble having certain responsibilities arrives at a site and start to live there, it will perform the tasks coming with that responsibility. This means that a civ-manager will do management while he's a citizen of your fortress.

The only AS_NEEDED-position that is created in world-gen is that of the responsibility DELIVERS_MESSAGES, of a site level.

==World-gen effects of the RESPONSIBILITY of available positions ==
It is possible to cause civs and individual sites to change their behavior substantially when they reach a certain size by controlling nobles.
* If a site can only appoint a position with [MILITARY_GOALS] after reaching a particular size, that site will not send armies on missions until the required size is reached.
* A civ-level LAW_MAKING position is required for the civilization to have any kind of cohesion. Without it, sites will be constantly embroiled in territorial disputes and civil wars will be commonplace.
* MILITARY_STRATEGY positions go out and tame wild animals. This makes your civ gain those animals as domesticated and also brings them in sieges.

=Availability and visibility=
==Availability of (new) positions==
Warning: Do not mistake "availability" for "visibility"!

Of all the possible positions existing in your site's entity, there may only be some available.
* Positions with [REQUIRES_POPULATION] require the population to have a specific size.
* Positions with [REQUIRES_MARKET] will only appear in "large" sites (which may have different rules for different site types). This tag has no effect in fort mode.
* Positions that are appointed by positions that have a AS_NEEDED number. The appointable positions only become available after a appoiner-position-slot is created. This works also on civ-level. If a position is appointed by a Land-holder, it only becomes available, when that level of landholder is created.

Only the replaced positions are culled and are no longer available.
A position that requires a certain population will become available, even if it doesnt have [APPOINTED_BY] or [ELECTED]. In that case, see 'automatic assignment' and 'assumption'

In fortress-mode, in some cases 'succession' is evaluated immediately after a position becomes available. See: Succession.
==Visibility of positions==
A position might be available, but can still be invisible for the player in the [[nobles screen]]. The positions with their respective holders are visible for players:
* All site-positions that are already filled-in (even if they could not be re-filled-in considering current conditions)
* Site-positions that are appointable by a filled-in site position
* Civ-positions of units that are also a citizen of your fortress.
If a position becomes available, for example because a certain pop number has reached or if it is available from the start(like expedition leader), als long as it cannot be appointed, it still is INVISIBLE for the player.

It might strike as odd, may a position becomes filled automaticly in fortress mode, when that position is not even visible. This might be the case if the current holder of a non-appoinable position dies or succeeds another position. Regardless of player-visibility, these positions will be automaticly filled in if the nescesary requisitions are met. It might happen with the expedition-leader.

A situation with a non-visible but available position, is for example when a position is solely appointed by the expedion leader, when the expedion leader's position is left vacant. It can no longer be appointed by the player and is invisible. Then, it gets automatically assumed, proving that the position still was available.

=NUMBER=
A position might be defined with a number. In that case, as many as defined can be available. If the positions become available, in world-gen and when embarking, they are all filled-in completely.

If the ruling position (with PRECEDENCE of 1) has a NUMBER higher than 1, a random unit of the ones holding these positions is shown as 'head of state' in the embark screen.
==Automatic spreading of assumed, non-singular positions==
If there are civ-positions that have a NUMBER higher then '1' and which are assumed (not APPOINTED_BY or ELECTED) but are '''not DUTY_BOUND''', these are automatically spread among the civilisation, based on population. If there are a number of '''20''' available slots of that position, they spread among a civilization with a combined population of, for example, 1000 of which your fortress has 100 (10%), '''2''' of your fortress' citizens will assume that position.
This may probably also work with elected and appointed positions, but that may be depending on the death of the current holders and this needs more testing. Assumption works within a day, anyway.

==AS_NEEDED==
These positions can be created automaticly by the game in world-gen. This however only works with
* [LAND_HOLDER]'s
* squad commanders (needs more testing)
* Messengers at sites

For all other types of positions, they're not created in world-gen, even if they are defined with RESPONSIBILITY's. For example, even in war, The game wouldn't create a MILITARY_GOALS position, if they have AS_NEEDED as number.

However, in fortress-mode / player mode, these positions can be created by the player at will.

Positions with AS_NEEDED need to be created first, before any symbols are assignable as 'symbols' (objects) for the position holder to carry or wear.

Positions with AS_NEEDED cannot be created and then ELECTED in fortress-mode. It only works with APPOINTED_BY.

=Replacement and Required Population=

The token REPLACED_BY:position means that once the replacing position reaches its required population-number, the 'to-be-replaced' position will disappear. This is defined in REQUIRES_POPULATION. These tags are closely related to eachother and seem to only have a meaningfull function if combined. Nobles with REQUIRES_POPULATION require the population to have a specific size.

This works on civ-level as well as on site-level, but those systems are in this mechanic strictly separated. Site-level positions cannot be replaced by civ-level positions and visa versa. This makes sense, because they both depend on their own population-count. When using REQUIRES_POPULATION on civ-level, it counts the total population of the civilisation.

==Effect of replacement==

Replacement is immediate. The current holding unit looses the position. Even before succession_by_position-rules are applied.

Replacement is also complete. A position with a number of 1 will replace all the slots of a position with a higher number of slots.

Even if the next position is available but not VISIBLE, replacement still takes place.

If a position is replaced, it is completely gone. It cannot be appointed, succeeded, elected or assumed any longer.
The unit immediately looses its position.

In legends, replacement is mentioned as: "(unit name) ceeded to be (position name)"

The replacement of a AS_NEEDED position empties the positions slot forever. In fortress-mode, it may seem as if you can create new slots and appoint new units in the nobles-screen, but this is made undone, as soon as you close the window.

==Evaluation of replacement and required_population==

The game does not constantly check if positions need to become available or need to be replaced. This is know behaviour with for example the mayor. He won't appear automaticly if the needed population is reached. The positions need to be "evaluated". It is not known when this will be done without any player interaction. Players can trigger the evaluation-mechanism by (re)assigning any random site position.

==LAND_HOLDER replacement==

The landholder-chain uses replacement differently. It does not empty the position completely, but uses it for succession to the next level's position. REPLACE_BY is required to let that system work properly. This also means that the way in which landholders succeed (replace + as_needed) does not work in any other way.

Replacement between LAND_HOLDERS and other site- or civ positions does not work, in any way. Only the vanilla replacement-sequence between levels of LAND_HOLDERs does work. If the token is omitted for land-holders, the land-holder-chain is broken, so replacement is required for the landholder-system to work.

REQUIRES_POPULATION does not work in the landholder-chain.

==What does not work==

Attention: If a position cannot be appointed, for example because of 'mutual appointment', it still exists according to replacements mechanics and will replace other positions if so defined. If a certain position(a) will be replaced by the baron's-assistant, which can only be appointed by the land_holder baron, than that position(s) still will be replaced from the start of the game, even if no baron or his assistant is ever present.

A position that is replaced by a somehow not-fillable position, is still replaced. This counts for mutual-appointing positions, replacement by not-yet assigned landholders, replacement by AS_NEEDED - positions, or replacement by not-yet-appointed positions.

Replacement does not work, if the replaced position is a land_holder, even with civ-positions. In that case, LAND_HOLDER's position is not replaced. It does not matter if AS_NEEDED is used or a fixed number and it also does not matter, what type of position the replacER is.

So this only works (correctly) with positions that become available by REQUIRES_POPULATION.

=Gaining a position=
There are several ways a unit can gain a position:
* Appointment: A unit is appointed by another unit or by the player.
* Election: A unit is elected by and among the members of the entity
* Assumption: A position is neither elected or appointed: a random unit just simply 'takes' the position
* Succession: a unit is the valid successor of this position(A), either by its current position(B) or because he is that position(A)-holder's heir.

Available positions will automatically be assigned to a random civ member when a new site/civ is created.

==Who can take a position==

* If so defined, a unit needs the be the right caste and/or class. It does not seem to work with creature-types.
* The unit needs to be a member of that site or its parent civ-government.
* It needs to be CAN_LEARN or INTELLIGENT (SLOW_LEARNER cannot take positions) or otherwise be able to think.
* It needs to be an adult.

==Appointment==

Positions that have a [APPOINTED_BY:position]-token require that position to exist, to be available and appointed. Any position that is APPOINTED_BY can be appointed if the appointer's position is filled in.
For site-positions to be appointed, it is required that the appointer is present at that location.

If the appointing unit is temporary not present or if that position is not filled, positions depending on it cannot be appointed. This is the case with [[militia captains]], when the [[militia commander]] is on a [[mission]].

A site-position cannot appoint a civ-position or LAND_HOLDER, in anyway, whatsoever.

Civ-level positions can appoint other civ-level positions and site-level positions can appoint other site-level positions.

''In contrary of what it said in the wiki so far, it is tested and confirmed, that civ-level nobles also CAN appoint site-level nobles. They need to be at that site to do so. Landholders can appoint both site-level and civ-level nobles. These systems are therefore not as separate as was assumed.''

'''Mutual appointment''' cannot take place. If these are the only requisites of the position, then the positions will never appear or get filled. These unfillable positions can be put to good use, for example to replace a position that is no longer needed, without creating a new one.

If a APPOINTED_BY-token refers to a non-existing position's code, it has the effect as if the appointment-token doesn't exist at all.

===Automatic appointment in world-gen and on civ-level===

Outside of fortress-mode, the game will always attempt to appoint nobles whenever possible, als long as these positions are '''available'''. Even if they are invisible to the player.
It shows this message in legends: "(unit name) has been appointed to the position of (position name)"

In word-gen all, positions become available and are automaticly appointed, taking population- and appointment-requirements in consideration.

Positions that are REPLACED_BY are culled and wont be filled.

If a citizen of your fortress holds a civ-position that can appoint another civ-level position, the appointment will happen automatically and without player intervention. It may happen that another citizen of your fortress is appointed by that unit, creating civ-level position holders in your fortress. But it is unknown what is required to force this effect.

===Manual appointments by the player in fortress mode===
In fortress mode, the positions that need to be appointed stay empty on embark. and it is for the player to appoint those. A player can appoint a unit to any available position, according to the hereabove mentioned conditions. The player takes the role of the automatic appointment-system. The player has no direct control over elections, successions and replacement. There are some differences in what is possible at world-gen sites and at player-controlled sites.

* A position that is appointed by a unit present as a fortress citizen, can be appointed, re-appointed or left vacant. This means also by civ-level nobles, living as a citizen in your fortress; not when they are only visiting, like the diplomat.
* A position that is APPOINTED_BY a unit present as the land_holder of your site, can be appointed, reassigned or left vacant.
* A position that has SUCCESSION BY_HEIR or BY_POSITION can 'initially' be appointed and also re-appointed or left vacant, but as soon as the [[nobles]] screen closes, ''it can not longer be replaced or left vacant''. From then on, the succession-rules determine who gains that position when the current holder loses the position.
* A position that is ELECTED nor APPOINTED_BY, can always be (re-)appointed by the player. This is the case with the [[Expedition leader]]. If it is left vacant however, it cannot be appointed, but will assumed shortly after.
* A position that is both ELECTED and appointed by, cannot be appointed by the player. In contrary to world-gen sites. It's slot is visible, but it doesn't show the +-sign. This is either by AS_NEEDED as by a fixed number. Even if the position somehow gets filled (re)assignment is never possible
* A player can appoint a number of units to a position, as much as the NUMBER-token dictates. If it is AS_NEEDED, the player may create as many slots if he likes, also in contrary of world-gen-sites.
* A civ-position can never be appointed, even if the appointing civ-noble is a citizen of your fortress. A civ position also never can be re-assigned or left vacant, would that position be defined as appointed by a site-position.

==Election==

Read more in [[Elections]]

The message that is shown, is: "(creature name) has been elected to the position of (position name)"

In worldgen, there is no functional difference between ELECTED and non-appointment, except that elected nobles tend to have high social skills and/or skills related to the position, while non-elected ones are assigned randomly.

An election goes before succession.

A position that is also APPOINTED_BY gets never elected. Even if the position somehow gets filled, (re)-elections wont happen. So, it doesn't seem possible to have a elected position become available from a certain land_holder's level.

A ELECTED civ-(or LAND_HOLDER)-position at your site will never be (re)-elected in fortress-mode. So real (re-)election only works with SITE-positions.

When a settlement gets up a level in the LANDHOLDER-track, an election is happening, in which the current electable positions undergo a new election-round.

==Assumption==

A position that is not APPOINTED_BY nor ELECTED, or is appointed by positions that are not available in your site or civ, it will be assumable by a random dwarf. If it has responsibilities that require certain skills, then these are taken into consideration. {{verify}}

The message that is shown in Legends-mode, is: "(unit name) has assumed the position of (position name)". This make also take place in fortress mode, which then shows this message to the player.

If a assumable position becomes empty, it will be assumed within a day. This is the case when you leave the position of expedition-leader vacant. It also happens with civ-entities.

Assumable positions that have become empty will not be assumed if that position has a valid SUCCESSION -successor. In that case, the successor inherits the position.

Even positions that are somehow invisible because they cannot be directly APPOINTED_BY players, can be assumed.

When you embark, the assumable positions are automatically assigned to a random unit. If there are multiple of this positions at embark, they all are assigned to the same unit.

A position that has an appointer, which got replaced because of REPLACED_BY, it will not become assumable. Also positions that have a AS_NEEDED appointer that is not yet filled (or ever), wil also not be assumed.

==Succession==

If a position-holder dies or advances to a new position via succession, the position will be granted to another unit based on the SUCCESSION tag. If they have an heir or the succeeding position exists, that unit will be assigned. If not, a new one will be appointed according to the usual rules. De succeeding dwarf will also lose its previous position. The message that is shown, is: "(creature name) being the rightful heir, has inherited the position of (position name)"

Succession works both at site-level as at civ-level, both in world-gen and in fortress-mode. Succession by position on Civ-level is also visible and functional in fortress-mode. If both civ-level nobles are a citizen of your fortress, succession is applied visually.

Vanilla example: The [[druid]] is succeeded by the [[acolyte]]. This means that as soon as the druid dies, the acolyte takes over.

When a position that is succeeded by position becomes available, immediately it is checked if a position-successor is available and the position is filled with that unit.

It is possible to assign multiple levels of SUCCESSION:BY_POSITION, creating a line of positions where the death of one causes all those "below" them to advance.

A position can have multiple tokens with position-succession. It seems to be random which one is used.
Its is not always:
* The first or last defined token
* The first or last appointed unit
Not yet tested:
* Age, unit-id or other possible variables
* The precedence of the succeeding-position

When a position is defined with a Succession-type, that unit cannot have another position that has a Squad-type. If the succession-position itself has a squad, than it can be assigned another position with a squad, but then it will loose the previous succesion-one. See further details by "Squad"

Assumed positions can also be succeeded by position, if the current holder dies.

If the successor is a AS_NEEDED-position, the used unit will leave a vacant position-slot on its removal by succession. This empty slot remains a real slot, which will only be cleaned up, if you (un)appoint a unit to this position-series. It isn't cleaned up after regular position-validation.

A Civ-level position of a unit living at your site might be inherited by a unit holding that does not currently live at your site. This unfortinately moves you civ-noble off site.
This may also happen with the land-holder of your site, for example when it is succeeded by another civ-level position.
Its needs further testing, if the landholder somehow can be called back.

===SITE and civ-combined succession===

Succession can work when combining site positions with civ-level positions or land_holders, but only in world-gen mode. In fortress-mode, it cannot be combined. There it only works with combining the same level of nobles, with Landholders regarded as civ-level.

So, in fortress mode, A site's position cannot succeed a landholder's position and it cannot succeed another type of civ-level position, and vice versa.
This wont work even if the positions:
* are AS_NEEDED or having a fixed number.
* Are LAND_HOLDER

===Succession BY_HEIR===

When a heir is needed for succession, all children and then other relatives are validated. They cannot take the position if their status does not allow the position. For example if they have become the member of another civilisation. See: "Who can take a position". If the unit has no valid heir on that location, the position may go to a unit living on another site. This may cause the title of Landholder of some land to be inherited by a unit living somewhere else. That might be a problem, because then you lose your landholders.

===Premature Succession===

There are some cases where succession by position is applied too early, when a position initially becomes available. It is filled in by the succession-mechanism, without player interaction. This is probably a bug, but it can be exploited to create some interesting textures. When a position first becomes available, the game will check whether there is a valid successor-by-position. Then this unit is immediately assigned for this new position. If this happens in Fortress mode with a position that can also be appointed by a unit present, succession is activated before the player has a chance to appoint a holder.
Using premature succession, a ELECTED + APPOINTED_BY position can be filled, but assignment or elections wont happen. It seems to have no other benefits.

This only applies to Fortress mode, not in world-gen, but can be used with both site and civ-level nobles.

This applies to:
* The successable position is created, because the REQUIRES_POPULATION is reached
* The successable position can be APPOINTED_BY another position of the same level (site/civ), that has just been created because that ones REQUIRES_POPULATION was reached.
* The successable position can be appointed by another SITE - AS_NEEDED-position, that has just been created and filled.
* The successable (site/civ) position is APPOINTED_BY the LAND_HOLDER-position, that has just been created because your site's level is elevated. It happens when the diplomat leaves the area. Presumably because landholders are also AS_NEEDED.

It is not applied when:
* An AS_NEEDED successable position-slot is just created by the player, that has a filled succeeding position. (AS_NEEDED- positions always need to be appointed after they are created)
* The successing position is filled after the successable position becomes available. Then its too late.
* The position can be appointed by another position(site/civ) with a fixed number, that is just appointed.
* Anything world-gen
* The succeeding position is replaced by the succesable position. In that case, the unit is first removed by the replacement, before the succession-mechanism had the chance to use that unit.

===What does not work===

* A circular succession-loop let the game crash.
* Succession plays no role during elections. Elections have priority

=Losing a position=

A unit can lose a position, when
* It dies
* It succeeds another position
* It is assigned to another SQUAD-holding position
* It commits a crime and is convicted.
* Another unit is ELECTED for the position
* Its position becomes replaced
* Another unit is appointed by the player, or the position is left vacant.
* It has assumed a civ-level-position, as this always leaves the previous position vacant.

=Embarkment=

Two types of positions are automaticly filled by embark.
* Positions without appointed_by or elected. All these positions, even with a NUMBER higher than 1, are all filled with the same, single, random dwarf.
* Positions that are elected are filled-in by the normal election rules.

Positions that have a defined appointment are never initially filled at embark.

=Land Holders=

A Land-holder is a '''special civ-level noble''' who gets a certain piece of land to hold, when that land gains a certain level. This is determined by the tag LAND_HOLDER and by the landholder triggers in the game's settings. In vanilla, these are the baron, the count and the duke.

==Functioning of the regular landholder-chain==

The distinct difference between an landholder and a regular civ-level noble, is that a landholder may gain the position of landholder "of (sitename)" They are then seen as ruler of a particular site.

For a land_holders position to function as so, it has a few requirements:
* NUMBER:AS_NEEDED
* The first landholder-number of 1 is defined.
* No SITE (so civ) tag in that position.
* Replaced_by the next level landholder
If a land-holder is defined with differentiating properties, it will function like a regular noble. A higher-up landholder that lacks the required tokens or connections will then not be used in elevation.

If a fortress meets the trigger for a new LAND_HOLDER tier when a caravan leaves, then the next time the outpost liaison or equivalent arrives, they will offer to make you an official colony, which will allow you to select all positions for that LAND_HOLDER level. Each time they appear, the outpost liaison will only promote your fortress one tier up the LAND_HOLDER track.

The landholders LAND_NAME is not required for the functioning of this system. If omitted, messages will be shown with a more generic text.

==Appointment==

This mechanism differs from the regular methods of position management. It ignores all regular appointment- and election rules, so it more or less functions like automatic assingment. A landholder is in vanilla appointed by the monarch. Changing this doesn't seem to do anything. If he is appointed by a site-position, a not-yet-existing civ-position, or not appointed at all: the system keeps working regularly.

A landholder can appoint civ-positions and site positions. This works as expected: the positions only are appointed then when that landholder becomes available on civ-level or when he arrives at that site for site-level positions.

If your rank of landholder is the first of its rank in the realm, and is the sole appointer of some civ-position, then immediately as it gains the title, it will appoint the empty civ-slots. This may happen on your site, but the frequency and certainty is hard to determine.

==Succession==

Succession-rules are applied to some extend:
* In world-gen it does work according to succession rules, and site-positions can be used here. This means that a site-position or a civ-position can inherit a landholders-positon and vice versa.
* In fortress-mode, once a landholder has been appointed, it then can inherit civ-level positions, and vica versa. This means that your baron can become king.
* Succession-rules do not apply within the land-holder chain; a count will not inherit a baron's land. This is because succession does not work well with the AS_NEEDED token.
* Premature succession works in fortress mode with landholders. If a unit gets a landholdersposition and that landholder is the appointer of an yet-empty position, which is defined as succeeding from a third one, then the succession is immediately applied. The landholder himself can even be the successor of a newly created position.
* A landholder's position is, in fortress mode, not successable by a site-position or visa versa

==Nomination==

The player is able to nominate a unit to become the land_holder. This only works with level 1. The player can select all units, only limited by the PRECEDENCE of the current units positions.

A unit that has a position with a PRECEDENCE lower or equal as that of the landholders-position, cannot be selected. This means that a baron (or count) from another site or the monarch or cannot be selected, because their precenence is lower or equal.

The token GENDER does not work here: also units with the wrong gender (sorry) can be selected.

==Levels==
In mods, up to 10 levels of land_holder may be defined.

If a landholder is replaced by a wrong landholder number (1 replaced by 3), then the number 3 is still correctly attached to the settlement.

If the current landholder has the highest available landholder number, then the next elevation will happen. The diplomat will not elevate your fortress to a higher position. Even if that position might be REPLACED_BY a lower landholder.

These chains do work:
* 1 -> 2a - > 2b -> 3
* 1 -> 3 -> 2 -> 4

These chains do not work:
* 2 -> 3 (need to start at 1)
* 1 -> 4 -> 2 -> 3 (stops after 4 as the highest)

==Moving landholders==

It may happen that a land-holder no longer lives at the site of which he is the landholder of. This happens when the current landholder dies, leaving the title to an heir living somewhere else.

To prevent this from happening, you can make his succession from heir and make sure that his kids live at your site. Or, you can make his position succeeded by another civ-position, and make it so that this civ-position is somehow available on your site. But if multiple of these positions exist, it cannot be guaranteed that a citizen of your fortress will inherit the title.

In world-gen, a landholder lacking the DUTY_BOUND-token will also move to the site he likes, according to legends mode.

==Replacement by a generic civ-position==

If a landholder is replaced by a AS_NEEDED non-landholder civ-position, then this will work: the current landholder loses that title upon settlement-elevation and gains that civ-title. However, the civ-title lacks the landholder-property of being attached to the land. It wil not show the name of the settlement alongside the position's name. So no "minister of Shovelmounts"

If a landholder is replaced by a general AS_NEEDED civ-position, that itself is also replaced by a generic AS_NEEDED civ-position, then firstly the elevation is executed and also the unit gains that new position. However, he immideatly looses it. Because a AS_NEEDED position that is replaced by another position can be filled initially, but units wont be able to hold that title.

==Landholder with fixed number==

A Landholders position that has a fixed number will be created and filled directly when the civilisation is born. So this position slot is then not available for the regular landholder-mechanic and will also not be used. That landholder will thus not be attached to a settlement.

It doesn't matter if the landholders position is connected to the regular landholder's-chain by the REPLACE_BY-token.

==Responsibilities==

When given a certain RESPONSIBILITY, a landholder may function as regular civ-level nobles. If the position has responsibility TRADE or OUTPOST_NEGOTIATING, then the landholder functions both as diplomat and as actual land holder. A landholder with the MILITARY_STRATEGY responsibility will travel around taming creatures in world-gen, according to legends-mode.

Besides that, the responsibilities work the same as with any other at your site living position-holder, civ or otherwise.

=Army-stuff=

==Squad assignment==

Squads can be assigned, even if the leader position has no holder. This seems to be the case if the number is fixed (1) or if the position is assigned by a non-military position.

A specific unit can only have one position associated with a squad. If it gains another 'squad holding position', it is unassigned of the first one. This does not work with a 0-squad, so only 1+squads are taken into consideration; so this technique can possibly be used to distribute all positions equally among all citizens. It does however not work with election and assumption.

If a civ-level position is associated with a squad and it gets a site-level squad-holding position assigned, it loses the current civ-position.

Squads can get really messed up, if you make the position (or multiple) either elected or not-elected and not-appointed, then this can cause the game to assign multiple squads to the same unit. Automatic assignment and election does not take squads in account, but the nobles-screen does. This can cause the positions to be cleared as the game figures out that they have more than one position, and immidiatly get elected or assumed again.

Positions that cannot have a squad-position:
* A site- or civ-position with a defined successor cannot be appointed a squad-holding-position.
* The other way around however does work. If a site-position with a successor is appointed to a unit that has already a squad-holding position, it does work. But when that squad position is assigned to another unit, it cannot be assigned back.
* A squad-holding position with a formed squad cannot be appointed to another squad holding position.

If a position had some squad-members, it cannot be left vacant. First, the squad has to be disbanded, then the position may be cleared.

=Further testing=
The following questions may need additional testing. Feel free to add or answer
* Everything regarding COMMANDING and army-structure
** [http://www.bay12forums.com/smf/index.php?topic=175437.msg8331668#msg8331668]
** [http://www.bay12forums.com/smf/index.php?topic=165213.msg8335682#msg8335682]
** [http://www.bay12forums.com/smf/index.php?topic=174584.msg8026854#msg8026854]
* Everything regarding CONQUERED_SITE, but it is presumably just like site. But what if you combine SITE or LAND_HOLDER with it?
* What are the exact requirements for a position to function as militia commander, so that squads can be created? I've not figured out this exactly.
* Stuff about the monarch, its arrival and its entourage.
* It seems that the monarch cannot be appointed manager. Why exactly? Precedence?
* can replaced positions be recreated?

{{Category|Modding}}
{{Category|Guides}}

Difficulty

2023-12-04T11:02:48Z

CobaltNinja: /* Custom settings */ Clarification on mandates & demands

{{Quality|Unknown}}
{{av}}
{{stub}}

While previous versions of ''Dwarf Fortress'' allowed you to toggle [[Invader|invaders]] on or off, v50 added more granular difficulty settings to fine-tune one's experience. Difficulty settings will affect whether your fortress can be attacked by outside forces, how frequent said attacks are, how big invading armies are, and [[noble]] neediness. You can modify these settings before and after embarking at any time.

== Default settings ==
'''Enemies''' has 3 options:
* '''Off''' will disable [[Ambush|ambushes]], [[Siege|sieges]], [[Megabeast|uninvited]] [[Forgotten beast|guests]], [[Werebeast|werebeasts]], and agitated wildlife attacks. It will not disable [[intrigue]], [[HFS]], or misbehaving dwarves, so it is still recommended to train a military.
* '''Normal''' is the standard ''Dwarf Fortress'' experience.
* '''Hard''' ensures a never-ending stream of [[Fun]], causing invaders to show up earlier, more often, and with more bodies to throw at the gates.
'''Economy''' has 2 options:
* '''Normal''' is the standard ''Dwarf Fortress'' economy.
* '''Hard''' requires you to produce more wealth in order to receive higher-ranking nobles, requires [[Temple|temples]] and [[Guildhall|guildhalls]] to be more valuable before satisfying petitions, and causes [[Noble|nobles]] to make more [[Mandate|mandates]] and [[Demand|demands]].

== Custom settings ==
If you wish, you can also fine-tune individual settings - maybe you only want megabeasts to assault your fortress, and would prefer the elves to leave well enough alone. The following options are available for enemy settings:
{| class="wikitable"
|-
! Setting !! Possible values !! Description !! Default values (Off, Normal, Hard)
|-
| Civilizations can attack || Yes/No || Controls whether [[Ambush|ambushes]] and [[Siege|sieges]] can occur. || No, Yes, Yes
|-
| Megabeasts can attack || Yes/No || Controls whether [[Megabeast|megabeasts]] and [[Forgotten beast|forgotten beasts]] can attack. || No, Yes, Yes
|-
| Werebeasts can attack || Yes/No || Controls whether [[Werebeast|werebeasts]] can attack. || No, Yes, Yes
|-
| Curious wilderness creatures can come to cause trouble || Yes/No || Controls whether agitated animals can assault your fortress, and whether animals will spawn with the intent to steal items. || No, Yes, Yes
|-
| Enemy population triggers || 1 to 300 || Likely affects when invasions attacks occur, and how difficult they are. Met when you have this many citizens.{{verify}} || 0/0/0/0/0, 20/50/80/110/140, 15/30/40/55/70
|-
| Enemy production triggers || 0 to 100,000,000 || Likely affects when invasions occur, and how difficult they are. Met when you've created this much wealth.{{verify}} || 0/0/0/0/0, 5000/25000/100000/200000/300000, 2500/12500/50000/100000/150000
|-
| Enemy trade triggers || 0 to 100,000,000 || Likely affects when invasions occur, and how difficult they are. Met when you've exported this much wealth.{{verify}} || 0/0/0/0/0, 500/2500/10000/20000/30000, 250/1250/5000/10000/15000
|-
| Megabeast attack period (seasons) || 0 to 100 || How many seasons must pass before a megabeast may attack your fortress.{{verify}} || 10, 10, 8
|-
| Forgotten beast sensitivity || 1 to 100,000 || Unknown; a smaller value will cause forgotten beasts to attack sooner. || 10000, 10000, 10000
|-
| Forgotten beast irritation minimum || 1 to 100,000 || Unknown; a smaller value will cause forgotten beasts to attack sooner. || 5000, 5000, 2000
|-
| Forgotten beast wealth divisor || 1 to 100,000 || Likely increases the amount of wealth you need to create before a forgotten beast attacks.{{verify}} || 40, 40, 40
|-
| Wilderness sensitivity || 1 to 100,000 || Performing nature-disrupting actions such as cutting down trees will agitate wildlife and may cause them to attack. A smaller value will increase the amount wildlife is agitated by. || 10000, 10000, 10000
|-
| Wilderness irritation minimum || 1 to 100,000 || Likely affects the maximum rate at which agitated wildlife will attack.{{verify}} || 2000, 2000, 0
|-
| Wilderness irritation decay || 0 to 100,000 || Causes wildlife to be less irritated after every season{{verify}}. A higher value will make them less irritated faster. || 2000, 2000, 0
|-
| Werebeast attack period (seasons) || 0 to 100 || How many seasons must pass before a werebeast may attack your fortress.{{verify}} || 10, 10, 8
|-
| Vampire migrant fraction || 1 to 1,000 || Affects what percentage of new migrants will be [[Vampire|vampires]]. A value of 0 will disable vampiric migrants. (Only on '''Off''' difficulty) || 0, 100, 75
|-
| Invasion caps (regulars) || 0 to 500 || The maximum amount of humanoid enemies that can be thrown at you when a civilization sieges you.{{verify}} || 0/0/0, 10/40/120, 20/60/120
|-
| Invasion caps (monsters) || 0 to 500) || The maximum amount of mounts and other tamed creatures that can be thrown at you when a civilization sieges you.{{verify}} || 0/0/0, 0/5/40, 1/10/40
|-
| Minimum raids before first siege (per civ) || 0 to 500 || Affects how many [[Ambush|ambushes]] must be performed before a civilization can try a proper siege for the first time. || 0, 2, 2
|-
| Minimum raids between sieges (per civ) || 0 to 500 || Affects how many ambushes must be performed before a civilization can try a proper siege from the second time onwards. || 0, 3, 1
|-
| Siege frequency (percentage, otherwise raid) || 0 to 100 || Percentage chance to receive a siege instead of an ambush. || 0, 25, 50
|-
| Cavern dweller scale (increase per attack) || 0 to 100 || Unknown. Likely affects how rapidly the amount of enemies cavern dwellers will send increases.{{verify}} || 0, 10, 20
|-
| Cavern dweller maximum attackers || 0 to 500 || The maximum amount of enemies that can be thrown at you when cavern dwellers attack. || 0, 50, 75
|-
| Diplomacy tree-fell count || 1 to 1000 || Affects the default amount of trees [[Elf|elven]] diplomats will request you limit your felling to. Your negotiator will still try and increase the tree limit. || 25, 25, 10
|-
| Diplomacy tree-fell count (untamed wilds) || 1 to 1000 || Affects the default amount of trees elven diplomats will request you limit your felling to if you've settled in a [[savage]] area instead. Your negotiator will still try and increase the tree limit. || 5, 5, 1
|}
The following options are available for economy settings:
{| class="wikitable"
|-
! Setting !! Possible values !! Description !! Default values (Normal, Hard)
|-
| Economy population triggers || 1 to 300 || Affects how many citizens you need to increase the rank of your fortress. Must meet population and one of production or trade. Triggers 1 through 5 correspond to Hamlet, Village, Town, City, and Metropolis. || 20/50/80/110/140, 20/50/80/110/140
|-
| Economy production triggers || 1 to 100,000,000 || Affects how much created wealth you need to increase the rank of your fortress. Must meet population and one of production or trade. Triggers 1 through 5 correspond to Hamlet, Village, Town, City, and Metropolis. Setting this trigger to 0 causes it to be met immediately. || 5000/25000/100000/200000/300000, 25000/125000/500000/1000000/1500000
|-
| Economy trade triggers || 1 to 100,000,000 || Affects how much exported wealth you need to increase the rank of your fortress. Must meet population and one of production or trade. Triggers 1 through 5 correspond to Hamlet, Village, Town, City, and Metropolis. Setting a trigger to 0 causes it to be met immediately. || 500/2500/10000/20000/30000, 2500/12500/50000/100000/150000
|-
| Land holder population triggers || 1 to 300 || Likely affects how [[Baron|barons]] and upwards are achieved.{{verify}} Values 4 through 10 are not used in the base game. || 20/20/20, 20/20/20
|-
| Land holder production triggers || 1 to 100,000,000 || Likely affects how barons and upwards are achieved.{{verify}} Values 4 through 10 are not used in the base game. || 10000/200000/300000, 500000/1000000/1500000
|-
| Land holder trade triggers || 1 to 100,000,000 || Likely affects how barons and upwards are achieved.{{verify}} Values 4 through 10 are not used in the base game. || 10000/20000/30000, 50000/100000/150000
|-
| Value of temple || 1 to 100,000,000 || Affects how valuable a designated [[temple]] zone must be before it satisfies a petition to create it. || 2000, 6000
|-
| Value of temple complex || 1 to 100,000,000 || Affects how valuable a designated temple zone must be before it satisfies a petition to upgrade it. || 10000, 30000
|-
| Priesthood unit count || 1 to 300 || Affects how many members of a religion must be citizens in your fortress before a petition for a temple is made. || 10, 10
|-
| High priesthood unit count || 1 to 300 || Affects how many members of a religion must be citizens in your fortress before a petition to upgrade an existing temple is made. || 25, 25
|-
| Value of guildhall || 1 to 100,000,000 || Affects how valuable a designated [[guildhall]] zone must be before it satisfies a petition to create it. || 2000, 6000
|-
| Value of grand guildhall || 1 to 100,000,000 || Affects how valuable a designated guildhall zone must be before it satisfies a petition to upgrade it. || 10000, 30000
|-
| Guild unit count || 1 to 300 || Affects how many members of a profession must be citizens in your fortress before a petition for a guildhall is made. || 10, 10
|-
| Grand guild unit count || 1 to 300 || Affects how many members of a profession must be citizens in your fortress before a petition to upgrade an existing guildhall is made. || 25, 25
|-
| Mandate period (more = fewer) || 1 to 10,000 || Affects how long nobles must wait before making new mandates. A higher value forces them to wait longer before mandating something.|| 1000, 500
|-
| Demand period (more = fewer) || 1 to 10,000 || Affects how long nobles must wait before making new demands. A higher value forces them to wait longer before making a demand.|| 500, 250
|}

Surrender

2023-11-27T22:26:41Z

CobaltNinja: Info on Fortress mode.

{{migrated article}}
{{Quality|Unrated}}
{{av}}

In [[adventurer mode]], it is possible to '''surrender''' by using the {{k|y}}ield key, thus assuming a submissive posture. Surrender may end a [[level of conflict|lethal]] conflict, but not a no quarter conflict. It is also possible to use the {{k|k}}onversation menu to demand that someone else yield. An enemy's surrender is generally indicated by them yelling "I yield! I yield!", though enemies may sometimes say "Stop! This isn't happening!". Faking surrender may elevate conflict from lethal to no quarter.

Attacking an enemy who has yielded will result in a confirmation message requiring you to press {{k+|ALT|y}} to confirm. Sometimes this message will be displayed, though, and the enemy hasn't visibly yielded. This indicates that the enemy is yielding, but hasn't finished saying the associated message. If the player waits (using {{k|.}} or {{k|,}}) the message will appear.

Upon the killing of an opponent who has surrendered, depending on the [[ethics]] of the [[civilization]], this will cause you to be known as a murderer, causing most persons of that civilization to denounce you as a murderer and [[spit]] at you every time you attempt to speak to them. Despite this, you can still engage in conversation with the subject, albeit while dodging their spit.

Creatures in [[fortress mode]] will never surrender in combat, even against overwhelming odds. All battles will be fought to the death, or until someone escapes.
{{stub}}

{{Category|adventurer mode}}
{{Category|Game mechanics}}
[[ru:Surrender]]

Finished goods

2023-10-30T16:26:50Z

CobaltNinja: /* Materials */ Changed grammar.

{{Quality|Unrated}}
{{av}}

[[File:finished_goods_preview.png|right]]'''Finished goods''' are items that go to a finished goods [[stockpile]] when made. Many of these items are frequently referred to as trade goods as they are lightweight and suitably valuable for [[trading]]. They include '''crafts''', '''goblets''', '''instruments''', '''toys''' and '''totems''', some of which have several subtypes.

Finished good types with several subtypes may have generic workshop orders to produce random subtype items, e.g. "Make crafts". Additionally, some specific subtypes of goods can be ordered directly at an appropriate workshop or through the [[manager]]. If you have a mandate to make rings, you can order rings directly, instead of waiting for a generic "crafts" job to produce rings; others, like puzzleboxes, though, can only be produced by generic jobs ("toys").

Some types of trade goods (crafts and goblets) can be produced in multiples. It is possible to get up to three crafts from a single resource. Skill does not affect the chance to produce multiples.

==Types of trade goods==

===Clothing===
{{main|Clothing}}
All clothing is stored in finished goods piles. Dwarves will replace their worn-out clothing automatically. Clothes can also be exported, but they are not especially valuable, unless they're made of exotic materials, like [[giant cave spider]] [[silk]].

===Crafts===
Crafts include [[figurine|'''figurines''']], [[jewelry|'''rings''', '''earrings''', '''amulets''', '''bracelets''', '''crowns''']], and '''[[scepter]]s'''. Some subtypes of crafts can reference [[historical figure]]s and events (figurines, for example); this does not have any meaningful effect on the value of the craft.

One generic order to "make crafts" consumes one resource and produces one to three items, two on average. All subtypes, if they can be produced from the chosen material, have an identical chance to be produced. Some crafts, such as bracelets, can be worn by dwarves like clothing.

Gem and glass crafts cannot be made directly. They may only be produced randomly by gem cutting jobs.

===Flasks===
{{main|Flask}}
Metal flasks are made at a [[metalsmith's forge]]. Leather flasks are called '''waterskins''', and are made in a [[leather works]]. Glass flasks are called '''vials''', and are made in a [[glass furnace]]. Flasks will be used by soldiers and hunters, allowing them to transport water or booze for drinking.

===Goblets===
[[File:BLW Betrothal Goblet.jpg|thumb|160px|right|A goblet.]]{{Tile|¶|7:1}} Goblets have no subtypes, but have different names depending on the material from which they are made: [[metal]] and [[glass]] goblets are simply '''goblets''', [[stone]] goblets are called '''mugs''', and [[wood]]en goblets are called '''cups'''.

Goblets are always produced at a 3:1 ratio. Metal goblets are made at a [[metalsmith's forge]]. Glass goblets are made at a [[glass furnace]]. Rock mugs and wooden cups are made at a [[craftsdwarf's workshop]].

Goblets can be used by dwarves for [[drink]]ing. If no goblets are available in a dining room stockpile or a coffer in a [[tavern]], a thirsty dwarf can drink [[alcohol]] straight from the [[barrel]], but this will result in an unhappy [[thought]]. If a dwarf is unable to use their arms, they will stall on picking up a goblet rather than drinking straight from the barrel{{bug|9440}}. Goblets can also be used to transport liquids in [[adventurer mode]].

===Instruments===
{{main|Instruments}}
[[File:wood_inst.jpg|thumb|150px|right|Wooden instruments.]]{{Tile|¿|7:1}} Instruments can be composed of one or more components made from specific materials. The presence of multiple high-value components can increase the trade value of an instrument far beyond any other finished good. Instruments can also be used by [[performer]]s in [[tavern]]s or [[temple]]s.

===Toys===
{{Tile|æ|7:1}} Toys include '''mini-forges''', '''toy hammers''', '''toy axes''', '''toy boats''', and '''puzzleboxes'''. Dwarven children can play with toys.

===Totems===
[[Image:Skull totem.jpg|right|thumb|200px|An example of a skull totem.]]

{{Tile|ç|7:1}} Totems are made from skulls by a [[bone carver]] at a [[craftsdwarf's workshop]].

Although totems have the same base [[value]] as all other crafts, totems made from the skulls of more valuable animals like [[unicorn]]s will fetch a hefty price.

===Large gems===
{{Tile|♦|7:1}} Large gems have no subtypes. Large gems can be ordered cut from every material '''except''' gems and glass (including beeswax and soap). For [[gem]] or [[glass]] large gems, a gem cutting job will occasionally produce a large gem. It can be assumed that this represents the rarity of large gem-quality rough gemstones, and the difficulty of creating thick evenly structured glass pieces. Large gems currently have no use beyond trade. The chance of gems being cut into large gems may have been disabled in early releases of the [[premium version]] of the game.

==Materials==
Most materials can be used to make trade goods - on occasion, a [[dwarf]] in a [[strange mood]] will make a trade good out of a material not normally suited for it (e. g., a bone toy).

{| class="wikitable"
| align="center" style="background:#f0f0f0;"|'''Material'''
| align="center" style="background:#f0f0f0;"|'''Labor'''
| align="center" style="background:#f0f0f0;"|'''Workshop'''
| align="center" style="background:#f0f0f0;"|'''Crafts'''
| align="center" style="background:#f0f0f0;"|'''Goblets'''
| align="center" style="background:#f0f0f0;"|'''Toys'''
| align="center" style="background:#f0f0f0;"|'''Large Gems'''
| align="center" style="background:#f0f0f0;"|'''Instruments'''
|-
| [[Stone]]||[[Stone crafter|Stonecrafting]]||[[Craftsdwarf's workshop]]||Y||Y||Y||Y||Y1
|-
| [[Wood]]||[[Wood crafter|Woodcrafting]]||[[Craftsdwarf's workshop]]||Y||Y||Y2||Y||Y1
|-
| [[Leather]]||[[Leatherworker|Leatherworking]]||[[Craftsdwarf's workshop]]||Y4||N||N||N||Y1
|-
| [[Cloth]]3||[[Clothier|Clothesmaking]]||[[Craftsdwarf's workshop]]||Y4||N||N||N||N
|-
| [[Bone]]5||[[Bone carving]]||[[Craftsdwarf's workshop]]||Y||N||N||Y||Y1
|-
| [[Shell]]||[[Bone carving]]||[[Craftsdwarf's workshop]]||Y||N||N||Y||Y1
|-
| [[Horn]]||[[Bone carving]]||[[Craftsdwarf's workshop]]||Y||N||N||Y||Y1
|-
| [[Ivory]]||[[Bone carving]]||[[Craftsdwarf's workshop]]||Y||N||N||Y||N
|-
| [[Pearl]]||[[Bone carving]]||[[Craftsdwarf's workshop]]||Y||N||N||Y||N
|-
| [[Ceramic]]||[[Potter|Pottery]]||[[Kiln]] or [[Magma kiln]]||Y||N||N||N||Y1
|-
| [[Wax]]||[[Wax worker|Wax working]]||[[Craftsdwarf's workshop]]||Y||N||N||N||N
|-
| [[Metal]]||[[Metalcrafting]]||[[Metalsmith's forge]] or [[Magma forge]]||Y||Y||Y||Y||Y1
|-
| [[Glass]]||[[Glassmaker|Glassmaking]]||[[Glass furnace]] or [[Magma glass furnace]]||Y6||Y||Y||Y6||Y1
|-
| [[Gem|Gems]]||[[Gem cutting]]||[[Jeweler's workshop]]||Y6||N||N||Y6||N
|}
1 Instruments and their components are procedurally generated items; the materials they can be made from depend on the particular world.

2 Wooden toys can only be made using the job [[manager]], as the craftsdwarf's workshop interface does not permit selecting them. {{bug|3119}}

3 [[Adamantine]] cloth cannot be used to make crafts. (Adamantine crafts can be created at a [[metalsmith's forge]]).

4 Amulets, earrings and bracelets are the only crafts that can be produced from [[leather]], [[plant]] cloth, and [[silk]] cloth. All crafts can be produced from [[yarn]] cloth.

5 Skull totems, like bone crafts, are made by a bone carver at a craftsdwarf's workshop.

6 Prior to v50, crafts and large gems were produced randomly by cutting jobs at a [[jeweler's workshop]], with the [[gem cutting]] labor. Raw glass possibly has a 33% chance to be cut into a large gem or a craft (with 11 crafts for every 16 large gems). Raw gems have a 5% chance to be cut into a large gem or a craft (with 1 craft for every 8 large gems).

{{D for Dwarf}}

The existence of toy boats indicate that the dwarf civilization does have the concept of using specialized vehicles to travel on water. However, due to the nature of [[Physics |Urist's principle]], there is some difficulty in scaling them up to a usable level.

Some dwarven children insist on calling puzzleboxes "game cubes". Scholars have yet to determine why.

{{Category|Items}}
{{Industry}}
[[ru:Finished goods]]

Dwarf Fortress Wiki talk:Versions

2023-10-28T21:24:45Z

CobaltNinja: /* v50 specific issues */

{{archive|
# [[DF Talk:Versions/Archive 1|Page 1]]}}

== Version 0.31.19 starts a new DF generation? ==

My reading of Toady's comments on the release of 0.31.19 is that it came out basically because he felt it would take too long to get DF all the way to 0.32. With the ore changes, the sitefinder changes, the addition of grazing and several different industries, there's a lot of changes between 31.18 and 31.19. So I'm thinking it might be a good idea to call it the first release of DF2011 - and what we refer to as "DF2010" would then become 0.31.18.

Thoughts? --[[User:DeMatt|DeMatt]] 07:06, 28 February 2011 (UTC)

==Revisiting Redirects==
I wasn't around when the redirect policy was created, and I'm having trouble understanding the rationale. The example claims that linking [[Main:Cheese]] to [[cv:Cheese maker]] is problematic...but mainspace only ever redirects to the current version. If the best target in the current version is cheese maker, why not link to it directly? (It's not, at least for Cheese, since [[DF2012:Cheese]] exists now.) The explanation seems to be claiming that 40d articles that link to Cheese will follow the Mainspace link--but that hasn't been the case for a long while now. Articles in 40d automatically link against other articles in 40d, so that version remains internally consistent no matter where mainspace links to in the current version. For a current example, what do we gain by linking [[Main:Mead]] to [[cv:Mead]] and linking [[DF2012:Mead]] to [[DF2012:Alcohol]]?

If this really is just an outdated procedure, I recommend we drop the mummery and allow mainspace to link to cv:(best target). Double redirects ''may'' work (sometimes, but [[Main:Mead]] demonstrates a common problem where automatic redirection fails), but if they are unnecessary I think they should be avoided, partly because of problems like [[Main:Mead]] and partly because of the effort required to protect double redirects from users who believe they are problematic.--[[User:Loci|Loci]] ([[User talk:Loci|talk]]) 20:16, 8 January 2014 (UTC)

:I was just thinking that. I'm currently attempting to write a basic extension to eliminate the need for mainspace redirects entirely, although Mediawiki's class structure may make this more difficult than I had hoped (the only method I've found for resolving redirects takes the ''article text'' instead of a title, e.g. "#REDIRECT ..."). I do agree that the current situation with redirects isn't ideal, so I'm hoping this will work better (once I get it to work). --[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 20:42, 8 January 2014 (UTC)

Okay, that wasn't quite as clear as I meant it to be. In general, I think this is a tricky situation. Mediawiki wasn't designed to have five content namespaces, and certainly not chains of redirects between them. The problem that was pointed out in the [[DF:REDIR|policy]] is the fact that with:
Main:Foo -> cv:Bar
pages in the cv: namespace can't use [[<nowiki/>foo]], since the namespace links modification causes it to be treated as [[<nowiki/>cv:foo]] instead, which doesn't exist. The current suggested solution is this:
Main:Foo -> cv:Foo -> cv:Bar
This fixes the problem of [[<nowiki/>foo]] not working on cv pages, but creates issues with double redirects not always working. Another solution, which is more intuitive to new editors, is:
Main:Foo -> cv:Bar
cv:Foo -> cv:Bar
Both require creating two redirects. The first method has the advantage of ''ensuring'' that the cv redirect exists (otherwise, main:foo would be a redlink), while the second has the advantage of working more reliably in a couple cases.

What I'm trying to do is make main:Foo "jump" to cv:Foo when cv:foo exists, ''even if main:foo doesn't exist'' (basically it would treat all mainspace pages as redirects to cv pages, but only if the cv page exists and not the mainspace page). I had main:Bar jumping to cv:Bar fine, but if cv:Foo redirected to cv:Bar, accessing main:Foo would mysteriously stop at cv:Foo even if I increased the redirect limit. What I'm trying to do now is follow the redirects internally, without relying on Mediawiki to do it automatically - unfortunately, that has proved to be harder than I had hoped (and I sent my web server into an infinite loop while trying). I will try to work on this some more when I get a chance, although I'm not sure when that'll be yet :(. For now, feel free to fix broken double mainspace redirects as necessary, as long as redirects in the DF2012 namespace stay pointing to the right page (and new mainspace redirects get added in the DF2012 namespace too). --[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 04:21, 9 January 2014 (UTC)

:You're treating cv like a namespace--it's not. It is simply shorthand for "fill in the current version here". [http://dwarffortresswiki.org/index.php?title=User_talk:Briess&diff=182404&oldid=181281 As I discovered a long time ago on a server not far away], linking from Main:Foo to cv:Foo tends to break redirection chains. If, instead of linking to cv:Foo, you link to DF2012:Foo, it might just work. It would, of course, be better if your patch could evaluate cv itself, but even if you have to hardcode the current version it's a single point of maintenance that requires update very infrequently. (For that matter, we could probably dispense with the cv hack entirely and just have a bot update mainspace links from DF2012 to DF201X when we switch to a new version.)--[[User:Loci|Loci]] ([[User talk:Loci|talk]]) 20:05, 9 January 2014 (UTC)
::I know cv isn't a namespace - I was just trying to avoid future confusion when the DF2012 namespace changes. It's interesting that changing "cv" to "DF2012" fixes some broken redirects, although I've found that simply making an edit to a broken redirect can usually fix it as well. I've actually had the most problems with double redirects when the second one (in the DF2012 namespace) doesn't use the DF2012 prefix (e.g. main:Foo containing <nowiki>[[cv:Foo]] and DF2012:Foo containing [[Bar]]</nowiki>). I'd rather keep the cv alias even if it isn't necessary for mainspace redirects when I get the patch to work, since it makes it easier to refer to the current version of the page (for example, several MDF articles contain links to a vanilla page for things that don't change in the mod).
::Also, using aliases like "cv" is supported by Mediawiki; in fact, several WMF wikis use them (for example, "[[wikipedia:WP:Redirects|WP:Redirects]]" on Wikipedia). It's quite likely that Mediawiki isn't processing double redirects using aliases correctly, though, since that's uncommon on most wikis. --[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 21:35, 9 January 2014 (UTC)

In light of the lack of support for the current redirect policy, I propose we replace the current redirect section with:

:Mainspace article pages should use the cv: alias when redirecting to a versioned page, which will automatically update the link when a new version is released. For example, page "Main:Foo" should redirect to page "cv:Bar" (where "Bar" is the page that best describes the topic Foo in the current version).

:Pages in mainspace should only redirect to an older versioned page if that content no longer exists in the current version of the game (e.g. [[Cave river]], [[Chunk]]). In these cases the cv: alias cannot be used.

:Pages inside a versioned namespace should not use the cv: alias. Instead, they should redirect to the best page within that versioned namespace (e.g. [[DF2012:Dodging]], [[v0.31:Drink]]).

:Due to limitations of the wiki software, double redirects should be avoided if possible. When fixing double redirects in mainspace, please make sure to use the cv: alias as appropriate.

If no one objects, I will make this change in a few days.--[[User:Loci|Loci]] ([[User talk:Loci|talk]]) 20:21, 15 January 2014 (UTC)

:Okay with me. It may be worth mentioning that double redirects only really need to be changed when they don't work (since changing a lot of redirects that work isn't necessary), but I think it's clearer and more relevant than the current policy. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 00:26, 16 January 2014 (UTC)

Done.--[[User:Loci|Loci]] ([[User talk:Loci|talk]]) 20:55, 22 January 2014 (UTC)

I was finally able to get my extension to work after being motivated by one too many malfunctioning redirects. It now causes nonexistent pages in the main namespace to behave exactly like redirects to their DF2012 counterparts (when linked to, accessed directly, and transcluded). Double redirects also work (up to 100, in fact, although that was a temporary safety measure that I'll probably change). This means we'll be able to safely get rid of all mainspace redirects (redirects that redirect to something other than "cv" will still function if not deleted). —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 01:20, 14 March 2014 (UTC)
:What about articles which don't exist in the current version but do exist in older versions? Will those still need mainspace redirects, or will your extension be able to automatically redirect them to v0.31/40d/23a? --[[User:Quietust|Quietust]] ([[User talk:Quietust|talk]]) 01:29, 14 March 2014 (UTC)
::It ignores all mainspace pages that actually have content, including redirects, so pages like [[masons guild]] won't be affected (unless deleted). —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 01:47, 14 March 2014 (UTC)

Done and deployed. [[Cat]] is still treated as a redirect, even though I just deleted it (try clicking on the "redirected from" link). Pages that exist are ignored, so [[Masons guild]] and [[History of Dwarf Fortress]] still function normally (as a redirect to a 23a page and a non-redirect, respectively). —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 18:57, 14 April 2014 (UTC)

I'm sending around a bot right now to delete all redirects of the format "foo -> cv:foo" (a surprising number don't fit this format, so I'm leaving them alone for now). —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 20:43, 14 April 2014 (UTC)

:I'm confused. Do we use double redirects or not? Is there a single place we define our linking policy (including redirects), and is it updated?
:I had trouble linking to [[Consolidated_development]] in [[v0.34:Dragon]]. It kept pointing to v0.34:Consolidated_development, which does not exist. I ended up linking to Main:Consolidated_development to make it work. --[[User:Nahno|Nahno]] ([[User talk:Nahno|talk]]) 10:18, 1 July 2014 (UTC)

::That's a separate problem altogether - links in the versioned namespaces (v0.34, v0.31, 40d, 23a) automatically link to pages within their namespace. I may be able to set up a fallback to mainspace once I'm able to deploy again, but for now the "main:" alias is the intended solution. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 11:36, 1 July 2014 (UTC)

== Google often directs people to the 0.31 page ==

I've noticed a couple of times that finding a wiki page from an external search will often drop me onto a page from an older version. Is it possible to mitigate this somehow for new players? I could imagine something like redirecting old:Bar -> cv:Bar unless the user has come from old:Foo; no idea if that would actually work though. [[User:PeridexisErrant|PeridexisErrant]] ([[User talk:PeridexisErrant|talk]]) 11:48, 4 May 2014 (UTC)

:As a temporary solution, I could write a script that displays a banner of some kind if the user came from an external site. I'll ask Briess if he can do anything on the server level to increase the weighting of the current version's pages. (Obviously there are situations where people are looking for old pages, like [[23a:dungeon master]], so we don't want to disable indexing entirely on old pages.) —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 17:03, 4 May 2014 (UTC)

== DF2014? ==

As Toady [http://www.bay12games.com/dwarves/ draws closer to a new release], it might be worthwhile to discuss the addition of a new version to the wiki. The upcoming release covers two years of changes and introduces a number of new plants, foods, drinks, multi-tile trees, climbing, jumping, etc., so it is likely to have significant changes from the current DF2012. To avoid having people start new pages (and lose all the effort spent refining the prior version's page), I think it would be best to have a bot automatically copy over the DF2012 pages as a starting point for DF2014. I would suggest that these copied pages include a noticebox template mentioning that the content may be outdated, so that we can easily track which pages have been reviewed. I think either the {{tl|version check}} or {{tl|old}} template would work. --[[User:Loci|Loci]] ([[User talk:Loci|talk]]) 19:43, 5 May 2014 (UTC)

:This is what [[User:QuietBot]] did after the 0.34 release, so it's certainly possible to use the same script to migrate to DF2014. I would like a way of tagging migrated pages, since inaccuracies in some pages went unnoticed for months after they were migrated. Since {{tl|old}} is already in use, {{tl|version check}} may be a better solution (it can be reworded slightly, or we can make a separate template for DF2014 migration). —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 19:23, 1 June 2014 (UTC)
:Made [[Template:DF2014 migrated]] as an example. Any thoughts? —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 19:32, 1 June 2014 (UTC)

== Redirects inconsistency ==

Following a redirect is supposed to be exactly the same as going straight to the page it redirects to, but this actually isn't the case:
* Go to [[Seeds]] and you get [[v0.34:Seed]] (outdated)
* Go to http://dwarffortresswiki.org/index.php?title=Seeds&redirect=no and click on the link and you get to [[DF2014:Seed]] (current)
So if you search for "seed", the top result is the DF2014 version. But search for "seeds" and you get the redirect, which sends you to the outdated page instead. [[User:Hairy Dude|Hairy Dude]] ([[User talk:Hairy Dude|talk]]) 23:22, 22 February 2015 (UTC)

While I'm talking about redirects, it seems redirects to sections don't work: see [[DF2014:How do I manage my seeds and crops]]. I know MediaWiki is capable of this trick because Wikipedia does it. [[User:Hairy Dude|Hairy Dude]] ([[User talk:Hairy Dude|talk]]) 23:32, 22 February 2015 (UTC)

:I have absolutely no idea why [[seeds]] redirects to a v0.34 page - it could be a Mediawiki bug. The section links issue is due to a known issue in the redirect extension we use, which has yet to be fixed. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 00:01, 23 February 2015 (UTC)
:It looks like deleting both [[Seeds]] and [[DF2014:Seeds]] fixed things (by allowing AutoRedirect to handle the redirects instead). Feel free to tag any others with {{tl|bad redirect}}. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 00:03, 23 February 2015 (UTC)
::It gets stranger. [[Vial]] redirects explicitly to [[cv:Flask]] which displays (when you look at it with &redirect=no) as [[DF2014:Flask]], but still goes to the v0.34 version. It seems redirects interpret the cv: pseudo-namespace (or whatever it's called) in an outdated way. [[User:Hairy Dude|Hairy Dude]] ([[User talk:Hairy Dude|talk]]) 18:08, 23 February 2015 (UTC)
::I've added a note to this page about this issue. If it gets resolved, the note should be removed. [[User:Hairy Dude|Hairy Dude]] ([[User talk:Hairy Dude|talk]]) 21:04, 23 February 2015 (UTC)

==Reorganizing versions==

The internet deals with moved content... poorly. Google is still linking to v0.34 pages more than a year after the switch to "DF2014", and even the wiki software still has cached links pointing to the old version pages.

I propose reorganizing versions on the wiki to avoid moving content whenever possible. Instead of having a temporary "current version" namespace that changes occasionally, all the current information gets promoted to the Main namespace. When the next version split occurs, the Main articles as of a certain revision number can be copied to the newly-created permanent "old version" namespace, while all the current information remains in Main. This not only fixes the link rot issue, but it has a few other benefits as well: fewer administrative tasks, no lockdown (a historical version of the Main pages can be copied at any point, even if the Main articles are already modified for the new version), almost all the article history is maintained in the Main article (instead of being spread unevenly across multiple versions), no "temporary" namespaces are needed, fewer problematic long redirect chains, and hopefully less user confusion (since Main gets priority in search results, etc.).

As an example, today we would not have a DF2014 namespace (which is good because "temporary" namespaces historically disappear anyway). If you ran a search for [[seed]] you'd end up at Main:seed, which would have all the current information on seeds. The version box at the top of the page would still link to the older versions of the seed article. When a new version is released, an admin would choose a revision number and copy the Main:seed article as it exists at that revision number to v0.40:seed. That's it. One historical copy that needs little to no new editing, and zero redirections/moves.--[[User:Loci|Loci]] ([[User talk:Loci|talk]]) 19:02, 27 July 2015 (UTC)

:Makes sense to me. It would involve a lot of work, though (e.g. fixing templates and categories to account for the current version being in mainspace), although that should be doable thanks to {{tl|category}}, {{tl|version switch}}, etc.. A bot could be set up to copy revisions from before a release date as well, which would be more difficult (and maybe slower) than a direct copy, but not severely. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 17:24, 30 July 2015 (UTC)

:Actually, there are a few issues with that, namely that there wouldn't be an easy way to distinguish between versioned and non-versioned mainspace pages. There are ways to resolve Google search priority (we can exclude pages from older versions from search engine results if there are newer versions of those pages available, for example). —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 19:47, 6 August 2015 (UTC)

::There aren't very many non-versioned mainspace pages, and determining if a page is versioned is as simple as looking for the version template and/or categories added by the version template (e.g. copy [http://dwarffortresswiki.org/index.php/Category:Current this category] instead of Main:*). The problem with "suggesting" newer pages to Google is that they obviously aren't crawling our wiki regularly (if they were, the fact that the mainspace redirects point to new pages would automatically be picked up). Even if your Google hints worked they wouldn't do anything for all the other broken links out on the 'net.--[[User:Loci|Loci]] ([[User talk:Loci|talk]]) 20:35, 6 August 2015 (UTC)

::: Google actually crawls the wiki constantly - we probably get crawl hits from google for a continuous block of 2-3 hours per day, each and every day. Why they are slow to update is beyond me though. I can't remember why we didn't do this initially, but there was a technical limitation involved if I remember correctly. --[[User:Briess|Briess]] ([[User talk:Briess|talk]]) 22:05, 6 August 2015 (UTC)

::: There are <meta> tags that can be used to hide pages from search results (for search engines that recognize them, that is). Searching for {{tl|av}} or [[:Category:Current]] might work, although we'd have to make sure all of the DF2014 pages include that (some pages don't, particularly some disambiguation pages, although all of them should). —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 22:53, 6 August 2015 (UTC)

:Is there a particular reason main and current are separate to begin with?—[[User:CLA|CLA]] ([[User talk:CLA|talk]]) 00:17, 7 August 2015 (UTC)

::It's mostly intended to distinguish between versioned and non-versioned pages and make version-related templates simpler to work with, since every versioned page has a namespace. I wasn't active here in 2010 when this system was created, so Briess and Emi would know more.
::Another issue I just thought of with Loci's suggestion is categories - currently, categories like [[:Category:Animals]] are used to organize the versioned sub-categories. Sure, we can change {{tl|Category}} to categorize mainspace pages in [[:Category:v0.40:Animals]] or [[:Category:DF2014:Animals]], but that would be less straightforward because there wouldn't be a namespace with that name (until pages are migrated when a newer major version is released). —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 13:05, 7 August 2015 (UTC)

:Moving current pages to the main namespace sounds like a great idea. -[[User:Jecowa|Jecowa]] ([[User talk:Jecowa|talk]]) 20:47, 4 January 2018 (UTC)

Another thought: dealing with migrating redirects could be difficult with this proposal - specifically, determining which redirects should be migrated to a versioned namespace. Redirects can't contain {{tl|av}}, at least not before ``#REDIRECT``. I ''think'' it would be possible to copy pages in two stages, though - all non-redirects first, then all redirects whose targets were also copied. Thoughts? Anything I'm missing? —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 23:41, 27 June 2019 (UTC)

Some subpages (particularly /raw and /Edit notice) also deliberately lack {{tl|av}}, although those shouldn't be too hard to handle. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 00:35, 9 July 2019 (UTC)

:Redirect pages (and all other edge cases I've looked at) can be included in categories (like [[:Category:Current]]) to determine whether or not they should be copied into an archival version. But if the redirects are "properly qualified" then they can all be copied over blindly. Mainspace redirects pointing to versioned information should use a blank namespace (which will be automatically constrained to the archival namespace); mainspace redirects pointing to unversioned information should use an explicit "Main" (which will automatically link back to the unversioned page). Then, when [[[[Toady]]]] gets copied to [[[[v0.4x:Toady]]]] it will point back to [[[[Main:Toady One]]]]. Meanwhile, [[[[Beer]]]], copied to [[[[v0.4x:Beer]]]], will properly point to [[[[v0.4x:Alcohol]]]].--[[User:Loci|Loci]] ([[User talk:Loci|talk]]) 20:00, 14 July 2019 (UTC)

::I think qualifying redirects is the best solution here - categorizing redirects manually is another possible source of errors, since categories (or a lack thereof) would only be visible on the redirect page itself, and [[:Category:Current]] is a hidden category. Copying over mainspace redirects into versioned namespaces would also resolve some issues that have come up due to those not reliably existing currently. I should be able to set up a bot script to add "main:" to current mainspace redirects (and it shouldn't break anything, since those redirects go to other mainspace pages anyway). —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 21:57, 14 July 2019 (UTC)

(Note: I wrote all of this without noticing the previous discussion above.) I was wondering, when the wiki creates a new namespace for a major release again, if it is possible to ''not'' create a namespace for the next current version (e.g. "DF202x") and instead have the mainspace articles (which are currently redirects) become the new cv and move the content there. Therefore, [[cv:Cat]] would just be "[[Cat]]" (or [[Main:Cat]]).

Certain namespace-related templates like [[Template:Ns/0]] would need to be changed, though nothing significant as far as I know. For most cases, any "DF2014" would be replaced with "Main" or even blank. There's also multiple extensions handling the current namespace system and they may need to be modified too, though I'm not sure if or how much. I'm guessing based on the discussions above that it will change stuff up.

My reason is the current namespace is increasingly becoming more anachronistic. "DF2014" could be misinterpreted as "this page is about the 2014 version of the game" or "this page was last updated in 2014", which I've seen a few people in forums mention. Granted that [[Template:Av]] is on the top of very article, I still think the namespace is inconsistent with the recentness of the article. But how is this related to what I'm asking for? Let's say we continue the current system: if we happen to do a new namespace change this year and create DF2020, the next major release (after graphics/UI) will be mythgen, which is estimated to take several years to develop (the Big Wait), and so the anachronism will start over again. The proposed way will prevent this from occurring for the next major release and every release thereafter.

I think the confusion with having a namespace that becomes old-fashioned overtime supersedes the confusion with not marking current versioned articles with a namespace. Most users just search "Cat" on the search bar and naturally expect to get information about the latest release of DF. So if users go a page that's just titled "Cat", they won't expect outdated info about cats from a previous release. That's how the current system works anyways. We'll be skipping the two-step process that we have now. It'll make several wiki tasks much simpler as well. Editors can create new articles for current versions without remembering to add a namespace. It'll fix any existing issues with (double) redirects; instead of [[Main:Kitten]] redirecting to [[cv:Kitten]], which goes to [[DF2014:Kitten]], which then redirects to [[DF2014:Cat]], [[Main:Kitten]] would just redirect to [[Main:Cat]]. And the cv: alias will no longer be necessary since "cv:" = "Main:" and will be forever.

There's no need to differentiate the current version and previous versions with a namespace for the current version is what I'm saying. Articles of previous versions will retain their respective namespaces. Users will still type "40d:Cat" to go to the 40d version of the article, but if they want the current version, they'll just type "Cat" (like now). The mainspace containing the "live" version of an article is natural and would create no uncertainty when browsing the wiki. And it would simplify the wiki somewhat and future-proof this anachronism problem. As a bonus, this change will also prevent web search engines from showing previous version pages when typing "DF cat" or something. (This isn't happening right now as DF2014 has been the current namespace for ~6 years, but it'll happen again when everything moves to a new namespace.)

This is the gist of it, and I may have ignored most of the problems with this proposal. I have personally wished for the whole version namespacing be made less complicated and have been seeking for a solution, and I feel like this is the best way to go about in the future. – [[User:Doorkeeper|Doorkeeper]] 21:27, 14 August 2020 (UTC)

:<s>Whoops, looks like Loci already proposed this exact thing long ago. I definitely missed that discussion and should have checked first. My apologies. I'll move my text to that section and remove this one. – [[User:Doorkeeper|Doorkeeper]] 21:36, 14 August 2020 (UTC)</s> Done. – [[User:Doorkeeper|Doorkeeper]] 21:40, 14 August 2020 (UTC)

:The main issue I have with that is that putting pages about the current version in a namespace also differentiates between those pages and pages not about ''any'' version (for example, [[Toady One]] does not need a 40d or v0.34 page). Yes, we can use {{tl|av}} to mark versioned pages, but people often forget to add that to new pages. The current system also allows determining whether a page is versioned or not from its title, which makes migrations a lot faster. Relying on {{tl|av}} would require either reading the content of every page (which would slow scripts down significantly) or cross-checking with the list of all pages including the template (feasible, but a bit more complicated, and still susceptible to missing templates). I suppose that manually fixing and migrating pages missing {{tl|av}} later wouldn't be too much work, though.
:I am definitely in favor of changing "DF2014" (or a new namespace) to "Current", though. I was in favor of "DF2014" in 2014, but I don't think it makes sense anymore, and "Current" seemed to be a popular alternative in both the DF2012 and DF2014 discussions on the matter. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 04:02, 16 August 2020 (UTC)

== Weird redirect behaviour ==

[[Pump stack]] redirects to [[cv:Screw pump#Pump stack]]. If you look at the redirect itself it says it redirects to DF2014 namespace, which is correct. But if you actually follow the redirect, it goes to v0.34 namespace. [[User:Hairy Dude|Hairy Dude]] ([[User talk:Hairy Dude|talk]]) 16:10, 20 August 2018 (UTC)
:Yeah, that's part of the issue described in the above section (the wiki caching part, not on Google's end.) —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 15:00, 21 August 2018 (UTC)

== v50 organization ==

Some wiki admins have had a talk on Discord and decided that the most sustainable path forward is to put content for all future versions of DF in the main namespace. We will be working on a bot to do this in the next few days. Feel free to chime in with suggestions here. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 22:56, 14 December 2022 (UTC)

:Is it maybe possible to do backwards-namespacing? Like we have a "Main" namespace, which people are free to update, and whenever there's a new version of DF the "Main" namespace is copied into a namespace for the then old version, much like how you'd branch a stable branch from a development branch when working with a git-project? [[User:Therahedwig|Therahedwig]] ([[User talk:Therahedwig|talk]]) 23:13, 14 December 2022 (UTC)

::Yeah, we could do that if we decide to. We were talking about doing that for v50, actually, and might still do something similar to preserve edit history if it doesn't end up being too hard to automate. Our hope is that we will not introduce new namespaces for v50 -> v5x, unless there is a serious breaking change (and hopefully there isn't one). But if we change our mind, one advantage of the type of migration you mentioned is that it can be done retroactively - we can copy historical revisions that were current at the time of the release, and would only lose some typo fixes made after the release that apply to earlier versions as well. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 02:11, 15 December 2022 (UTC)

ETA is < 24 hours. Doing some final checks on a migration script. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 07:08, 19 December 2022 (UTC)

: We should really have a task list as there are many things that change and need updating. Including but not limited to:
:* Most templates that used the previous namespace convention broke, including nav templates.
:* Many game files changed locations and their pages need to be updated.
:* Raws need to be updated.
:* Various features added, changed, removed.
:* UI has been changed -- though I am more inclined to wait for classic release to avoid extra work --[[User:Jan|Jan]] ([[User talk:Jan|talk]]) 06:56, 20 December 2022 (UTC)

"''Raws need to be updated.''" Including applying text wraparound where necessary, I suppose - more than a few of them have proven to be that special kind of...''difficult'' to navigate otherwise, shall we say? [[User:Silverwing235|Silverwing235]] ([[User talk:Silverwing235|talk]]) 12:52, 20 December 2022 (UTC)

:There is already a task list in the [[#v50 migration|section below]] that includes templates and raws, with an explanation. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 16:25, 20 December 2022 (UTC)

== v50 migration ==

The initial migration script is done. New content is in the '''main''' namespace, e.g. [[Cat]]. Old content is still at [[DF2014:Cat]]. History was migrated to the ''new'' (main namespace) articles.

I know several things are broken still. Please reply if you find any others:
<div style="border-left: 2px solid red">
* <s>Versioned templates haven't been migrated yet (e.g. {{tl|vermin}} on [[Ant]])</s>
** Fixed. Most were migrated by a bot.
* <s>Raws are missing on all pages that use them.</s>
** This also affects sidebars, such as on [[Cat]] and [[Microcline]].
** Update: The DFRawFunctions extension has been upgraded to include v50 raws, using the "v50:" prefix for filenames instead of "DF2014:". <s>I haven't finished a migration script to create the /raw pages themselves, but they can typically be created manually by copying the DF2014 /raw pages and changing "DF2014" to "v50" everywhere.</s> —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 20:20, 1 January 2023 (UTC)
** Update 2: Raws have been added for all pages! They were copied from the "DF2014" pages and had "DF2014" replaced with "v50", which appears to have worked from a spot-check, but let me know if you find any problems. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 05:57, 4 January 2023 (UTC)
* Some pages where the DF2014 page was a redirect to a main namespace page that contained content were migrated incorrectly.
** In this case, the main namespace page is usually a redirect to itself. This can be fixed by undoing LethosorBot's edit to the main namespace page, then copying the content to the DF2014 page.
** Update: most seem to have been fixed manually - thanks! —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 19:41, 21 December 2022 (UTC)
* <s>Some main-namespace talk pages redirect to DF2014 talk pages. Some of these redirects work, and some (usually older ones) do not.</s>
** Fixed with a bot. Some redirects from talk pages to other deleted talk pages are now broken, e.g. [[Talk:Above_ground]] (exists) -> [[Talk:Tile attributes]] (redlink). I am leaving them like that because they redirect to where the talk page should be created, but I'm also fine with people deleting them if they really want to. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 19:41, 21 December 2022 (UTC)
* {{tl|quality}} for new articles is disabled (see below)
* Some links from DF2014 to Main weren't working: e.g. the version selector [[DF2014:Mason's workshop]] was linking to [[DF2014:Main:Mason's workshop]] instead of [[Main:Mason's workshop]]. I'm not sure exactly why, but I fixed it with a change to the NamespaceLinks extension. Let me know if you spot similar broken links. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 23:19, 21 December 2022 (UTC)
</div>

—[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 04:54, 20 December 2022 (UTC)
:The quality levels of the 50.03 pages seem to be missing. I'm not sure if that's covered under that first point. [[User:Trainzack|Trainzack]] ([[User talk:Trainzack|talk]]) 06:47, 20 December 2022 (UTC)
::If the the [[Dwarf Fortress Wiki:Quality]] feature can be made to work with namespace scheme change, I suggest to automatically assign the lowest quality rating to all pages, alternately add the {{tl|old}} to all pages. Otherwise there will be a lot of pages that will fall through the cracks. --[[User:Jan|Jan]] ([[User talk:Jan|talk]]) 09:12, 20 December 2022 (UTC)
:::I disabled {{tl|quality}} in the main namespace because it would require some rework to make the rating script and the template work properly there. Feel free to take a stab at the template. I will see what can be done on the extension side. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 21:14, 20 December 2022 (UTC)
::::What needs to be done on the template side? I'm not sure I see too big of an issue leaving pages as "unknown-quality" for now (or just change the default to tattered) until we get the rating script working. Is that script up anywhere, anything that could be helped with? [[User:Vallode|Vallode]] ([[User talk:Vallode|talk]]) 11:10, 2 January 2023 (UTC)
:::::They're already marked as unknown. Really the only issue I know of with the template is that it doesn't show up with some of the newer skins we added, and that can be fixed by getting rid of the absolute positioning. As for the script, it can be found at https://github.com/DF-Wiki/QualityRatings, and the issue is really only with the configuration system not recognizing the main namespace as valid. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 02:29, 3 January 2023 (UTC)
::::::Great, I started having a crack at fixing the template with different themes. Is the preference to get some CSS going and then include it in the global stylesheet (i.e different styles per theme) or to try and get a "one size fits all" fix? —[[User:Vallode|Vallode]] ([[User talk:Vallode|talk]]) 08:14, 3 January 2023 (UTC)
:::::::I would rather avoid custom site-wide CSS if we can. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 03:29, 4 January 2023 (UTC)
::::::::I appreciate that, I think it's the simplest solution to add a few lines to common.css though. Unless there is a way to attach CSS specifically to a template, I saw a few extensions that allowed that but I'm not sure if any are present in the wiki at the moment. Regardless there already exists a class `div.topicon` that is specifically for the quality ratings, is there an issue with expanding this class to accommodate the themes? The list of themes where the quality rating display is broken/invisible: Citizen, MinervaNeue, MonoBook. —[[User:Vallode|Vallode]] ([[User talk:Vallode|talk]]) 21:48, 4 January 2023 (UTC)
:::::::::What do you think of moving the template out of the topicon entirely and just placing it in a div? It would take up a (hopefully) small amount of vertical space in the article. [[User:Lethosor/Sandbox/Quality_test]] is an example. Unfortunately it isn't possible to prevent other templates from displaying above the quality this way ([https://dwarffortresswiki.org/index.php?title=User:Lethosor/Sandbox/Quality_test&oldid=283883]). So maybe we do need some custom CSS after all if we want that. I'm open to trying out whatever you propose. I'm a bit worried about future-proofing against skins we add later (particularly a mobile skin) but at least MediaWiki supports skin-specific global CSS as well. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 00:33, 5 January 2023 (UTC)
::::::::::I would rather we avoid taking any more vertical space in the article. The growing block pyramid at the top, starting with version template, is annoying. If you end up placing it inside the article space please use a slim box 100% wide that would include both.--[[User:Jan|Jan]] ([[User talk:Jan|talk]]) 01:19, 5 January 2023 (UTC)
:::::::::::Agreed with you Jan, however I see that as two different tasks (ArticleVersion template changes, getting quality back on pages). I made a test adjustment to the quality and it takes up a negligable amount of extra space. See [[User:Vallode/sandbox#Page_quality]] for the example, we'd be able to completely remove "topicon" (unless it is used somewhere else?) and then potentially move on to making the ArticleVersion template into a slim version on the left-hand-side instead of a large box? Let me know what you think. --[[User:Vallode|Vallode]] ([[User talk:Vallode|talk]]) 17:35, 5 January 2023 (UTC)
:::::::::::: Sorry, I just noticed this, I hope you weren't waiting on me. I haven't looked into how it works. All I can say that it would be nice if it shows on main, it is annoying that it shows on discussion and history. And otherwise I think that those negligible spaces adds up when you have multiple notice, redirection etc templates and would prefer if you can [https://ibb.co/X7X7SjL condense all of it] somehow. I also had [https://dwarffortresswiki.org/index.php/User:Jan/sandbox#Misc_variants couple of ideas] on that front, but as dev designer you probably can come up with something more refined if this is direction you choose. --[[User:Jan|Jan]] ([[User talk:Jan|talk]]) 00:50, 10 January 2023 (UTC)

It appears some pages are redirecting recursively and never resolving correctly, like the [[https://dwarffortresswiki.org/index.php?title=Character_table&redirect=no|character table]] and [[tileset repository]] 07:35, 20 December 2022 (UTC)
: Indeed, these can be caught here: [[Special:DoubleRedirects]] --[[User:Jan|Jan]] ([[User talk:Jan|talk]]) 07:51, 20 December 2022 (UTC)

It might be useful to change the notice title to "release information '''for editors'''" --[[Special:Contributions/142.59.195.176|142.59.195.176]] 10:26, 20 December 2022 (UTC)
:Can do. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 16:27, 20 December 2022 (UTC)
::New here, hello. Should we set a date where we remove/only show the banner for logged in users. There are (some) pages that have 4 different notices about the upgrade. [[Engraving]] is one such page, the top banner states "information for editors", we then have the "this page was migrated" banner, a version selection which warns the article might be inaccurate, and a smaller banner saying the page might need to be updated. Quite a lot of screen space, I think we can start to slowly reduce the amount of warnings this coming month? [[User:Vallode|Vallode]] ([[User talk:Vallode|talk]]) 10:07, 2 January 2023 (UTC)
:::Unfortunately, only showing info to logged-in users is difficult with how MediaWiki caching works. In terms of reducing warnings, there is a discussion [[Template_talk:ArticleVersion#.22Note_that_some_content_may_still_need_to_be_updated..22|here]]. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 21:43, 4 January 2023 (UTC)
:::As for [[Engraving]] specifically, the {{tl|old}} banner was actually present on [[DF2014:Engraving]] as well and got carried over with the migration. I removed it, and agree that it was redundant. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 21:46, 4 January 2023 (UTC)

Main talkpages seem to redirect to DF2014 talk. Not sure if it is intentional but I like it, though we should pay attention when creating new discussion relating to v50 ending up there.--[[User:Jan|Jan]] ([[User talk:Jan|talk]]) 14:18, 20 December 2022 (UTC)
:That's unintentional. I specifically wrote the migration script to not move talk pages, but that has the side-effect of leaving any previously-created "Talk -> DF2014 talk" redirects intact. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 16:27, 20 December 2022 (UTC)

Yo Lethosor, are we adding graphic sprites for the pages in some way? Or are we waiting for you to add some sort of new template or something? I'm sure you don't need me to tell you that the current templates don't allow that. Not sure if I'm allowed to change/create any templates either, as I don't want to break things for hundreds of pages. Edit: And IF the icons are allowed, should they be left alone, or 2×-3× sized like how the Minecraft wiki does it? --[[User:Zippy|Zippy]] ([[User talk:Zippy|talk]]) 14:29, 20 December 2022 (UTC)
:Depends on which templates you mean. There are copyright concerns with uploading a premium sprite sheet, for instance. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 16:27, 20 December 2022 (UTC)
::I'm not talking about uploading an entire sprite sheet. I'm just talking about individual icons for each respective page. One image for cows, one for horses, one for werebeasts, etc. --[[User:Zippy|Zippy]] ([[User talk:Zippy|talk]]) 16:50, 20 December 2022 (UTC)
:::If we do that for every creature in the sprite sheet, that's not much different (in terms of copyright) from uploading the entire sprite sheet. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 17:09, 20 December 2022 (UTC)
::::Is there someone we can talk to about that? We finally get this new game with graphics, and then we can't use the very graphics of the game? No matter what the rules are, I'd say that would be the stupidest thing ever. I know I'm infamous here when it comes to copyright and images and stuff, but about 80% of game wikis out there are completely unofficial, and use game file images like no one's business. I can't imagine anyone's door being knocked on if we used the game's sprites, but I won't add any here until we have a go-ahead. --[[User:Zippy|Zippy]] ([[User talk:Zippy|talk]]) 17:14, 20 December 2022 (UTC)

:::::...I've made noise in Mayday's direction on this matter, at least (prob an incorrect maneuver, ''but'').[[User:Silverwing235|Silverwing235]] ([[User talk:Silverwing235|talk]]) 17:55, 20 December 2022 (UTC)
:::::: I hope some sort of arrangement can be made so we can use the new sprites with permission/limits, just as we are using the raw files. Otherwise we are all (devs and editors alike) shooting ourselves in the foot here.--[[User:Jan|Jan]] ([[User talk:Jan|talk]]) 21:07, 20 December 2022 (UTC)

:::::::I just thought of something. We're supposedly not allowed to upload entire sprite sheets, right? What if - for the time being - we just use a few of them for the purpose of testing out new infoboxes? --[[User:Zippy|Zippy]] ([[User talk:Zippy|talk]]) 21:46, 20 December 2022 (UTC)
::::::::I don't know. If someone could ask Kitfox and post the response here, that would be great. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 21:47, 20 December 2022 (UTC)

:::::::::I've reached out to Alexandra, but she hasn't answered yet. Until then I found these old approvals from the previous community manager, Feeona: ([http://www.bay12forums.com/smf/index.php?topic=173474.msg8243633#msg8243633 link1], [http://www.bay12forums.com/smf/index.php?topic=176640.msg8243642#msg8243642 link2]). Waiting for a newer response until we begin mass uploads is probably the politer option, but like Zippy said, it is also standard for wikis to use game sprites with less approval. I second their idea of trying it out with a few images to test the infoboxes. On the extreme off-chance (and I do think it is) Kitfox protests we can always remove these few. --[[User:Voliol|Voliol]] ([[User talk:Voliol|talk]]) 22:19, 20 December 2022 (UTC)
:::::::::And here is a third, more official statement: ([http://www.bay12forums.com/smf/index.php?topic=173474.msg8249718#msg8249718 link3]). Perhaps that address of info@kitfoxgames.com is the better channel to ask for a confirmation, rather than Discord DMs, but I will be going to bed, so it is best if someone else does that. --[[User:Voliol|Voliol]] ([[User talk:Voliol|talk]]) 22:29, 20 December 2022 (UTC)
::::::::::Thanks for tracking this down! Ok, sprites should be fine, but let's avoid uploading the entire premium tileset as a single image, for instance (as the forum thread says, "use common sense"). —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 00:21, 21 December 2022 (UTC)
::::::::::: Looks good, permission is always preferable over fairuse, I think it is a win win for all involved. I agree that we shouldn't upload entire sprite sheets (e.g. there is no reason to upload the windmill from every direction or whole construction phase for workshops) and that there are a lot of details that needs to be ironed out through testing. --[[User:Jan|Jan]] ([[User talk:Jan|talk]]) 05:07, 21 December 2022 (UTC)
:::::::::We have a green light on uploading all and any sprites. Their response to me can be seen [https://i.imgur.com/BhmHjzC.png here]. I'm sure someone else confirmed it before me. --[[User:Zippy|Zippy]] ([[User talk:Zippy|talk]]) 19:00, 21 December 2022 (UTC)

Shifting temporarily to a new issue, is the documentation of [[Template:ArticleVersion]] outdated? It would seem so to me, since the current version no longer has its own namespace, with the templates needing updating being different ones. --[[User:Voliol|Voliol]] ([[User talk:Voliol|talk]]) 18:30, 20 December 2022 (UTC)
:I think it is still accurate enough. We left open the possibility of making another namespace in the future, albeit with a different migration strategy - see [[#v50 organization|above]]. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 21:52, 20 December 2022 (UTC)

Some Changes to infoboxes might be needed. Too bad [[User:Doorkeeper]] isn't around. He did a great work with navbox project--[[User:Jan|Jan]] ([[User talk:Jan|talk]]) 20:52, 21 December 2022 (UTC)

I just realized that raw files aren't stored as regular wiki pages but loaded via the DFRawFunctions extension (hence the need to update). Good news it's going to be handled in bulk, consistently and relatively easy to updated. Even better it's Lethosor problem ;) Also I just realized that all the "raw files" (txt files in the new vanilla folder) are released into the public domain. Both are probably not news to the vets but I'll leave it here for those who less up to date like myself. --[[User:Jan|Jan]] ([[User talk:Jan|talk]]) 07:35, 22 December 2022 (UTC)

: I noticed that some templates aren't working properly in the new namespace, e.g. [[Basalt]] entry had its raw updated manually but the infobox fail to show any details. Cursory look suggest {{t|layerlookup/0}} need a minor tweak. This should do the work
:: Replace: <nowiki>{{layerlookup/aux|{{{{FULLPAGENAME}}/raw}}|uses={{{uses|}}}|wiki={{{wiki|}}}}}</nowiki>
:: With___: <nowiki>{{layerlookup/aux|{{</nowiki>:<nowiki>{{FULLPAGENAME}}/raw}}|uses={{{uses|}}}|wiki={{{wiki|}}}}}</nowiki>
: Not sure what the plan and ETA with raws update so I didn't touch this high usage template for now. --[[User:Jan|Jan]] ([[User talk:Jan|talk]]) 08:11, 24 December 2022 (UTC)

::Please do feel free to make this update. I am still working on a script to create the <code>/raw</code> pages themselves. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 03:12, 1 January 2023 (UTC)

Wouldn't it be an idea to add to the Sitenotice to remove the {{tl|migrated article}} tag when an article has been fully updated? I see many articles that seem to be updated still have the tag. And/or advise to make use of the {{tl|verify}} for sections still in need of checking? --[[User:Halavus|Halavus]] ([[User talk:Halavus|talk]]) 10:12, 2 January 2023 (UTC)
:Probably a good shout. The "see this page" link does include the detail on removing but we should more explicitly encourage removing the banner once a page has at least been looked over. [[User:Vallode|Vallode]] ([[User talk:Vallode|talk]]) 11:01, 2 January 2023 (UTC)

== v50 specific issues ==
=== Graphics===
Follow up on the use of game sprites and the need to trying it out with a few images to test the infoboxes. First sprite [[:File:Beds v50.png]] was uploaded and used on [[Bed]] entry. Any thoughts? --[[User:Jan|Jan]] ([[User talk:Jan|talk]]) 18:06, 21 December 2022 (UTC)
:Seems like it should be rearranged to be horizontal. Also, has there been a serious discussion about copyright? Full screenshots are 100% fine, but you start going into a grey area when you upload pieces of a spritesheet. I'm of the opinion that it's all fine as long as it's inconvenient to reconstruct the full sheet from the individual images. Maybe a further restriction could be you shouldn't upload any of the art unless it's used in an infobox (maybe an exception for pieces of the UI). And one more restriction could be you shouldn't show everything, like in your bed example, maybe just the wooden bed is good enough, leave out the stone and metal, especially since those can only be made from strange moods. [[User:Brightgalrs|Brightgalrs]] ([[User talk:Brightgalrs|talk]]) 18:43, 21 December 2022 (UTC)
::Actually, your bed image is kinda bad for showing off what a bed looks like because it doesn't show the pillow/blankets. That might point to cropped screenshots being the best path, although less convenient for the uploader, as you don't get details left out. [[User:Brightgalrs|Brightgalrs]] ([[User talk:Brightgalrs|talk]]) 18:46, 21 December 2022 (UTC)
::I created a new license template [[Template:Copyright game]], based it on the way the RimWorld wiki does things. Call it a prototype, but it's probably how your bed image should be labelled. Indeed, I added it to it already. [[User:Brightgalrs|Brightgalrs]] ([[User talk:Brightgalrs|talk]])

::: I agree that the horizontal arrangement would suit better here and that we should strive to represent how things look in-game. Otherwise, I am not too concerned about people being able to reconstruct anything (lets just say that ''anyone'' interested in that can get the real thing from the game files), also it seem we have permission to use the sprits on top of fairuse. --[[User:Jan|Jan]] ([[User talk:Jan|talk]]) 19:55, 21 December 2022 (UTC)

::: Modifying the existing template to allow the inclusion of the new sprites is easy (Something like [https://ibb.co/zFXCrjd this]?) The big question is the matter of consistency is there any exceptions that will break the format (size wise with variant bloat for example), the sprite naming format, etc --[[User:Jan|Jan]] ([[User talk:Jan|talk]]) 20:44, 21 December 2022 (UTC)
::: If we are going to show a variant for each material type, then maybe these should be added as separate images so we can add a tooltip for each image. --[[User:Jan|Jan]] ([[User talk:Jan|talk]]) 20:49, 21 December 2022 (UTC)

:I've got another prototype going here and here: [[User:Brightgalrs/vector.css]] and [[User:Brightgalrs/Sandbox]]. (You'll need to add the css stuff to your own /vector.css). Basically it's a way to recolor images using css classes. No idea if there's a better way. Also, the real implementation would require a change to [[MediaWiki:Common.css]]. [[User:Brightgalrs|Brightgalrs]] ([[User talk:Brightgalrs|talk]]) 22:41, 21 December 2022 (UTC)
:Should mention, there ''is'' a different way, just upload each image 16 times, one for each coloring. But maybe that's not very elegant. [[User:Brightgalrs|Brightgalrs]] ([[User talk:Brightgalrs|talk]]) 22:45, 21 December 2022 (UTC)

: It should be noted that soon the classic edition will be released, hence one should plan to have both the Premium and classic alongside in that little space --[[User:Jan|Jan]] ([[User talk:Jan|talk]]) 03:14, 22 December 2022 (UTC)
::I'm looking into a tab extension to potentially support this in infoboxes. Perhaps [https://www.mediawiki.org/wiki/Extension:Tabs Extension:Tabs]? I tried [https://www.mediawiki.org/wiki/Extension:TabberNeue Extension:TabberNeue], but it displays a placeholder if JavaScript is disabled, which isn't great. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 04:22, 22 December 2022 (UTC)
::: The Neue Tabber seem to works pretty much like the old one (which fandom [https://coding-help.fandom.com/wiki/Tabber#Adding_images_into_tabbers still use]) defaulting to showing the first tab only. Quick look suggest that neue work the same, plus the notice that 'Tabber requires Javascript to function' warning? if so, and if it is a bother, then you should be able to edit out the tabberneue-noscript string in code. --[[User:Jan|Jan]] ([[User talk:Jan|talk]]) 06:29, 22 December 2022 (UTC)
::: I much prefer your tabber solution, but if that fails we can also use the gallery slideshow mode. If so, beware it has no way to control image size so the images have to be maliciously uploaded using the exact same size. example:
<gallery mode="slideshow">
File:SteelSample.png
File:TinSample.png
File:ZincSample.png
File:GoldSample.png
</gallery> --[[User:Jan|Jan]] ([[User talk:Jan|talk]]) 10:19, 22 December 2022 (UTC)

==== adding premium set to Infobox ====
I am unclear where are we going with this? 
1) Will (A) tabs be implemented, (B) we be using mediawiki toggle [[Template_talk:V50_workshop|example]] for premium and classic/blocked, (c) put images side by side, or (d) something else? 
2) Also [[silver]] and [[Pig iron]] use very different image style for example. 
3) Anything else you want ? --[[User:Jan|Jan]] ([[User talk:Jan|talk]]) 12:32, 30 December 2022 (UTC)

: Personally, I would love tabs to be implemented, but I think that side by side might be best for most. --[[User:Jan|Jan]] ([[User talk:Jan|talk]]) 12:32, 30 December 2022 (UTC)
: Here is rough layout we can use. It should fit most buildings given the default sprite size. There is also a different floor plan for both (inspired by reddit)

{|
|- valign=top
|
{| style="width:200px; background-color:#eaecf0; border-collapse: collapse; "
|+ 5×5
|- style="border-bottom:2px solid #3366cc; "
|<div class="mw-customtoggle-infoboxtab mw-ui-button mw-ui-progressive" style="border-top-right-radius: 10px; border-top-left-radius:10px;">toggle</div>
|{{Tooltip|Hotkey|adasdasdasd}}: {{Key|b|o|g}}
|- valign=top
|colspan=2|<div class="mw-collapsible" id="mw-customcollapsible-infoboxtab">
[[File:Siege workshop.png|center|160px]]</div>
<div class="mw-collapsible mw-collapsed" id="mw-customcollapsible-infoboxtab"">
{|
|rowspan=2 style="width:50%; font-size: 125%;"|<center>{{Template:Picture Siege workshop}}</center>
|style="line-height: 1em; font-size: 125%;"|
{| style="border-spacing:4px;"
| style="width:12px; height:12px; background-color:#b7b9bd; border:1px solid #545557;"|
| style="width:12px; height:12px; background-color:#b7b9bd; border:1px solid #545557;"|
| style="width:12px; height:12px; background-color:#b7b9bd; border:1px solid #545557;"|
| style="width:12px; height:12px; background-color:#b7b9bd; border:1px solid #545557;"|
| style="width:12px; height:12px; background-color:#b7b9bd; border:1px solid #545557;"|
|-
| style="width:12px; height:12px; background-color:#b7b9bd; border:1px solid #545557;"|
| style="width:12px; height:12px; background-color:#86878a; border:1px solid #545557;"|
| style="width:12px; height:12px; background-color:#86878a; border:1px solid #545557;"|
| style="width:12px; height:12px; background-color:#86878a; border:1px solid #545557;"|
| style="width:12px; height:12px; background-color:#b7b9bd; border:1px solid #545557;"|
|-
| style="width:12px; height:12px; background-color:#b7b9bd; border:1px solid #545557;"|
| style="width:12px; height:12px; background-color:#b7b9bd; border:1px solid #545557;"|
| style="width:12px; height:12px; background-color:#b7b9bd; border:1px solid #545557;"|
| style="width:12px; height:12px; background-color:#b7b9bd; border:1px solid #545557;"|
| style="width:12px; height:12px; background-color:#b7b9bd; border:1px solid #545557;"|
|-
| style="width:12px; height:12px; background-color:#b7b9bd; border:1px solid #545557;"|
| style="width:12px; height:12px; background-color:#86878a; border:1px solid #545557;"|
| style="width:12px; height:12px; background-color:#86878a; border:1px solid #545557;"|
| style="width:12px; height:12px; background-color:#86878a; border:1px solid #545557;"|
| style="width:12px; height:12px; background-color:#b7b9bd; border:1px solid #545557;"|
|-
| style="width:12px; height:12px; background-color:#b7b9bd; border:1px solid #545557;"|
| style="width:12px; height:12px; background-color:#b7b9bd; border:1px solid #545557;"|
| style="width:12px; height:12px; background-color:#b7b9bd; border:1px solid #545557;"|
| style="width:12px; height:12px; background-color:#b7b9bd; border:1px solid #545557;"|
| style="width:12px; height:12px; background-color:#b7b9bd; border:1px solid #545557;"|
|}
|-
| style="text-align: center;" | Layout
|}
</div>
|}
|
{| style="width:200px; background-color:#eaecf0; border-collapse: collapse; "
|+ 3×3
|- style="border-bottom:2px solid #3366cc; "
|colspan=2 style="text-align: right;"|<div class="mw-customtoggle-infoboxtab mw-ui-button mw-ui-progressive" style="float:left; border-top-right-radius: 10px; border-top-left-radius:10px;">toggle</div>{{Tooltip|Hotkey|adasdasdasd}}: {{Key|b|o|g}}
|- valign=top
|rowspan=2 style="width:50%;"|
<div class="mw-collapsible" id="mw-customcollapsible-infoboxtab">[[File:Carpenter's workshop.png]]</div>
<div class="mw-collapsible mw-collapsed" id="mw-customcollapsible-infoboxtab""><center>
{| style="font-size: 175%; border-spacing: 0; background-color: black; border: 2px solid black"
|- 
| style="padding: 0; line-height: 1em"|
| style="padding: 0; line-height: 1em"| {{Raw Tile|"|7:0:0}}
| style="padding: 0; line-height: 1em"| {{Raw Tile|{{=}}|6:0:0}}
|-
| style="padding: 0; line-height: 1em"| {{Raw Tile|░|0:7:1}}
| style="padding: 0; line-height: 1em"|
| style="padding: 0; line-height: 1em"|
|-
| style="padding: 0; line-height: 1em"| {{Raw Tile|░|0:7:1}}
| style="padding: 0; line-height: 1em"| {{Raw Tile|]|0:0:1}}
| style="padding: 0; line-height: 1em"| {{Raw Tile|░|0:7:1}}
|}</center></div>
|
{| style="border-spacing:5px;"
| style="width:18px; height:18px; background-color:#b7b9bd; border:1px solid #545557;"|
| style="width:18px; height:18px; background-color:#b7b9bd; border:1px solid #545557;"|
| style="width:18px; height:18px; background-color:#b7b9bd; border:1px solid #545557;"|
|-
| style="width:18px; height:18px; background-color:#86878a; border:1px solid #545557;"|
| style="width:18px; height:18px; background-color:#b7b9bd; border:1px solid #545557;"|
| style="width:18px; height:18px; background-color:#b7b9bd; border:1px solid #545557;"|
|-
| style="width:18px; height:18px; background-color:#86878a; border:1px solid #545557;"|
| style="width:18px; height:18px; background-color:#b7b9bd; border:1px solid #545557;"|
| style="width:18px; height:18px; background-color:#86878a; border:1px solid #545557;"|
|}
|-
| style="text-align: center;" | Layout
|}
</div>
|
{| style="width:200px; height:100px; padding:10px; background-color:#eaecf0; border-collapse: collapse;"
|+ 1×1
|- style="border-bottom:2px solid #3366cc;"
| colspan=3 style="text-align:center;"|{{Tooltip|Hotkey|adasdasdasd}}: {{Key|b|o|g}}
|-
| style="border-right: 1px dotted #545557;"|[[File:Screw_press.png|32px|center|link=]]
| style="font-size:125%;"|<center>{{Template:Picture Screw press}}</center>
| style="border-left: 1px dotted #545557;"|<center>{{Template:Floor Plan Screw press}}</center>
|}
|
{| style="width:200px; height:100px; padding:10px; background-color:#eaecf0; border-collapse: collapse;"
|+ 1×3
|- style="border-bottom:2px solid #3366cc;"
| colspan=3 style="text-align:center;"|{{Tooltip|Hotkey|adasdasdasd}}: {{Key|b|o|g}}
|-
| style="border-right: 1px dotted #545557;"|[[File:water_wheel.png|32px|center|link=]]
| style="font-size:125%;"|<center>{{Template:Picture Water wheel}}</center>
| style="border-left: 1px dotted #545557;line-height:normal;"|<center>{{Template:Floor Plan Water wheel}}</center>
|}
|}
:Any thoughts on the direction and or any and all of its elements? --[[User:Jan|Jan]] ([[User talk:Jan|talk]]) 10:16, 31 December 2022 (UTC)

::I kind of like side-by-side, if it fits. If anyone wants to implement a toggle button or tabs, I would ask that that be implemented in a template for now, so that e.g. we could change a toggle button to tabs in a single place if we decide to install an extension to support that. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 03:14, 1 January 2023 (UTC)

::: I noticed a comment saying that [[impassable tile]] are no longer used in v50, is that true for all constructions? If so, floor plans are no longer needed, making things much easier as we can fit everything in except the 5v5 constructions like trade depot (and even these can be placed one above the other if so desired). If not, any thought on the alternative floor plan design? --[[User:Jan|Jan]] ([[User talk:Jan|talk]]) 07:46, 1 January 2023 (UTC)

:::: None of the constructions have blocking tiles any more from my experience playing. I haven't tested siege weaponry with that stuff, but none of the workshops have it, nor does any furniture. (walls and fortifications will of course obstruct movement [[User:AndrielChaoti|AndrielChaoti]] ([[User talk:AndrielChaoti|talk]]) 18:47, 1 January 2023 (UTC)
::::: Ok, I have removed them from v50. --[[User:Jan|Jan]] ([[User talk:Jan|talk]]) 23:48, 1 January 2023 (UTC)

I have added a basic side by side variant to [[Template:V50 workshop]] and [[Template:Building]] for testing, let us know if there any issues. Few notes:
* The default image naming scheme of <code>workshop-name.png</code> will likely conflict with existing images here or on commons, maybe another naming scheme should be used like <code>v50 workshop-name.png</code> as it is with ascii pictures.
* There is inconsistency in image size. If you want to use large zoomed images then toggle is best, otherwise they need to be all in native size (96px for 3x3).
* In the current version the code roughly centers the images and if there is a big image like with [[Siege workshop]] it drops to a new line --[[User:Jan|Jan]] ([[User talk:Jan|talk]]) 23:48, 1 January 2023 (UTC)

How about combining shortcut keys and the new menu icons:
<div style="color:white; font-size: large; text-shadow: -1px -1px 0 #000, 1px -1px 0 #000, -1px 1px 0 #000, 1px 1px 0 #000;">[[File:Ui b.png]]<div style="position: absolute; bottom:-14px; right:3px;">b</div>[[File:Ui bo.png]]<div style="position: absolute; bottom:-14px; right:3px;">o</div>[[File:Ui bol.png]]<div style="position: absolute; bottom:-14px; right:3px;">l</div>[[File:Ui boll.png]]<div style="position: absolute; bottom:-14px; right:3px;">l</div></div>
--[[User:Jan|Jan]] ([[User talk:Jan|talk]]) 02:24, 3 January 2023 (UTC)

:I worry that this is difficult to read (I read it as "boil" at first). I would rather use something like {{tl|k}} with a known background. What about something like this? [[File:Ui boll.png]]<div style="position: absolute; bottom:-14px; right:0px;">{{k|l}}</div> or, alternatively, using flexbox without any overlap: [[File:Ui boll.png]]{{k|l}} —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 02:37, 3 January 2023 (UTC)
:: Same, but that is the best I came up with. We can use the key or maybe someone can help improve the design. Also 'l' is hard to read even with {{t|key}}.--[[User:Jan|Jan]] ([[User talk:Jan|talk]]) 03:05, 3 January 2023 (UTC)
:: I added a {{t|Menu icon}} to start things so others can have a go with it. Also any thoughts on the icon naming convention (their shortcut sequence), is there easier/better way? --[[User:Jan|Jan]] ([[User talk:Jan|talk]]) 09:36, 3 January 2023 (UTC)
::[[User:BarelyCreative]] updated the template: {{Menu icon|b|o|l|y}}. I think it looks good, thoughts? --[[User:Jan|Jan]] ([[User talk:Jan|talk]]) 18:40, 3 January 2023 (UTC)
:::I like that, yeah. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 03:29, 4 January 2023 (UTC)
::::There were some places where it didn't make sense so display every icon all the time (like step-by-step guides), so I changed it slightly to allow display of fewer icons using "num" and counting from the end: <nowiki>{{Menu icon|b|o|l|y|sep=-;|num=2}}</nowiki> {{Menu icon|b|o|l|y|sep=-|num=2}} [[User:BarelyCreative|BarelyCreative]] ([[User talk:BarelyCreative|talk]]) 09:05, 4 January 2023 (UTC)

==== Bizarre palette-swapping idea/prototype ====
No idea if this is a good idea, since it takes a bit of time to set up, and there might be some performance issues... and maybe display issues?

But take a look at this:
{{User:Brightgalrs/Sandbox/PaletteSwitch|templatename=User:Brightgalrs/Sandbox/Rock|palette-name=amber}}

It's way to swap palettes on an image, although the image itself is a table, with each cell representing a pixel. The template itself looks like this:
<code><nowiki>{{User:Brightgalrs/Sandbox/PaletteSwitch|templatename=User:Brightgalrs/Sandbox/Rock|palette-name=saffron}}</nowiki></code>
Input the pattern and desired palette name.

I've got a larger showcase here: [[User:Brightgalrs/Sandbox/PaletteSwapShowcase]]. Only did a rock pattern so far, but all palettes are implemented.
The major use for this would be on each stone, metal, wood, etc. type's page. The palette could be read directly from the raws. [[User:Brightgalrs|Brightgalrs]] ([[User talk:Brightgalrs|talk]]) 03:22, 24 December 2022 (UTC)

:From a technical perspective, my primary concern is indeed performance. Both on the server side and client side, a large number of tables that large (in terms of markup and cell count, that is) tend to be resource-intensive to generate and render. I saw your image-filtering experiments on [[User:Brightgalrs/vector.css]], and while that strikes me as a newer and less-backwards-compatible approach, it would probably be more resource-friendly.
:Is this color adjustment something the game is doing natively? i.e. does this accurately match what the game displays? I bet we could slap together an image-filtering extension (or find an existing one?) that can do this if needed. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 03:49, 24 December 2022 (UTC)
::Yeah that's what I suspected. The images the template creates are spot on, checked it against a screenshot I took of some mica rocks in-game. The css stuff is unfortunately totally incorrect, was cool to learn about it though, so not a complete waste of my time :p. The premium, in-game graphics are true sprites, basically patterns of indexed colors. Each of the in-game colors (which are significantly expanded over the 16 ascii colors, there's 116/117) there is a palette defined in "\Dwarf Fortress\data\vanilla\vanilla_descriptors_graphics\graphics\images\palettes.png". Each indexed color of the sprite is swapped for the corresponding color in the palette. Because of that, the css stuff doesn't work since it's doing the hue/saturation/brightness changes to the entire sprite.
::I've looked into an existing mediawiki extension, couldn't find anything. One thing I did't really look at is some type of lua script/module that would basically emulate what the game is doing. So some function that takes in the base image as well as the desired palette, and based on that finds and replaces each color. No idea what mediawiki's capabilities are on that front. [[User:Brightgalrs|Brightgalrs]] ([[User talk:Brightgalrs|talk]]) 05:31, 24 December 2022 (UTC)
:::We do have Scribunto installed now, so it's totally possible to do something in Lua too - forgot about that. I can add you to the group that grants access to edit the Module namespace if you want to give that a shot. If we use an extension, we'd probably need a custom one, similar to DFDiagram (or perhaps DFDiagram could be extended - it's in dire need of a rewrite anyway). —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 05:43, 24 December 2022 (UTC)
::::I asked around on the mediawiki irc, I think scribunto/lua is a deadend, at least for taking an uploaded image and doing stuff to it with a lua script. However I did come up with this even more bizarre solution, using block elements. [[User:Brightgalrs/Sandbox/PaletteSwapShowcase2]], maybe less resource intensive? Definitely displays a lot worse though, probably unusable.
::::{{User:Brightgalrs/Sandbox/PaletteSwitch|templatename=User:Brightgalrs/Sandbox/Rock2|palette-name=saffron}}
::::I dunno, maybe none of this is worth it and we should just write some external program to put all the images together offline, and then just mass upload. It wouldn't be ''that'' many... [[User:Brightgalrs|Brightgalrs]] ([[User talk:Brightgalrs|talk]]) 06:37, 24 December 2022 (UTC)

====Is there an easy way to just paste images from the clipboard?====

I use KDE spectacle to take screenshots straight to the clipboard (after cropping) -- is there an easy way to just paste (and auto-upload) an image into an article? It would make it a lot easier to contribute images. [[User:Kelvie|Kelvie]] ([[User talk:Kelvie|talk]]) 23:35, 1 January 2023 (UTC)
:Unfortunately there is not. I would be open to a MediaWiki extension to support this if someone finds one. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 00:32, 2 January 2023 (UTC)
:: Looks like this could do it, but I haven't used it before: https://www.mediawiki.org/wiki/Extension:SimpleBatchUpload [[User:Kelvie|Kelvie]] ([[User talk:Kelvie|talk]]) 19:41, 2 January 2023 (UTC)
::: It won't solve paste-from-clipboard, but this would be great for making uploading sprites much easier (auto-cutup spritesheet, rename, bulk upload). Could you add this, Lethosor? [[User:OddballJoe|OddballJoe]] ([[User talk:OddballJoe|talk]]) 21:47, 6 January 2023 (UTC)

====Standards for adding graphical version screenshots and images====

Hello, new user looking into adding imagery from the new version. Is there a standard for quality of new screenshots or images? I noticed that at a certain zoom level (2 zooms in from the furthest zoomed-out view), the graphics appear crisp and 1:1 pixel scaled, and I would propose that all images be taken at this scale whenever possible. If they need to be displayed larger, they should be nearest neighbor scaled in a photo editing program at 100% increments (Microsoft Paint will do this if you first select the image rather than directly scaling the whole canvas). I would also propose that images should be cropped to conform to the 32x32 pixel grid when possible, though this could be problematic with so many new graphical elements exceeding the bounds of their tiles. I would say the best practice for capturing artwork for items, furniture etc. ought to be done in a 3x3 open area to avoid shadows from nearby walls, or else extracted from the raw files (if this doesn't run afoul of being able to re-create the graphical version using those assets).

I know that perfect is the enemy of good, and any documentation is better than none, but just thought I'd ask about this, and see if/where something like this ought to be posted. [[User:Unclesporky|Unclesporky]] ([[User talk:Unclesporky|talk]]) 13:58, 3 January 2023 (UTC)

:It has been stated in [[Template:V50 workshop]] that <q>screenshots should be at the "native" resolution</q> but someone could edit the [[Screenshot]] page for best practice for the steam version. Or post some examples in [[Talk:Screenshot]] to find out what is best? --[[User:Halavus|Halavus]] ([[User talk:Halavus|talk]]) 14:21, 3 January 2023 (UTC)

:: Although I haven't added any explanation about best practices, I added a slightly more user-friendly, (Windows) alternative screenshot capturing method to the page. It might be a more helpful/relevant method for use with any best-practices explanations.

::I agree that there needs to at least be some elaboration on the reference to a "native" resolution for screenshots, as it seems irrelevant and misleading with the new display settings and menu in the steam version. Unfortunately, having only just come back to DF after years away, I don't feel confident that I can do this myself, competently. [[User:Alpacalypse|Alpacalypse]] ([[User talk:Alpacalypse|talk]]) 11:32, 7 March 2023 (UTC)

: All of your suggestions seem perfectly sensible to me (assuming that the pixel perfect zoom level is consistent for every user). I don't see why you couldn't take the initiative and pretty much cut and paste your comment here, with some minor tweaks for readability, to a new section on the [[screenshot]] page with a relevant title. Get the ball rolling, it doesn't need to be exhaustively comprehensive to start with. Once the edit is there, it will encourage other wiki editors to make any additions or changes over time. [[User:Alpacalypse|Alpacalypse]] ([[User talk:Alpacalypse|talk]]) 11:42, 7 March 2023 (UTC)

====How would I/should I go about putting creature sprites on their pages?====

Howdy. New player and wiki user here. I wanted to try and help update the wiki to the Steam release of DF, so I figured I'd chip in by putting each creature's sprites on their respective page, since I'll often look up a creature I have yet to see in game only to be met by a blue J, or whatever. I found all of the game's creature sprites in C:\Program Files (x86)\Steam\steamapps\common\Dwarf Fortress\data\vanilla\vanilla_creatures_graphics\graphics\images, so I figured I could just chop those up in Photoshop and stick them on here no problem, but the programming syntax/whatever it is on this site is incredibly confusing, I don't know how I'd actually go about doing it. I figured I'd just find the spot on the page where the little letter is and replace that with the image code, but it seems the pages are built using heavily nested templates that I can't even begin to understand. Any help?--[[User:Treese|Treese]] ([[User talk:Treese|talk]]) 03:07, 5 January 2023 (UTC)
:Based on [[User:Zippy|Zippy]]'s work at {{tl|Creaturelookup_b}}, I added an "image" parameter to {{tl|creaturelookup/0}}, which is what creature pages should all be using. See [[Dwarf]] and [[Cow]] for examples. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 05:37, 5 January 2023 (UTC)

=== Hotkeys/Menu navigation ===
Most key bindings and menus have changed. Should the article reflect a) only the old version, b) only the GUI version or c) both? For example, [[Bridge|bridges]] used to be built via {{k|b}} -> {{k|g}}, but now it's in Place strucutures {{k|b}} -> Constructions {{k|n}} -> Bridge {{k|b}}. What should be written in the article? Currently, it's {{k|b}} -> {{k|g}}. I ''think'' it should be only b), but I am not sure if there will be differences regarding hotkeys or menus between the premium version and the free version and then, c) would be the most appropriate option. --[[User:Prometherus|Prometherus]] ([[User talk:Prometherus|talk]]) 10:16, 22 December 2022 (UTC)

: Not sure. I wish the classic release soon --[[User:Jan|Jan]] ([[User talk:Jan|talk]]) 16:45, 22 December 2022 (UTC)
:: Are you Toady's herald? Looks like it was just released! [[User:Brightgalrs|Brightgalrs]] ([[User talk:Brightgalrs|talk]]) 18:18, 22 December 2022 (UTC)
:: And our questions are answered, the old hotkeys seem to have been thrown out. Part of me is disappointed (useless muscle memory) but also relieved (unified UI for both versions is good in general and for the wiki). [[User:Brightgalrs|Brightgalrs]] ([[User talk:Brightgalrs|talk]]) 18:25, 22 December 2022 (UTC)
::: According to info, in a sort of 'demo version' at that. I'll wait a little while longer, for myself.[[User:Silverwing235|Silverwing235]] ([[User talk:Silverwing235|talk]]) 18:22, 22 December 2022 (UTC)
::::It's unlikely that keybindings in it will change significantly. My vote is that we should include information for both premium and classic, everywhere. Hopefully the keybindings are not different between versions. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 18:26, 22 December 2022 (UTC)
:::Shouldn't it be based on the 50 or what verion the article is written for? [[User:Dominick|Dominick]] [[User_talk:dominick|(TALK)]] 18:42, 22 December 2022 (UTC)
:::: The keybindings seem to be consistent between versions, (haven't checked exhausitvely, but since the menu layout is the same I think it is a good assumption). Should also keep in mind/consider that not all actions have keybindings. An option would be write 'Click on the <Example Text> icon or press {{k|E}}' [[User:Koos|Koos]] ([[User talk:Koos|talk]]) 23:14, 23 December 2022 (UTC)

=== Removed features & concepts ===

Since they're removed concepts, I've set [[Room]] to be a redirect for [[DF2014:Room]] and created [[Template:Activity zones]] for the nav bar bedrooms, etc, and made the necessary changes to [[Bedroom]] for it. Is this the correct approach, before I go on much further? (also a note, if it is, then [[Template:v50_rooms]] probably needs to be deleted) I also imagine that considering the number of changes in the interface, that things like [[Adventure mode]] and related pages might best be truncated to "not in 50.03" and when it does make it across, being more deliberately brought over in pieces? [[User:HawkOwl|HawkOwl]] ([[User talk:HawkOwl|talk]]) 06:23, 23 December 2022 (UTC)

:Usually it is marked with [[Template:Removed_feature]]. For example: [[Dipscript]] or [[Party]]. --[[User:Jan|Jan]] ([[User talk:Jan|talk]]) 07:45, 23 December 2022 (UTC)

:: Ah, that's fair. Should that be mentioned in [[Dwarf_Fortress_Wiki:Versions#Redirects]]? [[User:HawkOwl|HawkOwl]] ([[User talk:HawkOwl|talk]]) 10:03, 23 December 2022 (UTC)

:::I think the redirect policy mostly had in mind things that were removed a ''long'' time ago, like [[Tax collector]] and [[Economy]] (and the latter actually has a stub page as well). I guess we could clarify. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 19:34, 23 December 2022 (UTC)

:::: The "current" redirects also cause the version box to incorrectly show that the current version has a page - e.g. [[23a:Cave_river]] shows a v50.04 version, but it's just a redirect back to that version. Similarly, what should happen to redirects like [[Clothes maker]], where a concept has evolved? It currently goes to [[23a:Clothes maker]] - that's correct if the user is trying to look up a very old concept, but if a new user is looking for "how to make clothes", they should be directed to [[Clothier]]. --[[User:Danny252|Danny252]] ([[User talk:Danny252|talk]]) 12:16, 26 December 2022 (UTC)

::::: It won't work for every case; but strategic use of when, and on what pages to use either a redirect, or the "removed feature" template, should be able to correctly organize references for cases like this. I did it for the recently added "Places" page. With just a redirect from the "building list" page for the current version, The Places page's version template links to a non-existent v0.47 page. With [[Template:Removed_feature]] added to [[Building list]] the [[Places]] 0.47 version template link links to the old [[DF2014:Building list]] page via an automatically created [[DF2014:Places]] page with a redirect to the old Building list page. - A tweaked version of the removed feature template, doing something very similar with automated page redirects, might be a solution for the specific examples you have given for much older versions. (Template:Evolved_feature)? [[User:Alpacalypse|Alpacalypse]] ([[User talk:Alpacalypse|talk]]) 12:08, 7 March 2023 (UTC)

:::::: I may have been overthinking the "Evolved_feature" template idea, or maybe not, if it means manually correcting hundreds of redirects to old pages. Regardless of that, I will just manually edit the specific pages mentioned above to work as intended, especially as [[v0.31:Clothes maker]] did exactly that, and is why the chain in versioned page redirects for "clothes maker" was broken from there to the current version. [[User:Alpacalypse|Alpacalypse]] ([[User talk:Alpacalypse|talk]]) 12:36, 7 March 2023 (UTC)

:::: One should be careful with cv redirects. Most that were recently adjusted were unused plural forms (that should probably be deleted) but few like [[Crown]] needed that for backward compatibility. Removing the [https://dwarffortresswiki.org/index.php?title=Crown&type=revision&diff=279966&oldid=219482 cv part] means the the link on [[v0.31:Tilesets]] is now broken. --[[User:Jan|Jan]] ([[User talk:Jan|talk]]) 22:30, 26 December 2022 (UTC)

:::::If [[v0.31:Tilesets]] is about v0.31, it should not be using "main:" in its links - ''all'' of those links are going to pages about v50, not v0.31, regardless of whether the target is a redirect or not. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 23:37, 26 December 2022 (UTC)
:::::: You right, I removed it. --[[User:Jan|Jan]] ([[User talk:Jan|talk]]) 17:55, 27 December 2022 (UTC)

Crown cv redir issue is now fixed, I believe. As goes with such cases where one can simply revert the troublesome edit, unless I've mistepped, myself? [[User:Silverwing235|Silverwing235]] ([[User talk:Silverwing235|talk]]) 23:52, 26 December 2022 (UTC)
:Both [https://dwarffortresswiki.org/index.php?title=Crown&diff=prev&oldid=280026] and [https://dwarffortresswiki.org/index.php?title=Crown&diff=prev&oldid=279966] should not have had any effect, because "cv" is an alias to the main namespace now, just like "main". Proof: [[Crown]], [[cv:Crown]], [[main:Crown]]. It's possible caching is coming into play here, although I purged the redirect cache after making that alias change earlier this month... —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 00:02, 27 December 2022 (UTC)

I think there have been some changes not captured, but as a newb, I'm afraid to edit the page(s). A good example is Strawberry. I'm playing the Steam version right now and Strawberry plants are "not relevant to brewing" in Labor > kitchen > veg / fruit / leaves. Unless I'm mistaken and need to process them? Another example is the trade caravan = it seems the 3 square pathing no longer happens; it's just yak(s). 12:31, 28 December 2022 (UTC) 12:29, 28 December 2022 (UTC)
:Strawberries should be brewable according to the Raws.
:Trade wagons has been modified in v50. The first wagons will arrive at the same time your fort is becoming a barony. Until then, it's only pack animals and stairs are indeed fine. The [[Trading]] page needs a huge rework anyway... I'll try to do that next week. --[[User:Halavus|Halavus]] ([[User talk:Halavus|talk]]) 13:40, 2 January 2023 (UTC)

As far as I can tell, none of the workshop buildings in v50 have blocking tiles any more. There's a comment to the like in data/vanilla/vanilla_buildings/objects/building_custom.txt that says this "[BLOCK:1:0:0:0] workbenches no longer block". Hesitant to update that template as I'm not sure if it's referenced for all of the old versions too. [[User:AndrielChaoti|AndrielChaoti]] ([[User talk:AndrielChaoti|talk]]) 05:54, 29 December 2022 (UTC)
: A new template has been created: {{tl|V50 workshop}} --[[User:Halavus|Halavus]] ([[User talk:Halavus|talk]]) 13:40, 2 January 2023 (UTC)
::Thanks! In general, I would like to delegate the switching responsibility to the template (like how {{tl|creaturelookup/0}} works), but in cases where the parameters diverge significantly like with workshops, it could make sense to make an entirely new template. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 02:40, 3 January 2023 (UTC)

==== Irrelevant/outdated Pages (migrated?) from much older versions ====

I was just doing a simple edit to [[cave river]] so it redirected to a more relevant page, but this was such a seemingly innocuous page that raised some rather mind-boggling questions for me. Primarily, why does it even exist when it has not been referenced by any wiki pages post 40d, and even then [[40d:Cave river]] was already an outdated redirect. Before changing the redirect, it was redirecting to [[23a:Cave_river]] which lead to a circular v50 link on that page, back to itself, also implying that it might be some old feature reintroduced in v50.

I also added a "removed feature" tag to the page, so it would at least be marked as an obsolete feature, and though mostly irrelevant, due to the redirect, it adds a reference to "see... previous versions". If [[template:av]] is added it only shows v50 and dead v0.47 link; despite showing links, dead or not, to all versions, on the v23a page - when, in this case, it would be more relevant the other way around.

Though the wiki wizardry is a bit beyond me, I assume, for v50, this page was created automatically due to some page migration script, even though there are no pages for the three previous versions. Going by this precedent, shouldn't this page just be deleted? If not, considering it is hard to see why anyone would be searching for "Cave river" in the first place, unless they thought it was a feature for some reason, perhaps this page shouldn't redirect at all, and instead be presented as an "obsolete feature" entry with some relevant information and links.

If the above assumption is correct, it seems like there might be a lot of other possibly redundant and needlessly irrelevant, strangely redirected, or misleading pages for the current version lurking out there; in which case, this might be an issue worthy of further review and added somewhere onto a figurative or literal v50 housekeeping list. (Which this entry here may count as). [[User:Alpacalypse|Alpacalypse]] ([[User talk:Alpacalypse|talk]]) 13:41, 7 March 2023 (UTC)
:The last time [[cave river]] was edited before your edit was in 2011: https://dwarffortresswiki.org/index.php?title=Cave_river&action=history —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 15:34, 8 March 2023 (UTC)
::Yeah, this was primarily why I was wondering why it was even created as a page again for v50. It is hard to imagine why someone would be searching for such an esoteric feature, that hasn't been in the game for well over 10 years, and wasn't even referenced on the wiki for the versions between now and then. I only knew it existed due to Danny's comment four down from the top of [[Dwarf_Fortress_Wiki_talk:Versions#Removed_features_.26_concepts|this talk]] category [[User:Alpacalypse|Alpacalypse]] ([[User talk:Alpacalypse|talk]]) 17:57, 8 March 2023 (UTC)
:::It '''wasn't''' "created as a page again for v50" - from the edit history, it had existed for over 11 years as a redirect to the 23a page before v50 came out. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 20:00, 8 March 2023 (UTC)
::::Thanks for the clarification, the version template shows the page as not existing for the intermediary wiki version pages, so that's where the confusion started. [[User:Alpacalypse|Alpacalypse]] ([[User talk:Alpacalypse|talk]]) 20:43, 8 March 2023 (UTC)
Given the above conclusion, and lot of needless waffle on my part, I thought I may as well give an example of where this confusion arose, regarding the [[Template:ArticleVersion|version template]] links.
 - Although I was mistaken in thinking the [[cave river]] page migration was a mistake, it was suggested that I make a clearer comment and example about what was confusing to me. This is not intended as criticism, but I thought it might be a useful example, and information, for people who are more knowledgable about the wiki's history, page migration and how the version template works, and for this discussion page in general:
#If you got to [[23a:Cave river]] you can see that it lists red links for [[cave river]] pages for: [[DF2014:Cave_river|v0.47]] · [[v0.34:Cave_river|v0.34]] · [[v0.31:Cave_river|v0.31]].
#Before I added a redirect to [[Cavern#Geography]] the v50 [[cave river]] page also showed the red link for [[DF2014:Cave_river|v0.47]], in the version template.
#If you look at the [https://dwarffortresswiki.org/index.php?title=23a:Cave_river&action=history 23a:Cave river history] page it shows the last user edit was in 2021.
#From the [[23a:Cave river]] page, if you click the next (and last non-red before v50) [[40d:Cave river|v0.28]] it takes you to [[40d:Underground river]] via a [[40d:Cave river]] page redirect. The [https://dwarffortresswiki.org/index.php?title=40d:Underground_river&action=history 40d:Underground river history] page shows the last minor edit in 2021, and previous edit in 2014.
#This page's version template now shows red links for all future versions.
#If we backtrack to get back on the trail, the [https://dwarffortresswiki.org/index.php?title=40d:Cave_river&action=history 40d:Cave River history] page shows the last edit in 2010.
#Prior to my redirect edit on 7 March 2023‎, the current version (v50.07) [https://dwarffortresswiki.org/index.php?title=Cave_river&action=history cave river history] page shows the last edit 2011, redirecting it to [[23a:cave river]] which (see #3) has a [https://dwarffortresswiki.org/index.php?title=Cave_river&action=history history showing] twelve edits up to 2021.
Hopefully you can see why I thought this might not be a unique occurrence with page migration, and potentially misleading or confusing. I did my best to balance clarity and brevity, hope this is relevant or of interest. If I have misunderstood something obvious again, please let me know, as I don't want to clutter up this talk page with (even more) needless verbiage. [[User:Alpacalypse|Alpacalypse]] ([[User talk:Alpacalypse|talk]]) 17:48, 10 March 2023 (UTC)
:Just adding a note with a link to the [[Dwarf_Fortress_Wiki_talk:Versions#v50_migration|v50 migration]] discussion here, for anyone reading, as there is already some related discussions about version template linking. --[[User:Alpacalypse|Alpacalypse]] ([[User talk:Alpacalypse|talk]]) 16:52, 12 March 2023 (UTC)

=== creature infobox prototype (moved) ===

Check it out, I made a temporary template and added it to the [[cow]]s page. Now it shows the sprites (but not the zombified versions yet). I wanted to show everyone a prototype of what v50 creature infoboxes should look like. Or at least something similar to it. --[[User:Zippy|Zippy]] ([[User talk:Zippy|talk]]) 19:11, 27 December 2022 (UTC)
:Hi, I'm new to editing wikis but I have done a bit of work with sprite sheets and I've been going through the DF data files to find the different graphics hoping to help with the animal pages. I've thrown together a template with grass and a few nature sprites (plants, a tree, and a rock) for size reference but I'm unsure how large the 'display' tiles in the middle of the template should be to suit all animals. I can see in the sprite sheets that some land animals have an adult and child sprite, so two tiles. Others have a male, female, and child, but after seeing you include the zombie cows I'm unsure if I should make it twice the size to add them too. Alternatively, I could grab some tiles from the haunted biomes for the zombie animals and make a separate template for a side-by-side comparison. Either way, let me know if this helps. I'd like to help with other graphics too as we add the premium tilesets but the animals seemed the easiest to tackle with me being new to wiki editing. ~~[[User:UristTheSeventh|UristTheSeventh]] ([[User talk:UristTheSeventh|talk]])
::@Zippy, I am a bit perplexed about the purple cows. Why do we need a zombified version of creatures on every page?
::@UristTheSeventh, we can use all the help. Maybe post an example, so that we can have something to compare and contrast.--[[User:Jan|Jan]] ([[User talk:Jan|talk]]) 11:49, 3 January 2023 (UTC)
:::@Jan Here are the examples:
:::[[File:Creature template.png]] [[File:Armadillo.png]] [[File:Seagull.png]]
:::It'll need to be wider or arranged differently for different creatures with more that two sprites or for multi-tile creatures. I can also do an aquatic and air themed template for swimming and flying creatures. ~~[[User:UristTheSeventh|UristTheSeventh]] ([[User talk:UristTheSeventh|talk]])
::::Looks nice, like the metal template. There are several people working on updating the graphics you should talk more among yourselves. Best I can offer is that I width wise I am hoping to go up to 200px for infoboxes.--[[User:Jan|Jan]] ([[User talk:Jan|talk]]) 01:13, 5 January 2023 (UTC)
:::: We don't exactly ''need'' a zombie sprite on each page. I added it because it was... there. I was also hoping to get some opinions on it anyway since that infobox is a visual prototype, and not a final choice. --[[User:Zippy|Zippy]] ([[User talk:Zippy|talk]]) 03:28, 6 January 2023 (UTC)

===Furniture Infobox===
{{Quality|Unrated}}
{{v50_furniture|name=Bed
|graphic=[[File:bed_sprite_prototype.png]]
|tile=Θ|col=6:0:0
|wood=y
|rooms=
* [[Bedroom]]
* [[Barracks]]
* [[Dormitory]]
|value=10}}
I made a v50 furniture template prototype. I tested this on Firefox, Chrome and Microsoft Edge/Internet Explorer and it looks fine on all of them. I hope this is good enough to be the official thing, unless I'm missing something. --[[User:Zippy|Zippy]] ([[User talk:Zippy|talk]]) 03:28, 6 January 2023 (UTC)
{{clear}}

=== When do we remove the migration note on specific pages? ===

At what point can we remove the "this page was auto migrated from v47" warning? There are a bunch of small pages that are more or less accurate, if I've reviewed them, can I go ahead and remove the warning? [[User:Kelvie|Kelvie]] ([[User talk:Kelvie|talk]]) 23:33, 1 January 2023 (UTC)
:Yes, feel free to remove it if you think all content is accurate. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 00:31, 2 January 2023 (UTC)

=== Any info on fixing "creature description not found?" ===

I see this issue on most creature pages, it seems to be due to a lookup that's not currently functioning? Cows interestingly doesn't have this issue but I couldn't figure out how to recreate whatever fix it's editor did. --[[User:Yallendallis|Yallendallis]] ([[User talk:Yallendallis|talk]]) 00:22, 3 January 2023 (UTC)
:That is the missing raws issue described above. Cow was fixed by the addition of [[cow/raw]]. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 02:28, 3 January 2023 (UTC)
::Ah makes sense, not fully used to the language of wikis yet so I read over it while looking. To put this bit of questioning to rest for any future readers, is it correct that it's fine to update any raws manually, though it will be done automatically at some point? --[[User:Yallendallis|Yallendallis]] ([[User talk:Yallendallis|talk]]) 07:48, 3 January 2023 (UTC)
:::Yes. I'm circling back to work on a script right now, so not much point in doing it if you're reading this. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 04:57, 4 January 2023 (UTC)
:::This should be fixed now. If you continue to see pages with problems, you can try [https://www.mediawiki.org/wiki/Manual:Purge purging the cache]. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 05:59, 4 January 2023 (UTC)

=== Adventurer Mode related sections ===

The topic has already been discussed [[#Removed features & concepts|above]], but I don't see a clear line on what to do with article sections that mention Adventurer Mode. Like for example in [[Butcher#Adventurer_mode|Butcher]].

'''a) Truncate''' or '''b) leave in place with a mention''' that the mode is not yet present IG but will be added in a future update?

Personally I think option b) is better, because I think it's silly to undo some work just to reintroduce it a few weeks later, with the necessary corrections. Even if a copy/paste of a previous version takes ~15 seconds, considering the number of articles that need to be corrected, it would be a bit of a waste of time.--[[User:Halavus|Halavus]] ([[User talk:Halavus|talk]]) 14:22, 3 January 2023 (UTC)

=== New menus/interface changes ===

I went down a rabbit hole today after adding a "[[places]]" page and redirecting "building list screen" to that. After updating the "[[Template:V50_menus|Menu Tabs]]" template I realised there is a large ammount of missing or incorrect information after v0.47 page migration. It did lead to getting a clearer picture of what exactly has room for improvement though so I'll just add some notes here for now, so I don't forget, and so anyone else who might feel inspired doesn't have to check every reference one-by-one again.

Missing menu/interface entries:
:* [[Tasks]]
:* [[Objects]]
:* (Justice) - [[Open cases]] • [[Closed cases]] • [[Cold cases]] • [[Convicts]] • [[Intelligence]]

Outdated information/missing new interface info:
:* (Places) - [[Stockpile|Stockpiles]] • [[Workshops]] • [[Farming|Farm plots]]
:* (Objects) - [[Artifacts]] • [[Named objects]] • [[Symbols]] • [[Books|Written content]]
:* [[Justice]] - [[Fortress guard]]

I wasn't sure about the correct use of the "tattered" quality category, but if it counts for all those, shall I just change them to that for easier update tracking in general?

I think a lot of these probably just need their own categories added for menu/interface usage, but a few of the more elaborate ones might benefit from having their own menu/interface specific page perhaps?

Also, apologies if I went a bit far editing a template to such an extreme without checking first, I was a bit worried I might mess something up across multiple pages, but decided to take the '''B'''e bold! guideline at face value. :D [[User:Alpacalypse|Alpacalypse]] ([[User talk:Alpacalypse|talk]]) 13:59, 5 March 2023 (UTC)

=== New difficulty settings ===
Considering that these are shiny new features I find it a bit silly that we still don't have a page detailing what exactly these do. The most I've ever seen is little tidbits here and there discussing animal agitation. Some of them are pretty obvious (like tree-fell counts) but the nitty-gritty is always nice.

As far as I can tell, '''Off''' prevents [[sieges]], [[Megabeast|uninvited]] [[Forgotten beast|guests]], and agitated wildlife attacks, but still allows [[Intrigue]] and [[HFS]] to occur (likely evil biome zombie shenanigans as well), '''Normal''' is the default experience, and '''Hard''' ensures a nonstop stream of [[Fun]] assaults your fort. [[User:CobaltNinja|CobaltNinja]] ([[User talk:CobaltNinja|talk]]) 13:38, 18 October 2023 (UTC)

:I would encourage you to add such a page. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 18:17, 19 October 2023 (UTC)

:: The [[difficulty]] page has been created. Thank you for your encouragement! Still needs more info. [[User:CobaltNinja|CobaltNinja]] ([[User talk:CobaltNinja|talk]]) 21:24, 28 October 2023 (UTC)

== Toggleable image ==

Any objections/comments to using this template for now for toggling between classic and premium images? I'd probably rename it to "Template:Premium-classic thumb image". I'm sure someone can come up with a better UI eventually, but should be easy to migrate at that point. I also think we should use the same customtoggle class for this and for the infobox. [[User:NiftyManiac|NiftyManiac]] ([[User talk:NiftyManiac|talk]]) 23:12, 1 January 2023 (UTC)

{{User:NiftyManiac/Sandbox/TemplateDualImage|
premium=File:Quickstart-finder.png|
classic=File:Quickstart-finder-partial.png
}}

{{User:NiftyManiac/Sandbox/TemplateDualImage|
premium=File:Quickstart-finder.png|
classic=File:Quickstart-finder-partial.png|
caption=My caption|
width=100px
}}

:This looks nice to me! —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 00:30, 2 January 2023 (UTC)

: Good initiative. From the top of my head:
:* I suggest using a shorthand, no one wants to type 'Premium-classic thumb image'.
:* If we end up using toggle for infoboxes (not sure where we headed there), then I agree definitely same custom toggle class should be used for all, thus allowing to switch premium-classic view on the whole page at a click.
:* The button part on a separate row isn't pretty, creating a lot of dead space that can be used by the text. Are we set on the label 'toggle ascii'? Classic isn't Ascii per se, maybe we can use a 'toggle' with a tooltip {{tooltip|for example|does bla bla bla}}, or maybe we can get rid of the text and have a smaller icon button ([[User:Jan/sandbox#Metal_example|two examples]]).
: I hope that helps. --[[User:Jan|Jan]] ([[User talk:Jan|talk]]) 11:21, 2 January 2023 (UTC)

:: I added [[Template:Dual image]] with some of your suggestions. Agree that it's not super pretty, feel free to try something different.

::* I put the toggle in the caption mostly because I gave up on trying to make a more sophisticated replacement for the default thumb image behavior, I'm sure someone with better wiki-fu could put together something more intelligent.
::* I cut the text down to just "Toggle"; I think the best solution would be a small graphic showing the old and new dwarf icons with arrows between them. [[User:NiftyManiac|NiftyManiac]] ([[User talk:NiftyManiac|talk]]) 19:21, 2 January 2023 (UTC)

{{Dual image|
premium=File:DFwiki5by53by3farm.png|
classic=File:Quickstart_layout_3.png|
width=100px|
caption=A 5x5 room with a 3x3 farm plot
}}
::: I updated the layout, now it should look just like a regular image thumb. I didn't had time to test it, if it doesn't work for you or you don't like it just revert the last change. cheers. --[[User:Jan|Jan]] ([[User talk:Jan|talk]]) 21:46, 2 January 2023 (UTC)
::::I don't know which part of this talk page to put this, but I added the ability to add icons to the v50 workshops template. Leaving the icon part blank will not break the template in any way. --[[User:Zippy|Zippy]] ([[User talk:Zippy|talk]]) 09:47, 3 January 2023 (UTC)

=== Plant Infoboxes ===
Could someone put the toggle image thing on the plant infoboxes? --[[User:Zippy|Zippy]] ([[User talk:Zippy|talk]]) 20:08, 13 February 2023 (UTC)
{{clear}}

==Creature List Now Supports Graphics!==
I wasn't easy, but I made new templates so the [[Creature]]s page now supports both graphics sprites ''and'' ASCII tiles. Allow me to show you:

{{v50_creaturecurrent_table_head}}
{{v50_creaturecurrent table row|graphic=[[File:dwarf_sprite.png]]|name=[[Dwarf]]|symbol=☺|color=3:0:0|playable=Fort, Adv|hostile=No|food=No|size=60,000|value=Not tameable|biome=[[Mountain halls]], [[Fortress|dwarf fortress]]es, [[hillock]]s|note=Trading race}}
{{v50_creaturecurrent table row|graphic=[[File:elf_sprite.png]]|name=[[Elf]]|symbol=e|color=3:0:0|playable=Adv|hostile=Variable1|food=No|size=60,000|value=Not tameable|biome=[[Forest retreat]]s|note=Trading race}}
{{v50_creaturecurrent table row|graphic=[[File:human_sprite.png]]|name=[[Human]]|symbol=U|color=3:0:0|playable=Adv|hostile=Variable1|food=No|size=70,000|value=Not tameable|biome=[[Town]]s and cities|note=Trading race}}
{{v50_creaturecurrent table row|graphic=[[File:goblin_sprite.png]]|name=[[Goblin]]|symbol=g|color=7:0:0|playable=Adv|hostile=Usually1|food=No|size=60,000|value=Not tameable|biome=[[Dark fortress]]es and [[dark pit]]s|note=Snatchers2}}
{{v50_creaturecurrent table row|graphic=[[File:kobold_sprite.png]]|name=[[Kobold]]|symbol=k|color=6:0:0|playable=Adv|hostile=Usually1|food=No|size=20,000|value=Not tameable|biome=Caves|note=Skulking race}}
|}

Oh wait, there's a bonus. You can also modify the background color of the box the sprites go in. I added that to make possibly-hard-to-see-otherwise sprites more easy to see - depending on the colors it has. Allow me to demonstrate.

{{v50_creaturecurrent_table_head}}
{{v50_creaturecurrent table row|graphic=[[File:dwarf_sprite.png]]|bgcolor=#829ccc|name=[[Dwarf]]|symbol=☺|color=3:0:0|playable=Fort, Adv|hostile=No|food=No|size=60,000|value=Not tameable|biome=[[Mountain halls]], [[Fortress|dwarf fortress]]es, [[hillock]]s|note=Trading race}}
{{v50_creaturecurrent table row|graphic=[[File:elf_sprite.png]]|bgcolor=#c7dfc0|name=[[Elf]]|symbol=e|color=3:0:0|playable=Adv|hostile=Variable1|food=No|size=60,000|value=Not tameable|biome=[[Forest retreat]]s|note=Trading race}}
{{v50_creaturecurrent table row|graphic=[[File:human_sprite.png]]|bgcolor=#c7dfc0|name=[[Human]]|symbol=U|color=3:0:0|playable=Adv|hostile=Variable1|food=No|size=70,000|value=Not tameable|biome=[[Town]]s and cities|note=Trading race}}
{{v50_creaturecurrent table row|graphic=[[File:goblin_sprite.png]]|bgcolor=#dfc0c0|name=[[Goblin]]|symbol=g|color=7:0:0|playable=Adv|hostile=Usually1|food=No|size=60,000|value=Not tameable|biome=[[Dark fortress]]es and [[dark pit]]s|note=Snatchers2}}
{{v50_creaturecurrent table row|graphic=[[File:kobold_sprite.png]]|bgcolor=#dfc0c0|name=[[Kobold]]|symbol=k|color=6:0:0|playable=Adv|hostile=Usually1|food=No|size=20,000|value=Not tameable|biome=Caves|note=Skulking race}}
|}

To change the background color, add <code><nowiki>|bgcolor=COLOR</nowiki></code> segment after the <code><nowiki>|graphic</nowiki></code> part. You can use color names or HTML hex color codes. I added this to the v50 creatures page, but at this time, I only added the first five creatures I just displayed. It's gonna take a while to find ALL of those creature sprites. I hope a lot of people help out on that one. --[[User:Zippy|Zippy]] ([[User talk:Zippy|talk]]) 05:29, 5 January 2023 (UTC)

:Thanks, looks nice! —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 05:44, 5 January 2023 (UTC)
:Nice stuff, took the quick liberty to change the padding-left -> text-align to make all the sprites center aligned relative to each other :) Sweet work --[[User:Vallode|Vallode]] ([[User talk:Vallode|talk]]) 17:41, 5 January 2023 (UTC)
:: Good work indeed. One minor issue, is that all the sprites have different sizes, which sometimes create slight variation in table row height. Consider using capping the image size vertically for example <code><nowiki>[[File:dwarf_sprite.png|x32px]]</nowiki></code>--[[User:Jan|Jan]] ([[User talk:Jan|talk]]) 18:15, 5 January 2023 (UTC)
:: Also often in such tables people want to click on the image to go for the specific entry, and often will try to click on the very first thing they see in line the thumb image, but currently that will take them to the file page. Consider adding link parameter for example: <code><nowiki>[[File:dwarf_sprite.png|x32px|link=dwarf]]</nowiki></code> [[File:dwarf_sprite.png|x32px|link=dwarf]] or no link at all <code><nowiki>[[File:dwarf_sprite.png|x32px|link=]]</nowiki></code> [[File:dwarf_sprite.png|x32px|link=]] --[[User:Jan|Jan]] ([[User talk:Jan|talk]]) 18:24, 5 January 2023 (UTC)
::: I mean... Yeah, I could do that. I think that lessens the quality of the sprite a bit because it makes edges blurry, but either way is fine. I could have sworn I added a link for all those images the first time. --[[User:Zippy|Zippy]] ([[User talk:Zippy|talk]]) 03:23, 6 January 2023 (UTC)
::::Since we are adding pixel art sprites to the website it might be convincing to add a global class like .sprite or .pixel-image that uses the CSS attribute `image-rendering: pixelated;` in order to prevent blurryness when scaling the image up/down. Just a thought --[[User:Vallode|Vallode]] ([[User talk:Vallode|talk]]) 09:40, 6 January 2023 (UTC)
:::::Are we able to attach classes directly to images? If so, we can probably attach inline styles directly as well. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 16:52, 6 January 2023 (UTC)
::::::Looks like (without an extension) MediaWiki only supports classes on images: [[File:dwarf_sprite.png|x32px|class=pixelated]] and not styles: [[File:dwarf_sprite.png|x32px|style="image-rendering: pixelated;"]] it just treats it as alt text it looks like? Wrapping it in a div works and demonstrates the difference: <div style="image-rendering: pixelated;display:inline;">[[File:dwarf_sprite.png|64px]]</div> [[File:dwarf_sprite.png|64px|inline]]. Speaking from experience, however, image-rendering needs a browser specific prefix in certain browsers (safari, for example) in order to work properly. I'm not entirely sure what the best "MediaWiki" practice is for adding something like this but I would assume it's a simple class in common.css for now. --[[User:Vallode|Vallode]] ([[User talk:Vallode|talk]]) 17:17, 6 January 2023 (UTC)
:::::::Ah, yeah, you are correct, I should have checked https://www.mediawiki.org/wiki/Help:Images. I'd be fine adding a class like that to common.css. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 17:27, 6 January 2023 (UTC)
::::::::Great, in that case if no one is opposed we can add `.game-sprite` or something like that? See below for the CSS, the order of the attributes is relevant. --[[User:Vallode|Vallode]] ([[User talk:Vallode|talk]]) 18:23, 6 January 2023 (UTC)
<pre>/* Used for pixel-art images from the game so they can be resized and maintain crisp pixel edges. */
.game-sprite {
image-rendering: -webkit-optimize-contrast;
image-rendering: crisp-edges;
image-rendering: pixelated;
}</pre>
:::::::::So... you guys think each creature page should show the main sprite(s) alone, or should it show the baby versions alongside them? --[[User:Zippy|Zippy]] ([[User talk:Zippy|talk]]) 08:37, 8 January 2023 (UTC)
::::::::::I think adult + baby is sensible, the adult + baby + zombie was not, in retrospect. So yeah adult + baby (if there is one) from now on would be my vote. --[[User:Vallode|Vallode]] ([[User talk:Vallode|talk]]) 23:27, 8 January 2023 (UTC)
{{outdent}}
Well then, there's a TON of creatures to go - and I mean both the [[creature]]s page and the individual creature pages. I really hope everyone can pull their weight on that those images. The spritesheets are easy to find, and if you know how to read the .txt files near them, finding sprites on certain rows and columns should be a breeze. --[[User:Zippy|Zippy]] ([[User talk:Zippy|talk]]) 00:47, 9 January 2023 (UTC)
:Zippy, are you doing all of this by hand? That seems quite tedious. Cutting up the spritesheets can be done automatically. Renaming and updating the table could be done with a script and/or chatgpt. We'd need Lethosor to add the [https://www.mediawiki.org/wiki/Extension:SimpleBatchUpload batch upload extension] though. Maybe some manual work in updating names to match article names rather than raws. [[User:OddballJoe|OddballJoe]] ([[User talk:OddballJoe|talk]]) 06:55, 9 January 2023 (UTC)
{{clear}}
::So did the graphic people gained insights and reached some sort of consensus? are we using big up scaled images + toggle? multiple images to(adult + baby)? anything else? --[[User:Jan|Jan]] ([[User talk:Jan|talk]]) 00:32, 10 January 2023 (UTC)
:::I noticed that someone blew up the size of the previews in infoboxes. Was that you Jan that did that? Whoever did that enlarged the DFtext tile as well. Don't know if that was intentional or not. I'd prefer if the sprites were either left alone or at double-sized max (or however they look in-game at 1:1 - not zoomed in or out), though that's just me. It looks like maybe they're triple-sized or something.

:::@OddballJoe - It's not all by hand, I have some Photoshop scripts that cut my work time in half, or even by a third. Lethosor said something about us not uploading entire spritesheets. If we did it the entire spritesheet way, one update to the sheet could misalign everything and screw up many pages. For example, let's say Kitfox slipped in an extra couple rows of creatures in an image file, that means the other rows under it would be misaligned and pages would show the wrong creatures. Know what I mean? I'd still prefer if other people jumped in and added sprites, though. --[[User:Zippy|Zippy]] ([[User talk:Zippy|talk]]) 00:51, 10 January 2023 (UTC)

:::: Lethosor introduced the changes, using the image-rendering stuff. I am just waiting for any sort of consensus to do anything, same as with workshops I am not clear on the size people want to go for [[:File:Carpenter%27s_workshop.png|original]] or [[:File:Ashery.png|big]] --[[User:Jan|Jan]] ([[User talk:Jan|talk]]) 01:17, 10 January 2023 (UTC)

::::: I'm no graphics artist but I'm not sure I understand why global consensus needs to be achieved... We're dealing with pixel art, why wouldn't we just upload the pixel-perfect versions from the spritesheets for all images that we need? The display size can be discussed on the appropriate template pages and adjusted in the templates or css. I also tend to think that if we want to maintain something like 1k images that may change in the future, it'd be worth automating most of the work. Zippy, as far as I can tell the raws give all the coordinates needed to cut out and label each sprite, so I was thinking one script could parse the raws, make and label the cutouts, and upload. [[User:OddballJoe|OddballJoe]] ([[User talk:OddballJoe|talk]]) 04:49, 10 January 2023 (UTC)

::::: Likewise I think the image names should be standardized so we can just change the creature infobox template to look up the image rather than editing a gazillion pages by hand. Though I suppose at some point the pages will need review to remove the migration banner anyway. [[User:OddballJoe|OddballJoe]] ([[User talk:OddballJoe|talk]]) 04:51, 10 January 2023 (UTC)

::::: Looks like you answered your own question, standardization. Initially, it is best to try different things and figure out all the odd quirks that doesn't fit. But eventually, it is best if we all work toward the same goal, saving everyone time and making the result more consistent in terms of naming convention, parameter name, resolution, use of scaling (in-game or otherwise), use of sprites or screenshots (like for layered workshops), use of templates, amount of images planned or whatever else was mentioned above. I think that discussion of the desired outcome goes well in hand here. --[[User:Jan|Jan]] ([[User talk:Jan|talk]]) 10:38, 10 January 2023 (UTC)

=== Graphics in Skill Infoboxes ===
{{v50_skill
| color = 7:0
| graphic = [[File:miner_sprite_icon.png]]
| skill = Miner
| profession = Miner
| job name = [[Mining]]
| tasks =
* [[Dig]]
| attributes =
* Strength
* Toughness
* Endurance
* Willpower
* Spatial Sense
* Kinesthetic Sense}}I've made yet another visual prototype for skills. In other words, we can put sprites of matching dwarves (and possibly humans, elves, goblins, etc.) at the top of infoboxes. If multiple images are put up there, that can mess up the alignment, but don't worry, Zippy thought of that. <code><nowiki>|graphicmargin</nowiki></code> can added, and a percentage or a "px" number can be placed in that parameter to fix it. If you leave said parameter out, the alignment will default to about 42% from the left. --[[User:Zippy|Zippy]] ([[User talk:Zippy|talk]]) 06:06, 7 January 2023 (UTC)
<pre><nowiki>
{{v50_skill
| color = 7:0
| graphic = [[File:miner_sprite_icon.png]]
| graphicmargin = (OPTIONAL)
| skill = Miner
| profession = Miner
| job name = [[Mining]]
| tasks =
* [[Dig]]
| attributes =
* Strength
* Toughness
* Endurance
* Willpower
* Spatial Sense
* Kinesthetic Sense}}
</nowiki></pre>
::Not sure I understand the alignment issue, can you not put text-align: center on the parent table element instead of messing with explicit margins? As another sidenote, should we continue to be naming all of these templates v50_x, I find that a bit confusing. Why not just edit the main templates with the additional information. Loving all the new templates though nice work Zippy :) --[[User:Vallode|Vallode]] ([[User talk:Vallode|talk]]) 11:43, 7 January 2023 (UTC)
:::No, text-align doesn't work with images and divs. That just works for text. When it comes to images, you got to put a little "finesse" on the CSS with those. As for editing the classic templates with the new info, it doesn't always work that way with ''every'' template. Lethosor I think ''did'' update the creature infobox template in the way you mentioned. --[[User:Zippy|Zippy]] ([[User talk:Zippy|talk]]) 08:37, 8 January 2023 (UTC)
:::: You can use something like this to automatically handle that--[[User:Jan|Jan]] ([[User talk:Jan|talk]]) 08:56, 8 January 2023 (UTC)
{|
|-
|<div style="width:200px; display:flex; background-color:#eaecf0;">
[[File:miner_sprite_icon.png|center]]
<div>
|<div style="width:200px; display:flex; background-color:#eaecf0;">
[[File:miner_sprite_icon.png|center]] [[File:miner_sprite_icon.png|center]]
<div>
|<div style="width:200px; display:flex; background-color:#eaecf0;">
[[File:miner_sprite_icon.png|center]] [[File:miner_sprite_icon.png|center]] [[File:miner_sprite_icon.png|center]]
<div>
|}
:::::Hah I am very familar with the CSS finese :P Can you show me an example of a multi-sprite job infobox? I said what I said because I tested my proposed solution and it worked fine :)

==Adding Vermin list to Creatures page==
I wanna do that. You guys okay with that? I asked Lethosor, and he said to ask the majority. So uh... here I am... --[[User:Zippy|Zippy]] ([[User talk:Zippy|talk]]) 20:42, 7 February 2023 (UTC)

: My main concern is with page size, [[Creature]] is absolutely massive now. In fact, now that I look at it I see a ton of broken images; I'm guessing this is related to some size or timing limit that's being hit when rendering or expanding all the templates. This should definitely be fixed before we make the page even larger. In fact I'd probably even support splitting it out into more smaller pages for easier browsing. We already have [[Alternate creature sorting]] which can be used as the master sortable list of all creatures including vermin. -[[User:OddballJoe|OddballJoe]] ([[User talk:OddballJoe|talk]]) 22:47, 7 February 2023 (UTC)
::In my opinion, the page size isn't an issue. The vermin list is large, but not "excruciatingly" large. At the absolute worst, it makes a massive page just a bit bigger, and it isn't going to ease someone's scrolling adventure by all ''that'' much if it's not there. I put the vermin list there, under the aquatic creatures, just to see how people like it. For now... --[[User:Zippy|Zippy]] ([[User talk:Zippy|talk]]) 17:24, 8 February 2023 (UTC)
::: Unfortunately page size being an issue isn't a matter of opinion: [[Creature]] was, even before your edit, huge and partially broken. Nearly the entire vermin section you added has nothing but broken images (https://imgur.com/a/gpi7guA). We need to fix the situation of broken images before we can consider increasing this page's size further. The other issue with your edit is that we cannot have two vermin tables on different pages; we need a single source of truth to be able to maintain the info (which could be a template transcluded in multiple places). —[[User:OddballJoe|OddballJoe]] ([[User talk:OddballJoe|talk]]) 19:12, 9 February 2023 (UTC)
:::: Dude dude duuuuuuuuuuuuude. You posted this message at the wooooooorst time. I was posting my thing about tree infoboxes below, which caused a "edit conflict" warning, which erased my entire thing. It's not your fault in the slightest, but that's what happened. That sucked ass. Granted, I should have copy and pasted it. I have no what the sweet sweet shit the broken image thing is about, I've looked at the page on multiple browsers and even PC's and it looks fine. I'll remove the edit, but I can't for the life of me tell you what the image problem is. Try doing a cache refresh or something. --[[User:Zippy|Zippy]] ([[User talk:Zippy|talk]]) 19:27, 9 February 2023 (UTC)
::::: Yeah, that sucks; I think when you get an edit conflict it should still let you copy at that point, but I guess you know for next time. When testing the page, try loading it logged out in a new incognito/private window to avoid local cache effects. Since mediawiki can have weird caching behavior, the wayback machine helps for resolving arguments related to caching: [https://web.archive.org/web/20230209001103/https://dwarffortresswiki.org/index.php/Creature#Vermin this snapshot] from earlier today shows tons of broken images (note that archive.org is having some issues atm so that link might not work until it's up again). —[[User:OddballJoe|OddballJoe]] ([[User talk:OddballJoe|talk]]) 19:50, 9 February 2023 (UTC)

==Updating Tree Infoboxes==
Any idea on what that should look like? I have two mockups here:
<gallery widths="223px" heights="324px">
tree_infobox_example.png|Trunk and tile.
tree_infobox_example2.png|Trunk, branch, leaves and tile.
</gallery>
Whatever the choice, someone's gonna have to really help me. The amount of images I've added and edits I've made... I'm exhausted... --[[User:Zippy|Zippy]] ([[User talk:Zippy|talk]]) 19:27, 9 February 2023 (UTC)

: Maybe we follow the same "Toggle" format as with creatures for the ASCII? Then there's probably enough room to comfortably include all or most of the tree sprites (trunk, branches of different sizes, growths). While I admire your Herculean efforts, this stuff can be automated as well. I'm working on some code for a separate project for parsing raws and extracting various df sprites, which I'm hoping to share out sometime this month, which could be helpful for this kind of thing. —[[User:OddballJoe|OddballJoe]] ([[User talk:OddballJoe|talk]]) 20:19, 9 February 2023 (UTC)

Difficulty

2023-10-28T21:21:22Z

CobaltNinja: Woops. correction.

{{Quality|Unknown}}
{{av}}
{{stub}}

While previous versions of Dwarf Fortress allowed you to toggle [[Invader|invaders]] on or off, v50 added more granular difficulty settings to fine-tune one's experience. Difficulty settings will affect whether your fortress can be attacked by outside forces, how frequent said attacks are, how big invading armies are, and [[noble]] neediness. You can modify these settings before and after embarking at any time.

== Default settings ==
'''Enemies''' has 3 options:
* '''Off''' will disable [[Ambush|ambushes]], [[Siege|sieges]], [[Megabeast|uninvited]] [[Forgotten beast|guests]], [[Werebeast|werebeasts]], and agitated wildlife attacks. It will not disable [[intrigue]], [[HFS]], or misbehaving dwarves, so it is still recommended to train a military.
* '''Normal''' is the standard Dwarf Fortress experience.
* '''Hard''' ensures a never-ending stream of [[Fun]], causing invaders to show up earlier, more often, and with more bodies to throw at the gates.
'''Economy''' has 2 options:
* '''Normal''' is the standard Dwarf Fortress economy.
* '''Hard''' requires you to produce more wealth in order to receive higher-ranking nobles, requires [[Temple|temples]] and [[Guildhall|guildhalls]] to be more valuable before satisfying petitions, and causes [[Noble|nobles]] to make more [[Mandate|mandates]] and [[Demand|demands]].

== Custom settings ==
If you wish, you can also fine-tune individual settings - maybe you only want megabeasts to assault your fortress, and would prefer the elves to leave well enough alone. The following options are available for enemy settings:
{| class="wikitable"
|-
! Setting !! Possible values !! Description !! Default values (Off, Normal, Hard)
|-
| Civilizations can attack || Yes/No || Controls whether [[Ambush|ambushes]] and [[Siege|sieges]] can occur. || No, Yes, Yes
|-
| Megabeasts can attack || Yes/No || Controls whether [[Megabeast|megabeasts]] and [[Forgotten beast|forgotten beasts]] can attack. || No, Yes, Yes
|-
| Werebeasts can attack || Yes/No || Controls whether [[Werebeast|werebeasts]] can attack. || No, Yes, Yes
|-
| Curious wilderness creatures can come to cause trouble || Yes/No || Controls whether agitated animals can assault your fortress, and whether animals will spawn with the intent to steal items. || No, Yes, Yes
|-
| Enemy population triggers || 1 to 300 || Likely affects when invasions attacks occur, and how difficult they are. Met when you have this many citizens.{{verify}} || 0/0/0/0/0, 20/50/80/110/140, 15/30/40/55/70
|-
| Enemy production triggers || 0 to 100,000,000 || Likely affects when invasions occur, and how difficult they are. Met when you've created this much wealth.{{verify}} || 0/0/0/0/0, 5000/25000/100000/200000/300000, 2500/12500/50000/100000/150000
|-
| Enemy trade triggers || 0 to 100,000,000 || Likely affects when invasions occur, and how difficult they are. Met when you've exported this much wealth.{{verify}} || 0/0/0/0/0, 500/2500/10000/20000/30000, 250/1250/5000/10000/15000
|-
| Megabeast attack period (seasons) || 0 to 100 || How many seasons must pass before a megabeast may attack your fortress.{{verify}} || 10, 10, 8
|-
| Forgotten beast sensitivity || 1 to 100,000 || Unknown; a smaller value will cause forgotten beasts to attack sooner. || 10000, 10000, 10000
|-
| Forgotten beast irritation minimum || 1 to 100,000 || Unknown; a smaller value will cause forgotten beasts to attack sooner. || 5000, 5000, 2000
|-
| Forgotten beast wealth divisor || 1 to 100,000 || Likely increases the amount of wealth you need to create before a forgotten beast attacks.{{verify}} || 40, 40, 40
|-
| Wilderness sensitivity || 1 to 100,000 || Performing nature-disrupting actions such as cutting down trees will agitate wildlife and may cause them to attack. A smaller value will increase the amount wildlife is agitated by. || 10000, 10000, 10000
|-
| Wilderness irritation minimum || 1 to 100,000 || Likely affects the maximum rate at which agitated wildlife will attack.{{verify}} || 2000, 2000, 0
|-
| Wilderness irritation decay || 0 to 100,000 || Causes wildlife to be less irritated after every season{{verify}}. A higher value will make them less irritated faster. || 2000, 2000, 0
|-
| Werebeast attack period (seasons) || 0 to 100 || How many seasons must pass before a werebeast may attack your fortress.{{verify}} || 10, 10, 8
|-
| Vampire migrant fraction || 1 to 1,000 || Affects what percentage of new migrants will be [[Vampire|vampires]]. A value of 0 will disable vampiric migrants. (Only on '''Off''' difficulty) || 0, 100, 75
|-
| Invasion caps (regulars) || 0 to 500 || The maximum amount of humanoid enemies that can be thrown at you when a civilization sieges you.{{verify}} || 0/0/0, 10/40/120, 20/60/120
|-
| Invasion caps (monsters) || 0 to 500) || The maximum amount of mounts and other tamed creatures that can be thrown at you when a civilization sieges you.{{verify}} || 0/0/0, 0/5/40, 1/10/40
|-
| Minimum raids before first siege (per civ) || 0 to 500 || Affects how many [[Ambush|ambushes]] must be performed before a civilization can try a proper siege for the first time. || 0, 2, 2
|-
| Minimum raids between sieges (per civ) || 0 to 500 || Affects how many ambushes must be performed before a civilization can try a proper siege from the second time onwards. || 0, 3, 1
|-
| Siege frequency (percentage, otherwise raid) || 0 to 100 || Percentage chance to receive a siege instead of an ambush. || 0, 25, 50
|-
| Cavern dweller scale (increase per attack) || 0 to 100 || Unknown. Likely affects how rapidly the amount of enemies cavern dwellers will send increases.{{verify}} || 0, 10, 20
|-
| Cavern dweller maximum attackers || 0 to 500 || The maximum amount of enemies that can be thrown at you when cavern dwellers attack. || 0, 50, 75
|-
| Diplomacy tree-fell count || 1 to 1000 || Affects the default amount of trees [[Elf|elven]] diplomats will request you limit your felling to. Your negotiator will still try and increase the tree limit. || 25, 25, 10
|-
| Diplomacy tree-fell count (untamed wilds) || 1 to 1000 || Affects the default amount of trees elven diplomats will request you limit your felling to if you've settled in a [[savage]] area instead. Your negotiator will still try and increase the tree limit. || 5, 5, 1
|}
The following options are available for economy settings:
{| class="wikitable"
|-
! Setting !! Possible values !! Description !! Default values (Normal, Hard)
|-
| Economy population triggers || 1 to 300 || Likely affects how many citizens you need to increase the rank of your fortress.{{verify}} || 20/50/80/110/140, 20/50/80/110/140
|-
| Economy production triggers || 1 to 100,000,000 || Unknown. Maybe affects trade caravans?{{verify}} || 5000/25000/100000/200000/300000, 25000/125000/500000/1000000/1500000
|-
| Economy trade triggers || 1 to 100,000,000 || Unknown. Maybe affects trade caravans?{{verify}} || 500/2500/10000/20000/30000, 2500/12500/50000/100000/150000
|-
| Land holder population triggers || 1 to 300 || Likely affects how [[Baron|barons]] and upwards are achieved.{{verify}} Values 4 through 10 are not used in the base game. || 20/20/20, 20/20/20
|-
| Land holder production triggers || 1 to 100,000,000 || Likely affects how barons and upwards are achieved.{{verify}} Values 4 through 10 are not used in the base game. || 10000/200000/300000, 500000/1000000/1500000
|-
| Land holder trade triggers || 1 to 100,000,000 || Likely affects how barons and upwards are achieved.{{verify}} Values 4 through 10 are not used in the base game. || 10000/20000/30000, 50000/100000/150000
|-
| Value of temple || 1 to 100,000,000 || Affects how valuable a designated [[temple]] zone must be before it satisfies a petition to create it. || 2000, 6000
|-
| Value of temple complex || 1 to 100,000,000 || Affects how valuable a designated temple zone must be before it satisfies a petition to upgrade it. || 10000, 30000
|-
| Priesthood unit count || 1 to 300 || Affects how many members of a religion must be citizens in your fortress before a petition for a temple is made. || 10, 10
|-
| High priesthood unit count || 1 to 300 || Affects how many members of a religion must be citizens in your fortress before a petition to upgrade an existing temple is made. || 25, 25
|-
| Value of guildhall || 1 to 100,000,000 || Affects how valuable a designated [[guildhall]] zone must be before it satisfies a petition to create it. || 2000, 6000
|-
| Value of grand guildhall || 1 to 100,000,000 || Affects how valuable a designated guildhall zone must be before it satisfies a petition to upgrade it. || 10000, 30000
|-
| Guild unit count || 1 to 300 || Affects how many members of a profession must be citizens in your fortress before a petition for a guildhall is made. || 10, 10
|-
| Grand guild unit count || 1 to 300 || Affects how many members of a profession must be citizens in your fortress before a petition to upgrade an existing guildhall is made. || 25, 25
|-
| Mandate period (more = fewer) || 1 to 10,000 || Affects how long nobles must wait before making new mandates. || 1000, 500
|-
| Demand period (more = fewer) || 1 to 10,000 || Affects how long nobles must wait before making new demands. || 500, 250
|}

Difficulty

2023-10-28T21:20:22Z

CobaltNinja: Created page summarizing difficulty settings. It's messy, probably inaccurate, and doesn't even have all the information. Someone else know what each setting does?

{{Quality|Unknown}}
{{av}}
{{stub}}

While previous versions of Dwarf Fortress allowed you to toggle [[Invader|invaders]] on or off, v50 added more granular difficulty settings to fine-tune one's experience. Difficulty settings will affect whether your fortress can be attacked by outside forces, how frequent said attacks are, how big invading armies are, and [[noble]] neediness. You can modify these settings before and after embarking at any time.

== Default settings ==
'''Enemies''' has 3 options:
* '''Off''' will disable [[Ambush|ambushes]], [[Siege|sieges]], and [[Megabeast|uninvited]] [[Forgotten beast|guests]], and agitated wildlife attacks. It will not disable [[intrigue]], [[HFS]], or misbehaving dwarves, so it is still recommended to train a military.
* '''Normal''' is the standard Dwarf Fortress experience.
* '''Hard''' ensures a never-ending stream of [[Fun]], causing invaders to show up earlier, more often, and with more bodies to throw at the gates.
'''Economy''' has 2 options:
* '''Normal''' is the standard Dwarf Fortress economy.
* '''Hard''' requires you to produce more wealth in order to receive higher-ranking nobles, requires [[Temple|temples]] and [[Guildhall|guildhalls]] to be more valuable before satisfying petitions, and causes [[Noble|nobles]] to make more [[Mandate|mandates]] and [[Demand|demands]].

== Custom settings ==
If you wish, you can also fine-tune individual settings - maybe you only want megabeasts to assault your fortress, and would prefer the elves to leave well enough alone. The following options are available for enemy settings:
{| class="wikitable"
|-
! Setting !! Possible values !! Description !! Default values (Off, Normal, Hard)
|-
| Civilizations can attack || Yes/No || Controls whether [[Ambush|ambushes]] and [[Siege|sieges]] can occur. || No, Yes, Yes
|-
| Megabeasts can attack || Yes/No || Controls whether [[Megabeast|megabeasts]] and [[Forgotten beast|forgotten beasts]] can attack. || No, Yes, Yes
|-
| Werebeasts can attack || Yes/No || Controls whether [[Werebeast|werebeasts]] can attack. || No, Yes, Yes
|-
| Curious wilderness creatures can come to cause trouble || Yes/No || Controls whether agitated animals can assault your fortress, and whether animals will spawn with the intent to steal items. || No, Yes, Yes
|-
| Enemy population triggers || 1 to 300 || Likely affects when invasions attacks occur, and how difficult they are. Met when you have this many citizens.{{verify}} || 0/0/0/0/0, 20/50/80/110/140, 15/30/40/55/70
|-
| Enemy production triggers || 0 to 100,000,000 || Likely affects when invasions occur, and how difficult they are. Met when you've created this much wealth.{{verify}} || 0/0/0/0/0, 5000/25000/100000/200000/300000, 2500/12500/50000/100000/150000
|-
| Enemy trade triggers || 0 to 100,000,000 || Likely affects when invasions occur, and how difficult they are. Met when you've exported this much wealth.{{verify}} || 0/0/0/0/0, 500/2500/10000/20000/30000, 250/1250/5000/10000/15000
|-
| Megabeast attack period (seasons) || 0 to 100 || How many seasons must pass before a megabeast may attack your fortress.{{verify}} || 10, 10, 8
|-
| Forgotten beast sensitivity || 1 to 100,000 || Unknown; a smaller value will cause forgotten beasts to attack sooner. || 10000, 10000, 10000
|-
| Forgotten beast irritation minimum || 1 to 100,000 || Unknown; a smaller value will cause forgotten beasts to attack sooner. || 5000, 5000, 2000
|-
| Forgotten beast wealth divisor || 1 to 100,000 || Likely increases the amount of wealth you need to create before a forgotten beast attacks.{{verify}} || 40, 40, 40
|-
| Wilderness sensitivity || 1 to 100,000 || Performing nature-disrupting actions such as cutting down trees will agitate wildlife and may cause them to attack. A smaller value will increase the amount wildlife is agitated by. || 10000, 10000, 10000
|-
| Wilderness irritation minimum || 1 to 100,000 || Likely affects the maximum rate at which agitated wildlife will attack.{{verify}} || 2000, 2000, 0
|-
| Wilderness irritation decay || 0 to 100,000 || Causes wildlife to be less irritated after every season{{verify}}. A higher value will make them less irritated faster. || 2000, 2000, 0
|-
| Werebeast attack period (seasons) || 0 to 100 || How many seasons must pass before a werebeast may attack your fortress.{{verify}} || 10, 10, 8
|-
| Vampire migrant fraction || 1 to 1,000 || Affects what percentage of new migrants will be [[Vampire|vampires]]. A value of 0 will disable vampiric migrants. (Only on '''Off''' difficulty) || 0, 100, 75
|-
| Invasion caps (regulars) || 0 to 500 || The maximum amount of humanoid enemies that can be thrown at you when a civilization sieges you.{{verify}} || 0/0/0, 10/40/120, 20/60/120
|-
| Invasion caps (monsters) || 0 to 500) || The maximum amount of mounts and other tamed creatures that can be thrown at you when a civilization sieges you.{{verify}} || 0/0/0, 0/5/40, 1/10/40
|-
| Minimum raids before first siege (per civ) || 0 to 500 || Affects how many [[Ambush|ambushes]] must be performed before a civilization can try a proper siege for the first time. || 0, 2, 2
|-
| Minimum raids between sieges (per civ) || 0 to 500 || Affects how many ambushes must be performed before a civilization can try a proper siege from the second time onwards. || 0, 3, 1
|-
| Siege frequency (percentage, otherwise raid) || 0 to 100 || Percentage chance to receive a siege instead of an ambush. || 0, 25, 50
|-
| Cavern dweller scale (increase per attack) || 0 to 100 || Unknown. Likely affects how rapidly the amount of enemies cavern dwellers will send increases.{{verify}} || 0, 10, 20
|-
| Cavern dweller maximum attackers || 0 to 500 || The maximum amount of enemies that can be thrown at you when cavern dwellers attack. || 0, 50, 75
|-
| Diplomacy tree-fell count || 1 to 1000 || Affects the default amount of trees [[Elf|elven]] diplomats will request you limit your felling to. Your negotiator will still try and increase the tree limit. || 25, 25, 10
|-
| Diplomacy tree-fell count (untamed wilds) || 1 to 1000 || Affects the default amount of trees elven diplomats will request you limit your felling to if you've settled in a [[savage]] area instead. Your negotiator will still try and increase the tree limit. || 5, 5, 1
|}
The following options are available for economy settings:
{| class="wikitable"
|-
! Setting !! Possible values !! Description !! Default values (Normal, Hard)
|-
| Economy population triggers || 1 to 300 || Likely affects how many citizens you need to increase the rank of your fortress.{{verify}} || 20/50/80/110/140, 20/50/80/110/140
|-
| Economy production triggers || 1 to 100,000,000 || Unknown. Maybe affects trade caravans?{{verify}} || 5000/25000/100000/200000/300000, 25000/125000/500000/1000000/1500000
|-
| Economy trade triggers || 1 to 100,000,000 || Unknown. Maybe affects trade caravans?{{verify}} || 500/2500/10000/20000/30000, 2500/12500/50000/100000/150000
|-
| Land holder population triggers || 1 to 300 || Likely affects how [[Baron|barons]] and upwards are achieved.{{verify}} Values 4 through 10 are not used in the base game. || 20/20/20, 20/20/20
|-
| Land holder production triggers || 1 to 100,000,000 || Likely affects how barons and upwards are achieved.{{verify}} Values 4 through 10 are not used in the base game. || 10000/200000/300000, 500000/1000000/1500000
|-
| Land holder trade triggers || 1 to 100,000,000 || Likely affects how barons and upwards are achieved.{{verify}} Values 4 through 10 are not used in the base game. || 10000/20000/30000, 50000/100000/150000
|-
| Value of temple || 1 to 100,000,000 || Affects how valuable a designated [[temple]] zone must be before it satisfies a petition to create it. || 2000, 6000
|-
| Value of temple complex || 1 to 100,000,000 || Affects how valuable a designated temple zone must be before it satisfies a petition to upgrade it. || 10000, 30000
|-
| Priesthood unit count || 1 to 300 || Affects how many members of a religion must be citizens in your fortress before a petition for a temple is made. || 10, 10
|-
| High priesthood unit count || 1 to 300 || Affects how many members of a religion must be citizens in your fortress before a petition to upgrade an existing temple is made. || 25, 25
|-
| Value of guildhall || 1 to 100,000,000 || Affects how valuable a designated [[guildhall]] zone must be before it satisfies a petition to create it. || 2000, 6000
|-
| Value of grand guildhall || 1 to 100,000,000 || Affects how valuable a designated guildhall zone must be before it satisfies a petition to upgrade it. || 10000, 30000
|-
| Guild unit count || 1 to 300 || Affects how many members of a profession must be citizens in your fortress before a petition for a guildhall is made. || 10, 10
|-
| Grand guild unit count || 1 to 300 || Affects how many members of a profession must be citizens in your fortress before a petition to upgrade an existing guildhall is made. || 25, 25
|-
| Mandate period (more = fewer) || 1 to 10,000 || Affects how long nobles must wait before making new mandates. || 1000, 500
|-
| Demand period (more = fewer) || 1 to 10,000 || Affects how long nobles must wait before making new demands. || 500, 250
|}

Visitor

2023-10-28T20:14:30Z

CobaltNinja: /* Behavior */

{{Quality|Unrated}}
{{av}}
[[Image:Visitors Inspecting Classical Ruins MET DP230572.jpg|thumb|300px|right|Visitors inspecting the nearby architecture.]]A '''visitor''' or '''guest''' is a person who comes to the site at random to drop by at a [[location]], which includes [[tavern]]s, [[library|libraries]], and [[temple]]s. Some may seek permanent employment. Initially, a fortress will receive only about three visitors for a given location. First guests will initially visit out of curiosity, and when they leave, they bring back word of what the place is like. If the location proves to be popular and not deadly, it will attract more visitors. "Visitors" do not include [[merchant]]s, [[diplomat]]s, [[creature|wild animals]], or [[invader]]s.

The arrival of a visitor is notified in the [[announcement]]s. Visitors are listed in {{DFtext|Others}} on the [[unit list|{{k|u}}nit list]] and labeled as {{DFtext|Guest|2:1}} on the right side of their names, along with their current activity.

Visitors provide protection and social interactions for [[Citizenship|citizen]]s. Visitors are also a source of [[rumor]]s, which they bring and spread from site to site, including the player's fort. Several downsides to visitors include [[overcrowding]], [[alcohol]] depletion, accidental conflicts with citizens, and [[FPS]] issues from the increased population. Players wanting to remain an isolated fortress should restrict locations to {{DFtext|Citizens only|6:1}} to prevent people from visiting them, and shouldn't reveal a cavern, as its discovery will bring [[Visitor#Monster_slayer_and_beast_hunter|monster slayers]].

Visitor population cap is set to 100 by default, and can be modified in [[d_init.txt]] from <code>[VISITOR_CAP: <number>]</code>. If set to 0, visitors will not come at all. <code>[VISITOR_CAP]</code> does not count long-term residents.

== Behavior ==

A visitor's current activities, objectives, and type can be investigated by pressing {{k|v|g}} and hovering over it. The visitor must first interact with the locals before the information can be shown. Generally, visitors wanting to petition for residency are described as "seeking work", and typically call for meetings as soon as they arrive, unless there is another meeting taking place. Visitors who came to "relax" will socialize and partake in performances in taverns. Visitors described as "ready to leave" means they are exiting the map.

Visitors do not need to eat, drink, or sleep, but they receive alcohol from [[tavern keeper]]s. Inn rooms are used for long-term residents only.

Guests are initially friendly to citizens and other guests. Drunk or otherwise violence-oriented visitors — particularly goblins, due to their [[ethic]]s — may start arguments which can escalate into potentially-lethal brawls, or even [[loyalty cascade]]s. Visitors side with the attacking [[faction|force]] of their own civilization. On the other hand, in non-player [[site]]s, visitors can be drafted as defenders against invading armies (including your own [[mission]]s).

When visitors first arrive, they will head towards their desired location and do their respective activities, if possible. If there are no locations assigned that allow visitors, they locate a [[meeting hall]] or an active [[meeting area]] and remain there. They cannot do any activities in meeting halls or unassigned meeting areas, even socializing. If there are no available locations, meeting halls, or meeting areas, visitors will stand around and do nothing. Visitors finish their current activities first before relocating.

Their current activity can be viewed in the unit list next to {{DFtext|Guest /|2:1}}. Visitors with {{DFtext|No Activity|6:1}} either means they are leaving, have just finished an activity, or have no location available to do their activities. Visitors can wander into other locations, but do not do activities that they did not come for. For example, visitors coming to relax will only socialize at a tavern and do not do other activities such as reading books or praying. Visitors must become long-term residents in order to do other activities in different locations.

Visitors will try to leave after they complete all of their activities. If they cannot find a path to exit the map (due to say, a forbidden door) they seem to "panic", wandering around frantically looking for an exit. Visitors will also leave after being interrogated for a crime, though this doesn't stop you from re-interrogating them if you wish.

== Visitor types ==
{{stub}}
=== Diplomat ===
:{{dftext|This visitor has come for diplomacy and to relax.|7:1}}

Foreign [[diplomat]]s arrive to your fortress for a multitude of reasons. Once their meetings are done, they will linger around your locations, sometimes for many months until they finally decide to leave. They are often followed by a pair of bodyguards who will defend them if they are under threat.

=== Mercenary ===
[[Mercenary|Mercenaries]] come to enlist in the [[military]], or to relax at a tavern. They can petition for long-term residency, and once accepted, they can be added to any [[squad]] (note that they cannot be squad leaders) and will follow any order the squad receives.

=== Monster slayer and beast hunter ===
:{{dftext|This visitor has come to slay beasts.|7:1}}

[[Monster slayer]]s and [[beast hunter]]s seek wild creatures to kill, or just to relax at a tavern{{version|0.44.01}}. Monster slayers start arriving after a [[cavern]] is revealed; there does not need to be an unrestricted/public [[location]], such as a [[tavern]] - the discovery of a cavern is enough.

After they socialize at a tavern for a while, they will [[petition]] for long-term residency. If granted, they will go outdoors or deep below to slay beasts; if not, they will simply leave. They will not begin to slay beasts until they become a long-term resident, and there is a [[path]] to such a beast.

Monster slayers go down into the caverns alone to slay subterranean creatures. Beast hunters remain above-ground and hunt wild animals, similarly to [[hunter]]s.{{verify}}. Neither can have any [[labor]] enabled, but they are another able (and expendable) body if something unpleasant gets to where they are.

=== Performer ===
:{{dftext|This visitor has come to perform.|7:1}}

[[Performer]]s, as their name suggests, visit taverns to perform for other guests and citizens. They tell stories, dance, make music, or recite poetry. They do not ask for anything in return for their performances. They may seek long-term work.

Groups of performers under a single name may arrive as a [[performance troupe]], and when petitioning will apply as a group. Allowing the petition will allow all of its members. Troupes may be made up of several bards and poets. Attacking or killing one member of a troupe does not automatically turn the rest of the group hostile. Due to a bug, troupes may arrive completely naked{{Bug|9234}} .

=== Scholar ===
:{{dftext|This visitor has come to study.|7:1}}

[[Scholar]]s come to study in a library, which includes reading books and discussing topics with other scholars. If writing materials are available, they may use them to write their own books. While visiting scholars can depart with one or more of the local books from the library, they can also leave books that they have carried or written, thus encouraging new content in the book collection.

=== Traveler ===
:{{dftext|This visitor has come to relax.|7:1}}
:{{dftext|This visitor has come seeking sanctuary.|7:1}}

Travelers have no special purposes, and most only come to relax. Some may seek sanctuary if they were liberated from a site during [[mission]]s. Travelers who seek sanctuary will be able to petition even if there are no locations assigned that allow visitors.

=== Warrior ===
Warriors frequently visit the tavern to relax. They come armed with weapons and armor, so it is ill-advised to fight them. Most warriors are traveling [[quest]]ers, seeking rumors and asking questions regarding the location of their target, which is usually a lost artifact. Otherwise, they come to provide specific services.

=== Miscellaneous ===
Other types of visitors may come, such as [[prophet]]s, [[monk]]s, [[pilgrim]]s, [[peddler]]s or petty [[criminal]]s. They are for the most part identical to travelers, though sometimes (often times) they are [[agent]]s assuming fake identities in order to scout your fortress for items of value (see the Secret Agents section below)

== Questers ==

[[Quester]]s will visit your fortress as representatives of a foreign entity, usually looking to retrieve an [[artifact]]. They are usually warriors, i.e. mercenaries. They go through your tavern first to gather informations from chatting other patrons, then leave after they've learned what they want. If one of your dwarves can't hold their tongue and reveals the presence of an artifact they're looking for inside your fortress, they will usually make more pressing demands or even attempt to steal it. Visiting questers will leave after a while regardless of what they learn or how much they socialize.

== Secret agents ==

[[Agent]]s will visit from hostile civilizations to spy.{{version|0.44.01}} They assume cover identities and gather information concerning [[artifact]]s, then leave to report back to their civilization. Agents cannot be forced to reveal their true identities, but players can distinguish them from other visitors by closely inspecting their names, roles, and equipment. For example, an agent might arrive at your fort claiming to be called "Urist McBard" despite being an elf carrying only weapons and armor, with no bard skills whatsoever. Also, visitors with "names" appearing in quotation marks seems to be a reliable indicator that the individual is an agent using a false name.

Additionally, if you have any open or cold cases in the justice screen, you can interrogate them to attempt to determine whether they are, in fact, agents seeking to steal your artifacts or perform other nefarious deeds at your fort. If your interogations fail (because your Sheriff or Captain of the Guard has lower social skills than the interrogation subject), but you know the visitor is an agent, you can still convict them (falsely) of crimes and your Sheriff/Captain of the Guard (or other members of your Captain of Guard's militia squad) will attempt to arrest them.

Note that if the suspect is able to evade capture and is about to escape (but is still on your map) you can give them a nickname on their character page (for example, you might nickname them "KILL THIS THIEF"). This nickname will persist after they leave your map and will appear in their name the next time they visit your fortress.

== Petitioning ==

Visitors who wish to work or stay longer can [[petition]] to become ''long-term residents''. After about two years, long-term residents can apply for [[citizenship]], which makes them into full-fledged citizens.

=== Long-term residency ===

Visitors can [[petition]] to stay for a long time. When visitors request for long-term residency, they attend a meeting with the [[mayor]] at the mayor's [[office]]. Once the meeting starts, the {{k|P}}etition notice will flash on top of the screen. In the petition screen, their purpose to stay is displayed, and players can have the final say on whether they become a resident or not. Currently there are four reasons to stay: "eradicating monsters", "entertaining citizens and visitors", "soldiering", "study".

When accepted, visitors will be added to the citizens list in the units screen. Their needs, preferences, and thoughts will be visible as normal, but labors or occupations cannot be assigned to them. [[Soldier]]ing visitors can be assigned to [[squad]]s, but they cannot be appointed as [[Militia captain]]s. Aside from doing their main activities, long-term residents eat, drink, sleep, perform other activities, and reside at the [[Tavern]] if rooms are available. Locations set to {{DFtext|Citizens and long-term residents only|7:1}} are allowed for long-term residents; locations set to {{DFtext|Citizens only|6:1}}, however, disallow long-term residents.

Having finished their requirement, visitors whose petitions were not accepted will leave immediately after the meeting, unless they came for additional reasons.

=== Citizenship ===

Long-term residents can apply for citizenship after living in the fort for about two years. Accepting the application will allow labors and occupations assigned to them.

To assign them occupations, the fort-wide occupation they initially had when applying for long-term residency must be unassigned. View the new resident, then select their Labor tab, then their Locations sub-tab, and remove any Location assignments. After this, the new citizens will become available for other occupations.

== Bugs ==

* As of v50.05, AI pathing can sometimes cause visitors (along with caravans and their wagons) to become stuck waiting to enter the map, which can prevent some or all types of visitors from some or all civs from visiting, and even prevent some merchants from entering the map. This can be fixed through [[DFHack|DFHack's]] ``fix/stuck-merchants`` command.

{{Category|Fortress mode}}{{Category|Non-player characters}}
[[ru:Visitor]]

Visitor

2023-10-28T20:14:12Z

CobaltNinja: /* Behavior */ Based off of my experiences; visitors always say they're ready to leave after being interrogated, even if they just got here.

{{Quality|Unrated}}
{{av}}
[[Image:Visitors Inspecting Classical Ruins MET DP230572.jpg|thumb|300px|right|Visitors inspecting the nearby architecture.]]A '''visitor''' or '''guest''' is a person who comes to the site at random to drop by at a [[location]], which includes [[tavern]]s, [[library|libraries]], and [[temple]]s. Some may seek permanent employment. Initially, a fortress will receive only about three visitors for a given location. First guests will initially visit out of curiosity, and when they leave, they bring back word of what the place is like. If the location proves to be popular and not deadly, it will attract more visitors. "Visitors" do not include [[merchant]]s, [[diplomat]]s, [[creature|wild animals]], or [[invader]]s.

The arrival of a visitor is notified in the [[announcement]]s. Visitors are listed in {{DFtext|Others}} on the [[unit list|{{k|u}}nit list]] and labeled as {{DFtext|Guest|2:1}} on the right side of their names, along with their current activity.

Visitors provide protection and social interactions for [[Citizenship|citizen]]s. Visitors are also a source of [[rumor]]s, which they bring and spread from site to site, including the player's fort. Several downsides to visitors include [[overcrowding]], [[alcohol]] depletion, accidental conflicts with citizens, and [[FPS]] issues from the increased population. Players wanting to remain an isolated fortress should restrict locations to {{DFtext|Citizens only|6:1}} to prevent people from visiting them, and shouldn't reveal a cavern, as its discovery will bring [[Visitor#Monster_slayer_and_beast_hunter|monster slayers]].

Visitor population cap is set to 100 by default, and can be modified in [[d_init.txt]] from <code>[VISITOR_CAP: <number>]</code>. If set to 0, visitors will not come at all. <code>[VISITOR_CAP]</code> does not count long-term residents.

== Behavior ==

A visitor's current activities, objectives, and type can be investigated by pressing {{k|v|g}} and hovering over it. The visitor must first interact with the locals before the information can be shown. Generally, visitors wanting to petition for residency are described as "seeking work", and typically call for meetings as soon as they arrive, unless there is another meeting taking place. Visitors who came to "relax" will socialize and partake in performances in taverns. Visitors described as "ready to leave" means they are exiting the map.

Visitors do not need to eat, drink, or sleep, but they receive alcohol from [[tavern keeper]]s. Inn rooms are used for long-term residents only.

Guests are initially friendly to citizens and other guests. Drunk or otherwise violence-oriented visitors — particularly goblins, due to their [[ethic]]s — may start arguments which can escalate into potentially-lethal brawls, or even [[loyalty cascade]]s. Visitors side with the attacking [[faction|force]] of their own civilization. On the other hand, in non-player [[site]]s, visitors can be drafted as defenders against invading armies (including your own [[mission]]s).

When visitors first arrive, they will head towards their desired location and do their respective activities, if possible. If there are no locations assigned that allow visitors, they locate a [[meeting hall]] or an active [[meeting area]] and remain there. They cannot do any activities in meeting halls or unassigned meeting areas, even socializing. If there are no available locations, meeting halls, or meeting areas, visitors will stand around and do nothing. Visitors finish their current activities first before relocating.

Their current activity can be viewed in the unit list next to {{DFtext|Guest /|2:1}}. Visitors with {{DFtext|No Activity|6:1}} either means they are leaving, have just finished an activity, or have no location available to do their activities. Visitors can wander into other locations, but do not do activities that they did not come for. For example, visitors coming to relax will only socialize at a tavern and do not do other activities such as reading books or praying. Visitors must become long-term residents in order to do other activities in different locations.

Visitors will try to leave after they complete all of their activities. If they cannot find a path to exit the map (due to say, a forbidden door) they seem to "panic", wandering around frantically looking for an exit. Visitors will also leave after being interrogated for a crime.

== Visitor types ==
{{stub}}
=== Diplomat ===
:{{dftext|This visitor has come for diplomacy and to relax.|7:1}}

Foreign [[diplomat]]s arrive to your fortress for a multitude of reasons. Once their meetings are done, they will linger around your locations, sometimes for many months until they finally decide to leave. They are often followed by a pair of bodyguards who will defend them if they are under threat.

=== Mercenary ===
[[Mercenary|Mercenaries]] come to enlist in the [[military]], or to relax at a tavern. They can petition for long-term residency, and once accepted, they can be added to any [[squad]] (note that they cannot be squad leaders) and will follow any order the squad receives.

=== Monster slayer and beast hunter ===
:{{dftext|This visitor has come to slay beasts.|7:1}}

[[Monster slayer]]s and [[beast hunter]]s seek wild creatures to kill, or just to relax at a tavern{{version|0.44.01}}. Monster slayers start arriving after a [[cavern]] is revealed; there does not need to be an unrestricted/public [[location]], such as a [[tavern]] - the discovery of a cavern is enough.

After they socialize at a tavern for a while, they will [[petition]] for long-term residency. If granted, they will go outdoors or deep below to slay beasts; if not, they will simply leave. They will not begin to slay beasts until they become a long-term resident, and there is a [[path]] to such a beast.

Monster slayers go down into the caverns alone to slay subterranean creatures. Beast hunters remain above-ground and hunt wild animals, similarly to [[hunter]]s.{{verify}}. Neither can have any [[labor]] enabled, but they are another able (and expendable) body if something unpleasant gets to where they are.

=== Performer ===
:{{dftext|This visitor has come to perform.|7:1}}

[[Performer]]s, as their name suggests, visit taverns to perform for other guests and citizens. They tell stories, dance, make music, or recite poetry. They do not ask for anything in return for their performances. They may seek long-term work.

Groups of performers under a single name may arrive as a [[performance troupe]], and when petitioning will apply as a group. Allowing the petition will allow all of its members. Troupes may be made up of several bards and poets. Attacking or killing one member of a troupe does not automatically turn the rest of the group hostile. Due to a bug, troupes may arrive completely naked{{Bug|9234}} .

=== Scholar ===
:{{dftext|This visitor has come to study.|7:1}}

[[Scholar]]s come to study in a library, which includes reading books and discussing topics with other scholars. If writing materials are available, they may use them to write their own books. While visiting scholars can depart with one or more of the local books from the library, they can also leave books that they have carried or written, thus encouraging new content in the book collection.

=== Traveler ===
:{{dftext|This visitor has come to relax.|7:1}}
:{{dftext|This visitor has come seeking sanctuary.|7:1}}

Travelers have no special purposes, and most only come to relax. Some may seek sanctuary if they were liberated from a site during [[mission]]s. Travelers who seek sanctuary will be able to petition even if there are no locations assigned that allow visitors.

=== Warrior ===
Warriors frequently visit the tavern to relax. They come armed with weapons and armor, so it is ill-advised to fight them. Most warriors are traveling [[quest]]ers, seeking rumors and asking questions regarding the location of their target, which is usually a lost artifact. Otherwise, they come to provide specific services.

=== Miscellaneous ===
Other types of visitors may come, such as [[prophet]]s, [[monk]]s, [[pilgrim]]s, [[peddler]]s or petty [[criminal]]s. They are for the most part identical to travelers, though sometimes (often times) they are [[agent]]s assuming fake identities in order to scout your fortress for items of value (see the Secret Agents section below)

== Questers ==

[[Quester]]s will visit your fortress as representatives of a foreign entity, usually looking to retrieve an [[artifact]]. They are usually warriors, i.e. mercenaries. They go through your tavern first to gather informations from chatting other patrons, then leave after they've learned what they want. If one of your dwarves can't hold their tongue and reveals the presence of an artifact they're looking for inside your fortress, they will usually make more pressing demands or even attempt to steal it. Visiting questers will leave after a while regardless of what they learn or how much they socialize.

== Secret agents ==

[[Agent]]s will visit from hostile civilizations to spy.{{version|0.44.01}} They assume cover identities and gather information concerning [[artifact]]s, then leave to report back to their civilization. Agents cannot be forced to reveal their true identities, but players can distinguish them from other visitors by closely inspecting their names, roles, and equipment. For example, an agent might arrive at your fort claiming to be called "Urist McBard" despite being an elf carrying only weapons and armor, with no bard skills whatsoever. Also, visitors with "names" appearing in quotation marks seems to be a reliable indicator that the individual is an agent using a false name.

Additionally, if you have any open or cold cases in the justice screen, you can interrogate them to attempt to determine whether they are, in fact, agents seeking to steal your artifacts or perform other nefarious deeds at your fort. If your interogations fail (because your Sheriff or Captain of the Guard has lower social skills than the interrogation subject), but you know the visitor is an agent, you can still convict them (falsely) of crimes and your Sheriff/Captain of the Guard (or other members of your Captain of Guard's militia squad) will attempt to arrest them.

Note that if the suspect is able to evade capture and is about to escape (but is still on your map) you can give them a nickname on their character page (for example, you might nickname them "KILL THIS THIEF"). This nickname will persist after they leave your map and will appear in their name the next time they visit your fortress.

== Petitioning ==

Visitors who wish to work or stay longer can [[petition]] to become ''long-term residents''. After about two years, long-term residents can apply for [[citizenship]], which makes them into full-fledged citizens.

=== Long-term residency ===

Visitors can [[petition]] to stay for a long time. When visitors request for long-term residency, they attend a meeting with the [[mayor]] at the mayor's [[office]]. Once the meeting starts, the {{k|P}}etition notice will flash on top of the screen. In the petition screen, their purpose to stay is displayed, and players can have the final say on whether they become a resident or not. Currently there are four reasons to stay: "eradicating monsters", "entertaining citizens and visitors", "soldiering", "study".

When accepted, visitors will be added to the citizens list in the units screen. Their needs, preferences, and thoughts will be visible as normal, but labors or occupations cannot be assigned to them. [[Soldier]]ing visitors can be assigned to [[squad]]s, but they cannot be appointed as [[Militia captain]]s. Aside from doing their main activities, long-term residents eat, drink, sleep, perform other activities, and reside at the [[Tavern]] if rooms are available. Locations set to {{DFtext|Citizens and long-term residents only|7:1}} are allowed for long-term residents; locations set to {{DFtext|Citizens only|6:1}}, however, disallow long-term residents.

Having finished their requirement, visitors whose petitions were not accepted will leave immediately after the meeting, unless they came for additional reasons.

=== Citizenship ===

Long-term residents can apply for citizenship after living in the fort for about two years. Accepting the application will allow labors and occupations assigned to them.

To assign them occupations, the fort-wide occupation they initially had when applying for long-term residency must be unassigned. View the new resident, then select their Labor tab, then their Locations sub-tab, and remove any Location assignments. After this, the new citizens will become available for other occupations.

== Bugs ==

* As of v50.05, AI pathing can sometimes cause visitors (along with caravans and their wagons) to become stuck waiting to enter the map, which can prevent some or all types of visitors from some or all civs from visiting, and even prevent some merchants from entering the map. This can be fixed through [[DFHack|DFHack's]] ``fix/stuck-merchants`` command.

{{Category|Fortress mode}}{{Category|Non-player characters}}
[[ru:Visitor]]

Invader

2023-10-28T20:09:11Z

CobaltNinja: Clarified difficulty. Turning enemies off will only disable sieges and megabeasts.

{{Quality|Superior}}
{{av}}

'''Invader''' is a catch-all term for creatures that come to your fortress with the sole purpose of killing and/or enslaving your [[Dwarf|dwarves]]. Outside of hostile wildlife, they serve as the main source of [[fun]] of a playthrough as more and more critters choose to try and destroy you. Whenever an invader is discovered, the game will pause, center on them, and a red message will alert the player of what exactly they are.

Whether a fortress is targeted by invaders is mainly related to its total population, its accumulated [[wealth]] and its distance from the invader's base of operations, though some types of invasions may skip certain prerequisites. Most invaders also require a land path to the fortress in order to invade it, meaning some invasions can be avoided by settling on an [[island]].

The presence of invaders can be customized in <code>Settings</code>→<code>Difficulty</code>; changing to <code>Enemies: Off</code> will disable invaders (though this will not prevent [[intrigue]] or [[HFS]]), or by clicking the Custom Settings button, more fine-tuning (such as adjusting the type and frequency of enemies) may be done.

==Types of invaders==

*[[Ambush]]es and [[siege]]s, launched by [[civilization]]s at [[war]] with your dwarves
*[[Megabeast]]s and [[semi-megabeast]]s
*[[Thief|Thieves]], such as [[goblin]] snatchers and [[kobold]] thieves
*[[Werebeast]]s

{{D for Dwarf}}

Back in the good ol' days we could just say "[[Goblin]]" and everyone would know what you meant. But what with goblin [[merchant]]s popping up every year (admittedly only at a few new-age dwarven forts that proclaim "free love" and "tolerance" and "baloney"); and both [[human]]s, [[elf|elves]] and even other [[dwarf|dwarves]] mustering their forces for war, such racist remarks are no longer tolerated in today's modern dwarven society,

No, when someone visits your fort to stick the pointy end of their sword through your beer-soaked belly you should be politically correct and say "Oh drat! An ''invader''! Curse them!" We don't want <s>goblins</s> creatures getting upset.

==Trivia==
*Invading creatures can do so regardless of their [[age]], which can lead to rare and unusual events such as being attacked by a werebeast [[Children|child]] or a [[roc]] hatchling.

{{Military}}
[[ru:Invader]]

{{Category|Fortress mode}}

Dwarf Fortress Wiki talk:Versions

2023-10-18T13:38:32Z

CobaltNinja: /* v50 specific issues */ added section discussing difficulty settings

{{archive|
# [[DF Talk:Versions/Archive 1|Page 1]]}}

== Version 0.31.19 starts a new DF generation? ==

My reading of Toady's comments on the release of 0.31.19 is that it came out basically because he felt it would take too long to get DF all the way to 0.32. With the ore changes, the sitefinder changes, the addition of grazing and several different industries, there's a lot of changes between 31.18 and 31.19. So I'm thinking it might be a good idea to call it the first release of DF2011 - and what we refer to as "DF2010" would then become 0.31.18.

Thoughts? --[[User:DeMatt|DeMatt]] 07:06, 28 February 2011 (UTC)

==Revisiting Redirects==
I wasn't around when the redirect policy was created, and I'm having trouble understanding the rationale. The example claims that linking [[Main:Cheese]] to [[cv:Cheese maker]] is problematic...but mainspace only ever redirects to the current version. If the best target in the current version is cheese maker, why not link to it directly? (It's not, at least for Cheese, since [[DF2012:Cheese]] exists now.) The explanation seems to be claiming that 40d articles that link to Cheese will follow the Mainspace link--but that hasn't been the case for a long while now. Articles in 40d automatically link against other articles in 40d, so that version remains internally consistent no matter where mainspace links to in the current version. For a current example, what do we gain by linking [[Main:Mead]] to [[cv:Mead]] and linking [[DF2012:Mead]] to [[DF2012:Alcohol]]?

If this really is just an outdated procedure, I recommend we drop the mummery and allow mainspace to link to cv:(best target). Double redirects ''may'' work (sometimes, but [[Main:Mead]] demonstrates a common problem where automatic redirection fails), but if they are unnecessary I think they should be avoided, partly because of problems like [[Main:Mead]] and partly because of the effort required to protect double redirects from users who believe they are problematic.--[[User:Loci|Loci]] ([[User talk:Loci|talk]]) 20:16, 8 January 2014 (UTC)

:I was just thinking that. I'm currently attempting to write a basic extension to eliminate the need for mainspace redirects entirely, although Mediawiki's class structure may make this more difficult than I had hoped (the only method I've found for resolving redirects takes the ''article text'' instead of a title, e.g. "#REDIRECT ..."). I do agree that the current situation with redirects isn't ideal, so I'm hoping this will work better (once I get it to work). --[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 20:42, 8 January 2014 (UTC)

Okay, that wasn't quite as clear as I meant it to be. In general, I think this is a tricky situation. Mediawiki wasn't designed to have five content namespaces, and certainly not chains of redirects between them. The problem that was pointed out in the [[DF:REDIR|policy]] is the fact that with:
Main:Foo -> cv:Bar
pages in the cv: namespace can't use [[<nowiki/>foo]], since the namespace links modification causes it to be treated as [[<nowiki/>cv:foo]] instead, which doesn't exist. The current suggested solution is this:
Main:Foo -> cv:Foo -> cv:Bar
This fixes the problem of [[<nowiki/>foo]] not working on cv pages, but creates issues with double redirects not always working. Another solution, which is more intuitive to new editors, is:
Main:Foo -> cv:Bar
cv:Foo -> cv:Bar
Both require creating two redirects. The first method has the advantage of ''ensuring'' that the cv redirect exists (otherwise, main:foo would be a redlink), while the second has the advantage of working more reliably in a couple cases.

What I'm trying to do is make main:Foo "jump" to cv:Foo when cv:foo exists, ''even if main:foo doesn't exist'' (basically it would treat all mainspace pages as redirects to cv pages, but only if the cv page exists and not the mainspace page). I had main:Bar jumping to cv:Bar fine, but if cv:Foo redirected to cv:Bar, accessing main:Foo would mysteriously stop at cv:Foo even if I increased the redirect limit. What I'm trying to do now is follow the redirects internally, without relying on Mediawiki to do it automatically - unfortunately, that has proved to be harder than I had hoped (and I sent my web server into an infinite loop while trying). I will try to work on this some more when I get a chance, although I'm not sure when that'll be yet :(. For now, feel free to fix broken double mainspace redirects as necessary, as long as redirects in the DF2012 namespace stay pointing to the right page (and new mainspace redirects get added in the DF2012 namespace too). --[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 04:21, 9 January 2014 (UTC)

:You're treating cv like a namespace--it's not. It is simply shorthand for "fill in the current version here". [http://dwarffortresswiki.org/index.php?title=User_talk:Briess&diff=182404&oldid=181281 As I discovered a long time ago on a server not far away], linking from Main:Foo to cv:Foo tends to break redirection chains. If, instead of linking to cv:Foo, you link to DF2012:Foo, it might just work. It would, of course, be better if your patch could evaluate cv itself, but even if you have to hardcode the current version it's a single point of maintenance that requires update very infrequently. (For that matter, we could probably dispense with the cv hack entirely and just have a bot update mainspace links from DF2012 to DF201X when we switch to a new version.)--[[User:Loci|Loci]] ([[User talk:Loci|talk]]) 20:05, 9 January 2014 (UTC)
::I know cv isn't a namespace - I was just trying to avoid future confusion when the DF2012 namespace changes. It's interesting that changing "cv" to "DF2012" fixes some broken redirects, although I've found that simply making an edit to a broken redirect can usually fix it as well. I've actually had the most problems with double redirects when the second one (in the DF2012 namespace) doesn't use the DF2012 prefix (e.g. main:Foo containing <nowiki>[[cv:Foo]] and DF2012:Foo containing [[Bar]]</nowiki>). I'd rather keep the cv alias even if it isn't necessary for mainspace redirects when I get the patch to work, since it makes it easier to refer to the current version of the page (for example, several MDF articles contain links to a vanilla page for things that don't change in the mod).
::Also, using aliases like "cv" is supported by Mediawiki; in fact, several WMF wikis use them (for example, "[[wikipedia:WP:Redirects|WP:Redirects]]" on Wikipedia). It's quite likely that Mediawiki isn't processing double redirects using aliases correctly, though, since that's uncommon on most wikis. --[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 21:35, 9 January 2014 (UTC)

In light of the lack of support for the current redirect policy, I propose we replace the current redirect section with:

:Mainspace article pages should use the cv: alias when redirecting to a versioned page, which will automatically update the link when a new version is released. For example, page "Main:Foo" should redirect to page "cv:Bar" (where "Bar" is the page that best describes the topic Foo in the current version).

:Pages in mainspace should only redirect to an older versioned page if that content no longer exists in the current version of the game (e.g. [[Cave river]], [[Chunk]]). In these cases the cv: alias cannot be used.

:Pages inside a versioned namespace should not use the cv: alias. Instead, they should redirect to the best page within that versioned namespace (e.g. [[DF2012:Dodging]], [[v0.31:Drink]]).

:Due to limitations of the wiki software, double redirects should be avoided if possible. When fixing double redirects in mainspace, please make sure to use the cv: alias as appropriate.

If no one objects, I will make this change in a few days.--[[User:Loci|Loci]] ([[User talk:Loci|talk]]) 20:21, 15 January 2014 (UTC)

:Okay with me. It may be worth mentioning that double redirects only really need to be changed when they don't work (since changing a lot of redirects that work isn't necessary), but I think it's clearer and more relevant than the current policy. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 00:26, 16 January 2014 (UTC)

Done.--[[User:Loci|Loci]] ([[User talk:Loci|talk]]) 20:55, 22 January 2014 (UTC)

I was finally able to get my extension to work after being motivated by one too many malfunctioning redirects. It now causes nonexistent pages in the main namespace to behave exactly like redirects to their DF2012 counterparts (when linked to, accessed directly, and transcluded). Double redirects also work (up to 100, in fact, although that was a temporary safety measure that I'll probably change). This means we'll be able to safely get rid of all mainspace redirects (redirects that redirect to something other than "cv" will still function if not deleted). —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 01:20, 14 March 2014 (UTC)
:What about articles which don't exist in the current version but do exist in older versions? Will those still need mainspace redirects, or will your extension be able to automatically redirect them to v0.31/40d/23a? --[[User:Quietust|Quietust]] ([[User talk:Quietust|talk]]) 01:29, 14 March 2014 (UTC)
::It ignores all mainspace pages that actually have content, including redirects, so pages like [[masons guild]] won't be affected (unless deleted). —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 01:47, 14 March 2014 (UTC)

Done and deployed. [[Cat]] is still treated as a redirect, even though I just deleted it (try clicking on the "redirected from" link). Pages that exist are ignored, so [[Masons guild]] and [[History of Dwarf Fortress]] still function normally (as a redirect to a 23a page and a non-redirect, respectively). —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 18:57, 14 April 2014 (UTC)

I'm sending around a bot right now to delete all redirects of the format "foo -> cv:foo" (a surprising number don't fit this format, so I'm leaving them alone for now). —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 20:43, 14 April 2014 (UTC)

:I'm confused. Do we use double redirects or not? Is there a single place we define our linking policy (including redirects), and is it updated?
:I had trouble linking to [[Consolidated_development]] in [[v0.34:Dragon]]. It kept pointing to v0.34:Consolidated_development, which does not exist. I ended up linking to Main:Consolidated_development to make it work. --[[User:Nahno|Nahno]] ([[User talk:Nahno|talk]]) 10:18, 1 July 2014 (UTC)

::That's a separate problem altogether - links in the versioned namespaces (v0.34, v0.31, 40d, 23a) automatically link to pages within their namespace. I may be able to set up a fallback to mainspace once I'm able to deploy again, but for now the "main:" alias is the intended solution. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 11:36, 1 July 2014 (UTC)

== Google often directs people to the 0.31 page ==

I've noticed a couple of times that finding a wiki page from an external search will often drop me onto a page from an older version. Is it possible to mitigate this somehow for new players? I could imagine something like redirecting old:Bar -> cv:Bar unless the user has come from old:Foo; no idea if that would actually work though. [[User:PeridexisErrant|PeridexisErrant]] ([[User talk:PeridexisErrant|talk]]) 11:48, 4 May 2014 (UTC)

:As a temporary solution, I could write a script that displays a banner of some kind if the user came from an external site. I'll ask Briess if he can do anything on the server level to increase the weighting of the current version's pages. (Obviously there are situations where people are looking for old pages, like [[23a:dungeon master]], so we don't want to disable indexing entirely on old pages.) —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 17:03, 4 May 2014 (UTC)

== DF2014? ==

As Toady [http://www.bay12games.com/dwarves/ draws closer to a new release], it might be worthwhile to discuss the addition of a new version to the wiki. The upcoming release covers two years of changes and introduces a number of new plants, foods, drinks, multi-tile trees, climbing, jumping, etc., so it is likely to have significant changes from the current DF2012. To avoid having people start new pages (and lose all the effort spent refining the prior version's page), I think it would be best to have a bot automatically copy over the DF2012 pages as a starting point for DF2014. I would suggest that these copied pages include a noticebox template mentioning that the content may be outdated, so that we can easily track which pages have been reviewed. I think either the {{tl|version check}} or {{tl|old}} template would work. --[[User:Loci|Loci]] ([[User talk:Loci|talk]]) 19:43, 5 May 2014 (UTC)

:This is what [[User:QuietBot]] did after the 0.34 release, so it's certainly possible to use the same script to migrate to DF2014. I would like a way of tagging migrated pages, since inaccuracies in some pages went unnoticed for months after they were migrated. Since {{tl|old}} is already in use, {{tl|version check}} may be a better solution (it can be reworded slightly, or we can make a separate template for DF2014 migration). —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 19:23, 1 June 2014 (UTC)
:Made [[Template:DF2014 migrated]] as an example. Any thoughts? —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 19:32, 1 June 2014 (UTC)

== Redirects inconsistency ==

Following a redirect is supposed to be exactly the same as going straight to the page it redirects to, but this actually isn't the case:
* Go to [[Seeds]] and you get [[v0.34:Seed]] (outdated)
* Go to http://dwarffortresswiki.org/index.php?title=Seeds&redirect=no and click on the link and you get to [[DF2014:Seed]] (current)
So if you search for "seed", the top result is the DF2014 version. But search for "seeds" and you get the redirect, which sends you to the outdated page instead. [[User:Hairy Dude|Hairy Dude]] ([[User talk:Hairy Dude|talk]]) 23:22, 22 February 2015 (UTC)

While I'm talking about redirects, it seems redirects to sections don't work: see [[DF2014:How do I manage my seeds and crops]]. I know MediaWiki is capable of this trick because Wikipedia does it. [[User:Hairy Dude|Hairy Dude]] ([[User talk:Hairy Dude|talk]]) 23:32, 22 February 2015 (UTC)

:I have absolutely no idea why [[seeds]] redirects to a v0.34 page - it could be a Mediawiki bug. The section links issue is due to a known issue in the redirect extension we use, which has yet to be fixed. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 00:01, 23 February 2015 (UTC)
:It looks like deleting both [[Seeds]] and [[DF2014:Seeds]] fixed things (by allowing AutoRedirect to handle the redirects instead). Feel free to tag any others with {{tl|bad redirect}}. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 00:03, 23 February 2015 (UTC)
::It gets stranger. [[Vial]] redirects explicitly to [[cv:Flask]] which displays (when you look at it with &redirect=no) as [[DF2014:Flask]], but still goes to the v0.34 version. It seems redirects interpret the cv: pseudo-namespace (or whatever it's called) in an outdated way. [[User:Hairy Dude|Hairy Dude]] ([[User talk:Hairy Dude|talk]]) 18:08, 23 February 2015 (UTC)
::I've added a note to this page about this issue. If it gets resolved, the note should be removed. [[User:Hairy Dude|Hairy Dude]] ([[User talk:Hairy Dude|talk]]) 21:04, 23 February 2015 (UTC)

==Reorganizing versions==

The internet deals with moved content... poorly. Google is still linking to v0.34 pages more than a year after the switch to "DF2014", and even the wiki software still has cached links pointing to the old version pages.

I propose reorganizing versions on the wiki to avoid moving content whenever possible. Instead of having a temporary "current version" namespace that changes occasionally, all the current information gets promoted to the Main namespace. When the next version split occurs, the Main articles as of a certain revision number can be copied to the newly-created permanent "old version" namespace, while all the current information remains in Main. This not only fixes the link rot issue, but it has a few other benefits as well: fewer administrative tasks, no lockdown (a historical version of the Main pages can be copied at any point, even if the Main articles are already modified for the new version), almost all the article history is maintained in the Main article (instead of being spread unevenly across multiple versions), no "temporary" namespaces are needed, fewer problematic long redirect chains, and hopefully less user confusion (since Main gets priority in search results, etc.).

As an example, today we would not have a DF2014 namespace (which is good because "temporary" namespaces historically disappear anyway). If you ran a search for [[seed]] you'd end up at Main:seed, which would have all the current information on seeds. The version box at the top of the page would still link to the older versions of the seed article. When a new version is released, an admin would choose a revision number and copy the Main:seed article as it exists at that revision number to v0.40:seed. That's it. One historical copy that needs little to no new editing, and zero redirections/moves.--[[User:Loci|Loci]] ([[User talk:Loci|talk]]) 19:02, 27 July 2015 (UTC)

:Makes sense to me. It would involve a lot of work, though (e.g. fixing templates and categories to account for the current version being in mainspace), although that should be doable thanks to {{tl|category}}, {{tl|version switch}}, etc.. A bot could be set up to copy revisions from before a release date as well, which would be more difficult (and maybe slower) than a direct copy, but not severely. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 17:24, 30 July 2015 (UTC)

:Actually, there are a few issues with that, namely that there wouldn't be an easy way to distinguish between versioned and non-versioned mainspace pages. There are ways to resolve Google search priority (we can exclude pages from older versions from search engine results if there are newer versions of those pages available, for example). —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 19:47, 6 August 2015 (UTC)

::There aren't very many non-versioned mainspace pages, and determining if a page is versioned is as simple as looking for the version template and/or categories added by the version template (e.g. copy [http://dwarffortresswiki.org/index.php/Category:Current this category] instead of Main:*). The problem with "suggesting" newer pages to Google is that they obviously aren't crawling our wiki regularly (if they were, the fact that the mainspace redirects point to new pages would automatically be picked up). Even if your Google hints worked they wouldn't do anything for all the other broken links out on the 'net.--[[User:Loci|Loci]] ([[User talk:Loci|talk]]) 20:35, 6 August 2015 (UTC)

::: Google actually crawls the wiki constantly - we probably get crawl hits from google for a continuous block of 2-3 hours per day, each and every day. Why they are slow to update is beyond me though. I can't remember why we didn't do this initially, but there was a technical limitation involved if I remember correctly. --[[User:Briess|Briess]] ([[User talk:Briess|talk]]) 22:05, 6 August 2015 (UTC)

::: There are <meta> tags that can be used to hide pages from search results (for search engines that recognize them, that is). Searching for {{tl|av}} or [[:Category:Current]] might work, although we'd have to make sure all of the DF2014 pages include that (some pages don't, particularly some disambiguation pages, although all of them should). —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 22:53, 6 August 2015 (UTC)

:Is there a particular reason main and current are separate to begin with?—[[User:CLA|CLA]] ([[User talk:CLA|talk]]) 00:17, 7 August 2015 (UTC)

::It's mostly intended to distinguish between versioned and non-versioned pages and make version-related templates simpler to work with, since every versioned page has a namespace. I wasn't active here in 2010 when this system was created, so Briess and Emi would know more.
::Another issue I just thought of with Loci's suggestion is categories - currently, categories like [[:Category:Animals]] are used to organize the versioned sub-categories. Sure, we can change {{tl|Category}} to categorize mainspace pages in [[:Category:v0.40:Animals]] or [[:Category:DF2014:Animals]], but that would be less straightforward because there wouldn't be a namespace with that name (until pages are migrated when a newer major version is released). —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 13:05, 7 August 2015 (UTC)

:Moving current pages to the main namespace sounds like a great idea. -[[User:Jecowa|Jecowa]] ([[User talk:Jecowa|talk]]) 20:47, 4 January 2018 (UTC)

Another thought: dealing with migrating redirects could be difficult with this proposal - specifically, determining which redirects should be migrated to a versioned namespace. Redirects can't contain {{tl|av}}, at least not before ``#REDIRECT``. I ''think'' it would be possible to copy pages in two stages, though - all non-redirects first, then all redirects whose targets were also copied. Thoughts? Anything I'm missing? —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 23:41, 27 June 2019 (UTC)

Some subpages (particularly /raw and /Edit notice) also deliberately lack {{tl|av}}, although those shouldn't be too hard to handle. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 00:35, 9 July 2019 (UTC)

:Redirect pages (and all other edge cases I've looked at) can be included in categories (like [[:Category:Current]]) to determine whether or not they should be copied into an archival version. But if the redirects are "properly qualified" then they can all be copied over blindly. Mainspace redirects pointing to versioned information should use a blank namespace (which will be automatically constrained to the archival namespace); mainspace redirects pointing to unversioned information should use an explicit "Main" (which will automatically link back to the unversioned page). Then, when [[[[Toady]]]] gets copied to [[[[v0.4x:Toady]]]] it will point back to [[[[Main:Toady One]]]]. Meanwhile, [[[[Beer]]]], copied to [[[[v0.4x:Beer]]]], will properly point to [[[[v0.4x:Alcohol]]]].--[[User:Loci|Loci]] ([[User talk:Loci|talk]]) 20:00, 14 July 2019 (UTC)

::I think qualifying redirects is the best solution here - categorizing redirects manually is another possible source of errors, since categories (or a lack thereof) would only be visible on the redirect page itself, and [[:Category:Current]] is a hidden category. Copying over mainspace redirects into versioned namespaces would also resolve some issues that have come up due to those not reliably existing currently. I should be able to set up a bot script to add "main:" to current mainspace redirects (and it shouldn't break anything, since those redirects go to other mainspace pages anyway). —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 21:57, 14 July 2019 (UTC)

(Note: I wrote all of this without noticing the previous discussion above.) I was wondering, when the wiki creates a new namespace for a major release again, if it is possible to ''not'' create a namespace for the next current version (e.g. "DF202x") and instead have the mainspace articles (which are currently redirects) become the new cv and move the content there. Therefore, [[cv:Cat]] would just be "[[Cat]]" (or [[Main:Cat]]).

Certain namespace-related templates like [[Template:Ns/0]] would need to be changed, though nothing significant as far as I know. For most cases, any "DF2014" would be replaced with "Main" or even blank. There's also multiple extensions handling the current namespace system and they may need to be modified too, though I'm not sure if or how much. I'm guessing based on the discussions above that it will change stuff up.

My reason is the current namespace is increasingly becoming more anachronistic. "DF2014" could be misinterpreted as "this page is about the 2014 version of the game" or "this page was last updated in 2014", which I've seen a few people in forums mention. Granted that [[Template:Av]] is on the top of very article, I still think the namespace is inconsistent with the recentness of the article. But how is this related to what I'm asking for? Let's say we continue the current system: if we happen to do a new namespace change this year and create DF2020, the next major release (after graphics/UI) will be mythgen, which is estimated to take several years to develop (the Big Wait), and so the anachronism will start over again. The proposed way will prevent this from occurring for the next major release and every release thereafter.

I think the confusion with having a namespace that becomes old-fashioned overtime supersedes the confusion with not marking current versioned articles with a namespace. Most users just search "Cat" on the search bar and naturally expect to get information about the latest release of DF. So if users go a page that's just titled "Cat", they won't expect outdated info about cats from a previous release. That's how the current system works anyways. We'll be skipping the two-step process that we have now. It'll make several wiki tasks much simpler as well. Editors can create new articles for current versions without remembering to add a namespace. It'll fix any existing issues with (double) redirects; instead of [[Main:Kitten]] redirecting to [[cv:Kitten]], which goes to [[DF2014:Kitten]], which then redirects to [[DF2014:Cat]], [[Main:Kitten]] would just redirect to [[Main:Cat]]. And the cv: alias will no longer be necessary since "cv:" = "Main:" and will be forever.

There's no need to differentiate the current version and previous versions with a namespace for the current version is what I'm saying. Articles of previous versions will retain their respective namespaces. Users will still type "40d:Cat" to go to the 40d version of the article, but if they want the current version, they'll just type "Cat" (like now). The mainspace containing the "live" version of an article is natural and would create no uncertainty when browsing the wiki. And it would simplify the wiki somewhat and future-proof this anachronism problem. As a bonus, this change will also prevent web search engines from showing previous version pages when typing "DF cat" or something. (This isn't happening right now as DF2014 has been the current namespace for ~6 years, but it'll happen again when everything moves to a new namespace.)

This is the gist of it, and I may have ignored most of the problems with this proposal. I have personally wished for the whole version namespacing be made less complicated and have been seeking for a solution, and I feel like this is the best way to go about in the future. – [[User:Doorkeeper|Doorkeeper]] 21:27, 14 August 2020 (UTC)

:<s>Whoops, looks like Loci already proposed this exact thing long ago. I definitely missed that discussion and should have checked first. My apologies. I'll move my text to that section and remove this one. – [[User:Doorkeeper|Doorkeeper]] 21:36, 14 August 2020 (UTC)</s> Done. – [[User:Doorkeeper|Doorkeeper]] 21:40, 14 August 2020 (UTC)

:The main issue I have with that is that putting pages about the current version in a namespace also differentiates between those pages and pages not about ''any'' version (for example, [[Toady One]] does not need a 40d or v0.34 page). Yes, we can use {{tl|av}} to mark versioned pages, but people often forget to add that to new pages. The current system also allows determining whether a page is versioned or not from its title, which makes migrations a lot faster. Relying on {{tl|av}} would require either reading the content of every page (which would slow scripts down significantly) or cross-checking with the list of all pages including the template (feasible, but a bit more complicated, and still susceptible to missing templates). I suppose that manually fixing and migrating pages missing {{tl|av}} later wouldn't be too much work, though.
:I am definitely in favor of changing "DF2014" (or a new namespace) to "Current", though. I was in favor of "DF2014" in 2014, but I don't think it makes sense anymore, and "Current" seemed to be a popular alternative in both the DF2012 and DF2014 discussions on the matter. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 04:02, 16 August 2020 (UTC)

== Weird redirect behaviour ==

[[Pump stack]] redirects to [[cv:Screw pump#Pump stack]]. If you look at the redirect itself it says it redirects to DF2014 namespace, which is correct. But if you actually follow the redirect, it goes to v0.34 namespace. [[User:Hairy Dude|Hairy Dude]] ([[User talk:Hairy Dude|talk]]) 16:10, 20 August 2018 (UTC)
:Yeah, that's part of the issue described in the above section (the wiki caching part, not on Google's end.) —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 15:00, 21 August 2018 (UTC)

== v50 organization ==

Some wiki admins have had a talk on Discord and decided that the most sustainable path forward is to put content for all future versions of DF in the main namespace. We will be working on a bot to do this in the next few days. Feel free to chime in with suggestions here. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 22:56, 14 December 2022 (UTC)

:Is it maybe possible to do backwards-namespacing? Like we have a "Main" namespace, which people are free to update, and whenever there's a new version of DF the "Main" namespace is copied into a namespace for the then old version, much like how you'd branch a stable branch from a development branch when working with a git-project? [[User:Therahedwig|Therahedwig]] ([[User talk:Therahedwig|talk]]) 23:13, 14 December 2022 (UTC)

::Yeah, we could do that if we decide to. We were talking about doing that for v50, actually, and might still do something similar to preserve edit history if it doesn't end up being too hard to automate. Our hope is that we will not introduce new namespaces for v50 -> v5x, unless there is a serious breaking change (and hopefully there isn't one). But if we change our mind, one advantage of the type of migration you mentioned is that it can be done retroactively - we can copy historical revisions that were current at the time of the release, and would only lose some typo fixes made after the release that apply to earlier versions as well. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 02:11, 15 December 2022 (UTC)

ETA is < 24 hours. Doing some final checks on a migration script. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 07:08, 19 December 2022 (UTC)

: We should really have a task list as there are many things that change and need updating. Including but not limited to:
:* Most templates that used the previous namespace convention broke, including nav templates.
:* Many game files changed locations and their pages need to be updated.
:* Raws need to be updated.
:* Various features added, changed, removed.
:* UI has been changed -- though I am more inclined to wait for classic release to avoid extra work --[[User:Jan|Jan]] ([[User talk:Jan|talk]]) 06:56, 20 December 2022 (UTC)

"''Raws need to be updated.''" Including applying text wraparound where necessary, I suppose - more than a few of them have proven to be that special kind of...''difficult'' to navigate otherwise, shall we say? [[User:Silverwing235|Silverwing235]] ([[User talk:Silverwing235|talk]]) 12:52, 20 December 2022 (UTC)

:There is already a task list in the [[#v50 migration|section below]] that includes templates and raws, with an explanation. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 16:25, 20 December 2022 (UTC)

== v50 migration ==

The initial migration script is done. New content is in the '''main''' namespace, e.g. [[Cat]]. Old content is still at [[DF2014:Cat]]. History was migrated to the ''new'' (main namespace) articles.

I know several things are broken still. Please reply if you find any others:
<div style="border-left: 2px solid red">
* <s>Versioned templates haven't been migrated yet (e.g. {{tl|vermin}} on [[Ant]])</s>
** Fixed. Most were migrated by a bot.
* <s>Raws are missing on all pages that use them.</s>
** This also affects sidebars, such as on [[Cat]] and [[Microcline]].
** Update: The DFRawFunctions extension has been upgraded to include v50 raws, using the "v50:" prefix for filenames instead of "DF2014:". <s>I haven't finished a migration script to create the /raw pages themselves, but they can typically be created manually by copying the DF2014 /raw pages and changing "DF2014" to "v50" everywhere.</s> —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 20:20, 1 January 2023 (UTC)
** Update 2: Raws have been added for all pages! They were copied from the "DF2014" pages and had "DF2014" replaced with "v50", which appears to have worked from a spot-check, but let me know if you find any problems. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 05:57, 4 January 2023 (UTC)
* Some pages where the DF2014 page was a redirect to a main namespace page that contained content were migrated incorrectly.
** In this case, the main namespace page is usually a redirect to itself. This can be fixed by undoing LethosorBot's edit to the main namespace page, then copying the content to the DF2014 page.
** Update: most seem to have been fixed manually - thanks! —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 19:41, 21 December 2022 (UTC)
* <s>Some main-namespace talk pages redirect to DF2014 talk pages. Some of these redirects work, and some (usually older ones) do not.</s>
** Fixed with a bot. Some redirects from talk pages to other deleted talk pages are now broken, e.g. [[Talk:Above_ground]] (exists) -> [[Talk:Tile attributes]] (redlink). I am leaving them like that because they redirect to where the talk page should be created, but I'm also fine with people deleting them if they really want to. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 19:41, 21 December 2022 (UTC)
* {{tl|quality}} for new articles is disabled (see below)
* Some links from DF2014 to Main weren't working: e.g. the version selector [[DF2014:Mason's workshop]] was linking to [[DF2014:Main:Mason's workshop]] instead of [[Main:Mason's workshop]]. I'm not sure exactly why, but I fixed it with a change to the NamespaceLinks extension. Let me know if you spot similar broken links. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 23:19, 21 December 2022 (UTC)
</div>

—[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 04:54, 20 December 2022 (UTC)
:The quality levels of the 50.03 pages seem to be missing. I'm not sure if that's covered under that first point. [[User:Trainzack|Trainzack]] ([[User talk:Trainzack|talk]]) 06:47, 20 December 2022 (UTC)
::If the the [[Dwarf Fortress Wiki:Quality]] feature can be made to work with namespace scheme change, I suggest to automatically assign the lowest quality rating to all pages, alternately add the {{tl|old}} to all pages. Otherwise there will be a lot of pages that will fall through the cracks. --[[User:Jan|Jan]] ([[User talk:Jan|talk]]) 09:12, 20 December 2022 (UTC)
:::I disabled {{tl|quality}} in the main namespace because it would require some rework to make the rating script and the template work properly there. Feel free to take a stab at the template. I will see what can be done on the extension side. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 21:14, 20 December 2022 (UTC)
::::What needs to be done on the template side? I'm not sure I see too big of an issue leaving pages as "unknown-quality" for now (or just change the default to tattered) until we get the rating script working. Is that script up anywhere, anything that could be helped with? [[User:Vallode|Vallode]] ([[User talk:Vallode|talk]]) 11:10, 2 January 2023 (UTC)
:::::They're already marked as unknown. Really the only issue I know of with the template is that it doesn't show up with some of the newer skins we added, and that can be fixed by getting rid of the absolute positioning. As for the script, it can be found at https://github.com/DF-Wiki/QualityRatings, and the issue is really only with the configuration system not recognizing the main namespace as valid. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 02:29, 3 January 2023 (UTC)
::::::Great, I started having a crack at fixing the template with different themes. Is the preference to get some CSS going and then include it in the global stylesheet (i.e different styles per theme) or to try and get a "one size fits all" fix? —[[User:Vallode|Vallode]] ([[User talk:Vallode|talk]]) 08:14, 3 January 2023 (UTC)
:::::::I would rather avoid custom site-wide CSS if we can. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 03:29, 4 January 2023 (UTC)
::::::::I appreciate that, I think it's the simplest solution to add a few lines to common.css though. Unless there is a way to attach CSS specifically to a template, I saw a few extensions that allowed that but I'm not sure if any are present in the wiki at the moment. Regardless there already exists a class `div.topicon` that is specifically for the quality ratings, is there an issue with expanding this class to accommodate the themes? The list of themes where the quality rating display is broken/invisible: Citizen, MinervaNeue, MonoBook. —[[User:Vallode|Vallode]] ([[User talk:Vallode|talk]]) 21:48, 4 January 2023 (UTC)
:::::::::What do you think of moving the template out of the topicon entirely and just placing it in a div? It would take up a (hopefully) small amount of vertical space in the article. [[User:Lethosor/Sandbox/Quality_test]] is an example. Unfortunately it isn't possible to prevent other templates from displaying above the quality this way ([https://dwarffortresswiki.org/index.php?title=User:Lethosor/Sandbox/Quality_test&oldid=283883]). So maybe we do need some custom CSS after all if we want that. I'm open to trying out whatever you propose. I'm a bit worried about future-proofing against skins we add later (particularly a mobile skin) but at least MediaWiki supports skin-specific global CSS as well. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 00:33, 5 January 2023 (UTC)
::::::::::I would rather we avoid taking any more vertical space in the article. The growing block pyramid at the top, starting with version template, is annoying. If you end up placing it inside the article space please use a slim box 100% wide that would include both.--[[User:Jan|Jan]] ([[User talk:Jan|talk]]) 01:19, 5 January 2023 (UTC)
:::::::::::Agreed with you Jan, however I see that as two different tasks (ArticleVersion template changes, getting quality back on pages). I made a test adjustment to the quality and it takes up a negligable amount of extra space. See [[User:Vallode/sandbox#Page_quality]] for the example, we'd be able to completely remove "topicon" (unless it is used somewhere else?) and then potentially move on to making the ArticleVersion template into a slim version on the left-hand-side instead of a large box? Let me know what you think. --[[User:Vallode|Vallode]] ([[User talk:Vallode|talk]]) 17:35, 5 January 2023 (UTC)
:::::::::::: Sorry, I just noticed this, I hope you weren't waiting on me. I haven't looked into how it works. All I can say that it would be nice if it shows on main, it is annoying that it shows on discussion and history. And otherwise I think that those negligible spaces adds up when you have multiple notice, redirection etc templates and would prefer if you can [https://ibb.co/X7X7SjL condense all of it] somehow. I also had [https://dwarffortresswiki.org/index.php/User:Jan/sandbox#Misc_variants couple of ideas] on that front, but as dev designer you probably can come up with something more refined if this is direction you choose. --[[User:Jan|Jan]] ([[User talk:Jan|talk]]) 00:50, 10 January 2023 (UTC)

It appears some pages are redirecting recursively and never resolving correctly, like the [[https://dwarffortresswiki.org/index.php?title=Character_table&redirect=no|character table]] and [[tileset repository]] 07:35, 20 December 2022 (UTC)
: Indeed, these can be caught here: [[Special:DoubleRedirects]] --[[User:Jan|Jan]] ([[User talk:Jan|talk]]) 07:51, 20 December 2022 (UTC)

It might be useful to change the notice title to "release information '''for editors'''" --[[Special:Contributions/142.59.195.176|142.59.195.176]] 10:26, 20 December 2022 (UTC)
:Can do. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 16:27, 20 December 2022 (UTC)
::New here, hello. Should we set a date where we remove/only show the banner for logged in users. There are (some) pages that have 4 different notices about the upgrade. [[Engraving]] is one such page, the top banner states "information for editors", we then have the "this page was migrated" banner, a version selection which warns the article might be inaccurate, and a smaller banner saying the page might need to be updated. Quite a lot of screen space, I think we can start to slowly reduce the amount of warnings this coming month? [[User:Vallode|Vallode]] ([[User talk:Vallode|talk]]) 10:07, 2 January 2023 (UTC)
:::Unfortunately, only showing info to logged-in users is difficult with how MediaWiki caching works. In terms of reducing warnings, there is a discussion [[Template_talk:ArticleVersion#.22Note_that_some_content_may_still_need_to_be_updated..22|here]]. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 21:43, 4 January 2023 (UTC)
:::As for [[Engraving]] specifically, the {{tl|old}} banner was actually present on [[DF2014:Engraving]] as well and got carried over with the migration. I removed it, and agree that it was redundant. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 21:46, 4 January 2023 (UTC)

Main talkpages seem to redirect to DF2014 talk. Not sure if it is intentional but I like it, though we should pay attention when creating new discussion relating to v50 ending up there.--[[User:Jan|Jan]] ([[User talk:Jan|talk]]) 14:18, 20 December 2022 (UTC)
:That's unintentional. I specifically wrote the migration script to not move talk pages, but that has the side-effect of leaving any previously-created "Talk -> DF2014 talk" redirects intact. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 16:27, 20 December 2022 (UTC)

Yo Lethosor, are we adding graphic sprites for the pages in some way? Or are we waiting for you to add some sort of new template or something? I'm sure you don't need me to tell you that the current templates don't allow that. Not sure if I'm allowed to change/create any templates either, as I don't want to break things for hundreds of pages. Edit: And IF the icons are allowed, should they be left alone, or 2×-3× sized like how the Minecraft wiki does it? --[[User:Zippy|Zippy]] ([[User talk:Zippy|talk]]) 14:29, 20 December 2022 (UTC)
:Depends on which templates you mean. There are copyright concerns with uploading a premium sprite sheet, for instance. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 16:27, 20 December 2022 (UTC)
::I'm not talking about uploading an entire sprite sheet. I'm just talking about individual icons for each respective page. One image for cows, one for horses, one for werebeasts, etc. --[[User:Zippy|Zippy]] ([[User talk:Zippy|talk]]) 16:50, 20 December 2022 (UTC)
:::If we do that for every creature in the sprite sheet, that's not much different (in terms of copyright) from uploading the entire sprite sheet. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 17:09, 20 December 2022 (UTC)
::::Is there someone we can talk to about that? We finally get this new game with graphics, and then we can't use the very graphics of the game? No matter what the rules are, I'd say that would be the stupidest thing ever. I know I'm infamous here when it comes to copyright and images and stuff, but about 80% of game wikis out there are completely unofficial, and use game file images like no one's business. I can't imagine anyone's door being knocked on if we used the game's sprites, but I won't add any here until we have a go-ahead. --[[User:Zippy|Zippy]] ([[User talk:Zippy|talk]]) 17:14, 20 December 2022 (UTC)

:::::...I've made noise in Mayday's direction on this matter, at least (prob an incorrect maneuver, ''but'').[[User:Silverwing235|Silverwing235]] ([[User talk:Silverwing235|talk]]) 17:55, 20 December 2022 (UTC)
:::::: I hope some sort of arrangement can be made so we can use the new sprites with permission/limits, just as we are using the raw files. Otherwise we are all (devs and editors alike) shooting ourselves in the foot here.--[[User:Jan|Jan]] ([[User talk:Jan|talk]]) 21:07, 20 December 2022 (UTC)

:::::::I just thought of something. We're supposedly not allowed to upload entire sprite sheets, right? What if - for the time being - we just use a few of them for the purpose of testing out new infoboxes? --[[User:Zippy|Zippy]] ([[User talk:Zippy|talk]]) 21:46, 20 December 2022 (UTC)
::::::::I don't know. If someone could ask Kitfox and post the response here, that would be great. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 21:47, 20 December 2022 (UTC)

:::::::::I've reached out to Alexandra, but she hasn't answered yet. Until then I found these old approvals from the previous community manager, Feeona: ([http://www.bay12forums.com/smf/index.php?topic=173474.msg8243633#msg8243633 link1], [http://www.bay12forums.com/smf/index.php?topic=176640.msg8243642#msg8243642 link2]). Waiting for a newer response until we begin mass uploads is probably the politer option, but like Zippy said, it is also standard for wikis to use game sprites with less approval. I second their idea of trying it out with a few images to test the infoboxes. On the extreme off-chance (and I do think it is) Kitfox protests we can always remove these few. --[[User:Voliol|Voliol]] ([[User talk:Voliol|talk]]) 22:19, 20 December 2022 (UTC)
:::::::::And here is a third, more official statement: ([http://www.bay12forums.com/smf/index.php?topic=173474.msg8249718#msg8249718 link3]). Perhaps that address of info@kitfoxgames.com is the better channel to ask for a confirmation, rather than Discord DMs, but I will be going to bed, so it is best if someone else does that. --[[User:Voliol|Voliol]] ([[User talk:Voliol|talk]]) 22:29, 20 December 2022 (UTC)
::::::::::Thanks for tracking this down! Ok, sprites should be fine, but let's avoid uploading the entire premium tileset as a single image, for instance (as the forum thread says, "use common sense"). —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 00:21, 21 December 2022 (UTC)
::::::::::: Looks good, permission is always preferable over fairuse, I think it is a win win for all involved. I agree that we shouldn't upload entire sprite sheets (e.g. there is no reason to upload the windmill from every direction or whole construction phase for workshops) and that there are a lot of details that needs to be ironed out through testing. --[[User:Jan|Jan]] ([[User talk:Jan|talk]]) 05:07, 21 December 2022 (UTC)
:::::::::We have a green light on uploading all and any sprites. Their response to me can be seen [https://i.imgur.com/BhmHjzC.png here]. I'm sure someone else confirmed it before me. --[[User:Zippy|Zippy]] ([[User talk:Zippy|talk]]) 19:00, 21 December 2022 (UTC)

Shifting temporarily to a new issue, is the documentation of [[Template:ArticleVersion]] outdated? It would seem so to me, since the current version no longer has its own namespace, with the templates needing updating being different ones. --[[User:Voliol|Voliol]] ([[User talk:Voliol|talk]]) 18:30, 20 December 2022 (UTC)
:I think it is still accurate enough. We left open the possibility of making another namespace in the future, albeit with a different migration strategy - see [[#v50 organization|above]]. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 21:52, 20 December 2022 (UTC)

Some Changes to infoboxes might be needed. Too bad [[User:Doorkeeper]] isn't around. He did a great work with navbox project--[[User:Jan|Jan]] ([[User talk:Jan|talk]]) 20:52, 21 December 2022 (UTC)

I just realized that raw files aren't stored as regular wiki pages but loaded via the DFRawFunctions extension (hence the need to update). Good news it's going to be handled in bulk, consistently and relatively easy to updated. Even better it's Lethosor problem ;) Also I just realized that all the "raw files" (txt files in the new vanilla folder) are released into the public domain. Both are probably not news to the vets but I'll leave it here for those who less up to date like myself. --[[User:Jan|Jan]] ([[User talk:Jan|talk]]) 07:35, 22 December 2022 (UTC)

: I noticed that some templates aren't working properly in the new namespace, e.g. [[Basalt]] entry had its raw updated manually but the infobox fail to show any details. Cursory look suggest {{t|layerlookup/0}} need a minor tweak. This should do the work
:: Replace: <nowiki>{{layerlookup/aux|{{{{FULLPAGENAME}}/raw}}|uses={{{uses|}}}|wiki={{{wiki|}}}}}</nowiki>
:: With___: <nowiki>{{layerlookup/aux|{{</nowiki>:<nowiki>{{FULLPAGENAME}}/raw}}|uses={{{uses|}}}|wiki={{{wiki|}}}}}</nowiki>
: Not sure what the plan and ETA with raws update so I didn't touch this high usage template for now. --[[User:Jan|Jan]] ([[User talk:Jan|talk]]) 08:11, 24 December 2022 (UTC)

::Please do feel free to make this update. I am still working on a script to create the <code>/raw</code> pages themselves. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 03:12, 1 January 2023 (UTC)

Wouldn't it be an idea to add to the Sitenotice to remove the {{tl|migrated article}} tag when an article has been fully updated? I see many articles that seem to be updated still have the tag. And/or advise to make use of the {{tl|verify}} for sections still in need of checking? --[[User:Halavus|Halavus]] ([[User talk:Halavus|talk]]) 10:12, 2 January 2023 (UTC)
:Probably a good shout. The "see this page" link does include the detail on removing but we should more explicitly encourage removing the banner once a page has at least been looked over. [[User:Vallode|Vallode]] ([[User talk:Vallode|talk]]) 11:01, 2 January 2023 (UTC)

== v50 specific issues ==
=== Graphics===
Follow up on the use of game sprites and the need to trying it out with a few images to test the infoboxes. First sprite [[:File:Beds v50.png]] was uploaded and used on [[Bed]] entry. Any thoughts? --[[User:Jan|Jan]] ([[User talk:Jan|talk]]) 18:06, 21 December 2022 (UTC)
:Seems like it should be rearranged to be horizontal. Also, has there been a serious discussion about copyright? Full screenshots are 100% fine, but you start going into a grey area when you upload pieces of a spritesheet. I'm of the opinion that it's all fine as long as it's inconvenient to reconstruct the full sheet from the individual images. Maybe a further restriction could be you shouldn't upload any of the art unless it's used in an infobox (maybe an exception for pieces of the UI). And one more restriction could be you shouldn't show everything, like in your bed example, maybe just the wooden bed is good enough, leave out the stone and metal, especially since those can only be made from strange moods. [[User:Brightgalrs|Brightgalrs]] ([[User talk:Brightgalrs|talk]]) 18:43, 21 December 2022 (UTC)
::Actually, your bed image is kinda bad for showing off what a bed looks like because it doesn't show the pillow/blankets. That might point to cropped screenshots being the best path, although less convenient for the uploader, as you don't get details left out. [[User:Brightgalrs|Brightgalrs]] ([[User talk:Brightgalrs|talk]]) 18:46, 21 December 2022 (UTC)
::I created a new license template [[Template:Copyright game]], based it on the way the RimWorld wiki does things. Call it a prototype, but it's probably how your bed image should be labelled. Indeed, I added it to it already. [[User:Brightgalrs|Brightgalrs]] ([[User talk:Brightgalrs|talk]])

::: I agree that the horizontal arrangement would suit better here and that we should strive to represent how things look in-game. Otherwise, I am not too concerned about people being able to reconstruct anything (lets just say that ''anyone'' interested in that can get the real thing from the game files), also it seem we have permission to use the sprits on top of fairuse. --[[User:Jan|Jan]] ([[User talk:Jan|talk]]) 19:55, 21 December 2022 (UTC)

::: Modifying the existing template to allow the inclusion of the new sprites is easy (Something like [https://ibb.co/zFXCrjd this]?) The big question is the matter of consistency is there any exceptions that will break the format (size wise with variant bloat for example), the sprite naming format, etc --[[User:Jan|Jan]] ([[User talk:Jan|talk]]) 20:44, 21 December 2022 (UTC)
::: If we are going to show a variant for each material type, then maybe these should be added as separate images so we can add a tooltip for each image. --[[User:Jan|Jan]] ([[User talk:Jan|talk]]) 20:49, 21 December 2022 (UTC)

:I've got another prototype going here and here: [[User:Brightgalrs/vector.css]] and [[User:Brightgalrs/Sandbox]]. (You'll need to add the css stuff to your own /vector.css). Basically it's a way to recolor images using css classes. No idea if there's a better way. Also, the real implementation would require a change to [[MediaWiki:Common.css]]. [[User:Brightgalrs|Brightgalrs]] ([[User talk:Brightgalrs|talk]]) 22:41, 21 December 2022 (UTC)
:Should mention, there ''is'' a different way, just upload each image 16 times, one for each coloring. But maybe that's not very elegant. [[User:Brightgalrs|Brightgalrs]] ([[User talk:Brightgalrs|talk]]) 22:45, 21 December 2022 (UTC)

: It should be noted that soon the classic edition will be released, hence one should plan to have both the Premium and classic alongside in that little space --[[User:Jan|Jan]] ([[User talk:Jan|talk]]) 03:14, 22 December 2022 (UTC)
::I'm looking into a tab extension to potentially support this in infoboxes. Perhaps [https://www.mediawiki.org/wiki/Extension:Tabs Extension:Tabs]? I tried [https://www.mediawiki.org/wiki/Extension:TabberNeue Extension:TabberNeue], but it displays a placeholder if JavaScript is disabled, which isn't great. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 04:22, 22 December 2022 (UTC)
::: The Neue Tabber seem to works pretty much like the old one (which fandom [https://coding-help.fandom.com/wiki/Tabber#Adding_images_into_tabbers still use]) defaulting to showing the first tab only. Quick look suggest that neue work the same, plus the notice that 'Tabber requires Javascript to function' warning? if so, and if it is a bother, then you should be able to edit out the tabberneue-noscript string in code. --[[User:Jan|Jan]] ([[User talk:Jan|talk]]) 06:29, 22 December 2022 (UTC)
::: I much prefer your tabber solution, but if that fails we can also use the gallery slideshow mode. If so, beware it has no way to control image size so the images have to be maliciously uploaded using the exact same size. example:
<gallery mode="slideshow">
File:SteelSample.png
File:TinSample.png
File:ZincSample.png
File:GoldSample.png
</gallery> --[[User:Jan|Jan]] ([[User talk:Jan|talk]]) 10:19, 22 December 2022 (UTC)

==== adding premium set to Infobox ====
I am unclear where are we going with this? 
1) Will (A) tabs be implemented, (B) we be using mediawiki toggle [[Template_talk:V50_workshop|example]] for premium and classic/blocked, (c) put images side by side, or (d) something else? 
2) Also [[silver]] and [[Pig iron]] use very different image style for example. 
3) Anything else you want ? --[[User:Jan|Jan]] ([[User talk:Jan|talk]]) 12:32, 30 December 2022 (UTC)

: Personally, I would love tabs to be implemented, but I think that side by side might be best for most. --[[User:Jan|Jan]] ([[User talk:Jan|talk]]) 12:32, 30 December 2022 (UTC)
: Here is rough layout we can use. It should fit most buildings given the default sprite size. There is also a different floor plan for both (inspired by reddit)

{|
|- valign=top
|
{| style="width:200px; background-color:#eaecf0; border-collapse: collapse; "
|+ 5×5
|- style="border-bottom:2px solid #3366cc; "
|<div class="mw-customtoggle-infoboxtab mw-ui-button mw-ui-progressive" style="border-top-right-radius: 10px; border-top-left-radius:10px;">toggle</div>
|{{Tooltip|Hotkey|adasdasdasd}}: {{Key|b|o|g}}
|- valign=top
|colspan=2|<div class="mw-collapsible" id="mw-customcollapsible-infoboxtab">
[[File:Siege workshop.png|center|160px]]</div>
<div class="mw-collapsible mw-collapsed" id="mw-customcollapsible-infoboxtab"">
{|
|rowspan=2 style="width:50%; font-size: 125%;"|<center>{{Template:Picture Siege workshop}}</center>
|style="line-height: 1em; font-size: 125%;"|
{| style="border-spacing:4px;"
| style="width:12px; height:12px; background-color:#b7b9bd; border:1px solid #545557;"|
| style="width:12px; height:12px; background-color:#b7b9bd; border:1px solid #545557;"|
| style="width:12px; height:12px; background-color:#b7b9bd; border:1px solid #545557;"|
| style="width:12px; height:12px; background-color:#b7b9bd; border:1px solid #545557;"|
| style="width:12px; height:12px; background-color:#b7b9bd; border:1px solid #545557;"|
|-
| style="width:12px; height:12px; background-color:#b7b9bd; border:1px solid #545557;"|
| style="width:12px; height:12px; background-color:#86878a; border:1px solid #545557;"|
| style="width:12px; height:12px; background-color:#86878a; border:1px solid #545557;"|
| style="width:12px; height:12px; background-color:#86878a; border:1px solid #545557;"|
| style="width:12px; height:12px; background-color:#b7b9bd; border:1px solid #545557;"|
|-
| style="width:12px; height:12px; background-color:#b7b9bd; border:1px solid #545557;"|
| style="width:12px; height:12px; background-color:#b7b9bd; border:1px solid #545557;"|
| style="width:12px; height:12px; background-color:#b7b9bd; border:1px solid #545557;"|
| style="width:12px; height:12px; background-color:#b7b9bd; border:1px solid #545557;"|
| style="width:12px; height:12px; background-color:#b7b9bd; border:1px solid #545557;"|
|-
| style="width:12px; height:12px; background-color:#b7b9bd; border:1px solid #545557;"|
| style="width:12px; height:12px; background-color:#86878a; border:1px solid #545557;"|
| style="width:12px; height:12px; background-color:#86878a; border:1px solid #545557;"|
| style="width:12px; height:12px; background-color:#86878a; border:1px solid #545557;"|
| style="width:12px; height:12px; background-color:#b7b9bd; border:1px solid #545557;"|
|-
| style="width:12px; height:12px; background-color:#b7b9bd; border:1px solid #545557;"|
| style="width:12px; height:12px; background-color:#b7b9bd; border:1px solid #545557;"|
| style="width:12px; height:12px; background-color:#b7b9bd; border:1px solid #545557;"|
| style="width:12px; height:12px; background-color:#b7b9bd; border:1px solid #545557;"|
| style="width:12px; height:12px; background-color:#b7b9bd; border:1px solid #545557;"|
|}
|-
| style="text-align: center;" | Layout
|}
</div>
|}
|
{| style="width:200px; background-color:#eaecf0; border-collapse: collapse; "
|+ 3×3
|- style="border-bottom:2px solid #3366cc; "
|colspan=2 style="text-align: right;"|<div class="mw-customtoggle-infoboxtab mw-ui-button mw-ui-progressive" style="float:left; border-top-right-radius: 10px; border-top-left-radius:10px;">toggle</div>{{Tooltip|Hotkey|adasdasdasd}}: {{Key|b|o|g}}
|- valign=top
|rowspan=2 style="width:50%;"|
<div class="mw-collapsible" id="mw-customcollapsible-infoboxtab">[[File:Carpenter's workshop.png]]</div>
<div class="mw-collapsible mw-collapsed" id="mw-customcollapsible-infoboxtab""><center>
{| style="font-size: 175%; border-spacing: 0; background-color: black; border: 2px solid black"
|- 
| style="padding: 0; line-height: 1em"|
| style="padding: 0; line-height: 1em"| {{Raw Tile|"|7:0:0}}
| style="padding: 0; line-height: 1em"| {{Raw Tile|{{=}}|6:0:0}}
|-
| style="padding: 0; line-height: 1em"| {{Raw Tile|░|0:7:1}}
| style="padding: 0; line-height: 1em"|
| style="padding: 0; line-height: 1em"|
|-
| style="padding: 0; line-height: 1em"| {{Raw Tile|░|0:7:1}}
| style="padding: 0; line-height: 1em"| {{Raw Tile|]|0:0:1}}
| style="padding: 0; line-height: 1em"| {{Raw Tile|░|0:7:1}}
|}</center></div>
|
{| style="border-spacing:5px;"
| style="width:18px; height:18px; background-color:#b7b9bd; border:1px solid #545557;"|
| style="width:18px; height:18px; background-color:#b7b9bd; border:1px solid #545557;"|
| style="width:18px; height:18px; background-color:#b7b9bd; border:1px solid #545557;"|
|-
| style="width:18px; height:18px; background-color:#86878a; border:1px solid #545557;"|
| style="width:18px; height:18px; background-color:#b7b9bd; border:1px solid #545557;"|
| style="width:18px; height:18px; background-color:#b7b9bd; border:1px solid #545557;"|
|-
| style="width:18px; height:18px; background-color:#86878a; border:1px solid #545557;"|
| style="width:18px; height:18px; background-color:#b7b9bd; border:1px solid #545557;"|
| style="width:18px; height:18px; background-color:#86878a; border:1px solid #545557;"|
|}
|-
| style="text-align: center;" | Layout
|}
</div>
|
{| style="width:200px; height:100px; padding:10px; background-color:#eaecf0; border-collapse: collapse;"
|+ 1×1
|- style="border-bottom:2px solid #3366cc;"
| colspan=3 style="text-align:center;"|{{Tooltip|Hotkey|adasdasdasd}}: {{Key|b|o|g}}
|-
| style="border-right: 1px dotted #545557;"|[[File:Screw_press.png|32px|center|link=]]
| style="font-size:125%;"|<center>{{Template:Picture Screw press}}</center>
| style="border-left: 1px dotted #545557;"|<center>{{Template:Floor Plan Screw press}}</center>
|}
|
{| style="width:200px; height:100px; padding:10px; background-color:#eaecf0; border-collapse: collapse;"
|+ 1×3
|- style="border-bottom:2px solid #3366cc;"
| colspan=3 style="text-align:center;"|{{Tooltip|Hotkey|adasdasdasd}}: {{Key|b|o|g}}
|-
| style="border-right: 1px dotted #545557;"|[[File:water_wheel.png|32px|center|link=]]
| style="font-size:125%;"|<center>{{Template:Picture Water wheel}}</center>
| style="border-left: 1px dotted #545557;line-height:normal;"|<center>{{Template:Floor Plan Water wheel}}</center>
|}
|}
:Any thoughts on the direction and or any and all of its elements? --[[User:Jan|Jan]] ([[User talk:Jan|talk]]) 10:16, 31 December 2022 (UTC)

::I kind of like side-by-side, if it fits. If anyone wants to implement a toggle button or tabs, I would ask that that be implemented in a template for now, so that e.g. we could change a toggle button to tabs in a single place if we decide to install an extension to support that. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 03:14, 1 January 2023 (UTC)

::: I noticed a comment saying that [[impassable tile]] are no longer used in v50, is that true for all constructions? If so, floor plans are no longer needed, making things much easier as we can fit everything in except the 5v5 constructions like trade depot (and even these can be placed one above the other if so desired). If not, any thought on the alternative floor plan design? --[[User:Jan|Jan]] ([[User talk:Jan|talk]]) 07:46, 1 January 2023 (UTC)

:::: None of the constructions have blocking tiles any more from my experience playing. I haven't tested siege weaponry with that stuff, but none of the workshops have it, nor does any furniture. (walls and fortifications will of course obstruct movement [[User:AndrielChaoti|AndrielChaoti]] ([[User talk:AndrielChaoti|talk]]) 18:47, 1 January 2023 (UTC)
::::: Ok, I have removed them from v50. --[[User:Jan|Jan]] ([[User talk:Jan|talk]]) 23:48, 1 January 2023 (UTC)

I have added a basic side by side variant to [[Template:V50 workshop]] and [[Template:Building]] for testing, let us know if there any issues. Few notes:
* The default image naming scheme of <code>workshop-name.png</code> will likely conflict with existing images here or on commons, maybe another naming scheme should be used like <code>v50 workshop-name.png</code> as it is with ascii pictures.
* There is inconsistency in image size. If you want to use large zoomed images then toggle is best, otherwise they need to be all in native size (96px for 3x3).
* In the current version the code roughly centers the images and if there is a big image like with [[Siege workshop]] it drops to a new line --[[User:Jan|Jan]] ([[User talk:Jan|talk]]) 23:48, 1 January 2023 (UTC)

How about combining shortcut keys and the new menu icons:
<div style="color:white; font-size: large; text-shadow: -1px -1px 0 #000, 1px -1px 0 #000, -1px 1px 0 #000, 1px 1px 0 #000;">[[File:Ui b.png]]<div style="position: absolute; bottom:-14px; right:3px;">b</div>[[File:Ui bo.png]]<div style="position: absolute; bottom:-14px; right:3px;">o</div>[[File:Ui bol.png]]<div style="position: absolute; bottom:-14px; right:3px;">l</div>[[File:Ui boll.png]]<div style="position: absolute; bottom:-14px; right:3px;">l</div></div>
--[[User:Jan|Jan]] ([[User talk:Jan|talk]]) 02:24, 3 January 2023 (UTC)

:I worry that this is difficult to read (I read it as "boil" at first). I would rather use something like {{tl|k}} with a known background. What about something like this? [[File:Ui boll.png]]<div style="position: absolute; bottom:-14px; right:0px;">{{k|l}}</div> or, alternatively, using flexbox without any overlap: [[File:Ui boll.png]]{{k|l}} —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 02:37, 3 January 2023 (UTC)
:: Same, but that is the best I came up with. We can use the key or maybe someone can help improve the design. Also 'l' is hard to read even with {{t|key}}.--[[User:Jan|Jan]] ([[User talk:Jan|talk]]) 03:05, 3 January 2023 (UTC)
:: I added a {{t|Menu icon}} to start things so others can have a go with it. Also any thoughts on the icon naming convention (their shortcut sequence), is there easier/better way? --[[User:Jan|Jan]] ([[User talk:Jan|talk]]) 09:36, 3 January 2023 (UTC)
::[[User:BarelyCreative]] updated the template: {{Menu icon|b|o|l|y}}. I think it looks good, thoughts? --[[User:Jan|Jan]] ([[User talk:Jan|talk]]) 18:40, 3 January 2023 (UTC)
:::I like that, yeah. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 03:29, 4 January 2023 (UTC)
::::There were some places where it didn't make sense so display every icon all the time (like step-by-step guides), so I changed it slightly to allow display of fewer icons using "num" and counting from the end: <nowiki>{{Menu icon|b|o|l|y|sep=-;|num=2}}</nowiki> {{Menu icon|b|o|l|y|sep=-|num=2}} [[User:BarelyCreative|BarelyCreative]] ([[User talk:BarelyCreative|talk]]) 09:05, 4 January 2023 (UTC)

==== Bizarre palette-swapping idea/prototype ====
No idea if this is a good idea, since it takes a bit of time to set up, and there might be some performance issues... and maybe display issues?

But take a look at this:
{{User:Brightgalrs/Sandbox/PaletteSwitch|templatename=User:Brightgalrs/Sandbox/Rock|palette-name=amber}}

It's way to swap palettes on an image, although the image itself is a table, with each cell representing a pixel. The template itself looks like this:
<code><nowiki>{{User:Brightgalrs/Sandbox/PaletteSwitch|templatename=User:Brightgalrs/Sandbox/Rock|palette-name=saffron}}</nowiki></code>
Input the pattern and desired palette name.

I've got a larger showcase here: [[User:Brightgalrs/Sandbox/PaletteSwapShowcase]]. Only did a rock pattern so far, but all palettes are implemented.
The major use for this would be on each stone, metal, wood, etc. type's page. The palette could be read directly from the raws. [[User:Brightgalrs|Brightgalrs]] ([[User talk:Brightgalrs|talk]]) 03:22, 24 December 2022 (UTC)

:From a technical perspective, my primary concern is indeed performance. Both on the server side and client side, a large number of tables that large (in terms of markup and cell count, that is) tend to be resource-intensive to generate and render. I saw your image-filtering experiments on [[User:Brightgalrs/vector.css]], and while that strikes me as a newer and less-backwards-compatible approach, it would probably be more resource-friendly.
:Is this color adjustment something the game is doing natively? i.e. does this accurately match what the game displays? I bet we could slap together an image-filtering extension (or find an existing one?) that can do this if needed. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 03:49, 24 December 2022 (UTC)
::Yeah that's what I suspected. The images the template creates are spot on, checked it against a screenshot I took of some mica rocks in-game. The css stuff is unfortunately totally incorrect, was cool to learn about it though, so not a complete waste of my time :p. The premium, in-game graphics are true sprites, basically patterns of indexed colors. Each of the in-game colors (which are significantly expanded over the 16 ascii colors, there's 116/117) there is a palette defined in "\Dwarf Fortress\data\vanilla\vanilla_descriptors_graphics\graphics\images\palettes.png". Each indexed color of the sprite is swapped for the corresponding color in the palette. Because of that, the css stuff doesn't work since it's doing the hue/saturation/brightness changes to the entire sprite.
::I've looked into an existing mediawiki extension, couldn't find anything. One thing I did't really look at is some type of lua script/module that would basically emulate what the game is doing. So some function that takes in the base image as well as the desired palette, and based on that finds and replaces each color. No idea what mediawiki's capabilities are on that front. [[User:Brightgalrs|Brightgalrs]] ([[User talk:Brightgalrs|talk]]) 05:31, 24 December 2022 (UTC)
:::We do have Scribunto installed now, so it's totally possible to do something in Lua too - forgot about that. I can add you to the group that grants access to edit the Module namespace if you want to give that a shot. If we use an extension, we'd probably need a custom one, similar to DFDiagram (or perhaps DFDiagram could be extended - it's in dire need of a rewrite anyway). —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 05:43, 24 December 2022 (UTC)
::::I asked around on the mediawiki irc, I think scribunto/lua is a deadend, at least for taking an uploaded image and doing stuff to it with a lua script. However I did come up with this even more bizarre solution, using block elements. [[User:Brightgalrs/Sandbox/PaletteSwapShowcase2]], maybe less resource intensive? Definitely displays a lot worse though, probably unusable.
::::{{User:Brightgalrs/Sandbox/PaletteSwitch|templatename=User:Brightgalrs/Sandbox/Rock2|palette-name=saffron}}
::::I dunno, maybe none of this is worth it and we should just write some external program to put all the images together offline, and then just mass upload. It wouldn't be ''that'' many... [[User:Brightgalrs|Brightgalrs]] ([[User talk:Brightgalrs|talk]]) 06:37, 24 December 2022 (UTC)

====Is there an easy way to just paste images from the clipboard?====

I use KDE spectacle to take screenshots straight to the clipboard (after cropping) -- is there an easy way to just paste (and auto-upload) an image into an article? It would make it a lot easier to contribute images. [[User:Kelvie|Kelvie]] ([[User talk:Kelvie|talk]]) 23:35, 1 January 2023 (UTC)
:Unfortunately there is not. I would be open to a MediaWiki extension to support this if someone finds one. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 00:32, 2 January 2023 (UTC)
:: Looks like this could do it, but I haven't used it before: https://www.mediawiki.org/wiki/Extension:SimpleBatchUpload [[User:Kelvie|Kelvie]] ([[User talk:Kelvie|talk]]) 19:41, 2 January 2023 (UTC)
::: It won't solve paste-from-clipboard, but this would be great for making uploading sprites much easier (auto-cutup spritesheet, rename, bulk upload). Could you add this, Lethosor? [[User:OddballJoe|OddballJoe]] ([[User talk:OddballJoe|talk]]) 21:47, 6 January 2023 (UTC)

====Standards for adding graphical version screenshots and images====

Hello, new user looking into adding imagery from the new version. Is there a standard for quality of new screenshots or images? I noticed that at a certain zoom level (2 zooms in from the furthest zoomed-out view), the graphics appear crisp and 1:1 pixel scaled, and I would propose that all images be taken at this scale whenever possible. If they need to be displayed larger, they should be nearest neighbor scaled in a photo editing program at 100% increments (Microsoft Paint will do this if you first select the image rather than directly scaling the whole canvas). I would also propose that images should be cropped to conform to the 32x32 pixel grid when possible, though this could be problematic with so many new graphical elements exceeding the bounds of their tiles. I would say the best practice for capturing artwork for items, furniture etc. ought to be done in a 3x3 open area to avoid shadows from nearby walls, or else extracted from the raw files (if this doesn't run afoul of being able to re-create the graphical version using those assets).

I know that perfect is the enemy of good, and any documentation is better than none, but just thought I'd ask about this, and see if/where something like this ought to be posted. [[User:Unclesporky|Unclesporky]] ([[User talk:Unclesporky|talk]]) 13:58, 3 January 2023 (UTC)

:It has been stated in [[Template:V50 workshop]] that <q>screenshots should be at the "native" resolution</q> but someone could edit the [[Screenshot]] page for best practice for the steam version. Or post some examples in [[Talk:Screenshot]] to find out what is best? --[[User:Halavus|Halavus]] ([[User talk:Halavus|talk]]) 14:21, 3 January 2023 (UTC)

:: Although I haven't added any explanation about best practices, I added a slightly more user-friendly, (Windows) alternative screenshot capturing method to the page. It might be a more helpful/relevant method for use with any best-practices explanations.

::I agree that there needs to at least be some elaboration on the reference to a "native" resolution for screenshots, as it seems irrelevant and misleading with the new display settings and menu in the steam version. Unfortunately, having only just come back to DF after years away, I don't feel confident that I can do this myself, competently. [[User:Alpacalypse|Alpacalypse]] ([[User talk:Alpacalypse|talk]]) 11:32, 7 March 2023 (UTC)

: All of your suggestions seem perfectly sensible to me (assuming that the pixel perfect zoom level is consistent for every user). I don't see why you couldn't take the initiative and pretty much cut and paste your comment here, with some minor tweaks for readability, to a new section on the [[screenshot]] page with a relevant title. Get the ball rolling, it doesn't need to be exhaustively comprehensive to start with. Once the edit is there, it will encourage other wiki editors to make any additions or changes over time. [[User:Alpacalypse|Alpacalypse]] ([[User talk:Alpacalypse|talk]]) 11:42, 7 March 2023 (UTC)

====How would I/should I go about putting creature sprites on their pages?====

Howdy. New player and wiki user here. I wanted to try and help update the wiki to the Steam release of DF, so I figured I'd chip in by putting each creature's sprites on their respective page, since I'll often look up a creature I have yet to see in game only to be met by a blue J, or whatever. I found all of the game's creature sprites in C:\Program Files (x86)\Steam\steamapps\common\Dwarf Fortress\data\vanilla\vanilla_creatures_graphics\graphics\images, so I figured I could just chop those up in Photoshop and stick them on here no problem, but the programming syntax/whatever it is on this site is incredibly confusing, I don't know how I'd actually go about doing it. I figured I'd just find the spot on the page where the little letter is and replace that with the image code, but it seems the pages are built using heavily nested templates that I can't even begin to understand. Any help?--[[User:Treese|Treese]] ([[User talk:Treese|talk]]) 03:07, 5 January 2023 (UTC)
:Based on [[User:Zippy|Zippy]]'s work at {{tl|Creaturelookup_b}}, I added an "image" parameter to {{tl|creaturelookup/0}}, which is what creature pages should all be using. See [[Dwarf]] and [[Cow]] for examples. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 05:37, 5 January 2023 (UTC)

=== Hotkeys/Menu navigation ===
Most key bindings and menus have changed. Should the article reflect a) only the old version, b) only the GUI version or c) both? For example, [[Bridge|bridges]] used to be built via {{k|b}} -> {{k|g}}, but now it's in Place strucutures {{k|b}} -> Constructions {{k|n}} -> Bridge {{k|b}}. What should be written in the article? Currently, it's {{k|b}} -> {{k|g}}. I ''think'' it should be only b), but I am not sure if there will be differences regarding hotkeys or menus between the premium version and the free version and then, c) would be the most appropriate option. --[[User:Prometherus|Prometherus]] ([[User talk:Prometherus|talk]]) 10:16, 22 December 2022 (UTC)

: Not sure. I wish the classic release soon --[[User:Jan|Jan]] ([[User talk:Jan|talk]]) 16:45, 22 December 2022 (UTC)
:: Are you Toady's herald? Looks like it was just released! [[User:Brightgalrs|Brightgalrs]] ([[User talk:Brightgalrs|talk]]) 18:18, 22 December 2022 (UTC)
:: And our questions are answered, the old hotkeys seem to have been thrown out. Part of me is disappointed (useless muscle memory) but also relieved (unified UI for both versions is good in general and for the wiki). [[User:Brightgalrs|Brightgalrs]] ([[User talk:Brightgalrs|talk]]) 18:25, 22 December 2022 (UTC)
::: According to info, in a sort of 'demo version' at that. I'll wait a little while longer, for myself.[[User:Silverwing235|Silverwing235]] ([[User talk:Silverwing235|talk]]) 18:22, 22 December 2022 (UTC)
::::It's unlikely that keybindings in it will change significantly. My vote is that we should include information for both premium and classic, everywhere. Hopefully the keybindings are not different between versions. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 18:26, 22 December 2022 (UTC)
:::Shouldn't it be based on the 50 or what verion the article is written for? [[User:Dominick|Dominick]] [[User_talk:dominick|(TALK)]] 18:42, 22 December 2022 (UTC)
:::: The keybindings seem to be consistent between versions, (haven't checked exhausitvely, but since the menu layout is the same I think it is a good assumption). Should also keep in mind/consider that not all actions have keybindings. An option would be write 'Click on the <Example Text> icon or press {{k|E}}' [[User:Koos|Koos]] ([[User talk:Koos|talk]]) 23:14, 23 December 2022 (UTC)

=== Removed features & concepts ===

Since they're removed concepts, I've set [[Room]] to be a redirect for [[DF2014:Room]] and created [[Template:Activity zones]] for the nav bar bedrooms, etc, and made the necessary changes to [[Bedroom]] for it. Is this the correct approach, before I go on much further? (also a note, if it is, then [[Template:v50_rooms]] probably needs to be deleted) I also imagine that considering the number of changes in the interface, that things like [[Adventure mode]] and related pages might best be truncated to "not in 50.03" and when it does make it across, being more deliberately brought over in pieces? [[User:HawkOwl|HawkOwl]] ([[User talk:HawkOwl|talk]]) 06:23, 23 December 2022 (UTC)

:Usually it is marked with [[Template:Removed_feature]]. For example: [[Dipscript]] or [[Party]]. --[[User:Jan|Jan]] ([[User talk:Jan|talk]]) 07:45, 23 December 2022 (UTC)

:: Ah, that's fair. Should that be mentioned in [[Dwarf_Fortress_Wiki:Versions#Redirects]]? [[User:HawkOwl|HawkOwl]] ([[User talk:HawkOwl|talk]]) 10:03, 23 December 2022 (UTC)

:::I think the redirect policy mostly had in mind things that were removed a ''long'' time ago, like [[Tax collector]] and [[Economy]] (and the latter actually has a stub page as well). I guess we could clarify. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 19:34, 23 December 2022 (UTC)

:::: The "current" redirects also cause the version box to incorrectly show that the current version has a page - e.g. [[23a:Cave_river]] shows a v50.04 version, but it's just a redirect back to that version. Similarly, what should happen to redirects like [[Clothes maker]], where a concept has evolved? It currently goes to [[23a:Clothes maker]] - that's correct if the user is trying to look up a very old concept, but if a new user is looking for "how to make clothes", they should be directed to [[Clothier]]. --[[User:Danny252|Danny252]] ([[User talk:Danny252|talk]]) 12:16, 26 December 2022 (UTC)

::::: It won't work for every case; but strategic use of when, and on what pages to use either a redirect, or the "removed feature" template, should be able to correctly organize references for cases like this. I did it for the recently added "Places" page. With just a redirect from the "building list" page for the current version, The Places page's version template links to a non-existent v0.47 page. With [[Template:Removed_feature]] added to [[Building list]] the [[Places]] 0.47 version template link links to the old [[DF2014:Building list]] page via an automatically created [[DF2014:Places]] page with a redirect to the old Building list page. - A tweaked version of the removed feature template, doing something very similar with automated page redirects, might be a solution for the specific examples you have given for much older versions. (Template:Evolved_feature)? [[User:Alpacalypse|Alpacalypse]] ([[User talk:Alpacalypse|talk]]) 12:08, 7 March 2023 (UTC)

:::::: I may have been overthinking the "Evolved_feature" template idea, or maybe not, if it means manually correcting hundreds of redirects to old pages. Regardless of that, I will just manually edit the specific pages mentioned above to work as intended, especially as [[v0.31:Clothes maker]] did exactly that, and is why the chain in versioned page redirects for "clothes maker" was broken from there to the current version. [[User:Alpacalypse|Alpacalypse]] ([[User talk:Alpacalypse|talk]]) 12:36, 7 March 2023 (UTC)

:::: One should be careful with cv redirects. Most that were recently adjusted were unused plural forms (that should probably be deleted) but few like [[Crown]] needed that for backward compatibility. Removing the [https://dwarffortresswiki.org/index.php?title=Crown&type=revision&diff=279966&oldid=219482 cv part] means the the link on [[v0.31:Tilesets]] is now broken. --[[User:Jan|Jan]] ([[User talk:Jan|talk]]) 22:30, 26 December 2022 (UTC)

:::::If [[v0.31:Tilesets]] is about v0.31, it should not be using "main:" in its links - ''all'' of those links are going to pages about v50, not v0.31, regardless of whether the target is a redirect or not. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 23:37, 26 December 2022 (UTC)
:::::: You right, I removed it. --[[User:Jan|Jan]] ([[User talk:Jan|talk]]) 17:55, 27 December 2022 (UTC)

Crown cv redir issue is now fixed, I believe. As goes with such cases where one can simply revert the troublesome edit, unless I've mistepped, myself? [[User:Silverwing235|Silverwing235]] ([[User talk:Silverwing235|talk]]) 23:52, 26 December 2022 (UTC)
:Both [https://dwarffortresswiki.org/index.php?title=Crown&diff=prev&oldid=280026] and [https://dwarffortresswiki.org/index.php?title=Crown&diff=prev&oldid=279966] should not have had any effect, because "cv" is an alias to the main namespace now, just like "main". Proof: [[Crown]], [[cv:Crown]], [[main:Crown]]. It's possible caching is coming into play here, although I purged the redirect cache after making that alias change earlier this month... —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 00:02, 27 December 2022 (UTC)

I think there have been some changes not captured, but as a newb, I'm afraid to edit the page(s). A good example is Strawberry. I'm playing the Steam version right now and Strawberry plants are "not relevant to brewing" in Labor > kitchen > veg / fruit / leaves. Unless I'm mistaken and need to process them? Another example is the trade caravan = it seems the 3 square pathing no longer happens; it's just yak(s). 12:31, 28 December 2022 (UTC) 12:29, 28 December 2022 (UTC)
:Strawberries should be brewable according to the Raws.
:Trade wagons has been modified in v50. The first wagons will arrive at the same time your fort is becoming a barony. Until then, it's only pack animals and stairs are indeed fine. The [[Trading]] page needs a huge rework anyway... I'll try to do that next week. --[[User:Halavus|Halavus]] ([[User talk:Halavus|talk]]) 13:40, 2 January 2023 (UTC)

As far as I can tell, none of the workshop buildings in v50 have blocking tiles any more. There's a comment to the like in data/vanilla/vanilla_buildings/objects/building_custom.txt that says this "[BLOCK:1:0:0:0] workbenches no longer block". Hesitant to update that template as I'm not sure if it's referenced for all of the old versions too. [[User:AndrielChaoti|AndrielChaoti]] ([[User talk:AndrielChaoti|talk]]) 05:54, 29 December 2022 (UTC)
: A new template has been created: {{tl|V50 workshop}} --[[User:Halavus|Halavus]] ([[User talk:Halavus|talk]]) 13:40, 2 January 2023 (UTC)
::Thanks! In general, I would like to delegate the switching responsibility to the template (like how {{tl|creaturelookup/0}} works), but in cases where the parameters diverge significantly like with workshops, it could make sense to make an entirely new template. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 02:40, 3 January 2023 (UTC)

==== Irrelevant/outdated Pages (migrated?) from much older versions ====

I was just doing a simple edit to [[cave river]] so it redirected to a more relevant page, but this was such a seemingly innocuous page that raised some rather mind-boggling questions for me. Primarily, why does it even exist when it has not been referenced by any wiki pages post 40d, and even then [[40d:Cave river]] was already an outdated redirect. Before changing the redirect, it was redirecting to [[23a:Cave_river]] which lead to a circular v50 link on that page, back to itself, also implying that it might be some old feature reintroduced in v50.

I also added a "removed feature" tag to the page, so it would at least be marked as an obsolete feature, and though mostly irrelevant, due to the redirect, it adds a reference to "see... previous versions". If [[template:av]] is added it only shows v50 and dead v0.47 link; despite showing links, dead or not, to all versions, on the v23a page - when, in this case, it would be more relevant the other way around.

Though the wiki wizardry is a bit beyond me, I assume, for v50, this page was created automatically due to some page migration script, even though there are no pages for the three previous versions. Going by this precedent, shouldn't this page just be deleted? If not, considering it is hard to see why anyone would be searching for "Cave river" in the first place, unless they thought it was a feature for some reason, perhaps this page shouldn't redirect at all, and instead be presented as an "obsolete feature" entry with some relevant information and links.

If the above assumption is correct, it seems like there might be a lot of other possibly redundant and needlessly irrelevant, strangely redirected, or misleading pages for the current version lurking out there; in which case, this might be an issue worthy of further review and added somewhere onto a figurative or literal v50 housekeeping list. (Which this entry here may count as). [[User:Alpacalypse|Alpacalypse]] ([[User talk:Alpacalypse|talk]]) 13:41, 7 March 2023 (UTC)
:The last time [[cave river]] was edited before your edit was in 2011: https://dwarffortresswiki.org/index.php?title=Cave_river&action=history —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 15:34, 8 March 2023 (UTC)
::Yeah, this was primarily why I was wondering why it was even created as a page again for v50. It is hard to imagine why someone would be searching for such an esoteric feature, that hasn't been in the game for well over 10 years, and wasn't even referenced on the wiki for the versions between now and then. I only knew it existed due to Danny's comment four down from the top of [[Dwarf_Fortress_Wiki_talk:Versions#Removed_features_.26_concepts|this talk]] category [[User:Alpacalypse|Alpacalypse]] ([[User talk:Alpacalypse|talk]]) 17:57, 8 March 2023 (UTC)
:::It '''wasn't''' "created as a page again for v50" - from the edit history, it had existed for over 11 years as a redirect to the 23a page before v50 came out. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 20:00, 8 March 2023 (UTC)
::::Thanks for the clarification, the version template shows the page as not existing for the intermediary wiki version pages, so that's where the confusion started. [[User:Alpacalypse|Alpacalypse]] ([[User talk:Alpacalypse|talk]]) 20:43, 8 March 2023 (UTC)
Given the above conclusion, and lot of needless waffle on my part, I thought I may as well give an example of where this confusion arose, regarding the [[Template:ArticleVersion|version template]] links.
 - Although I was mistaken in thinking the [[cave river]] page migration was a mistake, it was suggested that I make a clearer comment and example about what was confusing to me. This is not intended as criticism, but I thought it might be a useful example, and information, for people who are more knowledgable about the wiki's history, page migration and how the version template works, and for this discussion page in general:
#If you got to [[23a:Cave river]] you can see that it lists red links for [[cave river]] pages for: [[DF2014:Cave_river|v0.47]] · [[v0.34:Cave_river|v0.34]] · [[v0.31:Cave_river|v0.31]].
#Before I added a redirect to [[Cavern#Geography]] the v50 [[cave river]] page also showed the red link for [[DF2014:Cave_river|v0.47]], in the version template.
#If you look at the [https://dwarffortresswiki.org/index.php?title=23a:Cave_river&action=history 23a:Cave river history] page it shows the last user edit was in 2021.
#From the [[23a:Cave river]] page, if you click the next (and last non-red before v50) [[40d:Cave river|v0.28]] it takes you to [[40d:Underground river]] via a [[40d:Cave river]] page redirect. The [https://dwarffortresswiki.org/index.php?title=40d:Underground_river&action=history 40d:Underground river history] page shows the last minor edit in 2021, and previous edit in 2014.
#This page's version template now shows red links for all future versions.
#If we backtrack to get back on the trail, the [https://dwarffortresswiki.org/index.php?title=40d:Cave_river&action=history 40d:Cave River history] page shows the last edit in 2010.
#Prior to my redirect edit on 7 March 2023‎, the current version (v50.07) [https://dwarffortresswiki.org/index.php?title=Cave_river&action=history cave river history] page shows the last edit 2011, redirecting it to [[23a:cave river]] which (see #3) has a [https://dwarffortresswiki.org/index.php?title=Cave_river&action=history history showing] twelve edits up to 2021.
Hopefully you can see why I thought this might not be a unique occurrence with page migration, and potentially misleading or confusing. I did my best to balance clarity and brevity, hope this is relevant or of interest. If I have misunderstood something obvious again, please let me know, as I don't want to clutter up this talk page with (even more) needless verbiage. [[User:Alpacalypse|Alpacalypse]] ([[User talk:Alpacalypse|talk]]) 17:48, 10 March 2023 (UTC)
:Just adding a note with a link to the [[Dwarf_Fortress_Wiki_talk:Versions#v50_migration|v50 migration]] discussion here, for anyone reading, as there is already some related discussions about version template linking. --[[User:Alpacalypse|Alpacalypse]] ([[User talk:Alpacalypse|talk]]) 16:52, 12 March 2023 (UTC)

=== creature infobox prototype (moved) ===

Check it out, I made a temporary template and added it to the [[cow]]s page. Now it shows the sprites (but not the zombified versions yet). I wanted to show everyone a prototype of what v50 creature infoboxes should look like. Or at least something similar to it. --[[User:Zippy|Zippy]] ([[User talk:Zippy|talk]]) 19:11, 27 December 2022 (UTC)
:Hi, I'm new to editing wikis but I have done a bit of work with sprite sheets and I've been going through the DF data files to find the different graphics hoping to help with the animal pages. I've thrown together a template with grass and a few nature sprites (plants, a tree, and a rock) for size reference but I'm unsure how large the 'display' tiles in the middle of the template should be to suit all animals. I can see in the sprite sheets that some land animals have an adult and child sprite, so two tiles. Others have a male, female, and child, but after seeing you include the zombie cows I'm unsure if I should make it twice the size to add them too. Alternatively, I could grab some tiles from the haunted biomes for the zombie animals and make a separate template for a side-by-side comparison. Either way, let me know if this helps. I'd like to help with other graphics too as we add the premium tilesets but the animals seemed the easiest to tackle with me being new to wiki editing. ~~[[User:UristTheSeventh|UristTheSeventh]] ([[User talk:UristTheSeventh|talk]])
::@Zippy, I am a bit perplexed about the purple cows. Why do we need a zombified version of creatures on every page?
::@UristTheSeventh, we can use all the help. Maybe post an example, so that we can have something to compare and contrast.--[[User:Jan|Jan]] ([[User talk:Jan|talk]]) 11:49, 3 January 2023 (UTC)
:::@Jan Here are the examples:
:::[[File:Creature template.png]] [[File:Armadillo.png]] [[File:Seagull.png]]
:::It'll need to be wider or arranged differently for different creatures with more that two sprites or for multi-tile creatures. I can also do an aquatic and air themed template for swimming and flying creatures. ~~[[User:UristTheSeventh|UristTheSeventh]] ([[User talk:UristTheSeventh|talk]])
::::Looks nice, like the metal template. There are several people working on updating the graphics you should talk more among yourselves. Best I can offer is that I width wise I am hoping to go up to 200px for infoboxes.--[[User:Jan|Jan]] ([[User talk:Jan|talk]]) 01:13, 5 January 2023 (UTC)
:::: We don't exactly ''need'' a zombie sprite on each page. I added it because it was... there. I was also hoping to get some opinions on it anyway since that infobox is a visual prototype, and not a final choice. --[[User:Zippy|Zippy]] ([[User talk:Zippy|talk]]) 03:28, 6 January 2023 (UTC)

===Furniture Infobox===
{{Quality|Unrated}}
{{v50_furniture|name=Bed
|graphic=[[File:bed_sprite_prototype.png]]
|tile=Θ|col=6:0:0
|wood=y
|rooms=
* [[Bedroom]]
* [[Barracks]]
* [[Dormitory]]
|value=10}}
I made a v50 furniture template prototype. I tested this on Firefox, Chrome and Microsoft Edge/Internet Explorer and it looks fine on all of them. I hope this is good enough to be the official thing, unless I'm missing something. --[[User:Zippy|Zippy]] ([[User talk:Zippy|talk]]) 03:28, 6 January 2023 (UTC)
{{clear}}

=== When do we remove the migration note on specific pages? ===

At what point can we remove the "this page was auto migrated from v47" warning? There are a bunch of small pages that are more or less accurate, if I've reviewed them, can I go ahead and remove the warning? [[User:Kelvie|Kelvie]] ([[User talk:Kelvie|talk]]) 23:33, 1 January 2023 (UTC)
:Yes, feel free to remove it if you think all content is accurate. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 00:31, 2 January 2023 (UTC)

=== Any info on fixing "creature description not found?" ===

I see this issue on most creature pages, it seems to be due to a lookup that's not currently functioning? Cows interestingly doesn't have this issue but I couldn't figure out how to recreate whatever fix it's editor did. --[[User:Yallendallis|Yallendallis]] ([[User talk:Yallendallis|talk]]) 00:22, 3 January 2023 (UTC)
:That is the missing raws issue described above. Cow was fixed by the addition of [[cow/raw]]. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 02:28, 3 January 2023 (UTC)
::Ah makes sense, not fully used to the language of wikis yet so I read over it while looking. To put this bit of questioning to rest for any future readers, is it correct that it's fine to update any raws manually, though it will be done automatically at some point? --[[User:Yallendallis|Yallendallis]] ([[User talk:Yallendallis|talk]]) 07:48, 3 January 2023 (UTC)
:::Yes. I'm circling back to work on a script right now, so not much point in doing it if you're reading this. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 04:57, 4 January 2023 (UTC)
:::This should be fixed now. If you continue to see pages with problems, you can try [https://www.mediawiki.org/wiki/Manual:Purge purging the cache]. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 05:59, 4 January 2023 (UTC)

=== Adventurer Mode related sections ===

The topic has already been discussed [[#Removed features & concepts|above]], but I don't see a clear line on what to do with article sections that mention Adventurer Mode. Like for example in [[Butcher#Adventurer_mode|Butcher]].

'''a) Truncate''' or '''b) leave in place with a mention''' that the mode is not yet present IG but will be added in a future update?

Personally I think option b) is better, because I think it's silly to undo some work just to reintroduce it a few weeks later, with the necessary corrections. Even if a copy/paste of a previous version takes ~15 seconds, considering the number of articles that need to be corrected, it would be a bit of a waste of time.--[[User:Halavus|Halavus]] ([[User talk:Halavus|talk]]) 14:22, 3 January 2023 (UTC)

=== New menus/interface changes ===

I went down a rabbit hole today after adding a "[[places]]" page and redirecting "building list screen" to that. After updating the "[[Template:V50_menus|Menu Tabs]]" template I realised there is a large ammount of missing or incorrect information after v0.47 page migration. It did lead to getting a clearer picture of what exactly has room for improvement though so I'll just add some notes here for now, so I don't forget, and so anyone else who might feel inspired doesn't have to check every reference one-by-one again.

Missing menu/interface entries:
:* [[Tasks]]
:* [[Objects]]
:* (Justice) - [[Open cases]] • [[Closed cases]] • [[Cold cases]] • [[Convicts]] • [[Intelligence]]

Outdated information/missing new interface info:
:* (Places) - [[Stockpile|Stockpiles]] • [[Workshops]] • [[Farming|Farm plots]]
:* (Objects) - [[Artifacts]] • [[Named objects]] • [[Symbols]] • [[Books|Written content]]
:* [[Justice]] - [[Fortress guard]]

I wasn't sure about the correct use of the "tattered" quality category, but if it counts for all those, shall I just change them to that for easier update tracking in general?

I think a lot of these probably just need their own categories added for menu/interface usage, but a few of the more elaborate ones might benefit from having their own menu/interface specific page perhaps?

Also, apologies if I went a bit far editing a template to such an extreme without checking first, I was a bit worried I might mess something up across multiple pages, but decided to take the '''B'''e bold! guideline at face value. :D [[User:Alpacalypse|Alpacalypse]] ([[User talk:Alpacalypse|talk]]) 13:59, 5 March 2023 (UTC)

=== New difficulty settings ===
Considering that these are shiny new features I find it a bit silly that we still don't have a page detailing what exactly these do. The most I've ever seen is little tidbits here and there discussing animal agitation. Some of them are pretty obvious (like tree-fell counts) but the nitty-gritty is always nice.

As far as I can tell, '''Off''' prevents [[sieges]], [[Megabeast|uninvited]] [[Forgotten beast|guests]], and agitated wildlife attacks, but still allows [[Intrigue]] and [[HFS]] to occur (likely evil biome zombie shenanigans as well), '''Normal''' is the default experience, and '''Hard''' ensures a nonstop stream of [[Fun]] assaults your fort. [[User:CobaltNinja|CobaltNinja]] ([[User talk:CobaltNinja|talk]]) 13:38, 18 October 2023 (UTC)

== Toggleable image ==

Any objections/comments to using this template for now for toggling between classic and premium images? I'd probably rename it to "Template:Premium-classic thumb image". I'm sure someone can come up with a better UI eventually, but should be easy to migrate at that point. I also think we should use the same customtoggle class for this and for the infobox. [[User:NiftyManiac|NiftyManiac]] ([[User talk:NiftyManiac|talk]]) 23:12, 1 January 2023 (UTC)

{{User:NiftyManiac/Sandbox/TemplateDualImage|
premium=File:Quickstart-finder.png|
classic=File:Quickstart-finder-partial.png
}}

{{User:NiftyManiac/Sandbox/TemplateDualImage|
premium=File:Quickstart-finder.png|
classic=File:Quickstart-finder-partial.png|
caption=My caption|
width=100px
}}

:This looks nice to me! —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 00:30, 2 January 2023 (UTC)

: Good initiative. From the top of my head:
:* I suggest using a shorthand, no one wants to type 'Premium-classic thumb image'.
:* If we end up using toggle for infoboxes (not sure where we headed there), then I agree definitely same custom toggle class should be used for all, thus allowing to switch premium-classic view on the whole page at a click.
:* The button part on a separate row isn't pretty, creating a lot of dead space that can be used by the text. Are we set on the label 'toggle ascii'? Classic isn't Ascii per se, maybe we can use a 'toggle' with a tooltip {{tooltip|for example|does bla bla bla}}, or maybe we can get rid of the text and have a smaller icon button ([[User:Jan/sandbox#Metal_example|two examples]]).
: I hope that helps. --[[User:Jan|Jan]] ([[User talk:Jan|talk]]) 11:21, 2 January 2023 (UTC)

:: I added [[Template:Dual image]] with some of your suggestions. Agree that it's not super pretty, feel free to try something different.

::* I put the toggle in the caption mostly because I gave up on trying to make a more sophisticated replacement for the default thumb image behavior, I'm sure someone with better wiki-fu could put together something more intelligent.
::* I cut the text down to just "Toggle"; I think the best solution would be a small graphic showing the old and new dwarf icons with arrows between them. [[User:NiftyManiac|NiftyManiac]] ([[User talk:NiftyManiac|talk]]) 19:21, 2 January 2023 (UTC)

{{Dual image|
premium=File:DFwiki5by53by3farm.png|
classic=File:Quickstart_layout_3.png|
width=100px|
caption=A 5x5 room with a 3x3 farm plot
}}
::: I updated the layout, now it should look just like a regular image thumb. I didn't had time to test it, if it doesn't work for you or you don't like it just revert the last change. cheers. --[[User:Jan|Jan]] ([[User talk:Jan|talk]]) 21:46, 2 January 2023 (UTC)
::::I don't know which part of this talk page to put this, but I added the ability to add icons to the v50 workshops template. Leaving the icon part blank will not break the template in any way. --[[User:Zippy|Zippy]] ([[User talk:Zippy|talk]]) 09:47, 3 January 2023 (UTC)

=== Plant Infoboxes ===
Could someone put the toggle image thing on the plant infoboxes? --[[User:Zippy|Zippy]] ([[User talk:Zippy|talk]]) 20:08, 13 February 2023 (UTC)
{{clear}}

==Creature List Now Supports Graphics!==
I wasn't easy, but I made new templates so the [[Creature]]s page now supports both graphics sprites ''and'' ASCII tiles. Allow me to show you:

{{v50_creaturecurrent_table_head}}
{{v50_creaturecurrent table row|graphic=[[File:dwarf_sprite.png]]|name=[[Dwarf]]|symbol=☺|color=3:0:0|playable=Fort, Adv|hostile=No|food=No|size=60,000|value=Not tameable|biome=[[Mountain halls]], [[Fortress|dwarf fortress]]es, [[hillock]]s|note=Trading race}}
{{v50_creaturecurrent table row|graphic=[[File:elf_sprite.png]]|name=[[Elf]]|symbol=e|color=3:0:0|playable=Adv|hostile=Variable1|food=No|size=60,000|value=Not tameable|biome=[[Forest retreat]]s|note=Trading race}}
{{v50_creaturecurrent table row|graphic=[[File:human_sprite.png]]|name=[[Human]]|symbol=U|color=3:0:0|playable=Adv|hostile=Variable1|food=No|size=70,000|value=Not tameable|biome=[[Town]]s and cities|note=Trading race}}
{{v50_creaturecurrent table row|graphic=[[File:goblin_sprite.png]]|name=[[Goblin]]|symbol=g|color=7:0:0|playable=Adv|hostile=Usually1|food=No|size=60,000|value=Not tameable|biome=[[Dark fortress]]es and [[dark pit]]s|note=Snatchers2}}
{{v50_creaturecurrent table row|graphic=[[File:kobold_sprite.png]]|name=[[Kobold]]|symbol=k|color=6:0:0|playable=Adv|hostile=Usually1|food=No|size=20,000|value=Not tameable|biome=Caves|note=Skulking race}}
|}

Oh wait, there's a bonus. You can also modify the background color of the box the sprites go in. I added that to make possibly-hard-to-see-otherwise sprites more easy to see - depending on the colors it has. Allow me to demonstrate.

{{v50_creaturecurrent_table_head}}
{{v50_creaturecurrent table row|graphic=[[File:dwarf_sprite.png]]|bgcolor=#829ccc|name=[[Dwarf]]|symbol=☺|color=3:0:0|playable=Fort, Adv|hostile=No|food=No|size=60,000|value=Not tameable|biome=[[Mountain halls]], [[Fortress|dwarf fortress]]es, [[hillock]]s|note=Trading race}}
{{v50_creaturecurrent table row|graphic=[[File:elf_sprite.png]]|bgcolor=#c7dfc0|name=[[Elf]]|symbol=e|color=3:0:0|playable=Adv|hostile=Variable1|food=No|size=60,000|value=Not tameable|biome=[[Forest retreat]]s|note=Trading race}}
{{v50_creaturecurrent table row|graphic=[[File:human_sprite.png]]|bgcolor=#c7dfc0|name=[[Human]]|symbol=U|color=3:0:0|playable=Adv|hostile=Variable1|food=No|size=70,000|value=Not tameable|biome=[[Town]]s and cities|note=Trading race}}
{{v50_creaturecurrent table row|graphic=[[File:goblin_sprite.png]]|bgcolor=#dfc0c0|name=[[Goblin]]|symbol=g|color=7:0:0|playable=Adv|hostile=Usually1|food=No|size=60,000|value=Not tameable|biome=[[Dark fortress]]es and [[dark pit]]s|note=Snatchers2}}
{{v50_creaturecurrent table row|graphic=[[File:kobold_sprite.png]]|bgcolor=#dfc0c0|name=[[Kobold]]|symbol=k|color=6:0:0|playable=Adv|hostile=Usually1|food=No|size=20,000|value=Not tameable|biome=Caves|note=Skulking race}}
|}

To change the background color, add <code><nowiki>|bgcolor=COLOR</nowiki></code> segment after the <code><nowiki>|graphic</nowiki></code> part. You can use color names or HTML hex color codes. I added this to the v50 creatures page, but at this time, I only added the first five creatures I just displayed. It's gonna take a while to find ALL of those creature sprites. I hope a lot of people help out on that one. --[[User:Zippy|Zippy]] ([[User talk:Zippy|talk]]) 05:29, 5 January 2023 (UTC)

:Thanks, looks nice! —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 05:44, 5 January 2023 (UTC)
:Nice stuff, took the quick liberty to change the padding-left -> text-align to make all the sprites center aligned relative to each other :) Sweet work --[[User:Vallode|Vallode]] ([[User talk:Vallode|talk]]) 17:41, 5 January 2023 (UTC)
:: Good work indeed. One minor issue, is that all the sprites have different sizes, which sometimes create slight variation in table row height. Consider using capping the image size vertically for example <code><nowiki>[[File:dwarf_sprite.png|x32px]]</nowiki></code>--[[User:Jan|Jan]] ([[User talk:Jan|talk]]) 18:15, 5 January 2023 (UTC)
:: Also often in such tables people want to click on the image to go for the specific entry, and often will try to click on the very first thing they see in line the thumb image, but currently that will take them to the file page. Consider adding link parameter for example: <code><nowiki>[[File:dwarf_sprite.png|x32px|link=dwarf]]</nowiki></code> [[File:dwarf_sprite.png|x32px|link=dwarf]] or no link at all <code><nowiki>[[File:dwarf_sprite.png|x32px|link=]]</nowiki></code> [[File:dwarf_sprite.png|x32px|link=]] --[[User:Jan|Jan]] ([[User talk:Jan|talk]]) 18:24, 5 January 2023 (UTC)
::: I mean... Yeah, I could do that. I think that lessens the quality of the sprite a bit because it makes edges blurry, but either way is fine. I could have sworn I added a link for all those images the first time. --[[User:Zippy|Zippy]] ([[User talk:Zippy|talk]]) 03:23, 6 January 2023 (UTC)
::::Since we are adding pixel art sprites to the website it might be convincing to add a global class like .sprite or .pixel-image that uses the CSS attribute `image-rendering: pixelated;` in order to prevent blurryness when scaling the image up/down. Just a thought --[[User:Vallode|Vallode]] ([[User talk:Vallode|talk]]) 09:40, 6 January 2023 (UTC)
:::::Are we able to attach classes directly to images? If so, we can probably attach inline styles directly as well. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 16:52, 6 January 2023 (UTC)
::::::Looks like (without an extension) MediaWiki only supports classes on images: [[File:dwarf_sprite.png|x32px|class=pixelated]] and not styles: [[File:dwarf_sprite.png|x32px|style="image-rendering: pixelated;"]] it just treats it as alt text it looks like? Wrapping it in a div works and demonstrates the difference: <div style="image-rendering: pixelated;display:inline;">[[File:dwarf_sprite.png|64px]]</div> [[File:dwarf_sprite.png|64px|inline]]. Speaking from experience, however, image-rendering needs a browser specific prefix in certain browsers (safari, for example) in order to work properly. I'm not entirely sure what the best "MediaWiki" practice is for adding something like this but I would assume it's a simple class in common.css for now. --[[User:Vallode|Vallode]] ([[User talk:Vallode|talk]]) 17:17, 6 January 2023 (UTC)
:::::::Ah, yeah, you are correct, I should have checked https://www.mediawiki.org/wiki/Help:Images. I'd be fine adding a class like that to common.css. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 17:27, 6 January 2023 (UTC)
::::::::Great, in that case if no one is opposed we can add `.game-sprite` or something like that? See below for the CSS, the order of the attributes is relevant. --[[User:Vallode|Vallode]] ([[User talk:Vallode|talk]]) 18:23, 6 January 2023 (UTC)
<pre>/* Used for pixel-art images from the game so they can be resized and maintain crisp pixel edges. */
.game-sprite {
image-rendering: -webkit-optimize-contrast;
image-rendering: crisp-edges;
image-rendering: pixelated;
}</pre>
:::::::::So... you guys think each creature page should show the main sprite(s) alone, or should it show the baby versions alongside them? --[[User:Zippy|Zippy]] ([[User talk:Zippy|talk]]) 08:37, 8 January 2023 (UTC)
::::::::::I think adult + baby is sensible, the adult + baby + zombie was not, in retrospect. So yeah adult + baby (if there is one) from now on would be my vote. --[[User:Vallode|Vallode]] ([[User talk:Vallode|talk]]) 23:27, 8 January 2023 (UTC)
{{outdent}}
Well then, there's a TON of creatures to go - and I mean both the [[creature]]s page and the individual creature pages. I really hope everyone can pull their weight on that those images. The spritesheets are easy to find, and if you know how to read the .txt files near them, finding sprites on certain rows and columns should be a breeze. --[[User:Zippy|Zippy]] ([[User talk:Zippy|talk]]) 00:47, 9 January 2023 (UTC)
:Zippy, are you doing all of this by hand? That seems quite tedious. Cutting up the spritesheets can be done automatically. Renaming and updating the table could be done with a script and/or chatgpt. We'd need Lethosor to add the [https://www.mediawiki.org/wiki/Extension:SimpleBatchUpload batch upload extension] though. Maybe some manual work in updating names to match article names rather than raws. [[User:OddballJoe|OddballJoe]] ([[User talk:OddballJoe|talk]]) 06:55, 9 January 2023 (UTC)
{{clear}}
::So did the graphic people gained insights and reached some sort of consensus? are we using big up scaled images + toggle? multiple images to(adult + baby)? anything else? --[[User:Jan|Jan]] ([[User talk:Jan|talk]]) 00:32, 10 January 2023 (UTC)
:::I noticed that someone blew up the size of the previews in infoboxes. Was that you Jan that did that? Whoever did that enlarged the DFtext tile as well. Don't know if that was intentional or not. I'd prefer if the sprites were either left alone or at double-sized max (or however they look in-game at 1:1 - not zoomed in or out), though that's just me. It looks like maybe they're triple-sized or something.

:::@OddballJoe - It's not all by hand, I have some Photoshop scripts that cut my work time in half, or even by a third. Lethosor said something about us not uploading entire spritesheets. If we did it the entire spritesheet way, one update to the sheet could misalign everything and screw up many pages. For example, let's say Kitfox slipped in an extra couple rows of creatures in an image file, that means the other rows under it would be misaligned and pages would show the wrong creatures. Know what I mean? I'd still prefer if other people jumped in and added sprites, though. --[[User:Zippy|Zippy]] ([[User talk:Zippy|talk]]) 00:51, 10 January 2023 (UTC)

:::: Lethosor introduced the changes, using the image-rendering stuff. I am just waiting for any sort of consensus to do anything, same as with workshops I am not clear on the size people want to go for [[:File:Carpenter%27s_workshop.png|original]] or [[:File:Ashery.png|big]] --[[User:Jan|Jan]] ([[User talk:Jan|talk]]) 01:17, 10 January 2023 (UTC)

::::: I'm no graphics artist but I'm not sure I understand why global consensus needs to be achieved... We're dealing with pixel art, why wouldn't we just upload the pixel-perfect versions from the spritesheets for all images that we need? The display size can be discussed on the appropriate template pages and adjusted in the templates or css. I also tend to think that if we want to maintain something like 1k images that may change in the future, it'd be worth automating most of the work. Zippy, as far as I can tell the raws give all the coordinates needed to cut out and label each sprite, so I was thinking one script could parse the raws, make and label the cutouts, and upload. [[User:OddballJoe|OddballJoe]] ([[User talk:OddballJoe|talk]]) 04:49, 10 January 2023 (UTC)

::::: Likewise I think the image names should be standardized so we can just change the creature infobox template to look up the image rather than editing a gazillion pages by hand. Though I suppose at some point the pages will need review to remove the migration banner anyway. [[User:OddballJoe|OddballJoe]] ([[User talk:OddballJoe|talk]]) 04:51, 10 January 2023 (UTC)

::::: Looks like you answered your own question, standardization. Initially, it is best to try different things and figure out all the odd quirks that doesn't fit. But eventually, it is best if we all work toward the same goal, saving everyone time and making the result more consistent in terms of naming convention, parameter name, resolution, use of scaling (in-game or otherwise), use of sprites or screenshots (like for layered workshops), use of templates, amount of images planned or whatever else was mentioned above. I think that discussion of the desired outcome goes well in hand here. --[[User:Jan|Jan]] ([[User talk:Jan|talk]]) 10:38, 10 January 2023 (UTC)

=== Graphics in Skill Infoboxes ===
{{v50_skill
| color = 7:0
| graphic = [[File:miner_sprite_icon.png]]
| skill = Miner
| profession = Miner
| job name = [[Mining]]
| tasks =
* [[Dig]]
| attributes =
* Strength
* Toughness
* Endurance
* Willpower
* Spatial Sense
* Kinesthetic Sense}}I've made yet another visual prototype for skills. In other words, we can put sprites of matching dwarves (and possibly humans, elves, goblins, etc.) at the top of infoboxes. If multiple images are put up there, that can mess up the alignment, but don't worry, Zippy thought of that. <code><nowiki>|graphicmargin</nowiki></code> can added, and a percentage or a "px" number can be placed in that parameter to fix it. If you leave said parameter out, the alignment will default to about 42% from the left. --[[User:Zippy|Zippy]] ([[User talk:Zippy|talk]]) 06:06, 7 January 2023 (UTC)
<pre><nowiki>
{{v50_skill
| color = 7:0
| graphic = [[File:miner_sprite_icon.png]]
| graphicmargin = (OPTIONAL)
| skill = Miner
| profession = Miner
| job name = [[Mining]]
| tasks =
* [[Dig]]
| attributes =
* Strength
* Toughness
* Endurance
* Willpower
* Spatial Sense
* Kinesthetic Sense}}
</nowiki></pre>
::Not sure I understand the alignment issue, can you not put text-align: center on the parent table element instead of messing with explicit margins? As another sidenote, should we continue to be naming all of these templates v50_x, I find that a bit confusing. Why not just edit the main templates with the additional information. Loving all the new templates though nice work Zippy :) --[[User:Vallode|Vallode]] ([[User talk:Vallode|talk]]) 11:43, 7 January 2023 (UTC)
:::No, text-align doesn't work with images and divs. That just works for text. When it comes to images, you got to put a little "finesse" on the CSS with those. As for editing the classic templates with the new info, it doesn't always work that way with ''every'' template. Lethosor I think ''did'' update the creature infobox template in the way you mentioned. --[[User:Zippy|Zippy]] ([[User talk:Zippy|talk]]) 08:37, 8 January 2023 (UTC)
:::: You can use something like this to automatically handle that--[[User:Jan|Jan]] ([[User talk:Jan|talk]]) 08:56, 8 January 2023 (UTC)
{|
|-
|<div style="width:200px; display:flex; background-color:#eaecf0;">
[[File:miner_sprite_icon.png|center]]
<div>
|<div style="width:200px; display:flex; background-color:#eaecf0;">
[[File:miner_sprite_icon.png|center]] [[File:miner_sprite_icon.png|center]]
<div>
|<div style="width:200px; display:flex; background-color:#eaecf0;">
[[File:miner_sprite_icon.png|center]] [[File:miner_sprite_icon.png|center]] [[File:miner_sprite_icon.png|center]]
<div>
|}
:::::Hah I am very familar with the CSS finese :P Can you show me an example of a multi-sprite job infobox? I said what I said because I tested my proposed solution and it worked fine :)

==Adding Vermin list to Creatures page==
I wanna do that. You guys okay with that? I asked Lethosor, and he said to ask the majority. So uh... here I am... --[[User:Zippy|Zippy]] ([[User talk:Zippy|talk]]) 20:42, 7 February 2023 (UTC)

: My main concern is with page size, [[Creature]] is absolutely massive now. In fact, now that I look at it I see a ton of broken images; I'm guessing this is related to some size or timing limit that's being hit when rendering or expanding all the templates. This should definitely be fixed before we make the page even larger. In fact I'd probably even support splitting it out into more smaller pages for easier browsing. We already have [[Alternate creature sorting]] which can be used as the master sortable list of all creatures including vermin. -[[User:OddballJoe|OddballJoe]] ([[User talk:OddballJoe|talk]]) 22:47, 7 February 2023 (UTC)
::In my opinion, the page size isn't an issue. The vermin list is large, but not "excruciatingly" large. At the absolute worst, it makes a massive page just a bit bigger, and it isn't going to ease someone's scrolling adventure by all ''that'' much if it's not there. I put the vermin list there, under the aquatic creatures, just to see how people like it. For now... --[[User:Zippy|Zippy]] ([[User talk:Zippy|talk]]) 17:24, 8 February 2023 (UTC)
::: Unfortunately page size being an issue isn't a matter of opinion: [[Creature]] was, even before your edit, huge and partially broken. Nearly the entire vermin section you added has nothing but broken images (https://imgur.com/a/gpi7guA). We need to fix the situation of broken images before we can consider increasing this page's size further. The other issue with your edit is that we cannot have two vermin tables on different pages; we need a single source of truth to be able to maintain the info (which could be a template transcluded in multiple places). —[[User:OddballJoe|OddballJoe]] ([[User talk:OddballJoe|talk]]) 19:12, 9 February 2023 (UTC)
:::: Dude dude duuuuuuuuuuuuude. You posted this message at the wooooooorst time. I was posting my thing about tree infoboxes below, which caused a "edit conflict" warning, which erased my entire thing. It's not your fault in the slightest, but that's what happened. That sucked ass. Granted, I should have copy and pasted it. I have no what the sweet sweet shit the broken image thing is about, I've looked at the page on multiple browsers and even PC's and it looks fine. I'll remove the edit, but I can't for the life of me tell you what the image problem is. Try doing a cache refresh or something. --[[User:Zippy|Zippy]] ([[User talk:Zippy|talk]]) 19:27, 9 February 2023 (UTC)
::::: Yeah, that sucks; I think when you get an edit conflict it should still let you copy at that point, but I guess you know for next time. When testing the page, try loading it logged out in a new incognito/private window to avoid local cache effects. Since mediawiki can have weird caching behavior, the wayback machine helps for resolving arguments related to caching: [https://web.archive.org/web/20230209001103/https://dwarffortresswiki.org/index.php/Creature#Vermin this snapshot] from earlier today shows tons of broken images (note that archive.org is having some issues atm so that link might not work until it's up again). —[[User:OddballJoe|OddballJoe]] ([[User talk:OddballJoe|talk]]) 19:50, 9 February 2023 (UTC)

==Updating Tree Infoboxes==
Any idea on what that should look like? I have two mockups here:
<gallery widths="223px" heights="324px">
tree_infobox_example.png|Trunk and tile.
tree_infobox_example2.png|Trunk, branch, leaves and tile.
</gallery>
Whatever the choice, someone's gonna have to really help me. The amount of images I've added and edits I've made... I'm exhausted... --[[User:Zippy|Zippy]] ([[User talk:Zippy|talk]]) 19:27, 9 February 2023 (UTC)

: Maybe we follow the same "Toggle" format as with creatures for the ASCII? Then there's probably enough room to comfortably include all or most of the tree sprites (trunk, branches of different sizes, growths). While I admire your Herculean efforts, this stuff can be automated as well. I'm working on some code for a separate project for parsing raws and extracting various df sprites, which I'm hoping to share out sometime this month, which could be helpful for this kind of thing. —[[User:OddballJoe|OddballJoe]] ([[User talk:OddballJoe|talk]]) 20:19, 9 February 2023 (UTC)

Dwarf Fortress Wiki:Page request/List

2023-10-15T19:20:16Z

CobaltNinja: New page request

{{page request header|List of page requests}}
:''This is a '''list''' of page requests. See [[DF:PR|this page]] for assistance with requesting a new page.''
== Recently created pages ==
{{Special:RecentChangesLinked/Template:Newpage|showlinkedto=1}}
----
{{page request footer}}

== Article requests ==


* Request: v50's been out for nearly a year now and there is still no page on this wiki detailing what the new granular [[Difficulty]] settings do. Do we even ''know'' what they do? From what I can gather, '''Off''' stops outside enemies from entering the map (but still allows [[Intrigue]] and wildlife treated as dangerous to occur), '''Normal''' is as per usual, and '''Hard''' ensures a nonstop stream of [[Fun]] will relentlessly assault your fort, but other than that, I've no clue. [[User:CobaltNinja|CobaltNinja]] ([[User talk:CobaltNinja|talk]]) 19:20, 15 October 2023 (UTC)

*Request: [[Unusual volcanic wall]] - Right now there's a small section for this new (added in v50) structure/formation under the page for [[obsidian]] but I think it's notable/complex enough for its own page [[User:KM942|KM942]] ([[User talk:KM942|talk]]) 03:50, 7 January 2023 (UTC)

* Request: I would like to upload a few pictures (that I made and edited for clarity) to demonstrate a modular [[Minecart]] thumper design. [[User:2Bob|2Bob]] ([[User talk:2Bob|talk]]) 15:23, 2 January 2023 (UTC)2Bob

*Request: I would like to create [[The Long Night]] and several associated articles [[The Long Night: Civilizations]], [[The Long Night: Creatures]], [[The Long Night: Materials]], [[The Long Night: Weapons]], and [[The Long Night: Armor]] to form a more easily navigated guide to the new features found in the mod of the same name. [[Special:Contributions/98.212.135.225|98.212.135.225]] 23:51, 1 September 2020 (UTC)
** Since this is a mod, it should go under the mod namespace. I've created [[Mod:The Long Night]]; as it expands, I would suggest creating subpages like [[Mod:The Long Night/Creatures]]. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 01:25, 2 September 2020 (UTC)

* request: [[DF2014:Altar]] [[Special:Contributions/35.191.8.17|35.191.8.17]] 00:11, 17 February 2020 (UTC)
** Done. DF also refers to these as "offering place"s in the {{k|b}} menu, but I didn't see existing pages where either of these were mentioned from a quick search. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 00:03, 30 June 2020 (UTC)

* Request: I would like to create [[DF2014:Messenger]] specifically with the information that they are assigned on the locations screen [[User:Keupo|Keupo]] ([[User talk:Keupo|talk]]) 06:56, 27 June 2018 (UTC)
** You already have permission to do this since you've made 3 edits now. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 17:31, 27 June 2018 (UTC)

* Request: I would like to create [[Civilization/World_Info_menu]] [[User:Azeroth2b|Azeroth2b]] ([[User talk:Azeroth2b|talk]]) 18:33, 13 December 2017 (UTC)

* Request: I would like to create [[DF2014:Kisat Dur]] [[Special:Contributions/174.27.44.232|174.27.44.232]] 00:14, 31 July 2016 (UTC)
** Done. [http://www.bay12forums.com/smf/index.php?topic=148015.0 Forum thread] for reference. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 02:09, 1 August 2016 (UTC)

* Request: [[DF2014:Reaction examples]] Simply copy the old page from v0.31 for more resources. Many old pages on modding haven't been pushed through versions even when they are still accurate. [[Special:Contributions/2606:A000:FD44:7A00:B58A:AB43:BD25:B51C|2606:A000:FD44:7A00:B58A:AB43:BD25:B51C]] 22:23, 28 March 2016 (UTC)Ryga_
** Done.--[[User:Loci|Loci]] ([[User talk:Loci|talk]]) 19:47, 1 August 2016 (UTC)

* Request: I would like to create [[DF2014:Philosopher]] and [[DF2014:Sage]] because these are new scholar jobs in 42.xx [[User:Lead Cafe|Lead Cafe]] ([[User talk:Lead Cafe|talk]]) 22:33, 28 January 2016 (UTC)
** Both are profession titles associated with scholars; I created them as redirects to [[DF2014:Scholar]].--[[User:Loci|Loci]] ([[User talk:Loci|talk]]) 04:08, 29 January 2016 (UTC)

*[[DF2014:Citizenship]] — here's one article on a new mechanic not currently covered by the wiki, we most definitely need to work on this. — [[Special:Contributions/94.19.200.59|94.19.200.59]] 20:39, 8 December 2015 (UTC)
**Done. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 22:17, 4 January 2016 (UTC)

*[[Masterwork:Titanite]]: I can't find any information about Masterwork's Titanite, either from the wiki or Google. After mining some, I can only cut it like gems. Also need a to-do for this: build a crucible to determine if [[Masterwork:Titanium]] can be extracted from titanite. 1 Jan 2016
**Done. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 22:17, 4 January 2016 (UTC)

*[[DF2014:Giant firefly]]: Just found one in my latest save of 0.42.05, realized a page didn't exist. [[User:ArcaneMusic|ArcaneMusic]] ([[User talk:ArcaneMusic|talk]]) 22:07, 19 January 2016 (UTC)
** I just added a list of all the new creatures (probably contains some errors) on the talk pages of the [[graphic set]] and [[creature]] pages. Most of those probably need to be added as new pages too. In addition the page [[Back_bear_man]] should be deleted (mistyped b-L-ack bear man). In the future, it would be nice to have a script that simply goes through the creature raws and suggests new pages to be created for missing creature entries. [[User:CLA|CLA]] ([[User talk:CLA|talk]]) 15:12, 20 January 2016 (UTC)
***The admins have bots that can create the pages automatically. Part of the hold-up is that the wiki's raws haven't been updated, so new creature pages aren't able to "autofill" with the appropriate details from the raws (and we prefer not to enter all that information manually).--[[User:Loci|Loci]] ([[User talk:Loci|talk]]) 20:38, 20 January 2016 (UTC)

*[[Masterwork:Drake]] The article is blank. Since these are a domestic animal that players can grab on embark, there should be some information about them for people new to the mod. [[User:Apollo Densin|Apollo Densin]] ([[User talk:Apollo Densin|talk]]) 02:00, 11 March 2019 (UTC)
** Done.--[[User:Loci|Loci]] ([[User talk:Loci|talk]]) 23:50, 13 March 2019 (UTC)

*Version 0.47.1 added [[DF2014:Fort]], [[DF2014:Constructed creatures]], and perhaps [[DF2014:Intelligent undead]]. It also allows to [[DF2014:Mount]] creatures. A lot of other new features deserve their pages. Perhaps we should create a DF2020 version of pages.

== Talk page requests ==

Requesting new talk page for https://dwarffortresswiki.org/index.php/Dwarf_Fortress_Wiki:Centralized_Discussion/page_describing_47_v50_differences [[User:Evilishies|Evilishies]]

I would like a page describing the differences between the 2014 (v0.47) and Steam (v0.50) versions. As a new player, a page outlining these differences would be massively helpful and allow me to read existing documentation and forums more easily, as well as make updates to the v0.50 pages.

Requesting new talk page for https://dwarffortresswiki.org/index.php/Template_talk:DF2014_labors please & thank you [[User:Blitz4|Blitz4]] ([[User talk:Blitz4|talk]]) 02:23, 5 July 2022 (UTC)

I would like a talk page for [[DF2014:Bauxite]] and [[DF2014:Aluminum]]. [[User:Magic9mushroom|Magic9mushroom]] ([[User talk:Magic9mushroom|talk]]) 04:24, 17 August 2019 (UTC)
:Done. -- [[User:Loci|Loci]] ([[User talk:Loci|talk]]) 18:58, 18 August 2019 (UTC)

Request: Talk page for [[DF2012:Repeater]] [[Special:Contributions/68.6.123.36|68.6.123.36]] 03:38, 25 March 2014 (UTC)
:Done. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 03:44, 25 March 2014 (UTC)

Masterwork_Talk:Guildhall [[Special:Contributions/68.46.84.117|68.46.84.117]] 14:02, 20 October 2013 (UTC)
:Done. --[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 15:01, 20 October 2013 (UTC)

Hello, would you be able to create a Talk page with the following question for me?:

"Do children born during fortress mode (or worldgen if you can find out) adopt the dieties of their friends/parents, or are they assigned a random diety? Is this with immediate effect from birth?

Thanks.

Josh"

Thank you! :)

Hello, I'd like to open another talk/discussion page for "Size" (http://dwarffortresswiki.org/index.php/DF2012:Size) with the following question:

Are there any combat benefits to SMALL dwarves?

On one of the pages for an older version of DF it notes that large creatures like elephants have a hard time landing a hit on small creatures like cavies. Would this alleged bonus to-dodge and/or penalty to-hit modifier translate in any meaningul way for smaller dwarves?
:[[DF2012 talk:Size|Done]]. --[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 19:05, 1 January 2014 (UTC)

I'd like to open a talk page for [[DF2012_Talk:Relationships]] with the following note (two paragraphs):

The royalty section is inaccurate. I have a second-generation native-born dwarf in one of my fortresses who has a plentitude of aunts and uncles and listed maternal and paternal grandparents. I'm not sure why having those relationships is only noticed for royalty, but I think it's partially because shorter worlds mean smaller lineages and partially because most forts don't last long enough to see native-born children grow up, get married, and have children of their own. I really don't think there's any reason why extended family would be limited to royalty in any case.

Anyway, I added parents to the Types section, and also grandparents because I hadn't noticed the Royalty section. I'd add Aunts/Uncles but I'm not sure where they fall in on the list, and baby Sarvesh doesn't have any cousins yet.

Thank you! --[[User:Lielac|Lielac]] ([[User talk:Lielac|talk]]) 02:41, 24 January 2014 (UTC)
:Done. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 03:37, 24 January 2014 (UTC)

Hello, I feel that [[DF2012:World_generation]] should cover what goes into history simulation, as it is obviously different to simulation in fortress mode.
However, this is not a matter I am educated on. I would put this request on the page, but I cannot yet create a talk page.
:Done. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 19:05, 22 April 2014 (UTC)

* https://dwarffortresswiki.org/index.php/Template_talk:DF2014_labors
[[User:Blitz4|Blitz4]] ([[User talk:Blitz4|talk]]) 02:23, 5 July 2022 (UTC)

Edits made by 76.116.204.8 were made by me while I was away from school/university on summer/winter vacation at my dad's. I wanted to make a note on [[User talk:76.116.204.8]] claiming attribution for the edits. Additionally, I would like to request the creation of [[Talk:Gem]] so that we can discuss a current bug where the new "cut gem" job never creates a large gem or gem craft (as of 0.50.03). – [[template:unsigned|unsigned]] comment by [[User:ArmokGoB|ArmokGoB]]

:You appear to have the ability to create pages now. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 04:31, 23 December 2022 (UTC)

== User page requests ==

{{upr|[[User:Allcrops|Allcrops]] ([[User talk:Allcrops|talk]])}}
{{upr|[[User:Blitz4|Blitz4]] ([[User talk:Blitz4|talk]])}}
{{upr|[[User:uberflut|uberflut]] ([[User talk:uberflut|talk]])}}
{{upr|[[User:DeathByBlue|DeathByBlue]] ([[User talk:DeathByBlue|talk]]) 02:31, 28 March 2020 (UTC)}}
{{upr|[[User:Lead Cafe|Lead Cafe]] ([[User talk:Lead Cafe|talk]])}}
{{upr|[[User:BillyJack|BillyJack]] ([[User talk:BillyJack|talk]])}}
{{upr|[[User:BillyJack|Sandbox]] ([[User talk:BillyJack|talk]])}}
{{upr|[[User:Theit8514|Theit8514]] ([[User talk:Theit8514|talk]])}}
:Created. --[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 23:37, 30 June 2013 (UTC)
{{upr|[[User:Mixtrak|Mixtrak]] ([[User talk:Mixtrak|talk]])}}
{{upr|[[User:Green Sprite|Green Sprite]] ([[User talk:Green Sprite|talk]])}}
{{upr|[[User:Mikerenfro|Mikerenfro]] ([[User talk:Mikerenfro|talk]])}}

== Redirect requests ==

*[[Hot tub]] should redirect to [[Magma Sea]]—not very common slang, but I've heard it consistently. [[Special:Contributions/68.56.148.200|68.56.148.200]] 06:57, 1 January 2022 (UTC)
**Do you have an example? I've never heard this. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 20:14, 1 January 2022 (UTC)
*[[DF2014:Fun]] to [[DF2014:Losing]]
[[dfhack]], [[DFHack]] and [[DF2012:DFHack]] to [[Utility:DFHack]]. --[[User:Lurker|Lurker]] ([[User talk:Lurker|talk]]) 14:07, 7 August 2013 (UTC)
:Done. --[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 17:48, 7 August 2013 (UTC)
* Page "Taming" should redirect to "DF2012:Tame" [[User:Latias1290|Latias1290]] ([[User talk:Latias1290|talk]]) 18:02, 27 August 2013 (UTC)
**[[DF2012:Tame]] is a redirect to [[DF2012:Animal trainer]]. Created [[Taming]] and [[DF2012:Taming]] as redirects. --[[User:Loci|Loci]] ([[User talk:Loci|talk]]) 19:33, 27 August 2013 (UTC)
* Page "Gcs" should redirect to [[DF2014:Giant_cave_spider]]. [[Special:Contributions/199.60.104.18|199.60.104.18]] 19:00, 1 September 2015 (UTC)
:Done. Just do it yourself next time. Just create the page and add "#REDIRECT" followed by a space and the link to the page.[[User:CLA|CLA]] ([[User talk:CLA|talk]]) 22:19, 1 September 2015 (UTC)
::The reason this page exists is because anonymous users can't create pages. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 12:09, 4 September 2015 (UTC)
:::Oh, that makes sense. Should have figured that out on my own.
* [[DF2014:Combat log]] could redirect to [[DF2014:Reports]], I think it's the phrase new players will search for. [[User:Okdewit|Okdewit]] ([[User talk:Okdewit|talk]]) 18:58, 30 January 2016 (UTC)
**Done. [[User:Jwoodward48|Jwoodward48]] ([[User talk:Jwoodward48|talk]]) 00:05, 2 March 2016 (UTC)
* create redirect page "World Activation" and redirect to World_activities [[User:Untrustedlife|Untrustedlife]] ([[User talk:Untrustedlife|talk]]) 00:13, 26 July 2016 (UTC)
-- Got it done [[User:Untrustedlife|Untrustedlife]] ([[User talk:Untrustedlife|talk]]) 00:16, 26 July 2016 (UTC)
* Page [[DF2014:Guineahen]] and [[DF2014:Keet]] could redirect to [[DF2014:Guineafowl]] the same way [[DF2014:Guineacock]] does currently. [[Special:Contributions/2A01:C50E:D66A:5500:0:0:0:10|2A01:C50E:D66A:5500:0:0:0:10]] 17:43, 29 November 2017 (UTC)
* Create redirect page for "Retire", "Unretiring", and "Retiring" and redirect to "Reclaim Fortress Mode" [[User:Benderdragon|Benderdragon]] ([[User talk:Benderdragon|talk]]) 16:21, 29 June 2020 (UTC)
** Created [[Retire]]; [[Unretire]] already existed, and I'm hesitant to create redirects for the gerund forms - we don't have guidelines that specifically discourage them, but {{Rule|N}} and {{Rule|E}} are similar, and partial searches for "retir" or "unretir" should bring up the relevant pages in the search box anyway. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 00:12, 30 June 2020 (UTC)
*redirect "ringleader" and potentially several other possible titles for crime bosses to [[DF2014:Boss]][[User:Rugnir|Rugnir]] ([[User talk:Rugnir|talk]]) 21:47, 13 August 2021 (UTC)

== Other requests ==


* I made some nice v50.xx graphics for the FPS efficient 1x3 pump stack design, and couldn't upload them when I tried to add a new block to the page. For the moment I've uploaded them here: [https://files.jelloraptor.com/s/oiM2z3Wq94ijjwt even-z-levels], [https://files.jelloraptor.com/s/XMLzyFTq4Ca9La9 odd-z-levels], [https://files.jelloraptor.com/s/gQyk8peJZrgzRQy gimp-source]. Could someone please upload them as appropriate and add them to the pump stack page? Thanks. Also I certify that these are all my creation and that DF-wiki can use them as it wishes. {{unsigned|Jello Raptor}}
** Uploaded [[:File:Gimp-z-levels-even.gif|even]] and [[:File:Gimp-z-levels-odd.gif|odd]]. Feel free to add them where you see fit. [[User:OddballJoe|OddballJoe]] ([[User talk:OddballJoe|talk]]) 01:54, 28 January 2023 (UTC)

* Could there please be a smaller version of the "D for Dwarf" template, maybe one that leaves the text ''joke'' near a sentence, so that we don't have a big-ass banner for little one-off jokes in articles and reserve the "D for Dwarf" template for entire sections or articles? [[Special:Contributions/68.56.148.200|68.56.148.200]] 23:15, 6 December 2021 (UTC)

* Can someone include a discussion about how dwarfs choose which jobs/tasks to do if they have enabled multiple labors and there are jobs in multiple labors on the DF2012:Labor page? Is it based on which job is created first? Their skills / traits / attributes? Which labor they are highest ranked or their titled profession? This seems to be an issue in the LPs I've been watching early on when there are only the 7 starting dwarves, sometimes extending into the first migration. I know a solution is to deactivate other labors, or use burrows, but I'm still curious how it works. Thank you, [[Special:Contributions/108.243.77.185|108.243.77.185]] 03:08, 17 August 2013 (UTC)

* Hello. I wanted to know how to make the tiles uniform for the ground. I'm sure to have read somewhere once that it was possible to change the tiles to be all "." (I am currently searching for a Goblin Snatcher for a while now ^^). I searched for "ground" what has yielded me a link to above ground page. There was no link there. Could make one to the relevant article or indicate the settings to do please? [[Special:Contributions/31.164.176.33|31.164.176.33]] 20:04, 23 September 2013 (UTC)
** Done: [[Ground]]. --[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 21:57, 23 September 2013 (UTC)

* Hi, im new and just want to start translation of the wiki into german. im really into this game and i guess i still could learn a shitload of new stuff by doing this. AND there would maybe be more players around if and when i/we translate. not every german is fluent in english. -f4nt4sy [[User:F4nt4sy|F4nt4sy]] ([[User talk:F4nt4sy|talk]]) 15:01, 1 March 2014 (UTC)
:See [[DF:Centralized Discussion/Translating the wiki|here]]. It's been suggested before, but it's been hard to set something up on this wiki. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 03:22, 2 March 2014 (UTC)

* I'd like to create a page under the centralized discussion for a proposal of subnamespaces for stuff like creatures, skills, etc. under a specific version. Stuff like DF2014:Rat becoming DF2014:Creatures:Rat. I'm not sure if the software allows this, but I thought I'd say it anyway.

* I'd like to add an image of the 'animated bedroom design' section I added to bedroom design. I uploaded a short screen cast here [https://imgur.com/XIGR8Ce], but to get it to below the 2 MB limit I also converted it to a GIF here [https://imgur.com/x86h2u4]. I feel like just adding an imgur link has to be frowned upon so I didn't want to just link to it in the article. [[User:Austin|Austin]] ([[User talk:Austin|talk]]) 05:43, 3 January 2023 (UTC)

*I'd like to add 2 pictures to the water reactor page (lower level and main level), showing how to build this in the Steam DF version. Since its the first edits, I can't get it to upload without request. [[User:Thurlin05|Thurlin05]] ([[User talk:Thurlin05|talk]]) 18:26, 13 January 2023 (UTC) Thurlin05