Gasto um pouco de meu tempo para compartilhar com os FLYzeiros o que aprendi nessas semanas intensas que venho mexendo nas tripas do FLY, com a esperança de que mais pessoas venham ter interesse em aperfeiçoar o Brasil virtual desse fantástico simulador. Porque a constatação é clara: um só não vai dar... O que veio no FLY 1.0 com relação ao Brasil não é muito entusiasmante, mas com um pouco (maneira de dizer...) de trabalho de todos, poderemos reverter isso, a ponto de, talvez, mapear o Brasil inteiro, completo, de aeroportos, waypoints, relevo, litoral, cidades, rios, lagos, estradas, vegetação, objetos 3D, etc, tudo de acordo com o que vemos nos mapas. Exagero? Eu acho que não. Pelo que descobri até agora (e que não caberá neste texto, mas em futuros) o potencial de "melhorias" que podemos fazer é enorme. E este potencial NÃO é aparente. É esse meu objetivo com este texto: mostrar o que podemos fazer, só com o editor, e muito trabalho duro.

**LEIA**
         Use essas informações por sua própria conta e risco!! Eu não garanto nada, nem que elas estejam corretas. Eu não serei responsável por nada que você fizer com elas.


         O que é preciso:

- interesse, tempo e disposição para aprender, arregaçar as mangas e trabalhar em melhorias para o Brasil virtual do FLY!
- agora, o mais fácil (com toda certeza): baixar e instalar o Editor da TRI (atualmente na versão 1.05). Ele DEVE ser instalado no mesmo diretório do FLY!. Além disso, você precisa do DBimport, para não apenas TESTAR suas alterações, como também adicionar múltiplas melhorias na base de dados da maneira mais fácil. Downloads disponíveis no final desta matéria.

         Existe uma página explicando a edição das bases de dados, por Marty Schultz, que você encontrará a partir de www.flightsimnetwork.com/flypictorial/flylinks.html. O que ele diz sobre montar o .epd com registros marcados causar um erro de "Access Violation" não procede.

*ADENDO
         Além disso, não é aconselhável marcar os arquivos como "read-only", porque o DBImport não acusa erro. Se o .epd for "read-only", ele fará todo o processo de criação e simplesmente não o atualizará, você não fica sabendo de nada, e depois nem percebe que nada foi atualizado. O melhor é ter cópias de reserva de TODOS os arquivos que for modificar (e mesmo de outros).


Rodando o Editor:

         Ao executar o editor pela primeira vez, ele lerá o cenário de San Francisco e o posicionará sobre o aeroporto KSFO. Para evitar que toda vez que entrar no Editor ele faça isso, o que é EXTREMAMENTE custoso e lento, primeiro posicione o "cursor" num aeroporto de área genérica (o aeroporto de sua cidade, p.e.): use a opção Goto/Airport by Name or Id; depois que ele estiver no aeroporto indicado, use a opção Goto/Set Default Editor Position. Da próxima vez que rodar, o editor vai entrar nessa posição indicada.

*ADENDO
         Note porém que o "Browser" de modelos 3D (menu Models) não vai dispor dos modelos dos cenários default se você estiver numa área genérica. Você precisa ir para um dos cenários para ter poder usar seus modelos, ou então consulte o fórum "FLY Scenery" da avsim que há uma solução (basicamente extraia os .bin, .raw e .act dos modelos nas pastas Models e Art).


Alterando as bases de dados:

         São os arquivos dentro da pasta system do FLY: Navaid.epd (NDBs e VORs), Airport.epd (aeroportos), Runway.epd (as pistas dos aeroportos), Comm.epd (as frequências dos aeroportos), Ils.epd (os ILS), Waypoint.epd (os "trianglinhos" coloridos do Flightplanner). Existem outras bases ainda, mas por enquanto fiquemos com essas. Adiante darei exemplos da edição da base de aeroportos, mas as operações serão iguais para todas as outras bases; o que mudará são os campos dos registros e seu significado.

• 1ª etapa: extrair os arquivos dos pods (.epds)

         Pelo que consegui perceber até agora (posso estar errado...), os pods são uma forma que a TRI criou para simular uma certa estrutura de pastas e dados requerida pelo seu "engine" de simulação e renderização 3D, sem precisar tê-las explicitamente. Além de agrupar tudo de forma mais limpa, para evitar aqueles "buracos-sem-fundo" que a Microsoft gosta de fazer, no Windows (system) e no próprio Flight Simulator (gauges). Se você estiver com a opção SearchPodFilesFirst=0 (=não) no Fly.ini, arquivos requeridos pelo FLY são primeiro procurados nas pastas normais do Windows; só se não encontrados é que são procurados pelos pods. Mas isso fica para depois, por ora, basta saber que a pasta database\ que você identificar nos pods de uma base de dados corresponde a uma pasta dentro do FLY (criada na instalação do Editor). E, se você estiver com SearchPodFilesFirst=0 no Fly.ini, os dados que você deixar nesta pasta SERÃO USADOS na execução do FLY! Só se não existirem ali, é que o FLY irá procurá-los nos pods. E se o FLY der algum problema (trancar, etc), é bem provável que o problema esteja nas suas "mexidas" de alguma base na pasta database.

*ADENDO
         Se você não percebeu ainda, existem outras pastas além da database que guardam diversos tipos de dados pro FLY (veja nos .epds): art (para as texturas, vide SKY), data (para as informações de cada parte do mundo em subdiretórios DXXXYYY\), models (os objetos 3D), sound, world, etc.

         No File Manager do Editor (tecle Alt+E, depois F):
- selecione 9 para ver o conteúdo de um pod - selecione 8 para extrair cada um dos arquivos requeridos: basta o .dbd e o .dbt!

         Você também pode ver e extrair o conteúdo dos pods com o "podviewer" da pasta tools (não estou bem lembrado se ele veio com o editor ou eu instalei separadamente...).

         Para editar e/ou acrescentar aeroportos, você precisa primeiro extrair dois arquivos de system\Airport.epd: Airport.dbd (a base de dados) e Airport.dbt (o "template" dos dados).

         O .dbt desta e de todas as outras bases de dados diz qual é o formato dos dados no respectivo .dbd. Ele é um arquivo texto, você pode ver com o Notepad. Lembre-se: o Editor está em versão beta ainda, sendo um pouco, digamos, temperamental quanto a erros. Se você extrair apenas um deles, p.e., só o Airport.dbd, o editor pendurará ao tentar ler a base de dados para edição (dará o famigerado "Access violation", que pelo jeito é a mensagem de erro pra quase tudo no Editor, e no FLY...).

         Os demais arquivos de Airport.epd, os *.dbi, são de índice, para o FLY vasculhar os dados mais rapidamente, e podem ser gerados depois automaticamente. Se você acrescentar ou eliminar registros da base (ou seja, acrescentar ou eliminar aeroportos), ou alterar os campos chave, nome, código, país e coordenadas, dos aeroportos já existentes, será preciso recriá-los. Se você apenas alterar um dos outros campos de um registro existente, não será preciso.

         A pasta de referência é a do FLY e onde o editor está instalado, portanto, sempre que for pedido um arquivo POD, basta o caminho a partir da pasta do FLY; também não é preciso a extensão .epd: se ele está pedindo um POD, é lógico que é um .epd.

Enter pod file: system\airport

         Como disse antes, os pods simulam uma estrutura de diretórios: você verá que o airport.dbd e airport.dbt dentro de Airport.epd estão numa pasta database. Ao extrair os arquivos, informe esse mesmo caminho e o nome de arquivo completo (com extensão):

Enter pod file: system\airport
Enter full file path: database\airport.dbd

         Faça o mesmo para o airport.dbt. Você verá que estes dois arquivos serão copiados na pasta database do FLY (não foi o caminho que você indicou?). Agora, basta sair do File Manager teclando ESC; você também pode teclar ESC para sair de uma das perguntas acima, quando entrar numa opção mas mudar de idéia e não quiser completá-la.

• 2ª etapa: editando a base de aeroportos

         Vá para o editor de Databases (Alt+E, depois D). Selecione a opção 2- Edit an existing database. Será perguntado o "Database Path". Apesar do nome, basta indicar o nome do arquivo .dbd (não precisa extensão) que JÁ ESTIVER NA PASTA DATABASE (como foi citado "Database", ele já assume a pasta database):

Database Path: airport

         Relembre que, se tanto o .dbd e o .dbt não estiverem na pasta database, o editor vai emburrar, portanto não mexa com a paciência dele! :) Sem falar que não há nenhuma mensagem de erro nunca, portanto SEJA MUITO CUIDADOSO ao trabalhar com o Editor. Guarde backups de todos os arquivos (.epds) que estiver mexendo.

         Será mostrado o primeiro registro (ou seja, o primeiro aeroporto) da base. Os diversos itens (cada um numa linha) são os campos de cada registro, com a indicação de seu formato na extrema esquerda: p.e., C/10 (texto de 9 Caracteres no máximo), I/4 (número Inteiro de 4 bytes/32-bits), D/8 (número Decimal de 8 bytes), e assim por diante. Óbvio não?

*ADENDO
         Os campos de caractere maiores que 1 são strings (claro) no formato de C/C++ (no qual o FLY foi programado), ou seja, com um 0 ('\0') no final, logo se o campo é C/10, como o campo chave, na verdade cabem no máximo 9 carateres, e não 10.

*ADENDO
         Se campos de 1 caractere (C/1) tiverem bytes não-mostráveis (0, 1, 2,...; há vários em airport.dbd e runway.dbd), irá aparecer '' no campo. E não dá pra ver que valor é, porque o "Current Value" parece sempre mostrar 0x0 não importa que valor tenha (isto é um erro que eles DEVIAM corrigir!). Mas dá pra adicionar um valor hexadecimal com 0xHH: por exemplo, 0x0A, para 10 (note que o 'x' tem que ser minúsculo). Isso está no readme do editor. Só é preciso descobrir QUAIS valores adicionar!

         Embaixo estão as teclas que podem ser usadas para edição (além de ESC, que volta ao menu do editor, e daí, sai do editor de databases). No canto inferior direito, está o nº do registro atual ao lado do total de registros da base. Este total será útil depois para você conferir se o seu .dex criado realmente acrescenta o número de registros esperado.

         As teclas de direção movem pelos campos do registro (pra cima e pra baixo) ou pelos vários registros (pros lados). Descrevo os campos no fim deste texto.

         Use a opção F (find) para achar um registro com determinado valor num dos campos (p.e. achar um aeroporto pelo seu código). Se o campo for do tipo caractere (texto) ele achará o primeiro registro que COMECE pela informação que você fornecer no CAMPO QUE ESTIVER SELECIONADO. Se você procurar pelo NOME "fazenda", ele vai parar em "FAZENDA ROSA DE MAIO", p.e. Maiúsculas e minúsculas são iguais. Se tentar de novo ele buscará o aeroporto seguinte que comece pelo que você digitar. Ele começa a procurar a partir do registro em que estiver, vai ao final e volta do início ao registro atual (caso este seja o único com o valor que você digitou).

         Você pode modificar o campo de um aeroporto com E, ou também teclando ENTER, o que é bem mais intuitivo. IMPORTANTE: você pode modificar vários campos num mesmo registro, mas SALVE IMEDIATAMENTE COM S (tecle S duas vezes, a segunda para sair da mensagem inútil sobre recriar índices). Se você mudar de registro sem ter salvo (com teclas para direita ou esquerda), suas alterações serão perdidas. Acostume-se também a MARCAR (teclando M) os registros que modificar ou acrescentar, se quiser gerar depois um arquivo de extração (.dex) com suas modificações para compartilhar com outros. Os registros marcados mostram um *EXPORT* no canto superior direito.

*ADENDO
         E muito cuidado que a tecla D (para eliminar registros) fica DO LADO do S!! Não há nenhuma mensagem nem mesmo alguma modificação na tela quando você elimina um registro...

         Tecle I para acrescentar um novo registro (um novo aeroporto, no caso). Note que aparece um *NEW* no campo inferior direito. Isto lhe indica que você não sairá do registro com as teclas pra direita e esquerda, só teclando ESC para cancelar a criação do registro ou S para salvá-lo. Note também que depois de salvo, ele é um registro normal, portanto, lembre-se de SALVAR o registro toda vez que fizer novas alterações. Perdi a conta das vezes em que mudei campos de vários aeroportos, voltei depois a eles e vi que as alterações que tinha feito não estavam lá (porque esqueci de teclar S).

         Antes de acrescentar um novo registro, com determinada chave (o primeiro campo) certifique-se de que esta chave não exista, porque este campo tem que ter um valor único para cada registro (os outros não precisam, nem mesmo o nome e código: você pode ter dois ou mais aeroportos com mesmo nome, p.e.). Ah, É MUITO IMPORTANTE você estabelecer um padrão de nomeação das chaves, de forma a poder encontrá-los facilmente com F, e garantir que não há repetição de chaves. E também para que fiquem agrupados depois, quando estiverem ordenados pelo campo-chave. Infelizmente, o editor aparentemente não aceita acentos (caracteres acima de ASCII 127).

*ADENDO
         A importação de registros NÃO APAGA os que já existirem com mesma chave, ela apenas os insere de maneira a ficarem ordenados. Os que você adicionou à base vão ficar lá no fim mesmo, o que causará duplicatas. Se for preciso importar de um .dex gerado com suas adições, você tem que fazê-lo na base original, sem essas adições.

*ADENDO
         Acho que não ele aceita acentos porque devem ter feito a pesquisa por nome (e criação de índices) só com A-Z maiúsculas e números...

         Note que enquanto está no modo *NEW* (adição de um registro), depois de entrar um valor num campo ele automaticamente o posiciona no próximo. Assim, se você tem vários aeroportos a acrescentar, me parece mais eficiente ir preenchendo os campos de cada um, em vez de acrescentar as informações dos aeroportos "campo-a-campo" (entrar com todos os códigos e nomes primeiro, depois cada uma das outras informações). Enfim, depende do que você achar melhor. Lembre-se: tecle sempre ENTER primeiro antes de modificar cada campo (e ENTER depois de digitar o valor do campo). É frequente esquecer do ENTER e sair digitando teclas que não fazem nada (até você teclar um S ou I, ou pior, um D como parte do campo que você quer entrar...)

         É ideal colocar nome e código em maiúsculas, porque a procura (no Airport Directory, Flight Planner e GPS) é feita só em maiúsculas. Portanto, use o CAPS LOCK. Até é possível gerar os índices de procura com os campos em maiúsculas, e depois mudá-los para minúsculas (mas sem recriar os índices): só que você terá que montar o .epd manualmente, sem usar o DBImport, porque este vai recriar os índices de qualquer jeito. Também achei útil, depois de entrar não sei quantos campos de números (latitudes/longitudes) ativar o NUM LOCK para digitar com os números mais facilmente no teclado numérico.

         Não custa ser repetitivo: LEMBRE-SE DE TECLAR S (SAVE) ANTES DE SAIR DO REGISTRO! Especialmente quando está só alterando registros existentes!

         A opção C (clear) limpa o campo selecionado (deixa com vazio ou 0). Novamente, essa mudança só terá efeito se você salvar o registro com S.

• 3a. etapa: efetivando as modificações no FLY

         Se você só alterou campos de registros existentes, pode rodar o FLY imediatamente (depois de sair do Editor, é claro) que ele lerá os registros de database\airport.dbd. Este se SOBREPÕE ao que está "podado" (embutido) em system\airport.epd (note que estou sempre assumindo a pasta do FLY como referência para os caminhos relativos citados, assim como o próprio editor assume -- se você instalou o FLY no "caminho sem fim" sugerido (\Arquivos de Programas etc. etc.) aconselho deixar um Windows Explorer permanentemente aberto nessa pasta... Se você alterou o código ou nome de aeroportos (mas não recriou os índices), e/ou não ORDENOU os registros pelo campo-chave (veja adiante), o FLY simplesmente (provavelmente) não achará esse registro se buscar pelo campo (no "Airport Directory" ou no GPS). Ou pode cuspir um "Access Violation" na sua cara.

         A melhor maneira de efetivar suas modificações será usando o DBImport. Suas modificações estão no .dbd (no caso, airport.dbd) na pasta database. Primeiro você precisa extraí-las gerando um arquivo .dex, que é o arquivo de entrada do DBImport e o que você irá passar aos outros as suas melhorias. Se você se lembrou de MARCAR para *EXPORT* todos os registros que quer extrair/exportar, volte ao editor de databases com ESC (se estiver editando uma base de dados). Escolha a opção K- Export records from database. Será pedida qual a base de onde quer exportar (lembre-se, ele assume a pasta database) e o nome do arquivo de extração (.dex), forneça um caminho relativo à pasta do FLY, p.e.:

Database Path: airport
Export Filename (.DEX): database\xxx

         Ele vai criar o arquivo xxx.DEX na pasta database do FLY. Pronto, suas modificações (se estiverem todas corretas) estão prontas neste arquivo!

***IMPORTANTE: GUARDE UM BACKUP DOS .EPDs DA PASTA SYSTEM\ QUE VOCÊ PRETENDE MODIFICAR: airport.epd, waypoint.epd, airport.epd, comm.epd, runway.epd, center.epd, etc.

         Com o .dex gerado, basta usar o DBImport, informar o caminho e nome deste arquivo e ele fará tudo automaticamente: extrairá os arquivos do pod apropriado (ele saberá qual é) na pasta database (perceba, o DBImport IRÁ SOBRESCREVER E APAGAR os respectivos *.dbd e *.dbi´s que estiverem na pasta database! Mas não os .dex, é claro...), reordenará os registros pelo campo-chave, recriará os índices e remontará o POD. Tudo limpo!

*ADENDO
         Lembre que o .epd não pode estar marcado "read-only" senão ele não o modificará, e não dará nenhuma mensagem de erro!! Você nem fica sabendo que foi tudo em vão...

         Existe uma outra maneira: reordenar os registros, recriar os índices e montar o pod você mesmo. Só vou explicar isso porque existem alguns aspectos que precisam ser comentados.

         Primeiro, os registros da base (qualquer uma) TÊM QUE ESTAR ORDENADOS pelo campo-chave, o primeiro campo (único). Registros que você adiciona (com I) SERÃO COLOCADOS NO FINAL DA BASE. Portanto, este .dbd que você está acrescentando NÃO ESTARÁ ORDENADO! Para ordená-lo, use a opção I- Re-sort database by master record keys, o que demora uma eternidade (não estou exagerando, melhor nem tentar...). Ou importe o .dex com a opção L- import records from extract file. Só não garanto que assim ele apague os registros no final da base ao inserir os importados com mesma chave. Está vendo como o DBImport é muito melhor?

*ADENDO
         Richard Harvey disse no fórum FLY Scenery da avsim que os registros NÃO PRECISAM estar ordenados, embora a rotina de importação ordene-os. Isso é porque eram procurados originalmente por pesquisa binária, que necessita dos registros ordenados. Agora apenas os índices são procurados assim. Estes sim são criados e precisam estar ordenados; eles "apontam" para os registros da base, que por isso podem estar em qualquer ordem. Portanto, desconsidere o que disse acima de os registros precisarem estar ordenados, você pode testá-los imediatemente depois de adicionar (mas crie os índices, né?). A opção I não serve mais pra nada (eu nunca usei mesmo...). Ah, e a importação realmente NÃO apaga registros com mesma chave que não estiverem ordenados, ela apenas insere os registros do .dex ordenadamente.

         Pra quem não souber: pesquisa binária é a forma mais simples, ainda que eficiente, de pesquisa: divide-se o espaço de procura pela metade até achar o registro. Ou seja, verifica se o registro procurado é o do "meio" da base, se sim pronto, fim da pesquisa; se ele for menor do que o procurado, o novo espaço de procura é a metade final (após este); se for maior, o novo espaço de procura é a metade inicial da base. Daí, repete-se o mesmo procedimento até achar (ou não).

         Você ainda precisa recriar os índices. Isto é fácil, basta no editor de databases escolher a opção de recriação de índices para a base que está editando, no caso de aeroportos, B- Recreate airport index files.

         Agora, com os .dbi's recriados e o *.dbd e *.dbt na pasta database, é preciso montar o pod. Isto é feito no File Manager, volte ao principal do editor com ESC's, depois tecle ALT+E e F. A montagem geral de PODs é na opção 6- Build epd from a response file. Este "response file" é um arquivo texto contendo os caminhos relativos e nomes dos arquivos que serão montados. Note que o caminho é igualmente importante e não deve ser diferente no pod (porque o FLY procura pelas bases na pasta database!). O conteúdo do response file é exatamente o conteúdo do respectivo .epd da pasta system (veja com a opção 9). No caso de airport.epd, o response file deve ser:

DATABASE\AIRPORT.DBT
DATABASE\AIRPORT.DBD
DATABASE\AIRPORT.DBI
DATABASE\APRTCTRY.DBI
DATABASE\APRTFAA.DBI
DATABASE\APRTICAO.DBI
DATABASE\APRTNAME.DBI
DATABASE\APRTSTAT.DBI
DATABASE\APRTGLOB.DBI

         Lembre-se que o caminho de referência é relativo à pasta do FLY, portanto forneça a localização deste arquivo relativo a ela:

Response file name: database\airport.txt
Enter name of .POD to build: system\airport

         Lembre-se de ter feito um backup dos .epd's da pasta system!

         Feito! Se alguma coisa não funcionar direito no FLY, é ou porque você fez alguma coisa errada, ou há alguma coisa errada nas minhas explicações (bem provável :-)). Ou ainda porque o editor é meio instável.


O Geograph.epd incluído junto com este texto:

         Coloque este arquivo na pasta system, depois de salvar o original do FLY noutro lugar, por precaução (aconselhável). O que estou fornecendo contém os nomes dos países em português e os estados do Brasil, para o Airport Directory e também para o GPS (APT 1). No Airport Directory você só podia selecionar estados para os EUA, não é mesmo? Agora, também para o Brasil, SÓ QUE é preciso que se coloque o estado correto dos aeroportos brasileiros em airport.dbd (estão todos com 'vazio' atualmente). Isto pode ser feito à medida que as pessoas forem adicionando aeroportos para os diversos estados: ao mesmo tempo já completam/corrigem as informações dos existentes, acrescentando estado, código IATA, etc.

         Me avisem se este Geograph.epd der algum problema. Deixá-lo 100% como (espero) está esse aqui foi complicado: tive que colocar as chaves de state.dbd como US?? (??, as abreviaturas dos estados), gerar os índices, depois renomear todas as chaves para BR??, mas sem recriar os índices. Só assim para os estados funcionarem tanto no Airport Directory (do Flight planner, p.e.) E também no GPS. Agora, à medida que a abreviatura do estado for sendo colocada nos registros dos aeroportos brasileiros, aparecerá o estado certo no APT 1 do GPS, em vez do sempre AL (que corresponde ao ALASKA, o primeiro registro do state.dbd original).


Usando os templates fornecidos com este texto:

         Como os *.dbt são arquivos texto, editei o airport.dbt, runway.dbt e comm.dbt para ficarem mais apresentáveis e informativos: são os que acompanham este texto. Faltou talvez traduzi-los para o português... Mas os campos já são bastante autoexplicativos, com um ou outro mais obscuro: Segmented circle (???), p.e.; "Frame service" deve ser manutenção de fuselagem, etc.

         Para utilizar estes novos .dbt, basta colocar na pasta database. Mas lembre-se que, se usar o DBImport, ELE VAI SOBRESCREVER E APAGAR NESSA PASTA TODOS OS ARQUIVOS RELACIONADOS À BASE QUE ELE ESTIVER ATUALIZANDO. Portanto, é bom montar o .epd manualmente uma vez para já incluir estes *.dbt de forma definitiva.

         Nesses novos .dbt:

• Campos que iniciam com traço (-) são os IMPORTANTES, os que, pelo que pude descobrir, fazem alguma diferença na simulação (pelo menos atualmente). Só aparecem em airport.dbd; em runway.dbd e comm.dbd, quase todos os campos são importantes.
• Campos na forma de pergunta (com "?" ao final) são do tipo sim/não: informe qualquer coisa diferente de vazio (p.e. 'Y') para "sim" ou deixe vazio, para "não" (não garanto que sejam todos realmente assim, estou apenas supondo...).
• Coloquei entre parênteses lembretes mnemônicos dos valores de alguns campos, limitados aos mais relevantes por causa do espaço: '+' significa que você pode adicionar os valores para múltiplos itens, e '|' indica "ou" exclusivo (é um OU outro). Note que você não pode colocar vírgulas nos nomes dos campos...

         Nalguns campos há só os significados sem seus respectivos valores. Confira com o texto "Database Values" da pasta Howto. Nestes casos, sempre assuma que os valores crescem nas potências de 2 a partir do 2 (2+4+8+16+32+...), a não ser quando atribuo um significado a um valor (Significado=Valor). Por exemplo, o campo "Fuel (types)" é seguido de (80+100+LL+JA=32+Auto=1024), que significa: 80=2 + 100=4 + 100LL=8 + ... + JetA=32 + ... + Auto=1024.


Campos de airport.dbd:

• Utilize chaves dos registros de aeroporto de maneira que você possa facilmente lembrá-las (se estiver acrescentando VÁRIOS registros), porque essa chave terá que ser usada em runway.dbd e comm.dbd para associar as pistas e frequências de rádio ao seu aeroporto.
  Por exemplo, estou acrescentando aeródromos para o RS com chaves BRA... junto com o código do aeroporto. Aos que não têm ou eu não sei o código OACI/ICAO, estou colocando B5??, onde 5 é o DDD do RS (dãã!, foi a forma que encontrei para identificar facilmente o estado e também garantir que o código não exista, já que os códigos ICAO não têm números), e ?? é um código de identificação de 2 letras. Mesmo fictício, esse código já é muito melhor que os indistinguíveis "SB" pra todos. Futuramente, quando eu ou alguém souber os códigos corretos (se é que existem...), é só modificar os campos FAA ID e ICAO ID, não precisa modificar a chave, senão terá de corrigir os registros de runway.dbd e comm.dbd também.
  
  

• Use o campo FAA ID para acrescentar os códigos IATA/Infraero dos aeroportos brasileiros: GRU, SDU, BSB, PAG, etc. Este terá precedência sobre o ICAO ID. Se existir, é o FAA ID que será mostrado no Flight planner, Airport Directory e GPS. Mais importante, é por ele que o FLY procura pelas taxiways. Então, se você acrescentar o código SDU para o Santos Dumont, p.e., terá que trocar os nomes DENTRO dos arquivos de taxiway feitos pelo Fernando M. Serenato (sbrj.epd) de sbrj.* para sdu.* (confira com ele primeiro, né?). Caso contrário, a taxiway NÃO aparecerá, porque o FLY estará procurando por arquivos sdu.* dentro dos PODs, quando as que existem atualmente estão nomeadas sbrj.*.
  
  

• Os campos Country (coloque BR para o Brasil), State e Usage aparecem no Airport Directory. Com o Geograph.epd fornecido junto, os estados aparecerão por extenso e os países em português.
  
  

• Ownership e Usage aparecem também no GPS (página APT 1). Se for militar (Ownership=3|4|5), aparece MILITARY, se Usage for privado, aparece PRIVATE.
  
  

• Fuel types também aparece no GPS (página APT 3). Só são mostrados os tipos de combustível 100, 100L (low-lead), JET (para todos os tipos de querosene: JETA, JETA1, JETB, etc) e AUTO (gasolina, suponho que para ultraleves?).
  
  

• Outra informação mostrada no GPS (APT 3) é o tipo de aproximação disponível, mas não consegui descobrir de onde vem: em todos aeroportos que estou incluindo aparece NP APR (aproximação de não-precisão). Outros valores são NO APR (sem aproximação) e ILS, se houver registros de ILS para o aeroporto em ILS.EPD (p.e., com a atualização de ILSs do Bruno M. Bahia e Fernando M. Serenato).
  
  

• Beacon color é a cor do farol rotativo que funciona quando em condições IFR (e sempre à noite). Se for indicado, uma torre com farol rotativo será posicionada automaticamente nas coordenadas do aeroporto (descritos adiante).
  * Será que dá pra atribuir um modelo 3D próprio à torre do farol e assim poder botar faróis de navegação (marítima) ao longo da costa?? Ou seja, será que dá pra usar o efeito do farol rotativo em outros modelos 3D?? Quem descobrir...
  
  

• TALVEZ o campo Based aircraft sirva para restringir os tipos de aeronaves que aparecem no aeroporto: p.e. evitar que apareça um Hawker em qualquer campinho mixuruca de terra...
  
  

• O ícone do aeroporto no Flight planner você indica em dois campos:
  "Airport Icon", valores:
    0x1: pista não-asfaltada/cimentada (círculo vazado)
    0x2: pista asfaltada/cimentada menor que 8000' (círculo cheio)
    0x3: maior que 8000' (o ícone de cruz)
    0x4: menor que 8000' com VOR (círculo cheio com um ponto)
    0x5: maior que 8000' com VOR (o ícone de cruz com um ponto)
  "ATC service available ?": coloque algum caractere (p.e. 'Y') e o ícone aparecerá azul em vez de magenta (para aeroportos com torre de controle).
  ***IMPORTANTE: Provavelmente você não verá as modificações de ícones que fizer se não apagar o arquivo airport.dat da sua pasta system. Richard Harvey disse no fórum da avsim que estes *.dat são gerados pelo Flight planner para agilizar a exibição e podem ser tranquilamente apagados, sendo então gerados de novo na próxima execução. Só aí suas modificações nos ícones terão efeito.
  
  

• É bom indicar o número de runways e o comprimento da pista mais longa (que talvez seja usado na função NRST do GPS).
  
  

• Lighting: deixe em 0 para a iluminação normal, padrão, que acende do pôr ao nascer do sol (18:00-7:00 hora local).
    - 2 é para 24h, fica aceso o tempo todo, 24h por dia.
    - 4 é "ATC" segundo o "Database Values", mas para mim sempre corresponde a NENHUMA iluminação: não há iluminação nem mesmo à noite e nada é indicado no GPS: não aparece L nas páginas APT 4. Portanto, use este valor para aeródromos sem iluminação.
    - 8 para rádio-controlado (PCL, pilot-controlled lighting): aparece LPC no GPS (APT 4). Se o aeródromo tiver uma frequência CTAF (Unicom, Multicom, etc), sintonize-a e pressione rapidamente a tecla BACKSPACE 5 vezes para acender suas luzes.
    - 16 para rádio-requerido e 32 para fone-requerido: não sei o que realmente significam, ambos aparecem como LPT no GPS (APT 4). Não há iluminação durante a noite.
  
  

• A latitude e longitude devem ser convertidas para um número decimal através das fórmulas:
  
    latitude-norte = Graus*3600 + Minutos*60 + Segundos (incluindo os decimais)
    longitude-leste = a mesma coisa
  
  As latitude sul e longitude oeste (justamente as do Brasil!) são:
  
    latitude-sul = - (a latitude norte)
    longitude-oeste = 360*3600 - (a mesma coisa) ou seja = 360*3600 - (Graus*3600 + Minutos*60 + Segundos)
  
  Exemplo: 24* 35' 56.78" S = - (24*3600 + 35*60 + 56.78)
                53* 12' 04.06" O = 360*3600 - (53*3600 + 12*60 + 4.06)
  (Há um utilitário na avsim, FlyComp, que faz esses cálculos, só que ele exige um MSVBVM60.DLL do Visual Basic.)
  
  Anote os valores calculados, se estiver acrescentando vários aeroportos, porque você terá de informá-los também nos registros de comm.dbd para as frequências do aeroporto (os que tiverem, claro). São necessárias ali também porque senão as frequências NÃO FUNCIONARÃO nem serão achadas com a função "Auto-tune".
  Estas coordenadas não são de nenhuma das pistas do aeroporto, são da "torre": onde fica o farol rotativo, se o campo Beacon color tiver alguma cor informada (ver acima). Também é a posição onde o cursor é colocado no Editor da TRI, ao "ir-para" (goto) o aeroporto.
  Se algum aeroporto estiver com a torre sobre a pista, acredito que você poderá corrigir isso deslocando as coordenadas desses campos um pouquinho pro lado, já que as pistas TÊM suas coordenadas próprias, e portanto, NÃO serão deslocadas junto (não testei isso).
  
  

• Os campos Attendance indicam quando o aeródromo funciona. Não sei as frequências da torre de controle (se houver) ou de outras facilidades (approach, departure, etc) deixam de funcionar fora dos horários indicados de funcionamento. Especificamente, não sei se a frequência da torre reverte para CTAF quando o aeródromo está fechado. Valores úteis (devem ser somados):
    - todos os meses do ano = 8190 (subtraia daí os meses em que não funciona),
    - todos os dias da semana = 8323072 (subtraia os dias em que não funciona).
  Confira os valores a ser subtraídos (dos meses e dias da semana) no documento "Database Values" da pasta Howto. Some o valor resultante dos meses e dias da semana com um dos seguintes para a parte do dia em que o aeródromo funciona (extraídos do texto "Database Values"):
    AllDay = 268435456
    Sunrise = 1073741824 (A partir do nascer do sol?? Até quando??)
    Sunset = 2147483648 (A partir do pôr-do-sol?? Até quando??)
    Specific Time = 536870912 (Indicar o tempo específico nos campos Attendance Start/End Time. Não sei o formato destes campos, mas HHMM aparentemente não é, porque há uns valores 1380, p.e.)
  
  

• Acho que os demais campos são apenas informativos, TALVEZ venham a ser usados no futuro. Os seguintes campos atualmente NÃO são usados, não têm valor em NENHUM registro:
    - Airport type (acima de Airport Icon)
    - ILS approaches available ? (penúltimo campo)
    - Reserved (último campo, esse é óbvio...)
  Os campos Lighting Start/End Time também parecem não ser usados; não têm valor na maioria absoluta dos registros (mesmo dos EUA, que teoricamente devem ser os mais completos).

Campos de runway.dbd:

***IMPORTANTE: Não rode o FLY com registros de airport.dbd adicionados sem as respectivas pistas em runway.dbd. Eu tive problemas por causa disso: trancamentos, Access Violations, etc.

• Segundo Marty Schultz, os campos-chave têm que ser ?EA...., onde ? é um dígito.
  
  

• O campo-chave do aeroporto a que a pista pertence você terá de informar aqui e também nos registros de comm.dbd. É a ligação entre as pistas e frequências com os aeroportos.
  
  

• O comprimento e largura da pista, não preciso dizer (mas já dizendo), são importantíssimos.
  
  

• Só alguns tipos de superfície têm efeito (visual apenas): concreto e cimento (HRD no GPS, APT 4), grama (TRF), terra (DRT), areia (SND). Os tipos cascalho (GRV) e "palha" (MAT) aparecem como um dos outros tipos, talvez porque não foram implementados ainda.
  Tentei criar textura para Mats e coloquei como Runmats.act e Runmats.raw na pasta art mas não funcionou. Por que fiz isso? Veja as texturas dos add-ons Runway, da How in the World, ou do FlyTex na pasta art (run????.raw/act); os originais do FLY estão em Startup.epd.
  Não consigo imaginar pistas de madeira ou metal, e os valores de neve, gelo, água, tratado, e estriado (grooved) devem ser adicionais, para acrescentar ao valor de um dos outros tipos de pistas; mas não há diferença visual, talvez apenas altere a aderência à pista. Testei só "água" em coordenadas no mar (inclusive com bóias no campo Markings!) e nada feito, aparece uma pista sólida no meio do mar, e nada de bóias... :(
  
  

• A condição da pista parece ter efeito: já pousei numa pista "ruim" e ficou mais difícil controlar o avião no solo. É como se houvesse óleo na pista (a opção "Ground Traction" do menu Realism deve estar ativada, acho), mas não há solavancos, não implementaram "buracos" na pista, infelizmente...
  
  

• O pavimento (que aparentemente não faz nenhum efeito na simulação) é 82, ASCII de R (rígido), ou 70, ASCII de F (flexível). Por que fizeram um campo de 32-bits pra isso? Boa pergunta.
  
  

• A direção do padrão de tráfego (ou "circuito") é ordenada pela torre de controle nas instruções de pouso; coloque L ou R.
  
  

• Embora aparentemente o PCL (pilot-controled lighting) funcione só colocando 8 no campo Lighting de airport.dbd (testei só assim e funcionou), por via das dúvidas, informe 0x1 aqui também, já que VÁRIOS registros já existentes têm esse valor preenchido. Encontrei também muitos registros com 1 no primeiro campo de RWY Light System (descrito adiante),inclusive só de uma das runways, mas sem qualquer diferença visual, nem mesmo o PCL funcionando (8 em Lighting de airport.dbd é que parece mesmo ser o "quente").
  
  

• Por fim vêm dois GRANDES conjuntos de campos, um para cada extremidade (runway) da pista (indicados mais claramente no template que modifiquei como "High RWY ..." e "Low RWY ..."). Por exemplo, para uma pista 26/08 informe os dados da runway 26 primeiro (High), e depois os dados da runway 08 (Low).
  
  

• A identificação da pista (RWY End ID) é importante: aparece no Airport Directory e no GPS, APT 4. São 3 caracteres no máximo para IDs do tipo 26L, 05C, etc. Note que provém sempre da proa MAGNÉTICA da pista. A direção real (True heading) corresponde à proa magnética + a variação magnética (indicada num campo de airport.dbd). Esta no Brasil é sempre negativa, ou seja, a direção real no Brasil é sempre "pra oeste". Exemplo: proa magnética = 350º, variação -9.8 (ou 9.8W), direção real = 340º.
  
  

• Tinha esperança de que não seria preciso informar as coordenadas das extremidades de cada pista, bastava as direções (real e magnética) mais as coordenadas "do aeroporto" (em airport.dbd) e pronto. Tentei isso e realmente o FLY coloca as pistas próximo das coordenadas do aeroporto, mas NÃO nas direções indicadas!! Além do mais, sem as coordenadas das extremidades não apenas o desenho e informações da pista não aparecerem no Airport Directory (o que impossibilita selecionar uma pista para começar a simulação direto nela), como também a pista fica "desaparecendo" em determinados ângulos e posições. Se você não sabe as coordenadas da pista (espero que o ROTAER informe, senão...), apenas "do aeroporto", pode tentar calculá-las "no olho" assim:
    - Coloque apenas as direções, deixe as coordenadas (de runway.dbd) vazias.
    - Crie novos airport.epd e runway.epd (com o DBImport ou manualmente). Isso porque as modificações em database NÃO são lidas pelo editor da TRI, ao contrário do FLY, que lê direto daí se você tiver SearchPodFilesFirst=0.
    - Com os novos EPDs na pasta system, vá para cada pista no editor (opção "Airport by Name or ID" do menu Goto). Aí, não tem jeito, você vai ter que "girar" a pista mostrada (que NÃO é disposta nas direções informadas) "no olho", movendo o cursor até as coordenadas que lhe parecerem colocar a pista nas direções corretas.
    - Anote as coordenadas das duas extremidades de cada pista informadas na janela lateral, e preencha os campos de runway.dbd com elas.
    - Vá para a pista no FLY e confira no cockpit se suas coordenadas dão a direção certa; senão, você vai ter que ajustar...
  Esse procedimento todo é um pesadelo, se alguém se dispor a escrever um programa que calcule as coordenadas a partir do "centro", da direção magnética e do raio do "círculo" (metade do comprimento da pista), vamos todos agradecer muitíssimo.
  
  

• A elevação de cada extremidade da pista parece não ter efeito atualmente, já que VÁRIAS pistas dos registros que vêm no FLY estão com 0. Richard Harvey disse no fórum da avsim que o FLY atualmente não simula pistas inclinadas, apenas pistas com mesma elevação em toda sua extensão. Talvez quando suportar (FLY 2?) estes campos venham a indicar isso.
  Se o(s) "normal tile(s)" do chão (as lajes delimitadas por quadrados brancos no editor) onde o aeroporto estiver forem inclinadas, vai acontecer da pista ficar suspensa no ar e/ou abaixo do chão em determinadas partes devido à inclinação do solo. Para resolver isto, use a opção Flatten Airports do menu Globe, depois de posicionar o editor no aeroporto certo. Esta função faz com que as lajes onde ele está sejam niveladas (a operação parece ser repetida para aeroportos próximos também).
  As alterações feitas na elevação do chão são escritas em uma ou mais pastas DXXXYYY dentro de data\ (onde XXX e YYY correspondem ao "globe tile" do aeroporto (indicado nas janelas laterais do editor). Se você está criando vários aeroportos para distribuir aos outros, precisará montar um .epd destas modificações também.
  Além disso, há o problema de as elevações do chão serem possivelmente diferentes SEM o patch de elevação, COM o patch de elevação, e ambos diferentes da elevação real (a publicada para o aeroporto). Pra resolver isso, ou seja, fazer com que o chão no lugar do aeroporto seja na elevação real, será preciso começar a aprender a colocar as elevações certas, buscar DEMs na WWW e criar os .epds com elevações de cenário (eu ainda tô longe disso).
  
  

• Displaced Threshold: indique o comprimento da área imprópria para pouso na extremidade inicial da pista. O início efetivo para pouso é então chamado LIMIAR deslocado (pra quem não souber...), e é indicado por grandes flechas pintadas de branco. O campo Threshold Elevation, como os de elevação das pistas, também não tem efeito atualmente, talvez no FLY 2...
  
  

• A seguir vem um conjunto de 7 campos sim/não (??) para os tipos de iluminação da pista. Aparentemente, basta informar qualquer coisa diferente de vazio (e diferente de 0x2, que também não funciona!), como 'S' p.e., para aquele tipo de iluminação aparecer, quando for a hora conforme o campo Lighting de airport.dbd. Registros já existentes (como os dos EUA, que devem ser os mais completos) parecem indicar que TAMBÉM é preciso colocar o número do tipo nos campos númericos Runway Light System 1 a 8 (ver adiante), mas testei sem esses códigos e mesmo assim funcionou:
    - End Lights: luzes do fim da pista, são vermelhas (parecem-me rosa) significando perigo: é aí que a pista TERMINA!! Mas são verdes quando você estiver pousando pela runway oposta, quando então indicam onde ela começa, é claro...
    - Alignment Lights: são luzes perpendiculares às luzes de aproximação (ALS, veja adiante) para ajudar o piloto conferir se ele está alinhado com a pista. Pelo que pude perceber, preencher este campo não é (atualmente) necessário já que os diferentes tipos de ALS já incluem luzes de alinhamento mesmo... (??)
    - Centerline Lights: luzes brancas de centro da pista, com um trecho vermelho no final do outro lado.
    - Touchdown Zone Lights: luzes duplas próximas às laterais, em toda a extensão da área adequada para o toque.
    - Threshold Lights: SE a pista tiver limiar deslocado (Displaced Threshold, ver campo acima), estas luzes correspondem a uma linha de 4 luzes verdes de cada lado da pista na altura do limiar, enquanto que as luzes do início da pista (na verdade, de fim da runway oposta) serão vermelhas em vez de verdes.
    - Edge Lights: não percebi diferença na intensidade das luzes laterais (ou isso não foi implementado), e não é preciso indicar este campo porque as luzes laterais vão aparecer por default.
    - Sequence Flashing Lights: pertencem aos diversos sistemas de luzes de aproximação (ALS, veja adiante); aparentemente, também não são necessárias já que os diversos sistemas (os que consegui fazer funcionar...) já "vêm" com elas.
  
  

• Markings: de todos os valores indicados no "Database Values", apenas os seguintes têm algum efeito (SÓ em pistas de asfalto/concreto):
    - 0x5 (numbers only): sem as linhas de centro, só números,
    - 0x8 (STOL): sem números, só a linha pontilhada de centro, (??)
    - 0x4 (NPIR: "Non-Precision Instrument Runway"?): números e linha pontilhada, mais marcas de pouso (grandes retângulos brancos a cada 300m mais ou menos),
    - 0x7 (PIR: "Precision Instrument Runway"??): tudo acima, mais pintura das bordas da písta, mais marcas de limiar (2 conjuntos de 4 barras brancas no limiar da pista). O trecho final das luzes laterais da pista (quando acesas) será amarelo.
  
  

• Não sei o que RVR (Runway visual range) e RVV (??) são, nem se fazem diferença, mas muitas pistas já existentes têm estes campos preenchidos.
  
  

• Os campos de Glideslope devem ser preenchidos junto com a adição ou modificação de ILSs para a pista. O Glideslope configuration (#lights) não parece ser usado em nenhum registro.
  
  

• O conjunto de 8 campos numéricos finais (Light System 1 a 8) é para indicar os códigos dos tipos de iluminação, além da pista, a iluminação de aproximação (num máximo de 8 simultaneamente). Como os tipos de iluminação da pista parecem funcionar só nos campos de caracteres já descritos acima, vou me concentrar aqui na iluminação de aproximação, embora aparentemente TODOS os registros de runway do FLY têm códigos 2 a 9 nesses campos EM ADIÇÃO aos campos de caractere anteriores...
  Somente os seguintes sistemas de iluminação de aproximação (ALS) consegui fazer funcionar isoladamente (os demais talvez funcionem em combinação com outros campos ou com os campos de caractere, ou não foram implementados ainda):
    - 10 (A/ALSF2): a mais completa e maior iluminação de aproximação, uma linha tripla de luzes ("lead-in"), a central verde e mais comprida e as laterais vermelhas (strobes), com um sequenciamento piscante ("rabbit") bastante longo.
    - 11 (A1/ALSAF/ALSF1): menor que o anterior, as linhas vermelhas laterais são bem curtas (só duas), e com faixa de alinhamento a uns 100m do limiar, mais ou menos.
    - 12 (A2/SALS/SSALF): sem estrobes vermelhos, mais curto (só 7 pontos), piscante de 4 pontos, 3 luzes por ponto.
    - 14 (A4/MALS/MALSF): igual ao anterior, só que 2 luzes por ponto.
    - 15 (A5/MALSR): o sequenciamento piscante é diferente dos dois anteriores (precede a linha "lead-in"), com 3 luzes por ponto.
    - 13 (A3/SSALR): igual ao anterior, só que com 2 luzes por ponto.
    - 42 (ODALS): linha simples de poucas luzes brancas piscando a intervalos de 1s.
    - 43 (VASI: visual approach slope indicator): 2 conjuntos de 4 luzes cada que ficam no lado esquerdo e parecem estar um acima do outro à distância: tudo branco, você está muito alto, tudo vermelho, muito baixo, branco-vermelho, você está "na rampa".
    - 46 (PVASI): como o anterior, mas um só conjunto de 4 luzes que piscam quando você estiver fora da rampa de planeio (vermelho se abaixo, branco se acima).
    - 47 (V3): 2 conjuntos de 4 luzes mas um de cada lado da pista.
    - 48 (V4/VT): um conjunto de luzes que mudam de vermelho (se abaixo) para verde (na rampa) para amarelo (se acima).
    - 50 (PAPI): VASI mais preciso, com várias gradações de "abaixo" e "acima".

         Acho que é isso. Correções, críticas, comentários, e.pad@ig.com.br (estou conferindo mais frequentemente meu e-mail mas só até final de setembro, depois disso estarei de mudança...) O ideal, se alguém souber de mais coisa ou houver erros no texto acima, é escrever adendos e erratas e disponibilizar, dizendo explicitamente a que texto se referem, porque eu não pretendo atualizar este texto, eu vou seguir adiante para explorar outras áreas. :)