Parts show up as Chapters when compiled

I’m having trouble getting Part titles to behave as they’re supposed to when compiling. I’m compiling as a Novel With Parts and am following the procedure exactly as laid down in the “Novel Format” text document at the head of the binder, i.e. renaming the Part and Chapter folders as they appear in the binder and adding others in the same way. However, when I compile, no differentiation is made - they all appear as Chapters. So the first Part appears as Chapter One with the renamed name below it, then the first chapter appears as Chapter Two (plus name), and so on. Not a part in sight.

I’m doing nothing at all in the Compile window apart from choosing Novel and Microsoft Word 97-2004.

It sounds as though your folder hierarchy isn’t set as the compiler expects. If you click the disclosure button to the right of the “format as” dropdown menu in the Compile window, you should see a pane that includes the content of your manuscript. First check that the dropdown there at the top says “Manuscript” (or whatever you have renamed that folder in the binder) and then ensure that your parts, chapters, and scene documents look indented like this:
folder hierarchy.png
The “Part” folders, whatever you’ve titled them, should be the first level (lined up along the left edge of the pane), with “chapter” folders indented slightly. The compiler adds the proper prefix (part or title) according to the level the folder sits at, and it sounds like your part folders are coming at the second level instead of the first.

If that’s the problem, then either the selection being compiled may have been changed or your binder structure may have gotten altered at some point from the template, so we can take a look at that. You want all the Part folders to be at the first level under the Manuscript folder, and Chapter folders to be a level below that.

Does that help?

'Fraid not. The hierarchy is exactly as it should be. To test again, I’ve just created a new Scrivener Novel in Parts project from the template and simply altered the Part, Chapter and Scene names in the binder. All I did was to add numbers to the titles as they exist in the template. I made no other alterations and added no textual content. The result is the same: Parts are not recognised.

I attach the two documents so you can see what is happening.
Compile Test.doc (2.87 KB)
Compile Test.scriv.zip (205 KB)

Presumably you’ve selected “Novel (Standard Manuscript Format)” from the presets at some point, or otherwise changed the compile settings. Your compile settings are set up to use the normal novel compile, not the “Novel (with Parts)” compile settings. If you create another project from the “Novel (with Parts)” template and compare the settings in the “Formatting” pane of the Compile sheet you’ll see what I mean - you have changed the settings so that they are no longer set up to use parts.

You can click on “Save…” in the Compile sheet in the new test project you create from the “Novel (with Parts)” project to save a “Novel (with Parts)” compile preset, and then load that in your existing project to restore the settings you want.

Ah, I see. I was choosing Standard Manuscript Format from the Format As menu in the Compile pane, as Custom came up by default and didn’t seem right. If I leave it as Custom, however, everything is fine.

Maybe it’s just me, but I wonder if there isn’t a problem with the options in this menu. Custom comes up as default, but seems misleading as it implies you want to tweak the settings, when this is precisely what you don’t want to do if you want to follow the template format. But none of the other alternatives fit as they all change the template settings. Would it possible to add a default setting - something like “Template settings,” perhaps - in order to make clear what is happening?

No, it’s fine. If you change any settings, it becomes “Custom”. The others are presets. Some project templates have custom compile settings - it wouldn’t make sense to have a preset for every template, otherwise you’d be bogged down with presets you don’t need except for particular templates. (And once you have created a project from a template, it’s just a regular project and Scrivener doesn’t know it was made from a template, so “Template Settings” would make no sense - “Custom” is much more accurate and informative.)

Fair enough. I see the logic. The problem is that it depends on you grasping what Custom means in this context, i.e. that it refers to either the already customised template settings or your own tweaks, depending on what you choose. Normally Custom as a menu choice implies the latter, not choosing something that is already customised by the app itself and so for the user is in fact a preset, though in this case one specific to the template. That’s what threw me. But I see the difficulty about bogging down the menu. Maybe it needs spelling out clearly in the manual exactly what this menu item is offering, as at the moment it’s a tad counterintuitive at first sight. (The manual mentions in general terms that the templates are pre-formatted, but not what it means when Custom pops up as the default Format option when you come to compile.)

Great holidays to you all!

Strictly speaking of normal, for a menu that selects presets (collections of settings to speed up the use of a more complicated set of instructions), changing any of the instructions within the realm of the preset very often do end up renaming the menu item to Custom to help indicate that the instructions no longer reflect the stated preset. What some will do is keep track of the original preset and place it in parenthesis, but that aside most of them revert to saying “Custom” or something of that nature. For menus that supply simple single-ended presets, having a “Custom” choice at the end does more often imply greater control being provided if you select it, but then this would have three dots after it, indicating the menu command will lead to further requests of action from you.

You do have a good point on modifying the wording a bit in the manual. The template section was written long prior to any built-in templates existing, and so does not fully address everything they ended up being. The frequent reliance upon custom compile settings is certainly worthy of note in their usage section.

Scrivener 2.0 did this is an early beta (as you may recall, Ioa). But I got rid of it as it seemed silly, given that if you took a preset and completely changed it, the name had no meaning at all - and Scrivener has no idea at what point the preset has changed enough to stop having any relation to the original (Theseus’ ship and all that…?).

Anyway - Christmas Eve! You should be on holiday, Ioa, so shoo - and so should I!

Merry Christmas!

All the best,
Keith

Yeah, exactly, and while it is a nice idea in theory I do agree that in this case it isn’t terribly useful—especially not in templates which is why you ultimately decided to take it out if I remember correctly. It just looked weird with Custom (Novel) in a screenwriting template, and no way to get rid of it without contortions. I think this mechanic works better in applications where the set of options the preset governs are fairly static in what they perform. Some image resizing options in Lightroom, for example, where a preset might hold such information as resolution and how much meta-data to export in the photograph. With the compiler, a few tweaks can make it go from a outliner generator to an ebook generator.

Yeah okay, I’m not here again. :slight_smile: