O que o FDX troca e o que ele deixa perder

O FDX ocupa no SlateX o lugar da troca de estrutura de roteiro: episódio, cena, cabeçalho de cena, marcação de dia e noite, contagem de páginas, itens de texto e cor de revisão podem entrar nessa cadeia; planos já filmados, registros de tomada, dias de filmagem, configurações de câmera e estado do set não pertencem aos objetos que esta importação cria. Em outras palavras, o FDX traz a estrutura do roteiro para dentro, mas “a importação deu certo” não equivale a “o projeto de filmagem já está montado”, e muito menos a “depois de ir e voltar o arquivo volta byte por byte igual”.

Aqui o FDX é um vetor de troca de estrutura de roteiro, e não um contêiner de resultado de filmagem.

O que a importação cria de fato

O caminho de importação atual do SlateX cria apenas três tipos de objeto de negócio: episódio, cena e item de roteiro. Planos não são criados pela importação, registros de tomada não são criados, dias de filmagem não são criados e configurações de câmera também não. Predefinições de equipe, como grupo, direção e direção de fotografia, também não têm ponto de escrita nesse caminho de importação e precisam ser tratadas à parte no produto.

Essa fronteira decide diretamente que perguntas o FDX serve para responder. Ele serve para decompor o roteiro em cenas e estrutura de texto legíveis, dando base de roteiro aos registros posteriores; ele não serve para ser descrito como “depois de importar, o plano de filmagem e o registro do set já estão prontos”. Que a estrutura exista só diz que a estrutura entrou no modelo de dados.

O conteúdo antes do primeiro cabeçalho de cena legível não vira texto dentro de cena

A análise atual usa o cabeçalho de cena legível como ponto de partida para criar cenas. Os parágrafos antes do primeiro cabeçalho de cena legível não têm uma cena já existente onde se apoie, então não entram no texto interno das cenas depois da importação. Conteúdo do tipo cabeçalho de abertura fica fora dessa fronteira.

Se o próprio texto do cabeçalho de cena estiver vazio, a cena correspondente também não será criada. Não é preciso explicar isso como alguma “intenção” do produto; o que diz, com precisão, é o seguinte: o passo que cria a cena exige haver texto de cabeçalho de cena utilizável, e sem essa condição de apoio não existe objeto de cena a ser escrito.

“Análise concluída” também pode não trazer cena nenhuma

Existe ainda um caso que convida a erro: um FDX bem formado que não contenha nenhum cabeçalho de cena legível pode, ainda assim, ter sucesso na análise e abrir normalmente a interface de seleção de cenas, só que com a lista vazia e sem aviso adicional.

Isso mostra que “o arquivo foi analisado com sucesso” e “já entrou conteúdo importado” são duas checagens diferentes. A primeira só diz que o fluxo de análise chegou ao ramo de sucesso; a segunda ainda exige ver se a lista de seleção de cenas realmente apresenta cenas e se, depois da importação, foram criados os correspondentes itens de roteiro.

O status de importação dizer sucesso não quer dizer que já exista cena dentro do projeto; olhe primeiro a estrutura que foi criada de fato.

Na ida e volta há alguns pontos que são reescritos por certo

A combinação dos dois lados de leitura e escrita do SlateX hoje permite deduzir algumas reescritas determinísticas. Uma cena que já passou pela importação de FDX, ao ser escrita de novo, faz a construção do cabeçalho de cena concatenar mais uma vez o título e a marcação de dia e noite que já estavam no cabeçalho original. O prefixo do cabeçalho de cena é lido mantendo o ponto final, e a escrita acrescenta outro ponto, de modo que a ida e volta pode produzir um duplo ponto como INT...

O campo de resumo também não é simétrico nos dois sentidos. O resumo entra na leitura, mas o lado da escrita não devolve o valor ao mesmo campo de resumo; numa nova importação, o resumo da cena ainda é substituído pelo conteúdo do primeiro item de texto. Quando a contagem de páginas é zero, o lado da escrita não grava atributo de extensão, e a leitura, na ausência de extensão, trata como 1/8 de página. O estado de filmagem também não viaja nessa troca de estrutura, e a reimportação devolve a cena ao estado “não filmada”.

Essas conclusões não são suposição sobre o comportamento de algum software de terceiros: são o resultado combinado dos dois lados de leitura e escrita do próprio SlateX. A fronteira precisa ser escrita junto: ainda não fizemos a aceitação de ida e volta “abrir, salvar como e reimportar” com software de roteiro de terceiros real, então para fora só podemos dizer que a ida e volta não garante fidelidade byte a byte, e não que passou por alguma aceitação externa.

Que informações de filmagem simplesmente não estão nessa troca

Planos, registros de tomada, dias de filmagem, configurações de câmera, timecode, avaliação, caminhos de mídia e demais resultados de filmagem não estão no alcance atual do FDX. O caminho de importação não cria esses objetos, e o lado da escrita também não encaixa esses registros do set dentro da estrutura do roteiro.

Portanto, ao ver que algum dado não voltou, a pergunta certa é “existe nessa camada um campo ou objeto que o carregue”, e não inventar para o produto um motivo do tipo “por que ele teria que descartar”. Não existe caminho de escrita onde não existe caminho de escrita.

Ida e volta sem fidelidade não quer dizer que o arquivo não sirva

O FDX continua servindo para trocar estrutura de roteiro. Ele traz para o SlateX cenas, cabeçalhos, marcação de dia e noite, contagem de páginas e itens de texto, e também escreve de volta ao arquivo a estrutura de roteiro do projeto atual. Só que essa troca deve ser entendida hoje como entrega de estrutura, e não como um ciclo de trabalho em que se pode ir e voltar editando sem que um caractere mude.

Se a parte receptora for continuar usando o arquivo, deve conferi-lo contra a estrutura que realmente existe nele, e não tratar “abre” ou “reimporta” como prova de fidelidade de conteúdo.

Essa família ainda precisa responder a duas perguntas em separado

Este texto responde apenas a quais estruturas o FDX serve para trocar e que conteúdo não é preservado nesse caminho. Duas perguntas ainda devem ser abertas cada uma na sua própria página: uma é “que informação não volta”, dizendo campo a campo se o que falta é um campo, um objeto ou um caminho de escrita; a outra é “o que a importação cria de fato”, separando na conferição episódio, cena e item de roteiro dos objetos de filmagem que não são criados.

FAQ

A importação de FDX cria planos e registros de tomada sozinha?

Não. A importação atual cria episódio, cena e item de roteiro, e não cria planos, registros de tomada, dias de filmagem nem configurações de câmera.

Se o arquivo foi analisado com sucesso, já quer dizer que cenas foram importadas?

Não necessariamente. Hoje um arquivo bem formado sem cabeçalho de cena legível ainda pode chegar ao sucesso da análise e abrir uma lista de seleção de cenas vazia, então é preciso conferir as cenas criadas de fato.

O FDX mantém o cabeçalho de cena byte a byte na ida e volta?

Não se pode garantir isso. Os dois lados de leitura e escrita produzem reescritas determinísticas, como título e marcação de dia e noite somados de novo e duplo ponto no prefixo, e por isso para fora só se escreve “a ida e volta não garante fidelidade byte a byte”.

Por que certas informações de filmagem não voltam pelo FDX?

Porque o caminho de troca de FDX atual não carrega objeto nem campo correspondente para elas. Descreva o caminho de escrita ou de leitura que falta, e não explique essa ausência como motivação do produto.

Axiom One LLC — SlateX. Os números acima são os de 2026-09-24.