Apple doesn't make it easy.

If you're signing in on a new mobile device, you have to activate it first. This is entirely between you and Apple, we don't hear about it or know about it. Use a Pro feature -> I Already Own It -> Restore (not Sign In). This activates the mobile app via the App Store. THEN sign in to it using your HCW account, and your mobile purchase is discovered by us.

Hi, Yes, it's terribly confusing. Apple tries to trick people into believing that mobile/desktop apps are the same, but they're not. As a desktop app, the mobile Shot Designer is quite constrained. You have to (a) create an account on the HCW website, and (b) get activated in the mobile app, then (c) sign in to the mobile app. That's the first time we hear about the purchase, and we copy the license over to your account. Now you can activate via your HCW account on all other platforms, as well as sync.

I appreciate it! I wish we could do everything faster. Your request is very common. But it's imperative that we make sync/collaboration work perfectly, with high quality engineering that never fails.

Hi, This is everyone's #2 feature request. #1 is sync/collaboration, and that's where all the energy is going right now. Mobile apps also aren't great without a smooth way to shuttle the data around. The app itself is written in a cross-platform framework from the ground up, so the code will compile as-is on mobile. The biggest change is retooling the UI for mobile. There are some kinks, for example that we've used mouse areas for a lot of things instead of touch areas, and all of that needs to be rewritten. The mobile UI will basically be a full desktop UI, with each area taking up a full screen. And then there are some "wormholes" for easily going between screens. It's basically like if you had each area in a separate full screen window and switched between them. This UI will also be available on desktop. But even though we know every step and there are no mysteries in making the mobile app, we're a small team, and we have to properly focus on collaboration. Emotion tracking and several other crucial features will likely also go ahead of mobile. So it's not immediately around the corner. I wish it was. A proper status system is also coming. Is it possible this is what you wanted to do with Emojis?

Hi, We've avoided having scene numbers in the scene at all. We can discuss the wisdom of that original choice, but that's how the app operates. People put scene numbers into the name of the scene, e.g. "38B Gas Station Scene". The shots themselves inside the scene are A-B-C or 1-2-3. It's only that the scene number is redundant when you're working within the scene. Then it's more about shots and versions. Part of the resistance to having the scene number inside the file is that sync operates on whole scenes. This is easy to do, and the reason everyone has free sync without any subscription. But it means that if you wanted to change the number of scene, you'd have to both change the filename and the data inside the scene. And since it's common to start one scene based on another, the inner data in the scene will never get corrected, and will need a ton of babysitting, and will always be out of sync, resulting in unreliable information for the majority of the user base. The 3D version we're working on is database driven, and things like scene numbers are kept outside the scene. Then we're freer to suddenly change the scene number, and we're also freer to make numbering systems that bake the scene number into the shot number. It's just that if it isn't automatic, it'll implode. There's no "freestyle" numbering method in the app. All scene numbering is internally integers. This is so we keep the ability to reason about scene numbers, i.e. sort, filter, export.

Hi, You can toggle any fields in the label: But turning off the shot number makes you incredibly non-standard, and you're also ditching all the features that work with shot numbering, like sorting and exporting data. It will likely cause confusion for anyone else on the set who's used to more standard numbering, and can look unprofessional. Instead, there are a number of numbering systems you can select in the Shot List menu.

So you're trying to make a shot list without shot numbers? That's definitely unexpected. It's incredibly fundamental to blocking and shot lists that shots have numbers. There's lots different use-cases for what numbering system to use. But basically, a shot list without numbers cannot be worked with on the set. Nobody does this, and I'd strongly discourage it.

I don't fully understand, since Camera number and Camera nickname are two different fields. Could you clarify?

It's exactly this kind of stuff Frame For Action is trying to automate during export, because I think that any manual way would be a lot of babysitting. The app should be able to guess what is relevant, and then fade things out around it. That said Frame For Action kind of sucks for auto-framing the page, but it does a better job of only showing the part of a walk that's relevant. Could you post your example of how this goes wrong in your case?

Hi, Yes, this is coming, along with multiple images per shot. But it requires a document version update, so we didn't want to mix it with the large internal changes in 1.70.

Hi, Yes, this list will converted to a field you can edit. It's ultimately naive to make a list of shot types, because it could never be satisfying.

Hi, That's pretty much the idea. It's a little logic tree. You create a Happiness < 20 and wire it into some important event that requires that. It's modeled after these learn-to-code things for kids, for example the Disney/Facebook one where you click these puzzles pieces together. They're even called puzzle pieces in the code. That is actually what the whiteboard was in the beginning, but everybody expected it to the a whiteboard, i.e. 100% time-based left to right, so we had to align the app with the universal intuition. But it means that we lost this kick-ass way to model the logic of the story. We now already have all of this in the code, exactly because we knew it would come back, and what's holding it back is more pedestrian, that we need a new selection model in the app, because it's buckling and can't handle adding more areas. Shot Designer already has this new selection model, and it's not difficult, but it means rewiring a lot of existing code for it, and it will take time and crashes to do. Basically anything new that need a selection state is on hold for this.

We're highly limited in text display in the current (old) branch of Shot Designer, because we're relying on a PDF library that hasn't been updated in quite a while, and is abandoned by its creator. The only thing we could do is simply have an option to enable right-to-left text, and then all text is printed right to left, without actually looking at the text, just a global preference. That would at least allow you to output it. I do believe we have the option of switching the text to right-to-left, I just don't know if we can make it automatic in the existing branch.

Sorry for the late reply. Google business suddenly started marking forum notifications as spam, so I never saw it. I'm wondering if the best workflow wouldn't simply be that you write the topic as the beat title, and then write the full action in the "snippet" (we don't call it that anymore, just "beats", so write the full action in the beat in the script). There's no longer any separation between the beat in the whiteboard and the beat in the script. So I'm not 100% clear why you'd prefer a special workflow. Am I understanding your problem correctly?

It's a pity we don't yet have a feature that's coming in the next year, which is the ability to have multiple expressions of the same script side by side, e.g. a screenplay version next to a novel version. I don't think you should be doing a workflow of building a novel in a separate lane. Presumably, the story is the same, with just some beats added or disabled. So you should work with the beats as they are, and simply change the text to novel. Now, about the text formatting itself, we're in a weird middle state where documents have a "type", either a screenplay or a novel. As I said, in the future, these will just be separate documents shown side by side. Screenplays will have screenplay formatting, and novels will have novel formatting. But for now, the entire document is *either* a screenplay or a novel, so you won't be able to gradually transition to novel. And you can't even change the mode, because we were expecting this side by side feature to roll out sooner, so there aren't facilities in the app to convert between document types. It's something we can do for you, or instruct you how to do. It's a major omission, and not pretty. So I'd suggest that you stay in a screenplay format for a while, and write all your work as action lines. You can also go into paragraph styles and change the style for action lines so they look like novels, e.g. Times New Roman, first line indent, no space after paragraph. That way, you can transition the text to something that looks and feels like a novel, while actually still being a screenplay.

Hi, The free version is unlimited terms of research and whiteboard, and the main limit is the size of the final script, around 10 pages. That allows unlimited outlining, and the pro version kicks in when actual writing has reached a certain size.

Hi, I've seen this before submitted by a few users, but I've never seen it in person, and I don't know what to make of it. I thought it might be about how async image loading isn't fast enough so the pages are rendered before the images are loaded, but it's all well behaved. I can't provoke this to happen in any test. Would you be able to send some of your scenes? If you feel like you have consistnt behavior on some scenes, please send a zip of maybe 5 or 10 scenes to support@hollywoodcamerawork.com, so we can try to do a batch export on your exact scenes. It might be tied to the images themselves, e.g. their format, which might cause unexpected timing in the app. I doubt it, but it's my only lead. I'd love to see it happen here. Also, which device does this happen on for you? Does it happen on other devices with stronger/weaker CPU? I guess I'm just stuck on us somehow having a bug around async image decoding, which could be hidden by working on fast devices.

Hi, It's not, it's worldwide. There are only two standard formats for screenplays, FDX and Fountain. Word is non-standard in the extreme, and will make you look terribly unprofessional. And you'd have to convert it back to FDX for anyone in the whole world to use it. For books, a Word file is standard. But for screenplays, you should abandon this idea, it's very incorrect.

Just being completely honest, this is a horrible workflow. Word is not competent for handling screenplay formatting. Whether it comes from Final Draft or Causality, you're taking a sledgehammer to the formatting. All core screenplay concepts such as the critical page-count, highly conditional line and page breaking, mores, cont'ds, all of that is gone or unmaintained, and at least for an English speaking screenplay, it would render it deeply unprofessionally looking. Delivering a screenplay as a Word file would make you look quite bad as a writer. Incidentally, the current HTML export does output to Word with some formatting. But this is, in my view, not a serious workflow, and I would try to talk you out of it in the strongest possible terms.