Thanks for the reply!
I’m really using only one project (the same project) when I run into these two issues on Scrivener 3 for Windows. When I use the same project and import it into Scrivener 3 for Mac, it compiles perfectly without my needing to make any changes to the configuration in the compile…
Last night, I sent a response post to the most recent questions asked of my project with an attachment of a new error message, but it isn’t here now. Did it get deleted or am I missing something?
The essence of the message was that I am thinking that my issues with the asterisks and other error message has to do with having Scrivener 1.9 for Windows and Scrivener 3 for Windows (Beta) installed on the same PC. One seemed to interfere with the other at some level. After uninstalling them and reinstalling them several times in different directories, I no longer seem to have the issue with the asterisks. With that said, I will test it further and let you know if the problem reappears.
Hi all - Thank you for the info and the project sample. I’m happy to say I believe I’ve tracked down the bug causing the asterisks, and it should be a relatively easy fix until we have a new beta with the compile engine fixed. It looks like the text layout option to replace empty lines falling across page breaks is rather replacing all empty lines, and it is affecting all file formats. To fix this, you can edit the format by double-clicking it in the compile format list (choose Duplicate & Edit if you’re trying to change one of the built-in options) and choose PDF at the top of the list. Select “Text Layout” on the left, then deselect the “Empty Lines Across Page Breaks” box.
Please let me know if this resolves the asterisk issue for you.
Hi Jennifer,
Thanks for this.
For some reason, I can’t reproduce the issue anymore on either on my installs, but I can confirm that your “fix” isn’t likely to work at least here, because that option wasn’t enabled on either of my installs. Did it show as enabled in any of the compile formats files I sent you?
Also this bug happened suddenly with beta 22, And disappeared just as suddenly, for an unknown reason. I have never changed that option, on any of the installs.
Mimetic,
I am getting the same issue, randomly, in *.docx compiles on a custom template (copied and modified from the “Non-fiction Manuscript (Times)” default template), opened ONLY to compile with no modifications it replaced EVERY blank line with ***. First time it happened was Tuesday with beta 22. And of course it was the draft I had to quickly send to my boss. 
Manni - That’s odd (not to say disappointing…that the fix wouldn’t have fixed it for you, not that everything’s started working!). The VM version of the compile format you sent had that option enabled, and disabling it removed the asterisks, producing the PDF I attached in my email. In further testing with that setting on new projects and new compile formats, I was able to reliably trigger–and remove–the issue, hence thinking (wistfully, I suppose!) that I’d nailed it. 
dyany - Would you be willing to zip the project producing the asterisks and send it to win3beta@literatureandlatte.com with a link to this thread so I could take a look at it and the compile settings? (If the compile format you’re using is not saved as a project format, please use the gear button at the bottom of the compile dialog to export the format to a file that you can also zip and send.) Creating a copy of the project via Save As and trimming it down would be fine as long as it’s still producing the unwanted asterisks on empty lines.
I’ll continue poking it and see what else I can come up with. Manni, if you start seeing the issue again, please let us know! This is proving increasingly mysterious…!
Hi Jennifer,
Just to clarify, if I check that box in the text layout, it does bring back the ***, but the thing is that the box wasn’t enabled on either of my installs when I checked. So there might be something entirely random (or linked to something else) that enables/disables that box. What you should rule out is that this happens because the user changes the status of that box. I have never changed the content of that box in my compile files, ever. I also never had this issue before beta 22.
The way I had found to fix this was to re-import my original compile file, as exported from the Mac. I had done that on the bootcamp install, and it did fix the problem. I’m glad I didn’t do it on the VM before exporting the compile formats file, because at least that allowed us to narrow it down to one option.
All I’m saying is that your workaround works, but it’s not a fix because something in the background is changing this option behind the user’s back, in either direction (check or uncheck). So I would look at any process (for example whenever the compile format file is saved/open) that could have that effect due to a bug in beta 22. Has anything changed in the compile format saving/reading process in beta 22?
Finally, while checking that box brings the *** back, it doesn’t bring the skipped new page issue that I also used to experience with that build (out of the blue with beta 22) and that doesn’t happen anymore, irrespective of the box status.
Jennifer, I will get to it as soon as I can today. Sorry I’ve just been so busy! (Though my soul weeps for you code-fire-fighters level of busy)
Not sure if there is still any doubt about this issue’s existence in [beta 22], but I can confirm that these pesky “* * *” separators keep popping up (seemingly) randomly in my compiled DOCX files.
Not sure about [beta 21] but this never happened in [beta 20] or earlier, which seems reasonable, as the compiler didn’t seem to change at all back then.
I don’t know if this is happening anymore for anyone else, but I have done a few compiles with beta 24 and now 25, and it seems to be gone. Thanks!
Now if we could only get the <$img> placeholder to work… 