Just tap any number and insert steps before/after.

Thanks for posting! That's strange that we somehow omitted that. There's no technical obstacle to having this whatsoever. I've put it on the list.

Great! It's one of these two solutions for your exact problem.

Again, did you start the app and quit it again and did this folder show up? And please don't navigate manually to any folders, only use the Go To Folder command in Finder.

Please run the app and quit it. If us.hollywoodcamerawork.shotdesigner doesn't show up, you're definitely in the wrong folder.

Did you do this part from the instructions? Go to Finder -> Go menu -> Go To Folder -> ~/Library/Application Support/

Make sure these are the instructions you've followed: https://www.forum.hollywoodcamerawork.com/forum/shot-designer/saving-issues-on-desktop

I'm not certain what "no, i work only with macbook" means in this context.

Hi, I'm sorry for your troubles. The app saves every 3 seconds when there are changes, so if you're losing 2-3 minutes, that's something else. Are you working on multiple devices at the same time and the apps are both saving changes to the same file? On the crash, it's most likely that you haven't followed the steps completely, because this is the resolution. There are a couple of causes, one of which that the operating system on 1 out of 1000 computers suddenly thinks that we need express permissions to access our own folders, and locks us out. Sometimes the user is presented with a dialog, sometimes not, and sometimes they ignore it. It's necessary to recreate the folders in order to reset the permissions. There's a visible folder in Documents / Shot Designer Scenes, and there's an invisible folder in Application Support. But if you don't follow the exact instructions to get to your Library folder that it's in, and you manually navigate, you go to the wrong Library folder (there are multiple, all called Library, which is very user friendly). So I would suggest that you take the steps again. Also consider that auto sync runs in the background, so sync might happen even if you haven't expressly started it. Disable auto sync until you're done. This will also let you verify that this is caused by sync by triggering it manually. There are additional causes, for example BitDefender, which for some people blocks access to our own folders, including for writing, but doesn't tell us about it and pretends to write the file, while the file actually goes poof and disappears. So let's try to narrow down which problem you're having. All of this will be ancient history. The 3D version of Shot Designer, which is coming along nicely, uses a completely different distributed document model, which is real-time across any number of devices and users and cannot conflict. The whole sync thing will be infinitely smoother in the future.

Hi, Great! Quick notes: I think that anchoring a tag to text will be doable. This will be how comments will work in collaboration as well. The comment is in actual reality attached to the beat, but it'll refer to specific text. The trouble is the life cycle, because text is fluid, and it's very difficult to maintain identity for specific text as it's copy/pasted/edited/replaced/duplicated. So things will anchor to text in a best-effort kind of way, but if the text deteriorates too much, we'll stop attempting to refer to specific text. We may look into a toolbar, but we're very conservative about real estate, because once we crowd the real estate, lots of UI will stop working as a concept and then need new solutions. Truth be told, the primary reason we're looking at it is simply familiarity. We know that we're "weird" in terms of being a very different way to manage a story, and the presence of things that people already know allows them to get past the perceived unusualness. This is the kind of problem that goes away when everybody knows Causality. In the beginning, people had all kinds of questions about Shot Designer. All of that has gone away. Now we only answer two kinds of emails, activation, or a specific crash we're unable to make go away in the current iteration. Few people wonder how to use it. On tag colors, there has been some talk of multi-colored beats, i.e. a primary and a secondary color. Having drawn lots of prototypes for this, I don't believe in this idea. Basically, you can't highlight everything. Color must have immediate meaning, and everything else should be colorless or neutral. If everything is colored, then none of the coloring provides any meaning, you tune it out. Every prototype that tries to do multi-colored beats looks like confetti. It barely works in a still image, which guarantees that it won't work at real-use speed. But if we went in this direction, you could have an option that the first and second tags/characters color the beat. We're just driving dangerously close to the edge where color loses all meaning. On Undo, we don't do anything deliberately to flatten the undo stack, except when we really have to, which is rare, only a couple of special operations. I think you're seeing actions that break into two undo-steps. Try to press undo one more time. This is a regression we're tolerating until we can rewrite the functions that need this. On image support, this will all come with the distributed data model for sync. We can't direct-link to files, because that won't work if the document is cloud-connected, which you also need for just working on several of your own devices. A feature you'll also want is a feature planned for a long time where you can have multiple expressions side by side, i.e. a screenplay version and a book version. Or a comic book version and a plaintext scratchpad version, or write multiple language editions as the same time.

Hi, On tags on text, this isn't technically possible, and I'm also not sold that it's good. But technically, it's a massive and deep rewrite of the app that fundamentally changes hundreds of assumptions. It would also need a whole new kind of UI that shows tags inside the text, and the confusion would be endless about where a tag is, because now you can't know whether a tag is on a beat or somewhere inside of it. We need to stick to things happening at the object level. Getting rid of a lot of this kind of ambiguity for 3.0 is a huge success, and it re-teaches the lesson that ambiguity causes a lack of intuition about the state of the app, which slows you down overall and forces the app into countless contortions in order to display and react to ambiguous information. I'm happy to air the idea for the team, but this is with 99.99% probability not going to happen. On selecting beats in the timeline, that's strange that that doesn't already work. The intention is as much as possible that these are just different views on the same thing and it shouldn't matter where you make the selection. Does your app not scroll to the beat and highlight it? Is the running man icon in the bottom right disabled? Visual cues, yes, and we used to have more of that. The reality is that even with the inspector on the screen, your eye simply doesn't go over there. And it wouldn't be very disruptive to have icons with a popup menu to show additional information directly on a beat. The only real downside is that the hover you'd use to do this on desktop doesn't exist on mobile, so it's not a complete solution, i.e. only solving a problem by introducing a hover is not a true solution. So we'd need to answer how this works on a touch interface. On bullet lists, this was something we postponed for later. It's actually something that's native to the text editor, and we disabled it, because we need to answer how to encode it in our text format. But agree, for non-fiction, it's a very missing feature. I've moved it higher on the list. Truth be told, we're soon going into the cave to work on collaboration for a while, and we're ruthless about which features are allowed to get in front. I don't understand the text format being too clunky suggestion. Which dropdown? If this is about not having buttons for bold/italic/underline, consider that these are on the keyboard, and we're keen on not plastering the app with ribbons and panels. Where a word processor doesn't need the real estate, we desperately do, and the app as a whole is hurt by having too many panels that are rarely used. Our contention is that nobody is dying from not having panels, and power-users want to use the keyboard anyway. On tag color, we'd rather that if the tag is so important that it should color the beat, it's also not wrong to have it first. It's just that these kinds of suggestions are just adding new dimensions and micro-configuration, which turns around and becomes ambiguity. I don't agree that this needs a separate a new configuration dimension. Move the tag first. If it's important enough to color the beat, it's also important enough to be first. Interesting idea to have multiple versions side by side. I see the utility. Technically, it's quite a curveball, but I'll put it on the list. It was actually always intended that you could have two versions side by side in a Diff view to see what was changed. This would also be necessary for some conflict resolution in collaboration. So this problem will have to be solved. The dialogs are just hard-coded right now to make it difficult. It will need some thought. Are you submitting the crashes? Our crash volume is quite low. Please email the email address you've used on reports to support@hollywoodcamerawork.com. Are the crashes tied to anything, a specific action? Sometimes one single user has 80% of the crashes on a given version, because their intuition of the app or their specific document makes them take a specific route that crashes, and nobody else takes the exact same route. So it's quite possible we don't know about whatever issue you're having. And no crash has the dozens of crashes you seem the allude at (all our crashes are little corner cases with 1-2 incidents). So we'll need some help to understand this. Undo is back to the beginning of the session. There are some actions that have to flatten the undo stack because they cannot be undone. We have also allowed some actions to require two undo steps, which is an anomaly we're tolerating because we're getting rid of some code that was merging commits. Once the sync data model is operational, we can let multi-step actions be a single undo step again. This is in an area of some code that we're throwing out shortly, so we'd rather not invest weeks in it and then throw it out immediately after. Which auto-complete is that you can't get working? Character names? Scene headings? Specific fields? We don't have any awareness of any problems here, so we'll need some help to understand it. When you mention having to click parenthetical twice, where are you clicking? System menu? Toolbar? Right-click? Keyboard? On that note, most people simply use the automation, and typing "(", which switches them to a parenthetical line. It sounds like you're selecting styles a lot by clicking, which is quite unusual. Could you describe this workflow and why you're doing it this way?

Hi, That seems to be a bug that the filtered view doesn't respect the global setting for whether to show scene headings at all. I've added it to the next polish list. This is requested quite often, and we should do something. Could you make a list of which word counts are most useful? Please try to be as non-speculative as possible, i.e. list the ones that have historically helped you in other apps. This is just to not over-implement a feature beyond what is actually going to be used. Yes, we should have link parsing, both in beat text, synopsis and notes.

Hi, This is a known bug in the underlying cross-platform framework the app is built in. It's most likely just a bug in the exact version of the framework, but we're holding back on updating the framework, because it cuts off several older versions of Mac OS X, and we still have enough users on those old Mac OS X versions that we feel bad about killing Causality for them and forcing them to buy new computers. So it's basically a choice between tolerating a small-ish bug, versus kicking out 10%-15% of Mac users until they buy newer computers. It's not the only reason. The framework update requires a number of cross-cutting changes to Causality. So we're picking our time to go there, but it's soon. The bug appears to be how they handle a "flick", like you scroll on an iPad by moving your finger and suddenly letting go. The flick should start from where you let go, but the bug appears to start the flick from the original drag position. So it seems like a stupid bug that they've likely long since fixed. I think your magic mouse's scroll wheel is actually like a mini touchpad, so that's why you get flicking behavior. A mouse with an old-school scroll wheel doesn't send out flick events, it sends out regular scroll-wheel events, and those work fine.

@drunkpierro Hi, that's too unspecific to do anything with, though. I fully agree with abstract goals of working such things out, but I can't tell anything specific about what you do in other apps and what is missing in Causality.

Select Image Prop when adding a prop.

Here is the last 2.4.x version: https://releases.hollywoodcamerawork.com/cau/2.4.14-61cc394f/Causality%202.4.14%20Installer.exe To be clear, I think this is a killer feature as well. We were surprised at launch that this wasn't a widely held view. People just thought our whiteboard was weird. It wasn't a whiteboard at all, it was a pure dependency graph. Consider yourself ahead of the curve. I'm convinced that thinking in dependencies is the way you get a handle on a complex story before you've written it, and then having the app enforce the rules you've defined. So it's a very high priority to get this back in a proper way. The old way was baby steps, and incompatible with also being a whiteboard. I'm only being cognizant that this isn't (yet) central for most users, and then the needs of the many outweigh the needs of the few.

We won't delete previous tutorials, we'll only mark them as relating to a previous version. I'm happy to send a 2.x, although I would suggest to not be too blinded by one missing feature where overall 3.0 is a more powerful app, and practically bug free as well. What platform are you on?

I agree, it's super important, enough that the app is actually named after it. The problem was that it was always an ugly hack to have this in the whiteboard, and it was literally holding back everything else. 2.4 was basically a dead end without making the changes made in 3.0. Statistically speaking, the features gained in 3.0 are about 100 times more important to people than being able to map dependencies between subtext beats, which is disappointing, because I also think it's a core feature. But we couldn't realistically tell all users that they can't have the features that matter the most to them in order to give continuity to a feature very few people use. What is coming is a proper dependency graph, which was actually where the whiteboard started some years back, and this was the only reason that you could ever make dependencies in the whiteboard. It wasn't a timeline to begin with. The more the whiteboard became a timeline, the more wrong it was to have alternative-timeline stuff living in the same space. That said, I think that the people who aren't desperate for a dependency graph are wrong, because mapping dependencies is the most succinct way to map the rules of a story, and to be able to manipulate that story while everything is in a flux. It allows you to define the rules of the story before you know anything else about the story, and a ton of the story's structure flows from it. But a proper dependency graph is larger, and it would have meant holding 3.0 back for another very long time for a feature that we know that very few people use, and that the collective consciousness hasn't yet arrived at. How this dependency graph will work is that it'll replace the relationship canvas, and will become a combo way of expressing relationships between things, of which some of those relationships are dependencies. The underlying code transition is already in 3.0 in anticipation of this. It's only missing a UI. Then it'll simply be liked a node-editor in any compositing program. You can of course make connections between beats, but you can also make a beat dependent on a tag (subtext), so that certain plot is only allowed to happen when certain character traits have been established. It'll also work with targets on emotions (tying into upcoming emotion tracking), so that certain plot depends on certain emotions being at certain levels. You'll also be able to make dependencies between research folders, allowing you to divide up groups of beats into character arcs etc. This is where it belongs. Until then, your best option is to put subtext beats into successive folders, and then set In A Sequence on the parent folder. This was a feature made a couple of years ago in the absence of a proper dependency graph, and this will will go away when we have one, as it's a poor-man's version. I don't have an ETA, because collaboration is the #1 feature request and is getting most of the love. You'll have to go through a period without this feature, but it is coming, and what's coming is more what you want than you imagine.

To be clear, some kind of input and output is being thought about, because people have quite a lot of notes in various mind managers or bullet lists that it would be nice to especially import.

There's currently no way to share the research area. Of course, when collaboration is ready, you could simply bring people in as guests. But on printing, it's not 100% clear how to actually do this, because there's potentially a LOT of information in there, including multiple versions of beats, and later, multiple document types in parallel. I have some doubts that the output is useful, because it would be like sending people a phone book that they would struggle to dig information out of. If you've ever tried to export a mindmap to a linear document like Word, your eyes just glaze over, a linear format is not good at presenting tree-information unless it's very short. I agree that it would be nice to be able to output something. But I think it would work best when you're restrained in what is being exported. Including the beat text with versions, for example, will instantly turn this into a 200 page document that nobody actually reads. I think that collaboration is the best way to share this kind of information, because it isn't overwhelming. Perhaps, in the meanwhile, send people the Causality file and tell people to open it in the free version. They'll be able to navigate all of it, they just won't be able to modify it.