Xamanian

Branding para Primo e Nextgen Pessoal, apresento um pack contendo arquivos branding.zip para Primo 2.0 e 2.4, além do Nextgen. Eles dão suporte para todas as resoluções disponíveis. Abaixo uma gif animada exemplificando os novos ícones; usou-se um Primo para Android na resolução 800x480. Os arquivos estão divididos em duas pastas: Nextgen e Primo. Estas pastas estão assim dividas: -- Nextgen 1: branding.zip para iGO Nextgen, preparado para todas as resoluções, porém o mesmo é otimizado para duas em particular: 1024x600 e 1920x1080 (full HD). -- Nextgen 2: branding.zip para iGO Nextgen, preparado para todas as resoluções, porém o mesmo é otimizado para duas em particular: 1280x720 (HD) e 2556x1440 (QHD, isto é, quad-HD). -- Android (1024x600): branding.zip para iGO Primo Android, para pacotes preparados para a resolução 1024x600, mas que usam a pasta 800_480 como base (Ultimate, Enterprise, etc.). -- Android (1280x720): branding.zip para iGO Primo Android, para pacotes preparados para a resolução 1280x720, mas que usam a pasta 800_480 como base (Ultimate, Enterprise, etc.). -- Android (1920x1080): branding.zip para iGO Primo Android, para pacotes preparados para a resolução 1920x1080, mas que usam a pasta 800_480 como base (Ultimate, Enterprise, etc.). Obs.: nos três últimos casos acima, o usuário deverá renomear as pastas para 800_480 para que funcione como o esperado. -- Android (Padrão): branding.zip para iGO Primo Android, para pacotes que foram montados usando as resoluções e pastas originais deste navegador: 320_240, 480_272, 800_480, 1024_600 e 1024_768. Por exemplo, aqueles que usam um pacote na (real) resolução 800x480, então este deve ser o arquivo escolhido. -- WinCE: branding.zip para iGO Primo WindowsCE, para ser usado em qualquer pacote baseado nas versões 2.0 e 2.4 do Primo. Este arquivo dá suporte às seguintes resoluções: 320_240, 480_234, 480_272, 800_480, 1024_600 e 1024_768. PROCEDIMENTOS PARA INSTALAÇÃO E USO: 1. Escolher um branding.zip de acordo com o navegador usado e o sistema operacional. 2. Feito isso, copiar o arquivo branding.zip para a pasta raiz do(s) pacote(s) usado(s). Antes de apagar ou substituir o branding.zip usado, fazer um backup do mesmo. 3. Entrar na pasta \save\profiles\01 e localizar o arquivo poi_visiblities.txt (no caso do Nextgen são dois arquivos: poi_visiblities_A.txt e poi_visiblities_B.txt). 4. Fazer um backup do(s) citado(s) arquivo(s) no passo 3 para logo em seguida apagá-lo(s). Este procedimento é importante, pois visa a correta exibições dos (novos) ícones de POI. 5. Configurar a exibição dos POI de acordo com a preferência pessoal. O caminho, no caso do Primo, é: Configurações => Configurações da tela de navegação => POI: pontos de interesse => na tela que se abre, em cada categoria selecionável, habilitar ou desabilitar o POI de acordo com a preferência do usuário. Obs.: aqui apresenta-se os motivos da escolha para dois branding.zip para o navegador Nextgen. O primeiro motivo é que este arquivo ainda usa arquivos de extensão .bmp ao invés do .svg, que é um padrão vetorial. No padrão vetorial, o navegador redimensional o tamanho da imagem de acordo com a resolução usada, mas de maneira transparente para o usário. Já com o uso de bmp isto não é possível, de modo que o tamanho real do ícone será aquele que aparecerá na tela de navegação. O segundo motivo é que as resoluções 1024x600 e 1280x720 usam a mesma subpasta de ícones (xhdpi), o mesmo acontecendo com as resoluções 1920x1080 e 2556x1440 (pasta xxhdpi). Em testes, a resolução 1024x600 fica melhor com ícones de 75 px, enquanto a resolução 1280x720 melhora com ícones de 80 px. Analogamente, a resolução 1920x1080 tem uma aparência melhor com ícones de 120 px, enquanto a resolução 2556x1440 se adequa melhor com ícones de 130 px. Em todas as demais pastas de ícones (para resoluções distintas), os tamanhos dos ícones são os mesmos nos dois arquivos branding.zip; somente as duas pastas citadas foram preparadas de modo distinto. Assim, dois branding.zip foram preparados para o Nextgen, de modo que o usuário deste navegador poderá selecionar o arquivo melhor lhe convier, de acordo com a resolução usada. Peço que apontem falhas, problemas, etc. Só assim conseguiremos construir algo razoável e que possa atender a todos e todas. Abraços, .XA. senha: GPS Clube Download: Branding para Primo e Nextgen.txt

Meyer, a pasta Save não pode ser compartilhada, apenas arquivos de conteúdos (mapas, POI, etc.), isto é, as subpastas da pasta \content. A pasta Save dos navegadores iGO8 e Amigo seguem um determinado padrão que é diferente dos demais navegadores. As versões 1.1 e 1.2 do Primo são baseadas no iGO8, mas já apresentando diferenças. As versões 2.0 e 2.4 do Primo muda tudo em relação as anteriores. O mesmo ocorre com o Nextgen, radicalizando ainda mais as diferenças dos arquivos internos da Save em relação ao Primo 2.4. A questão é simples de entender: a programação usada nestes navegadores é diferente em cada versão. Basicamente a pasta Save é um repositório de arquivos relacionados a configuração do navegador e as configurações personalizadas do usuário. Mas para isso o navegador, ao gravar tais informações nos arquivos, usa a forma de programação nativa de seu projeto. Por exemplo, o Primo usa a linguagem Lua e os navegadores iGO8 e Amigo, não; de modo que um navegador não consegue ler o que o outro escreveu. Sim, é possível levar as informações de um dado arquivo para outro, por conversão, mas não é possível compartilhar toda a pasta Save. Também vi os navegadores que você usa, onde, exceto o Amigo, todos os demais são pacotes baseados em Primo 2.4. Bem, nem assim é interessante compartilhar a Save (mesmo se fosse possível), pois estes pacotes foram modificações feitas, mas de tal modo que uma skin diMka, por exemplo, pode ser tão diferente de outra, que um carregamento de um navegador pode gerar problema quando outro for carregado. Exemplifico: tempos atrás, eu, Ziko e o Kadao modificamos uma diMka para exibir o número de postos de pedágio e a distância restante até o mesmo. A ideia do Ziko basicamente consistia em definir uma função com esta finalidade. Pois bem, uma determinada linha, após carregamento de uma skin com esta característica, é gravada no system.ini, que fica na pasta \save\profiles\01. Caso a Save seja compartilhada e um navegador sem uma skin com esta característica seja usada, então um comando será usado e a skin não poderá executá-lo, de modo que problemas surgirão, até mesmo um travamento. Anos atrás este tipo de problema era muito comum ao usar-se uma skin TomSoft e depois voltar para uma diMka Padrão; hoje a maioria dos problemas foram solucionados, pois adotou-se uma espécie de comunalidade entre as skins da família diMka e que foram modificadas por algumas pessoas, entre elas, eu. Por fim, sugiro no máximo usar compartilhamento das subpastas da \content, até porque o tamanho da pasta Save é muito pequeno, não economizando, na prática, espaço significativo. Abraços!

Leandro, conferi as informações na última versão do TollRates.lua e os pontos que você citou estão com os valores indicados em seu último post. São aqueles que você citou que estão errados ou os mesmos são os certos em sua avaliação? Insisto, os valores e locais indicados por você são aqueles presentes no último TollRates.lua. Abraços!

Levandoski, para que o Google funcione no Primo é necessário ter toda uma configuração pronta e, principalmente, licenças específicas para que tudo funcione corretamente. Duas licenças que sei que funcionam são: iPhone_Primo_ISR_1101__NNG__DEM__3D__PST__CAR__JV__Google__TMC___v2.1__.lyc iPhone_Primo_ISR_LITE@1203_(NNG,_DEM,_POI,_3DLM,_PST,_JV,_Google,_CAR)_(v2.1)_.lyc Acho que a licença abaixo também funciona: iPhone_Primo_Italy_13Q2_NQ_DEM_3DLM_CAR_TTS_PHO_HERE_LS_JV_v2_1_.lyc As duas primeiras contêm, nos nomes dos arquivos, a palavra "Google", indicando que estão aptas para o correto funcionamento (supondo que as configurações de sis.txt, etc. estejam ok). Já a terceira, não, mas li que funciona também. Sem as licenças corretas e sem as configurações específicas, não funciona mesmo. Não me recordo se precisa de mais alguma coisa, então não arriscarei. Sobre as licenças, não posto nada, pois isto sempre dá problema. Acredito que não terá dificuldades para obtê-las por aí. Boa sorte; abraços. .XA.

Vitalaine, tais skins citadas não emitem avisos de área de rodízio simplesmente porque as duas pessoas que criaram este recurso à época não fizeram as modificações devidas nas mesmas. Quem são as pessoas que criaram e desenvolveram o recurso de "área de rodízio"? Repondo: Adinis e Xamanian. Abraços "compreensivos". ;-)

Banksy, veja o tópico abaixo, que está em outra seção do fórum: http://gpsclube.com/forum/index.php?/topic/4213-primo-20-android-para-cm-800x480/&do=findComment&comment=47364 Abraços!

Banksy, você tem razão, naquela época eu personalizei, sob duras penas, um pacote baseado em Primo 2.0 para uma CM da M1 com Android. Posso lhe garantir que funciona corretamente e tem todas as funções que mencionou e muito mais. Ainda tenho o pacote e o mesmo está atualizado. Posso lhe enviar sim, mas precisarei de um tempo para prepará-lo, upá-lo e enviar-lhe um link. Só não vou inserir os conteúdos (mapas, POI, etc.), para diminuir o tamanho final. Porém aqui mesmo neste fórum você os encontra; talvez você já os tenha. Peço-lhe um tempinho, mas pode me cobrar se eu demorar (pode ser por MP, se preferir). Abraços.

Banksy, você está usando um Primo para Android, então o procedimento é diferente. Os arquivos de vozes, que ficam na subpasta \content\voice, em sistemas baseados em Android só têm a função de corrigir as pronúncias, não representam as vozes em si. O mecanismo de síntese de voz (TTS) deve ser selecionado nas configurações do próprio Android, o que é diferente no WinCE, onde as vozes fazem parte do pacote/navegador. Vá nas configurações de áudio do Android, selecione uma voz em português, faça o pequeno teste de áudio para ver se está tudo ok e só depois recarregue o navegador GPS para ver se está tudo ok. Caso não encontre uma voz em português em seu Android, então você terá que instalar pelo menos uma para que tudo funcione como o esperado. Os arquivos disponibilizados em post anterior só possuem as correções de pronúncias e não as vozes em si. Abraços.

Catonne, as opções que você informou estão corretas, mas isto apenas nas skins diMka, na skin padrão e GJ a situação é outra. Talvez o João esteja usando a skin padrão ou outra sem o recurso que você citou. Aí tem que usar o módulo ux mesmo, aquele que o Sherlock postou logo acima. Abraços!

Maurício, este módulo ux foi desenvolvido para usar todos os recursos para os alertas de condução disponíveis para Primo. Assim, ele emite um alerta visual através de ícones (que geralmente ficam no canto direito superior da tela de navegação, mas corrigidos para o exato padrão BR. Além do alerta visual, a ux emite um alerta por som, tipicamente um bipe ou um bipe seguido por anúncio de voz (por meio de uma TTS) sobre a natureza do alerta de condução. Eu, em particular, desabilito a TTS para estes alertas de condução, pois em estradas é muito desconfortável ficar ouvindo o tempo todo frases como "curva à esquerda", "curva acentuada à direita", etc. Ou seja, não é necessário usar uma TTS para usar o módulo ux. Em essência, este módulo ux apenas troca a tabela dos comandos presentes na skin, redefinindo os novos bmp (incluídos), além de sobrepor um arquivo do global_cfg, que está mais completo e corrigido. Todo o resto é ignorado, de modo que as mudanças não afetam os ícones em outros países, pois tudo foi feito apenas para o Brasil. Não me recordo se cheguei a fazer testes com a skin padrão na época, mas recentemente não fiz. Acredito que o módulo não dará problema com a skin padrão e funcionará corretamente, mas é preciso testar. Vou tentar fazer isso ainda hoje. Volto depois que testar. Abração! Edit: acabei de testar e funcionou com a skin padrão. No navegador/pacote que uso os ícones aparecem no canto esquerdo da tela, ao contrário das diMka. Além disso, aparece um ícone esmaecido (em cinza) avisando sobre o próximo alerta de condução, para logo após soar um bipe (nas diMka é configurável, acredito que o mesmo na skin padrão) e passar o ícone para a versão colorida. Este sistema significa o seguinte: o ícone fica cinza até que se aproxime da manobra (uma curva, por exemplo), quando soa o bipe e o ícone fica colorido, indicando "é aqui, nesse ponto". Em suma, o módulo ux também é funcional na skin padrão. Ele funciona com ou sem voz TTS.

Pessoal, o txt em anexo contém o módulo ux DriverAlert_BR atualizado e corrigido. Como dito anteriormente, seu uso exige novos ajustes nos dicionários do lang e das voices, que também seguem em conjunto. Além disso, para testes da ux, segue um global_cfg (onde a única modificação feita reside na alteração das cores das placas, de amarelo-verde para azul-verde). Caso estejam usando a versão anterior, o módulo ux deve ser retirado (fica na pasta "ux" na raiz do navegador Primo) antes de se usar o novo. Há um detalhe: o nome do arquivo anterior estava marcado erroneamente: "DriveAlert_BR.zip", ao invés de "DriverAlert_BR.zip" (isto é, falta uma letra "s" no meio do nome). Isto significa dizer que um arquivo não substituirá o outro, pois têm nomes distintos. Fiquem atentos a este detalhe e evitem ter dois módulos ux semelhantes na mesma pasta, pois isto implicará em conflitos. Antes de qualquer substituição ou inserção de novos arquivos é sugerido que se faça um backup dos arquivos antes da troca. Abraços! GPS Clube.txt

Pessoal, neste período de férias, em algumas viagens, pude notar que este módulo ux referente aos DA (Driver Alert, "alerta de condução") continha alguns problemas, Fiz esta ux por volta de 2014, logo já tem muito tempo, além de falhas previsíveis. A ideia de fazer esta simples ux devia-se ao fato de os alertas de condução (ícones e/ou bipe-voz) estarem completamente fora da realidade de nosso país. Os ícones presentes no global_cfg destinados ao Brasil estão errado, em cores diferentes (laranja no lugar do amarelo, etc.). Aí resolvi corrigir e notei que poderia fazer muito mais. O problema, que somente dias atrás pude notar, está na tabela de substituição, onde os nomes usados (em inglês) eram diferentes dos nomes originais no global_cfg. Nem é preciso muita explicação para entender as falhas... Por exemplo, "curva acentuada à direita" estava com ícone, lang e voz configurados para "curva à direita" (na primeira, a seta é quebrada, já na segunda é uma curva suave); "pista sinuosa à esquerda" estava configurado como "curva em S à esquerda", e assim por diante. Isto deixa claro que as informações que estávamos recebendo eram incorretas. A nova configuração que fiz implica em alteração em outro arquivo do global_cfg, mas ter que fazer isso a cada troca do global_cfg é chato, e em caso de esquecimento, o não funcionamento correto. Então consegui resolver esta questão também, deixando tudo no módulo ux modificado/atualizado. Mas isto implica em mudanças no lang e nas vozes. A troca pela nova ux implicará em mudanças de lang e vozes; feito isso, tudo ok. Abaixo deixo uma gif animada contendo as novas imagens e categorias corrigidas e novas habilitadas: Observo que novas categorias habilitadas, e que aparecem nas figuras acima, podem não ser exibidas, pois isso depende da informação está presente no arquivo de extensão FDA. Pode ser que um dia se torne disponível, pode ser que não; mas caso seja liberado, então o módulo ux já está preparado. Outra coisa que estou "brincando" é com a possibilidade do usuário cadastrar um "buraco na pista" como ponto de alerta, que pode ser feito com apenas alguns cliques a partir da tela de navegação, inserindo tal alerta como se fosse outro qualquer. Não sugiro a ideia de um bloco de alertas para "buracos", pois isto não teria limites, seria um arquivo maior do que o de lombadas que temos. A minha ideia e liberar uma categoria para quem quiser usar em sua região, pois buracos surgem e são tampados, sendo o conveniente deixar para cada usuário a escolha. Nas skins que uso o recurso já está habilitado e plenamente funcional. Deixo uma gif com duas figuras para vocês olharem o novo recurso (ícone de cone): Em uma das duas figuras aparece a tela para ouvir as frases ditas pela voz TTS e na outra a tela para inserir "buraco na pista" como ponto de alerta. Este é outro assunto que deve ser tratado em outro tópico, onde poderei dar os procedimentos para quem quiser modificar suas diMka. Outro assunto é um módulo ux que permite apagar os dados do computador de bordo sem ter que deletar o arquivo certo no computador. Esta última ux funciona de maneira análoga ao mesmo recurso que foi implementado nas skins TomSoft. Bem, caso haja interesse no primeiro módulo ux (DriverAlert_BR), então apresentarei links no momento oportuno. []'s

Maurício, não tenho material em mãos neste momento para dar uma olhada e lhe auxiliar de maneira específica. Logo, falarei de memória, apenas com comentários superficiais. No caso da skin padrão, seus principais arquivos estão na subpasta \ui_igo9\common\ui do data.zip; ou seja, aí estão os arquivos de programação desta skin. Já os bmp's ficam na pasta de resolução (por exemplo, 800_480), com nas diMka. Observe que na subpasta citada existem inúmeros arquivos, onde aqueles que você procura têm extensão ui ou lua. A questão é que, diferentemente das diMka, os arquivos lua desta subpasta estão criptografados, sendo impossível visualizar/editar os arquivos diretamente. Para isso será necessário descriptografar os arquivos antes, onde sugiro usar o programinha de nome "iGOLua.exe" para isso. Este programinha permite criptografar e descriptografar estes arquivos; seu uso é muito simples. Um bom ponto de partida é dar uma olhada no arquivo variable_def.ui, que não está criptografado e pode dar uma pista sobre os bipes que menciona. Por exemplo, localize este parágrafo: Nele aparece a maneira que a skin padrão adota para testar o nível do áudio de cada categoria (onde se ajusta o volume, no menu de áudio). Não sei dizer se o bipe padrão usado por esta skin parte daí, acredito que não, mas não custa procurar com mais atenção. Tipicamente, nas diMka, o arquivo é indicado no arquivo customized.lua, mas este inexiste na skin padrão. Só procurando, coisa que não consigo fazer agora (sem ferramentas adequadas) Você falou, acertadamente, que é possível ajustar os bipes através do sys.txt, mas não é apenas na skin que se encontram as demais opções de ajustes. Em geral, no arquivo igo9.ini, que fica na subpasta project_config do data.zip, também é possível fazer estas escolhas dos bipes, lá nas categorias de pontos de alerta (e de warming). Ou seja, mesmo que no sys.txt não tenha nada, pode ser que o igo9.ini existam tais configurações. Dê uma olhada nisso também. Aliás, sugiro olhar o igo9.ini antes de tentar os arquivos de programação, pois, obviamente, dá bem menos trabalho. Porém, certamente, há nestes arquivos de programação indicação do bipe a ser usado, mas não consigo falar neste momento. Ou seja, caro amigo, apenas deixo pistas para você tentar algo, já que não tenho como lhe auxiliar de maneira concreta neste momento (longe das ferramentas de edição). Grande abraço!

João, o procedimento é simples, mas requer alguns detalhes. Basicamente consiste em hospedar uma figura capturada no seu navegador GPS (esta parte também é simples, acredito que saiba como proceder) e depois usar o editor completo para inserir figura. Estou sem tempo para fazer um mini tutorial, mas tente o seguinte: 1. Hospede a(s) figura(s) que você quiser em um site específico para isso, como, por exemplo, o site https://uploaddeimagens.com.br/ 2. Finalizando a hospedagem (tem que ser figura por figura, uma de cada vez), você deve clicar com o botão direito do mouse sobre a figura e escolher "copiar o endereço da imagem" (ou coisa do tipo). Antes de voltar para o fórum, cole o link copiado da figura em nova aba do seu navegador Web e teste para ver se ela aparece corretamente (isto é, só a figura, sem propagandas, etc.). 3. Estando tudo ok, volte a tela aqui deste fórum e clique na janela responder, mas escolhendo a opção mais completa (é um botão no canto direito inferior da janelinha de respostas). 4. Na parte superior da janela que se abre, observe um botão quadrado verde. Clique sobre o mesmo e na janelinha que se abre, cole o link da figura e depois em ok. 5. Se tudo for feito corretamente, na janela em que você escreve o texto normal, aparecerá a figura já inserida; isto é, já será possível ver a figura que será postada como resposta. Se a figura não aparecer após o último passo, então algo ficou errado. Por fim, dependendo o site hospedeiro de imagens, pode acontecer de aparecerem caracteres após a extensão do arquivo de imagem, que devem ser eliminados. Especificamente: digamos que o arquivo tenha extensão .jpg. Se aparecerem caracteres depois do nome da figura e de sua extensão (isto é, no lado final do link), então estes devem ser eliminados para que a figura apareça corretamente aqui neste fórum. Não é difícil, faça alguns testes aí; qualquer coisa pergunte novamente. Abraços, .XA.

Kito, os nomes dos arquivos de extensão txt não importam, você pode usar qualquer nome que quiser. Caso mude o nome de um ou mais destes arquivos, então você deverá apagar o arquivo speedcam.spdb, que também fica na subpasta "speedcam". Isto é necessário para que o banco de dados anterior não entre em conflito. Feito isso, inicie seu navegador, que irá gerar novo arquivo speedcam.spdb e tudo funcionará normalmente. []'s .XA.

Amigo Speed Racer, terá que ser por tentativa e erro, já que o problema está surgindo em rota traçada. Vou sugerir algumas ideias para você seguir, mas não precisa ser na ordem indicada. Todo procedimento será feito no arquivo config_transforms.lua. 1. Abra o arquivo e localize a seguinte tabela (usaremos duas neste arquivo): local replace_mapinfo = { Em seguida, localize a seguinte linha (ainda na tabela indicada): {L" Jo[aã]o V ",L" João quinto "}, Acredito que você esteja usando um arquivo no qual já fiz o tratamento da seguinte linha (se ela não existir, crie!): {L" Jo[aã]o XXIII ",L" João Vinte e Três "}, Esta última linha deve estar antes da linha anterior (abaixo explicarei o motivo). Se a última linha não existir, crie uma idêntica, mas insira antes de "João quinto". 2. Agora localize o início da seguinte tabela: local replace_sentence={ A linha {L"Jo[aã]o XXIII", L"João Vinte e Três"}, deve estar inserida antes da seguinte linha (não importa se existirem outras entre estas duas): {L"Jo[aã]o V", L"João quinto"}, Observe que as duas linhas acima são parecidas com as duas linhas no item 1 acima, mas tem sutilezas no espaçamento e nas aspas. As linhas devem seguir o formato apresentado, pois cada uma das duas tabelas segue um procedimento específico. Motivo para inserir a linha "João vinte e três" antes da linha "João quinto": o Primo lê os comandos na ordem em que as linhas são apresentadas. Assim, uma linha contendo parte de um nome, mas inserida antes de outra similar, não apresentará problemas. Dou um exemplo: Na primeira tabela citada, no mesmo arquivo, tem-se o seguinte: {L" Jo[aã]o Paulo II ",L" João Paulo Segundo "}, {L" Jo[aã]o Paulo I ",L" João Paulo Primeiro "}, Se a ordem for invertida, então o Primo, via TTS, lerá o seguinte (para Paulo II): "João Paulo primeiro ih". Novo exemplo: suponha que existam as seguintes linhas (hipotéticas, claro) nesta ordem: {L" Br ",L" bê érre "}, {L" Bras. ",L" Brasileiro "}, Então a TTS leria assim: "bê érre asileiro". Hehehehe Sim, é necessário usar estes macetinhos para que as pronúncias fiquem corretas. Continuando... 3. Se as linhas já estiverem na ordem que recomendei, então o problema não está nos itens anteriores, obviamente. Uma ideia é inserir {L" Papa Jo[aã]o XXIII ",L" Papa João Vinte e Três "}, antes da linha {L" Jo[aã]o XXIII ",L" João Vinte e Três "}, da primeira tabela. O mesmo deve ser feito na segunda tabela, isto é, inserir {L"Papa Jo[aã]o XXIII", L"Papa João Vinte e Três"}, antes da linha {L"Jo[aã]o XXIII", L"João Vinte e Três"}, Este tipo de tratamento funciona com a frase toda, isto é, com o nome completo da rua/avenida. Os casos anteriores funcionam para nomes de ruas/avenidas que não aparece a expressão "Papa". 4. Se ainda não der certo, então sugiro localizar o nome da rua/avenida do jeito que aparece no arquivo de mapa. A ideia consiste em indicar no mapa o local da via e ver como aparece grafado. Falo isto porque a grafia pode estar errada e deve ser tratada no arquivo indicado da maneira que aparece no arquivo de mapa (observe que pode diferir do mapa da TT para o da Here). Além disso, configure a tela de navegação para o modo 3D e depois para o modo 2D, pois já vi grafias distintas no mesmo mapa. Se for o caso, faça o tratamento nas duas tabelas indicadas acima. 5. Outro "carinha" problemático é o arquivo de phoneme, principalmente aquele da TT. Tente remover um deles, ou ambos, e usar só o arquivo de voice para ver se o problema desaparece. No fundo isto é só um teste, mas pode ajudar ou até mesmo resolver o problema. 6. Bem, em rota traçada, a informação dada pela voz TTS é feita através do módulo ux Wiman. Pode ser que o módulo que você está usando tenha algum problema, isto é, possa estar gerando algum conflito com o arquivo de voice. Já vi isto acontecer antes com este módulo ux. Motivo: o que está nesta ux tem prioridade sobre o arquivo de voice, de modo que ele poderá distorcer algo. Também pode dar problema uma skin que tenha este módulo ux em seu interior e que está entrando em conflito com o próprio módulo ux caso este também esteja sendo usado. Por isso que sempre defendi que as skins não deve ficar recebendo muitos módulos ux em seus arquivos internos, pois a maioria não sabe destas coisas, não recebem informações para retirar este ou aquele módulo ux, mas vive tendo problemas. Sugestão: se desconfiar que está usando uma skin que já tenha a ux Wiman em seu interior, então veja se o módulo Wiman está na subpasta "ux". Basta retirar a ux, fazendo um backup antes, e testar só com a skin. 7. Por fim, sem querer desanimá-lo, informo que já tentei tratar certos nomes de vias, mas sem obter sucesso. Acredito que seja uma maneira diferente de grafar o nome da via, de modo que só "chutando" várias possibilidades para ver se dá certo. Se não for maneira de grafar o nome da via, resta supor a existência de alguma tabela que não está sendo usada, ou seja, ainda não detectada por nós. Aí é tentativa e erro mesmo. Como dito, caro amigo, as possibilidades são muitas, por isso afirmei que será tentativa e erro. Tente o que falei, mas o problema persistir, me avise para tentar ajudá-lo com outras dicas. Boa sorte! Grande abraço, .XA.

João, o Fast Ultimate é um navegador Primo modificado. Navegadores baseados em Primo não reconhecem o arquivo de extensão FJW, logo não é possível visualizar junções deste arquivo. Provavelmente você inseriu este arquivo e também aquele de extensão FJV, que é reconhecido pelo Primo. O arquivo FJW só reconhecido e é funcional em navegadores baseados no Nextgen. Você deve ter feito alguma confusão. Se este não é o caso, explique melhor o que sucedeu aí. Abraços.

Amigo d780, é exatamente isso que o Primo faz! Com as configurações sugeridas, o Primo dá um aviso por voz TTS ao se aproximar do ponto de alerta, descrevendo o tipo do ponto de alerta, a velocidade prevista e a distância. Passado o aviso por voz, o Primo mantém no canto direito inferior um alerta visual contendo um ícone que informa o tipo do ponto de alerta, uma plaquinha circular contendo a velocidade máxima associada ao ponto de alerta e, por fim, uma plaquinha retangular na parte inferior do conjunto visual que informa a distância restante até o ponto de alerta. Além disso, caso o veículo esteja acima do limite de velocidade previsto para aquele ponto de alerta, então o Primo emite bipes contínuos que só serão interrompidos caso a velocidade do veículo seja igual ou inferior àquela do ponto de alerta. Caso o veículo trafegue em velocidade inferior a do ponto de alerta, então o Primo apenas avisará por voz TTS, mas nada de bipes (ou seja, bipes apenas para indicar que a velocidade do veículo supera aquela do ponto de alerta). O Primo também permite usar voz gravada no lugar da voz TTS para avisos de pontos de alerta; não aquela voz natural para os comandos e orientação por voz, mas sim aqueles arquivos .wav ou .ogg que ficam na subpasta "audio". Não aconselho o uso deste recurso, apenas em aparelhos com muita limitação de hardware ou para aquelas pessoas que não gostam de voz TTS (são raras, mas elas existem! hehehe). Por fim, também existem algumas pessoas que gostam dos bipes mesmo abaixo do limite de velocidade do ponto de alerta (não é o meu caso). No caso do Primo, que é mais chatinho do que o iGO8 para isso, é possível habilitar estes avisos por bipe, mas isto deve ser feito através do sys.txt, editando algumas linhas naquelas 32 categorias de pontos de alerta. Tempos atrás escrevi sobre isso em outro tópico aqui no fórum, mas não me recordo mais, só que houve uma boa polêmica. hehehe Abração!

mucascosta, o Primo já dá o aviso sonoro ao ultrapassar o limite de velocidade do ponto de alerta (radar, lombadas, etc.) automaticamente. Caso queira conferir as suas configurações, basta observar estes caminhos: 1. Configurações => Sons, avisos e alertas => Configurações de voz TTS Pro => na tela que se abre, eu só deixo desmarcado as opções "Falar ações das placas de alertas de condução", "Anunciar que a velocidade já pode ser aumentada", "Falar as restrições de manobras", "Falar as ações dos botões do menu" e "Falar o status de energia". Claro que você pode habilitar tudo o que quiser, o importante é deixar as demais marcadas. 2. Configurações => Sons, avisos e alertas => Configurações de aviso de velocidade da via => na tela que se abre, em "Avisar ao exceder o limite de velocidade da via", escolha a opção "Áudio e visual". Em "Alertas visuais", na janela que se abre, marque as três opções. Em "Aviso por áudio (bipe e voz)", na tela que se abre, selecione o áudio para o bipe e o nível de volume desejado. Em "Configurações de tolerância", na tela que se abre, em "Cidade" e "Estrada", selecione +0 km/h$. No campo "Tipo", selecione "valor fixo". 3. Configurações => Sons, avisos e alertas => Configurações dos pontos de alerta => habilite "Habilitar os avisos dos pontos de alerta"; em "Perfil selecionado" deixe "Perfil 1"; em "Perfis automáticos" deixe "Desligado". Em "Distância para o aviso", na tela que se abre, selecione tudo e clique sobre cada ícone para configurar a distância para o aviso, caso deseje mudar o valor padrão. Em "Alertas visuais", na janela que se abre, selecione tudo. Em "Configurações dos alertas por voz", selecione tudo e certifique-se que sobre cada categoria aparecerá, no canto esquerdo superior, um ícone de alto-falante. Em "Bipes: ao exceder-se o limite de velocidade", na tela que se abre, selecione todos e depois clique sobre cada ícone para alterar os limites de velocidades individualmente. Neste último caso, sugiro deixar configurado do seguinte modo: Ligado; +0 km/h, volume no máximo e bipe = sua preferência pessoal. Basicamente é isso que você precisa revisar. Lembro que certas expressões usadas acima podem ser diferentes, pois depende da versão do arquivo de idiomas (lang) e de alguns detalhes, mas isso não será impeditivo, pois no fundo é muito parecido, bastando interpretar a ideia das expressões que usei e comparar com as suas. Abraços.

Tomio, você erra em suas afirmações e tem inteligência o bastante para reconhecer, só não o faz porque sempre foi um puxa-saco do Fidelis. Respeito seu ponto de vista, respeito seu puxa-saquismo, mas gostaria que fosse mais autêntico e fosse você mesmo, em sua opinião honesta e pessoal, não como um porta-voz do Fidelis, que é o que você sempre foi. Não se apequene, seja grande como merece ser. O Fidelis é um cara que respeito e admiro, ele não precisa de porta-vozes, nem advogados de suas ideias, pois é culto o bastante para se defender, sábio para se explicar. Aliás, ele não precisa explicar nada, pois raramente merece crítica ou cobrança. E você, por que precisa ser assim? Seja você você! Insisto e não é de hoje: comprei uma briga aberta com você lá no Point e foi a minha única vez, justamente por fazer defesa deste erro crasso sobre pontos de alerta. Na época cheguei a sugerir o que estava por trás deste jogo, mas um Gerente de lá me pediu para não ir além, pois queria entender o caso. Ele entendeu o caso e o fórum acabou; me deu razão. Mesmo que você seja sócio fundador do GPS Clube, não venha enganar o povo daqui, pois denunciarei e levarei tudo ao limite e até além. Seja aqui ou em instância adequadas. Estou cansado com suas hipocrisias sobre este assunto de pontos de alerta. Passar bem!!! Edit: Se apagar este post, farei o mesmo que fiz com o "dono" do GPSMirrow, insistirei em postar e respostar o mesmo texto até ser banido. Ou... Fazer com que um fórum fosse abandonado e extinto por falta de público. Esta é uma briga antiga minha e insistirei nela; saiba!

Atlan, o arquivo que se edita para mudar as cores, como você sabe, é o signpost_colors.csv, que fica no global_cfg. Ao abrir este arquivo, você verá na primeira linha o seguinte: "Country","Highway-HighwayFg","Highway-HighwayHi","Highway-HighwayBg", "Highway-ExpressFg","Highway-ExpressHi","Highway-ExpressBg", "Highway-RoadFg","Highway-RoadHi","Highway-RoadBg", "Highway-LocalFg","Highway-LocalHi","Highway-LocalBg", "NonHW-HighwayFg","NonHW-HighwayHi","NonHW-HighwayBg", "NonHW-ExpressFg","NonHW-ExpressHi","NonHW-ExpressBg", "NonHW-RoadFg","NonHW-RoadHi","NonHW-RoadBg","NonHW-LocalFg","NonHW-LocalHi","NonHW-LocalBg","Any-ChargeOrTollFg","Any-ChargeOrTollHi","Any-ChargeOrTollBg" Na linha que você inseriu em seu post tem os códigos referentes a cada uma das categorias acima, sendo o primeiro para o país e as demais cores específicas para cada uma delas. Apesar de resumidas e em inglês, é bem intuitivo imaginar ou entender o significado de cada categoria e fazer a troca de cores (em hexadecimal) para aquela desejada. Tente colar a sua linha abaixo da linha que indiquei para localizar a cor usada. Se achar melhor, tome a linha que indiquei, faça uma quebra de linha em cada categoria e cole em frente o correspondente código da cor usada. Assim a aparência ficará similar a uma tabela, que é mais fácil para determinar cada categoria. Depois é só voltar a com a(s) cor(es) alterada(s) para o arquivo signpost_colors.csv, salvar, voltar para o global_cfg e testar. Abraços!

Alipark, até onde eu sei, ninguém mudou os tipos de radares na skin padrão e nas diMka, estes tipos são originais. O que houve anos atrás foi um equívoco no entendimento sobre a classificação dos tipos, onde pensava-se que os códigos eram os mesmos do iGO8 e Amigo, o que é falso. Em relação aos pontos de alertas, os primeiros tipos, que são destinados à classe "radares" (radar fixo, radar móvel, câmera no semáforo, radar no semáforo e radar de velocidade média), tudo está ok e segue a lógica original do Primo. Aliás, a NNG, que é a desenvolvedora do iGO8/Amigo/Primo/Nextgen, só dá suporte a estes tipos de pontos de alerta (radares). Alguns outros tipos, como lombadas, túneis, passagem de nível (cruzamento com via férrea), etc., também foram mantidos nas diMka e demais skins com o mesmo padrão usado na skin padrão, para não haver conflitos. Por outro lado, como o Primo (e Nextgen) tem 32 categorias de pontos de alerta, porém muitos não usados, então há liberdade para que estes "livres" sejam usados da forma que se quiser. Aqui no Brasil adotou-se o completamento das categorias não cadastradas oficialmente (as "livres") de maneira idêntica aos modificadores/criadores de skins da Europa. Os principais modificadores de skins de tempos atrás estavam na Grécia e na Rússia e o que eles fizeram foi aqui adaptado, apenas fazendo-se traduções e no máximo modificação de ícones de pontos de alerta. Ou seja, o que aqui usamos é o mesmo que se usa na Europa, porém com ligeiras modificações, como a introdução de "altura limitada" e "área de violência" (Fidelis), S.A.U. (Serviço de Auxílio ao usuário; Sherlock, Xamanian e Akoszt), etc. Todo o resto foi mantido, mas observo que os códigos originais não foram alterados, foram mantidos. Digamos que o "vacilo" ocorreu com o tipo "radar no semáforo", que poderia ser adotado como type 2 e optou-se pelo type 11. Também não era necessário inverter os types 3 e 4 para 4 e 3, respectivamente, pois não daria erro, o Primo "daria um jeito". Para nós, para efeitos práticos, bastaria trocar os ícones e nada mais. Mas usou-se ícones feito para a Europa e que gerou dúvidas e erros. Agora o melhor é não mexer em mais nada e assumir que o que temos é o padrão. Tem funcionado bem assim e ninguém nota estas coisas na prática. Está bom assim. Abraços!

Cerberus, a coisa é mais simples do que você imagina. A categoria 5 nunca existiu no Primo, isto é, é uma categoria considerada livre. Assim, o Fidelis entendeu que a categoria 5 poderia ser ocupada normalmente, só que ele seguiu uma lógica parecida com as categorias 3 e 4, que são invertidas. A lógica é a seguinte: Cat. Real | Cat. na prática type 3 => type 4 type 4 => type 3 type 5 => type 37 Ou seja, internamente o Primo reconhece como a categoria 4, numerada nos txt de pontos de alerta, como o type 3; já a numeração marcada como 3 é reconhecida como 4 e a numeração 37 é traduzida como 5. Assim nenhum problema ocorre neste tipo de classificação.Grosso modo, há um conversor para estes primeiros type que faz com que o Primo funcione corretamente. Em relação à categoria "altura limitada", não há problema algum com o txt usar um padrão diferente dos demais, pois o type 5 é uma reprogramação feita do zero pelo Fidelis para que tudo isso seja reconhecido corretamente, isto é, ao localizar a categoria 37 no arquivo speedcam, o algoritmo já busca e utiliza as informações sobre a altura de cada ponto, mas nos demais casos este procedimento é ignorado. Cabe observar que o recurso "altura limitada" foi adaptado apenas para skins diMka e só funciona plenamente com o uso destas skins já preparadas (não são todas as diMka, apenas as "Cone" do Fidelis, as do Rafael, as modificadas pelo Xamanian a partir daquelas do Rafael, as skins do Ziko e -- acho -- que as skins do Estreante). Também é possível usar o "altura limitada" na skin padrão, fazendo ajustes no sys.txt (inserir a categoria 5) e usar ícones adaptados, mas isso não implicará na exibição da altura do ponto na tela e nem tal altura será informada por voz. Códigos: no post #4 que escrevi mais acima tem a listagem dos códigos usados pelo MapaRadar e pelo Fidelis. A única atenção que se deve ter é justamente sobre o altura limitada, que aparece como 5/37. Explico: o código 5 está inserido internamente nas diMka modificadas, já o número 37 é aquele marcado no txt de pontos de alerta específico para altura limitada. Assim sendo, tome como categoria o 37 (isto é, estou falando sobre códigos externos, aqueles que aparecem nos txt do MapaRadar e Fidelis). Lombadas: nunca otimizei e não sei se melhorará ou não. A única coisa que posso dizer é que o MapaRadar só aceita cadastramento de lombadas em rodovias, nada de cidades. Já o banco de pontos de alerta do Hélio/Fidelis aceita cadastramento de lombadas em cidades e rodovias. Não vejo problema na redundância de pontos de alerta, como lombadas, por exemplo. O grande problema é quando um usuário cadastrada uma lombada (ou outro tipo de ponto de alerta) muito próximo a um radar, digamos, fixo. Neste caso, o algoritmo interno do Primo prioriza o aviso daquele ponto de alerta que estiver mais próximo. Por exemplo, se há uma lombada a poucos metros de um radar, mas aparecendo antes, então o aviso priorizará a lombada e não haverá tempo para que o radar seja avisado. Rodando de carro por aí, pude localizar cerca de dez lugares que têm uma lombada antes de um radar; imagine isso acontecendo em todo o país! Recentemente passei por uma rodovia de pouca circulação, muito sinuosa, com três radares fixo em cerca de 15-20 km de trecho da rodovia. Pois bem, um radar não estava cadastrado, o que me levou ao MapaRadar para cadastrar (já havia um pedido, então desisti). Em um outro havia o aviso de faixa de pedestre justamente no lugar do radar; ou seja, alguém cadastrou um radar (no banco de pontos de alerta do Fidelis, pude confirmar) com o código de faixa de pedestres. No caso do MapaRadar, o usuário pede o cadastramento e a equipe verifica se aceita o pedido após verificar a existência real de um radar naquele ponto (sim, os radares são cadastrados em um banco de dados e que é público, não se permite "radar fixo escondido"). Já no método de cadastramento usado pelo Fidelis, o usuário vai em um site, lança as coordenadas, acerta a direção do ponto e seleciona a categoria do mesmo. Se algo der errado, errado ficará. O que tenho feito: usado os pontos de alerta do MapaRadar e do Fidelis (aquelas categorias ainda da época do Hélio, somente), mas retirando o txt de pedágios de ambos os bancos de pontos de alerta. Aí aparecem conflitos, como já relatei várias vezes. Então tento selecionar o ponto de alerta problemático e peço ao Primo/diMka para removê-lo. Esta informação fica guardada no arquivo de extensão .spud (que fica na pasta \content\speedcam). Depois converto este spud com a ferramenta igodb_gui desenvolvida pelo Fidelis e seleciono as informações, que passo para novo txt para que os pontos de alerta não sejam mais usados. Remover tais pontos dos txt antes de usar dá muito trabalho e entrar no site para editá-lo, pior ainda, pois já fiz isso e alguém foi lá e voltou com o erro. Desisti de colaborar. Esta é a minha crítica, muita gente mexendo e sem ter conhecimento, mas louvo a iniciativa. Abraços!

Amigo Cerberus, do banco de pontos de alerta do MapaRadar só não uso o de pedágios (desmarco este e deixo todos os demais); uso todos os outros. Já o banco de pontos de alerta do Fidelis é maior do que a listagem que coloquei no post anterior. Nesta listagem (a do post anterior), só não uso "hospital" (é um incômodo sem igual, principalmente nas grandes cidades, pois há cadastros de clínicas médicas, gabinetes médicos, etc.), todas as demais eu uso (insisto, na listagem de ontem). Por outro lado, como já comentei, tenho passado por problemas com este último bloco de pontos de alerta; na boa, tem me irritado o elevado número de ponto de alerta mal cadastrado e cheio de erro crasso. Eu sabia que tal problema ocorreria, pois água que muitos botam a mão rapidamente se torna suja. ;) Abraços!

Amigo Cerberus, Vamos por partes... As terminologias usadas pelo MapaRadar, bem como as originais do Hélio e depois do Fidelis, são: MapaRadar: - Radar fixo (1); - Radar móvel (5); - Semáforo com câmera (3); - Semáforo com radar (11); - Polícia rodoviária (17); - Pedágio (12); => Não usar caso seja utilizada a ux de postos de pedágios (Rafael) - Lombada (18); Fidelis: - Altura limitada (5/37); - área escolar (9); - Bombeiros (14); - Câmera de faixa exclusiva (7); - Crianças (19); - Curva perigosa (20); - Distrito policial (23); - Hospital (13); - Lombada (18); - Passagem de nível (6); - Pedágio (12); => Não usar caso seja utilizada a ux de postos de pedágios (Rafael) - Perímetro urbano (10); - Polícia rodoviária (17); - Trecho perigoso (31); - Túnel (21); - Via preferencial (16); - Zona de acidentes (8); - Zona violenta (30). Para aquelas pessoas que usam o módulo ux de postos de pedágio (do Rafael), é importante não selecionar/usar os arquivos txt do MapaRadar e do bloco do Fidelis que apontam para o ponto de alerta "pedágios". Sei que o Fidelis está migrando os dados corretos para o txt, mas já li aqui neste fórum o relato de vários usuários que estão tendo problemas. Enquanto isso, o melhor é não usar tais txt, apenas o arquivo TollRates.lua (e que deve ficar na pasta \content\speedcam também). Sobre as lombadas: o banco de dados do MapaRadar só aceita cadastro de lombadas em rodovias, isto é, fora de área urbana. Logo seu uso não tem problema algum. Na época do Point, houve um entendimento entre os usuários que se usasse também as lombadas em circuito urbano e por isso tal bloco foi criado pelo Hélio. Com o tempo algumas pessoas passaram a cadastrar, ou indicar cadastramento, de lombadas em circuito rural (tipicamente em rodovias) e isto passou a gerar conflitos com as lombadas do MapaRadar. Atualmente o bloco do Fidelis aceita qualquer tipo de lombada, de modo que certamente haverá conflito ou redundância com o bloco do MapaRadar. Cabe a cada um(a) decidir como proceder: aceitar a redundância com ou sem possibilidade de conflitos ou fazer uma escolha entre um dos dois blocos de dados de lombadas. Polícia rodoviária: o código do MapaRadar é 17 (Mobile Speed Camera(fixed)), o mesmo usado pelo Fidelis recentemente. Porém, na época do Hélio, esta categoria (17) não era usada, mas tentou-se o type 23, que é reconhecido em nosso país por "Posto policial" (RPS Post). Este tal "posto policial" seria indicação (como ponto de alerta) de delegacias de polícia (civil e/ou militar), cabines policiais militares, bases móveis da polícia, etc. Em sua, o type 23 era (ou é) reservado para posto policial em geral. Já aquilo que nomeamos "polícia rodoviária" (o type 17) é polícia rodoviária federal; na verdade, posto de polícia rodoviária federal ao longo das rodovias. Pois bem, com o tempo sugeriu-se (Point, bloco do Hélio) que postos de polícia rodoviária estadual (ao longo de rodovias estaduais) pudessem estar contemplados na categoria 23, diferenciando daquela (type 17) do MapaRadar. Aí virou uma confusão só... Hoje tem postos de polícia rodoviária nos dois blocos. Para piorar, o bloco (o recente, não aquele da época do Hélio) foi reclassificado para type 17, mas tem de tudo, desde posto de polícia rodoviária (federal e estadual) até delegacias de polícia e coisas do tipo. Não tenho uma opinião sobre este type, acho que virou uma bagunça só. Altura limitada e zona de violência: estes dois types são modificações significativas e que foram introduzidas pelo Fidelis (créditos a ele e somente ele). Só funcionam em skins diMka modificadas para estas categorias (as do Rafael, Xamanian, Ziko e poucas mais). Em skin padrão é possível funcionar também, mas apenas em alguns pacotes já ajustados, mas apenas com indicação visual limitada (mas com possibilidade de voz e/ou bipes). Em outras skins, nada feito. Apenas uma observação. Quantos aos erros que comentei em post anterior, insisto: falha por cadastramento de pontos de alerta de certa categoria, mas classificados como type com numeração trocada. Foi a isso que chamei de "bagunça", ou seja, algo que fica fora do controle do Fidelis, pois não dá para saber se uma pessoa digitou algo com desatenção, com falta de habilidade mesmo, ou até mesmo para "criar confusão" (e como tem gente neste meio fazendo isso...). Não é culpa do Fidelis e seus amigos que labutam e lutam para oferecer um banco de dados de pontos de alerta de elevado nível; registre-se! Abraços! PS: escrevi os types de memória (pode haver erros, espero que não). Os nomes que usei são aqueles adotados pelo MapaRadar e Fidelis; uso nomes diferentes em meu lang, mas a essência é a mesma. Só falo isso para não gerar dúvidas e/ou mal-entendidos.