GUIDE · MEASURING
How to Take Measurements in Dressmaker
Record the values a request actually asks for before you cut anything.
Quick answer
A commission states the values that matter for that delivery, so the request decides what to measure. Record each value the request names next to the attribute it belongs to before cutting anything, keep the request values and the garment values apart, and re-read both immediately before delivery. The comparison should be made from the note, not from memory.
Which values a commission states, and the order to record them
A request names the garment and the attribute expectations attached to it, usually as a minimum, a maximum, or both for each attribute. Those expectations decide whether the delivery succeeds, and they can differ from one request to the next. A general table of important measurements would therefore be misleading: the request in front of the player is the authority on which values matter for that job.
This page does not list attribute names, thresholds or body measurement values, because no dated source read for this site states them. What it describes is a recording method that works with whatever set the request names. The commissions guide covers the reading order that comes before this step.
The recording order below keeps each value attached to the attribute it belongs to, so nothing is carried across the page by memory.
- Read the request fully before taking any value. A value read before the whole request is understood can belong to the wrong attribute.
- Start one dated note for the delivery. The date goes at the top, because a value without it cannot be compared with a value from a later patch.
- Write each attribute the request names as its own line, in the order the request shows them.
- Beside each attribute, write the stated minimum, the stated maximum, or both. Where a bound is not shown, write not stated rather than leaving the line blank.
- Note the garment and the pattern the values apply to, so the note cannot be confused with a later attempt on a similar request.
- Add the values the garment reports as it is assembled, in a second column beside the request values. The sewing workflow shows where those pauses fall.
- Re-read the request before delivery and compare it with the note line by line. This is the step the whole sheet exists for.
Worksheet: what to write and when to re-check
The worksheet below is the shape of a delivery note. It contains labels and instructions only. Every value written into it is read from the player’s own screen, and a value the request does not show is recorded as not stated rather than filled in.
| Label | Where it is read | What to write | When to re-check |
|---|---|---|---|
| Request date | The request | The date the request was read | Before delivery, to confirm it is the same request |
| Garment asked for | The request | The garment as it is described there | Before choosing a pattern |
| Attribute names | The request | Each name on its own line, in the order shown | Before delivery, in case a line was missed |
| Stated minimum | The request | The value, or the words not stated | Before delivery |
| Stated maximum | The request | The value, or the words not stated | Before delivery |
| Pattern and materials | The selection steps | What was chosen, and what it cost | After a failure, to identify the variable to change |
| Values reported while sewing | The garment view during assembly | The value, with the stage it appeared at | At each stage, not only at the end |
| Final values | The finished garment | The value for each recorded attribute | Immediately before delivery |
| Delivery result | The outcome of the delivery | Pass or fail, with the date | When the next attempt is planned |
Nothing in the worksheet is a game value. The fabric database shows which fields a material record needs before it can be published, and the same discipline applies to a delivery note: an empty line is more honest than a likely answer.
Re-checking before delivery
The re-check is a comparison of two columns, not a decision made from memory. Read the request column from top to bottom, read the finished garment’s values in the same order, and mark each line as inside or outside its recorded bound. A line marked not stated is not compared, because there is nothing in the request to compare it with.
If a value sits exactly on a bound, the note should say so plainly rather than rounding it towards success. Whether the game treats a boundary as inside or outside is not published here, and a session note is more useful when it records that uncertainty instead of resolving it by assumption.
The check has to be repeated after any change. Adding a finishing detail or swapping a material after the first comparison makes that comparison stale, and the values have to be read again. The pattern-cutting guide and the beginner guide both assume the note is re-read at that point rather than trusted.
General garment-sewing practice that transfers
As in real garment sewing, measuring twice and cutting once is the cheap habit. In a game the cost of a wrong value is usually materials and time rather than cloth, but the principle holds: a value confirmed before the cut is cheaper than a garment corrected afterwards.
As in real garment sewing, one reference sheet beats several scraps. A single note holding the request, the chosen materials and the reported values can be read in one pass at delivery time, while three notes taken at different stages cannot be compared without hunting through them.
As in real garment sewing, memory is not a measurement. A value recalled from an earlier session is an estimate, and an estimate cannot be honestly compared with a request. Writing the value down at the moment it is read is what makes the later comparison worth anything.
None of that describes how Dressmaker computes anything. It describes habits borrowed from ordinary sewing practice that make the game’s own output easier to read and easier to check.
Common mistakes
Reading the request after choosing materials is the most expensive mistake, because the choice has already been narrowed by guesswork. Copying a value from a community list instead of the request is the second: a value in a write-up belongs to that writer’s session and patch, not to the request in hand.
Treating a missing bound as zero, or as unlimited, is the third. Both readings invent a limit the request did not state, and either can turn a passing garment into a recorded failure. Mixing request values and garment values in one column is the fourth, because it makes the final comparison a memory exercise again.
Re-checking only the strictest attribute and assuming the others will follow is the fifth. The other lines were recorded for a reason, and the check is only as good as its weakest line. The sixth is writing a value down without the date, which quietly removes it from any later comparison.
What stays unknown
This page does not publish attribute names, minimums, maximums, body measurement values, quality thresholds, or the units the game displays. No dated source read for this site states them, and the page will not estimate them.
Open questions include whether the same attribute set appears on every request, whether a stated bound is inclusive, how a value is rounded when it is displayed, and whether a recorded value can change after delivery. Each of those is settled by reading the screen and writing down what it says, then repeating the check, rather than by choosing the most likely answer.
Where a value is needed, the instruction is unchanged: read it from the request or the garment, write it down with the date, and keep it on the same sheet as the rest of the delivery. The commission checker compares values that have been recorded that way; it cannot supply one that has not.
Frequently asked questions
Which measurements does a Dressmaker commission ask for?
Whichever ones the request in front of you names. A request carries attribute expectations with a minimum, a maximum, or both, and those are the values the delivery is judged against. This page does not publish a fixed list, because no dated source read here states one.
How should I record them?
One sheet per delivery, dated at the top, with each attribute the request names on its own line. Write the stated minimum or maximum beside it, and write not stated when a bound is missing. Keep the request values and the garment values in separate columns so the final comparison is mechanical.
When should I re-check the values?
Immediately before delivery, and again after any change to the garment. Read the request column top to bottom, read the finished values in the same order, and mark each line as inside or outside its recorded bound. An earlier check becomes stale as soon as a material or a detail changes.
Does real sewing advice apply to Dressmaker?
Only as general practice, never as a confirmed game mechanic. Measuring twice, keeping one reference sheet, and refusing to trust memory are habits that transfer from ordinary garment sewing and make the game’s own output easier to read. They are not claims about how the game computes anything.