Resetting Chapter numbers

I’m trying to generate a novel with parts. I’d like to have the chapter numbers restart from 1 in each part. I know about the <$rst> tag, but it only works if it’s immediately followed by the <$n> tag. As such, I can’t see any way to use it without immediately using up chapter 1.

So my question is, how would you reset chapter numbers such that you can have multiple parts to a novel, each or which has its own chapter numbering, starting with chapter 1? And to clarify, the sample template that comes with Scrivener does NOT do this.

I have a novel with parts I’m working on, and basically all I did to accomplish this was to create a chapter folder for each new chapter one and put the text ‘Chapter <$rst><$t>’ in each seperate first chapter folder (except the initial first chapter). Then selected “As-IS” from the Contents menu in the compile settings. Since you’re using the <$n> tag you would use ‘<$rst><$n>’ in its place.

You can also do this by adjusting your binder structure so that the first scene of each chapter is at a different level or document type than the other compiling documents, so it can be formatted uniquely. For instance, either of these binder structures lets you format the initial scene of the chapter separately, so you can give it the prefix “<$rst><$n>” and the other scenes in the chapter simply “<$n>”.
Restart Structure.png
In the first chapter example, you make the first scene a document group by placing the other scenes as its subdocuments. All the text formatting for the document group row and the single document row in compile should be the same; just the title prefixes will change, with the restart code in the document group prefix.

In the second example, you convert the first scene to a folder. It’s at level 2, whereas the chapter folders are level 1, so by clicking the “+” button in compile formatting, you can create a new “Level 2+” folder row and format it differently. Thus you give the Level 1 row the chapter prefix and whatever else, and then have the Level 2+ row compile the folder text, formatting that the same as the single documents to match your other scenes, and then give it the restart numbering prefix.

It took me few re-reads to get what you are saying. It sounds like the idea is that the first chapter of a Part is done at a different level than the rest of the chapters so that it can receive a different formatting in the compile dialog. That sounds like it should work. Thanks.

Right, either at a different level or using a different document type, e.g. make it a folder containing text rather than a regular document containing text. (Folders load by default in a group view mode, but if you toggle that off by clicking the orange-highlighted button in the view mode trio in the main toolbar, the editor will switch to show just the folder’s text.) As long as it is distinct from the other items you’re compiling–the parts folders and your other chapters/scenes–either by level or type, you can apply unique rules to it during compile.

I’ve also put in a request to have <$rst> able to work on its own. That would make it possible to just put it in the Part folder formatting. Much cleaner. One can only hope…

Yes, there’s a plan for a modified version of the tag that would work that way.

Well, this is very odd. This technique works fine for the actual chapter titles in the body of the book. However, in the TOC, I get this:

Toba, Sumatra - 74,000 BCE
Part 1 - Be Careful What You Wish For
CHAPTER <$n> -1 Plan
CHAPTER 2 - Discussing Toba
CHAPTER 3 - Toba, Sumatra - 74,000 BCE

The third line should say “CHAPTER 1 - The Plan”. And that’s exactly what it says at the top of the chapter. The second part of the novel has exactly the same problem. Unless there’s some subtle TOC-formatting option that I don’t know about, I think this must be a bug.

Anywhere in particular I should be posting this?

Normally in the Bug Hunt forum, but there’s no need in this case. Apparently the <$rst> tag is breaking the number generation for the ebook. I’ll file the bug report. Meanwhile, you can correct this easily in an epub editor like Sigil after compile.

I was going to suggest that you use the replacements tab in the compile window: Replace “<$n>” with nothing… however, it looks like there’s a bug in the Windows version that drops the line in the replacements tab if you don’t fill the “With” field with something. I substituted a space, and it worked, and seems to happen after the substitution value is replaced with a number (or a word like ONE, for instance), so in theory this would eliminate left-over substitution variables. However, having to input some kind of character complicates the matter.

If you have no use for multiple spaces in your output, you could follow the replacement of <$n> with a space by adding a line that replaced two spaces with just one space… :confused:

Edit: or if you have a space after the <$n> everywhere it appears in your compiled output, you could input "<$n> " (note the space after the closing “>”) into the replacement field and just replace with a single space.

The problem though is that the <$rst> tag is preventing the immediately following <$n> placeholder from compiling as the correct number, so it’s not an extraneous tag that needs to be cleared but rather one that needs to be replaced with the proper numeral. Replacing <$n> with 1 doesn’t work, however, because the compile replacements happen before the numbering tags are–er, replaced–so this would prevent the other instances of <$n> from compiling correctly.

Are you sure about this? My reading of Angry_Guy’s issue is that <$rst><$n> is both resetting and adding in the numeral “1”, but the <$n> part isn’t being removed afterward. Furthermore, my understanding of the Replacements section of compile is that it works on the text after the placeholder tags have been replaced. So it seems to me that if Angry_Guy meant to show the ToC as “CHAPTER <$n>1 - Plan”, then replacing “<$n>1” with “1” would work.

Yes, I tested this for filing the report. The <$rst><$n> code is working within the document text, correctly replaced with “1” without leaving a placeholder tag around. But in the auto-generated table of contents in ebooks, the <$rst> breaks the <$n> after it so there the numbering doesn’t come up, just the un-replaced <$n> tag in that first instance. The rest of the numbering for the section is correct.

I’d have to check on specifics for the replacements, because there is an order in which tags are replaced and I’m not definite on what happens when. In this case, though, the compile replacements would happen before the <$n> tag is replaced with the auto-numbers, so everything would just come out as “1”. You can try it if you like. :wink:

I bow to your superior research skills. I had tested this myself, but obviously I didn’t formulate my test very well. I guess that’s why they pay you the big bucks, eh?

Edit: In a effort to salvage some usefulness out of my postings, did you note that trying to leave the “With” field blank will result in Scrivener dropping the entry in the Replacements window? :blush:

Yep, here on my private island I’m just looking down my nose at you while sipping my morning mimosa… :wink: I did double check the suggestion you made, because using replacements for this was very clever and I was trying to find a way to make it work, but because of the ordering and because it’s only partially broken, nothing you can do there will be a wholly working solution. So the easiest thing still I think is to just correct the text in Sigil after compiling. The link still works, it’s just the title appearing incorrectly, so a simple WYSIWYG edit there.

And yes, the blank replacements problem is on the bug list.